Re: two requests: output tabbar and history

  • From: <tpgww@xxxxxxxxxxx>
  • To: emelfm2@xxxxxxxxxxxxx
  • Date: Wed, 19 May 2010 09:47:07 +1000

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.


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.

Other related posts: