Re: two requests: output tabbar and history
- From: Liviu Andronic <landronimirc@xxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Fri, 21 May 2010 00:38:50 +0100
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.
Other related posts:
