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: