Sorry Robert, your bugfix hasn't entirely worked.

[Max Bowsher]

Robert Collins <rbcollins@cygwin.com> wrote:

> On Mon, 2002-11-25 at 11:16, Max Bowsher wrote:
>
>> PS: Attached is a patch which colour-codes version numbers in setup.
>> Obviously its going to require much discussion before checkin, but
>> it is what allowed me to notice the bug so easily.
>>
>> The colour code is:
>> Dark Blue:    [curr]
>> Cyan:    [prev]
>> Yellow-Brown: [prev]
>> Red:    not in setup.ini at all. (i.e. ancient)
>
> Ok, concept wise, I'm ok but not enthusiastic.

Sure - it was really a "this might help with debugging the current
versioning problems" and a "here's what I'm thinking about", rather than a
"let's commit this".

> Firstly, not having a
> trust level, does not mean not in setup.ini at all.
>
> With merged setup.ini's, version skew can occur between the ini files,
> and there are only three trust slots. Thus the sorted list of versions
> to iterate through.

OK. But 'no trust slot' still == 'older than prev', right?

> Secondly, for colour insensitive or colour blind folk, this may be
> more of an annoyance than anything else.

I know. I don't think this can go in to setup until we have some kind of
option persistense framework.

> I'd rather mark the version
> with <prev>, <curr>, <test> than use colours.

This would make resizability even more pressing by taking up precious
pixels.
So, I think this depends on an options framework as well.

> Thats then able to be
> read out by screen readers in the future,

Unless the screen reader OCRs the text off the screen, its going to have
trouble making sense of a custom control like the package picker.

> and won't play visibility
> games with folk.

Yes, important.

> We can do both in fact - would you like to get setup
> to do both and resubmit?

Do you think I should put this on hold until we have an options store, or
just add some temporary command line options to control it in the meantime?

Max.