Wheelevents in combos (Re: kdelibs/kdeui)

[David Faure]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 24 October 2002 13:40, Troels Tolstrup wrote:
> On Torsdag 24 oktober 2002 12:24, David Faure wrote:
> > I don't think _anyone_ uses wheel-scroll on konqueror's location bar,
> > since any wheel operation _loads_ a page. 
> 
> What i don't understand is, why does it load a page when using the 
> scroll wheel, but not when using the arrow keys? (on a closed konq 
> location bar)
> 
> Could this be changed so it would just behave like when using the arrow 
> up/down keys?
> 
> If yes, would this not be a sensible way to handle all comboboxes?

I just investigated this, and:
* [QK]omboBox emits activated(int) as soon as the current item changes,
whether you do that with the arrows keys, the wheelmouse, or the usual open+select.

* KHistoryCombo (i.e. this is only for editable comboboxes with history handling)
has code for keyup/keydown, which sets the current edit text. Understand that
this is just as if the user had typed that item - the text is now in the lineedit,
but no activated() signal has been edited, one still needs to press Return or click Go.

Obviously KHistoryCombo - or in fact any editable combo - could use the same
trick for handling the wheel events: setting the text, as if it was typed manually.

However this doesn't solve the problem for readonly combos (or currently also
readwrite combos that don't derive KHistoryCombo) : on those, changing the
current item _must_ emit activated(), otherwise the wrong value might be 
submitted when closing the dialog or form. This is because some code might
react on slotActivated() only (quite common) ... whereas with an editable
combo the code knows it has to read the text when Ok/Submit is clicked -
the combo doesn't emit activated() at each keypress, fortunately ;-)

Conclusion:
========
I suggest that editable combos get a "wheel scrolling doesn't emit activated()" feature
(comparable to the keyup/keydown code, it sets the text),
and that readonly combos keep the current "wheel scrolling emits activated()".

There is nothing inconsistent here - those two kind of combos are different widgets
already (you can type in one, and not in the other). And user-wise, wheelscrolling
would work everywhere.

Patch:
=====
Hmm, I don't know why we have up/down only in KHistoryCombo and not in
KComboBox (when editable).... I implemented wheelscrolling using the same
code (moving it to new methods), so it's in KHistoryCombo for now. I need
Carsten's input on this I think :}
Anyway it works great where I tested it (Konqueror's combo, readonly combos
in forms). I hope it makes everyone happy finally :)

Note to testers: you need to recompile konq avec "make install" in kdeui
(so that KHistoryCombo::wheelEvent gets called).

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
Get the latest KOffice - http://download.kde.org/stable/koffice-1.2/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9uHRq72KcVAmwbhARAu+TAJ9zSqslDpuBdxw3a6v/srOPiCjJ2wCghDNl
uoB/mBQqTDXkFGGCn9rpdw4=
=FEI6
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kcombobox.diff
Type: text/x-diff
Size: 3763 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20021025/6d8a815c/attachment.diff>