1.9.2: Search box placement and size does not accont for scrollbars. about frescobaldi HOT 9 CLOSED

Hi, thanks!

On my system the search box does not cover the last lines of a document (i.e. the scrollbar accounts for it). Also appearing scrollbars do not cover the search widget. What Qt version do you use and on which OS do you see the problem?

Indeed Enter is not used by the search widget and therefore makes it to the document. The vertical arrows jump between matches (or F3 and Shift+F3). May be this can be improved. Also Ctrl-Z does change the search entries, while one would expect it would undo a replace...

from frescobaldi.

Hi,

Wilbert Berendsen a écrit :

Hi, thanks!
No problem!

On my system the search box does not cover the last lines of a document (i.e. the scrollbar accounts for it). Also appearing scrollbars do not cover the search widget. What Qt version do you use and on which OS do you see the problem?
Windows 7 64 bits, Python 2.7 (32 bits, because I could not find
precompiled 64 bits versions of all the prerequisites, namely poppler
and its qt interface, and I do not have a compiler on that machine), Qt
4.7.3.

I will need to check at work but I think the same problem occurs on my
Linux workstation (Mandriva 2010, Qt 4.7.1, everything in 64 bits).

Indeed Enter is not used by the search widget and therefore makes it to the document. The vertical arrows jump between matches (or F3 and Shift+F3). May be this can be improved. Also Ctrl-Z does change the search entries, while one would expect it would undo a replace...

Maybe making this a dialog would clarify things. It is easier to
understand from a user's point of view why events are sent to the main
window or the dialog than to sort out what is happenning when everything
is included in the main window.

Regards,
Richard.

from frescobaldi.

Hi again,

Wilbert Berendsen a écrit :

Also Ctrl-Z does change the search entries, while one would expect it would undo a replace...

Probably because it is using a QLineEdit widget. Even a one-line text
edit has standard editing keybindings, as described here:

http://developer.qt.nokia.com/doc/qt-4.7/qlineedit.html

If you want a different behaviour, it is unfortunately the programmer's
responsibility to implement it by changing the binding and, say, forward
it to the appropriate slot in the main window. In the case of the undo
it is probably as simple as having the undo() slot in the QLineEdit call
the undo() from the main window. A more complicated way would be to
either set your own event filter on the line edit, or subclass it to
rewrite the keyPressEvent(). But I do not know to what extent you can do
this through the python bindings.

(even changing the undo() slot might require to subclass the line edit
widget).

I don't think you can use inputMask or validators for this, as these
apply to the content, but do not change the bindings so if a key is
bound to an action it is, if memory serves, interpreted and never sent
to the validator.

Regards,
Richard.

from frescobaldi.

I like to avoid dialogs as they always cover the wrong part of the screen :-)

I could easily make the search widget not let any key event through to the main editor.

But the issue that it does not draw properly on your system is more important. I use the setContentsMargins() feature of QScrollArea, which should properly update the drawing of scrollbars, etc.

from frescobaldi.

Indeed, when I set Frescobaldi to the Windows style (Edit->Preferences, Gui style) I see that the scrollbars cover the search widget. Although the whole text document can be made visible. On my system the default style is Oxygen, which handles the scrollbars fine.

from frescobaldi.

Wilbert Berendsen a écrit :

Indeed, when I set Frescobaldi to the Windows style (Edit->Preferences, Gui style) I see that the scrollbars cover the search widget. Although the whole text document can be made visible. On my system the default style is Oxygen, which handles the scrollbars fine.

On Windows only the CDE or Motif styles handle the scrollbars fine. They
make frescobaldi look like a 15 years old application though...

Regards,
Richard.

from frescobaldi.

fixed in 0fa75e1, please test. I now position the widget myself, instead of relying on QLayout to do the right thing.

from frescobaldi.

Tested on linux with my default style (QtCurve, which also exhibited the problem): fixed.

Regards,
Richard.

from frescobaldi.

Great!

from frescobaldi.