Re: [RFH] QGit: how to cram a patch in a crowded screen

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/31/07, Pavel Roskin <proski@xxxxxxx> wrote:
On Wed, 2007-05-30 at 21:18 +0300, Marco Costalba wrote:
> My (crazy) idea is:
>
> - Let switch from message to diff content scrolling down after the end
> of message.
...

I'll appreciate if you follow standard conventions for standard GUI
actions and don't change the behavior of such basic keys as arrows.

It would be better to use something more advanced for application
specific behavior.  I belong to the post-vi generation, so my mind
cannot easily associate letters (like 'i' and 'k') with up and down
actions.  But we could use some key combinations with obvious
"directional meaning", such as Ctrl-arrows.

I've said it before, and it's worth repeating - any key must be
discoverable through the GUI.  No key or feature should be discovered by
accident - it would be a sign of bad design.


yes I agree with you. The only thing that until now stopped me to add
buttons to tool bar is that it seems to me already over crowded. But I
agree keys should be discoverable. Also regarding arrow keys, they
still have the same good old action to go up and down in text content,
and will keep that.


> So I imagine two labels for each content type:
>
> - for message content a top right label called "Up" and one in bottom
> right position called "Diff"
...
> I plan also to change the labels in something more intuitive with
> scroll action, as example adding an up and down direction little
> arrows next to them.

I'm afraid it would misuse the paradigm of labels.  It should be
buttons, perhaps in the toolbar.


The idea of labels comes from using gmail, where in long threads you
can see the following with a coloured label with an arrow and the name
of the sender.

The labels, used in this way and decorated with small up and down
arrows, give more the meaning of "scroll down to see what's next" then
using a button, but when yhe machinery is implemented it should be
straightforward change from labels to buttons and test also with them.


> P.S: In case someone wonders what's the goal of this label madness. It
> is to be able to browse a repo in either both sequential directions,
> up or down, using only the mouse wheel.

It may be a cool feature, but users don't expect the mouse wheel to
change anything other than position of the text.  Switching the revision
by the scrolling the wheel would be a feature discovered by accident.


Yes, this problem is still open. I think the key is the graphical
rapresentation of the labels/butons and their placement inside the
window to give the user the hint that when scrolling with the mouse
he'll reach what's advertised in the label. Again gmail use of "go to
next thread" labels gave me some ideas.


Thanks
Marco
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux