Re: [ANNOUNCE] qgit new "smart browsing" feature

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

 



On 6/4/07, Andy Parkins <andyparkins@xxxxxxxxx> wrote:
On Monday 2007 June 04, Marco Costalba wrote:

> The tabbed widget is here to stay. I do not plan to remove it. But the
> tabbed widget is also slower then a well behaved scroll swicth or link
> clicking.

Ah - I've not explained myself clearly.  What I mean is _another_ tab widget,
instead of the scroll-to-switch.  It can't possibly be slower, as it's the
same amount of work for Qt...  So it would look like this (excuse rubbish
ASCII art):

 +-----------------------------+
 |                             |
 | <rev list here>             |
 |                             |
 |                             |
 +-----------------------------+
 | Log | Patch |               |
 +-----|       |---------------+
 | <diff goes here>            |
 |                             |
 +-----------------------------|

At the moment, you have a label in the top left of the text window that is
mouse-clicked to change mode; I'm suggesting replacing that with a tab widget
as above where you mouse click to change mode.  It's no more operations,
doesn't include a strange floating label and is a more standard and
recognisable user interface.

If you still wanted up and down buttons, they could very easily go to the far
right of the log|patch tabs, similar to the "close" button on the top tabs.


Andy,

 I have to say that I really like your idea!

Now I really don't know what to do!  :-)

Probably I will create a new branch called andy_gui where I'll
implement your idea, while continue to refine the current approach. As
example one enanchment I would like to implement is to keep the labels
normally hidden and show the top (bottom) one only when user scrolls
to the top (bottom) boundary of the view so that we could resolve two
issues: knowing when a scrolling action will cause a switch (i.e. only
when the corresponding label is visible) and do not have the arrows
when not needed.

Another enanchment could be to have only one link per label instead of
two and right clicking on it to show a popup menu with available
alternatives.

Of course at the end there will remain only one! The winner will be,
of course, chosen by a democratic polling among us.


Comments?


Thanks
Marco

P.S: Your approach is simple and good, the only downside is the screen
estate taken by the tab bar. But I agree it's absolutly not a biggie.
-
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