On 5/20/10, tpgww@xxxxxxxxxxx <tpgww@xxxxxxxxxxx> wrote: > I'm not sure what you mean. What exactly is not updated? Here I'm seeing > behaviour I would expect. > Oh, nothing, really. Gremlins, I think. Although in specific instances I get strange behaviour, such as no GTK c-menu when right-clicking on an input area. I'll hunt a debug on that. > <shift> + home and backspace, and only > > then I type my command. > You can press <Control><Delete> any time that a combobox entry is focused, to > clear its current content. > Nice, I wasn't aware of this. > > - when "cyclic list" is disabled, do not allow to immediately access > > the last item in list by pressing <up>. > That behaviour is one of the 2 essential purposes of cyclic history lists. If > you want otherwise, disable the option. > I probably wasn't very explicit. When "cyclic list" is enabled, the user can immediately use <up>/<down> to access the last/first item in the list. This is as expected. When "cyclic list" is disabled, the user can still immediately use <up>/<down> to access the last/first item in the list. This is unexpected behaviour. It would be more intuitive if the user could immediately only use <down> to access the first item in the list. Regards Liviu > This would conform to the > > logic of the recently introduced wheel-scrolling behaviour > > - integrate the "clear button" into the input entry widget. For > > example, see the attached shot of the implementation in Geany. This > > would allow to free up space on the "command line toolbar" and remove > > the ambiguity of the two "clear" pane and command line buttons > > (personally I'm never quite sure which one to press). > > > No net gain in screen real-estate - it merely moves it from one spot to > another. And prevents that part of the UI from being user-configurable (as > the in-entry icon would have to be hard-coded). In-entry icons/actions are, > IMHO, for situations where there is no suitable toolbar, such as the screenie > you posted. > > The output-pane related buttons, including the one for clearing, are (unless > you changed the default) grouped to the left of the commands combobox. Hence > the other clear button is for the commands. > > > It would be > > useful in other places, too. > > > Given our ideal of making things doable by either mouse or keyboard, and > since <Control><Delete> is always available, it's arguable that entries for > comboboxes in dialogs should have an embedded 'clear' icon. Against this, the > small risk that the user prefers some icon other than cl_clear_48.png, for > clearing, the loss of space within the entry, and the extra code. > > > 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. > -- Do you know how to read? http://www.alienetworks.com/srtest.cfm http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader Do you know how to write? http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail -- 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.