On 21/12/2008 20:17, Tommaso Cucinotta wrote:
Pavel Sanda ha scritto:
its in.
p
Thanks.
Also, please, find attached a UI patch that:
- solves some issues related to the dialog set-up
(overlapping of dialog title with upper sub-widget),
by "borrowing" the widget structure from
ViewSource.{h,cpp}
Not sure about that but OK.
- reduces the default occupation of the dialog (in particular,
it was "colliding" with the ViewSource itself);
OK.
- proposes to introduce a tabbed-panel in the F&R
dialog, so as to have a "basic" and "advanced" tabs;
(one option could be to make the dialog even smaller
by moving all of the replace-related stuff into a separate
"Replace" tab)
Too complicated IMHO. I'd rather see a simple 'Advanced' button that
will 'uncollapse' or 'uinhide' a child window with Regexp stuff etc. In
any case, as long as we use a dock widget we have a lot of room here.
- recovers the eventFilter functionality back, so as to catch
"Enter" or "Esc" key presses while in the Search Work Area
Well, I explicitly got rid of this thanks to the initialiseParams()
method which takes care of focus. Your patch is undoing that.
About the Enter key catching, I am not sure this is desired as one may
want to search for multiple lines text. I'd be OK with alt+Return though...
About the Esc key, maybe...
Unfortunately, in the current trunk, it seems we have still
the focus issue on F&R dialog show, I can't remember if it
had been fixed previously. Also, now the trick of calling
find_work_area_->setFocus() right after a find operation
does not manage to give the focus to the findWorkArea
itself back anymore.
Probably, these focusing issues may be related to the comment
someone (Abdel ?) placed in F&R.cpp:
// FIXME: create a Dialog::returnFocus() or something instead of this:
view_.setCurrentWorkArea(view_.currentMainWorkArea());
which I can't actually comprehend, as of now.
I have to go back and read the code in order to understand what I meant,
but I can't for the time being :-(
About your patch, I think we have too choices:
1) You split up your patch in smaller patches so that we can apply them
on per fix or per feature iteration.
2) You manage to get svn access so that you can commit the
uncontroversal parts of your patch yourself.
In any case I (we) don't want to loose you as a developper so please
take my comments lightly and don't be turned off by them.
Abdel.
