On Tue, 18 May 2010 08:55:26 +0100 Liviu Andronic <landronimirc@xxxxxxxxx> wrote: > On 5/18/10, tpgww@xxxxxxxxxxx <tpgww@xxxxxxxxxxx> wrote: > > It's easy enough to detect scrolling (actually, converted to button 4..7 > > press(es)). However what to do with it? We could pop up/down the list of > > history-items, but I see no real benefit in that. We can't access the > > treeview which shows the list, to manage a change of selection there. > > > I'm thinking of something similar to what I currently see in > file.owners. Strangely enough, since other similar input boxes do not > behave the same, using the scroll-wheel on the input box makes it > scroll the list of available owners. (In that particular dialogue, > actually a bug seems to be lurking: if you wheel-scroll on the second > input box, "cancel" is activated and the dialogue is closed.) Would it > be possible to make all such boxes behave the same, bar the bug of Strange indeed. There's nothing in emelfm2 which makes this happen. It looks to me like a gtk bug. At risk of getting too technical, scroll-wheel movement improperly causes (among other things) an "activate" signal to be issued. Just like pressing <Enter>. In the user combo, that signal skips focus to group, and there, the activation closes the dialog and applies whatever is then current in the combos. Bad. I'll try to find a workaround. Regards Tom -- Users can unsubscribe from the list by sending email to emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by logging into the web interface.