On 16.09.2009 05:48, Steve Borho wrote:
> On Tue, Sep 15, 2009 at 8:00 AM, Adrian Buehlmann <adr...@cadifra.com> wrote:
>> # HG changeset patch
>> # User Adrian Buehlmann <adr...@cadifra.com>
>> # Date 1253018428 -7200
>> # Node ID 872342294b88f713cb43b293a1a8e562772f5f87
>> # Parent f83cb2afb97e5b34d8924a9fc829a43a83c96823
>> status: put status file type checkboxes into expander
>
> Nice, this one was the keeper.
There would have been a lot more space on the right pane, but alas
I got no consensus for it (hi Sune! :), so I had to bite the bullet.
Using an expander seems the lesser evil than to continue piling them
"in the status bar", yes.
> After thinking about this some more, I would be fine with removing the
> MAR checkboxes and only having ?! and CI (two columns, two rows).
Well, it could be that *not* wanting to see the MAR files could
be useful.
For example, I can imagine just wanting to see the ignored
files can be useful to check .hgignore or something. In that case,
turning MAR's off makes sense.
It might make sense to combine them into a single MAR checkbox though
(looking at the logic behind the UI). But that would be hard to label
an layout though, since we can't just have the three characters 'MAR' as
a label alone. And if we spell it out, we take up nearly as much space
as the current solution does or we have to make up a new artificial
term that has no other bearing.
The existing labels in the expander also serve as a help index that
lists all the typecodes ('MAR?!CI') together with their meanings spelled
out ('modified', 'added', 'removed', ...). This is useful for
the newbies and even for the moderately experienced users it is
helpful. After all, these typcodes are used in the table right above.
> repo.status() does not even give you the option of *not* getting MAR
> files, so there's no benefit in not asking for them.
That might be true, but there might be a benefit not wanting to
show them, maybe at least temporarily.
> Those checkboxes
> are vestiges of the original gstatus command that wanted to be 100%
> command line compliant with normal status. It's not so important for
> hgtk st and ci.
I don't think that mimicking the command line is the point here.
But thanks for writing these thoughts, I will think about them.
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Tortoisehg-develop mailing list
Tortoisehg-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
