Re: two requests: output tabbar and history
- From: <tpgww@xxxxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Thu, 20 May 2010 19:24:49 +1000
On Thu, 20 May 2010 09:22:23 +0100
Liviu Andronic <landronimirc@xxxxxxxxx> wrote:
> I just tried out r2092, and it all seems very nice now. There is
> however an issue in the file.owners dialogue: to replicate, click for
> example on the user entry (here, 'liviu') and then try scrolling the
> group entry. The second entry will be scrolled accordingly, but the
> screen will get updated only when clicking on the group entry.
I'm not sure what you mean. What exactly is not updated? Here I'm seeing
behaviour I would expect.
>
> I also have several minor ideas that could polish the UI:
> - always keep an empty line in the lists (command interpreter, user
> input, etc.) It often happens to start scrolling the history list for
> a useful line, but realise that the command is no longer in history.
> In such cases I always go back to the first item ("cyclic list"
> disabled) assuming that I will get back to the empty line, then
> discover that there is no such,
Can I gently suggest that you remember :-)
<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.
An empty line would would benefit cyclic
> lists, too, allowing to understand where it starts and where it ends.
> - 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.
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.
Other related posts:
