Hello Tom
On 5/20/10, tpgww@xxxxxxxxxxx <tpgww@xxxxxxxxxxx> wrote:
> It seems that active management of gtk's scroll-events blocks the
> inappropriate behaviour to which I referred. So now, those events (typically,
> rotation of a mouse-wheel) which happen in a combobox entry cause that
> entry's active (and displayed) item to correspondingly move up or down the
> combobox history, if any. If a <Ctrl> key is pressed at the time, it changes
> to the top or bottom of the history. Note that the text shown in filelist
> comboboxes is not necessarily in the corresponding history (if it is there,
> it will shown in colored text). If not in the history, scrolling down will
> still work as described, but upward has nowhere to go.
>
> The change of active item does not activate the item, of course. For that
> you still need to press <Enter>, or double-click in the entry, or click some
> related button elsewhere in the UI.
>
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 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, <shift> + home and backspace, and only
then I type my command. 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>. 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). It would be
useful in other places, too.
Let me know what you think. Regards
Liviu
Attachment:
17.png
Description: PNG image
