RE: Sorry Robert, your bugfix hasn't entirely worked.
> From: Max Bowsher > > 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) Ohhh, nice :) J. === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
Re: Sorry Robert, your bugfix hasn't entirely worked.
On Mon, 2002-11-25 at 13:09, Max Bowsher wrote:
> > Or perhaps a customisable / / . Yep,
> > options are needed :].
>
> is excessive. I'll go for boolean, or tri-state
> (none||) if you think that is a good idea.
Just use a string option:
static StringOption PrevMarker("", 'p', "prev-label", "Mark versions of
packages that are from the 'prev' trust level with the value passed");
Finito.
Rob
--
---
GPG key available at: http://users.bigpond.net.au/robertc/keys.txt.
---
signature.asc
Description: This is a digitally signed message part
Re: Sorry Robert, your bugfix hasn't entirely worked.
> On Mon, 2002-11-25 at 12:54, Max Bowsher wrote: >> OK. But 'no trust slot' still == 'older than prev', right? Robert Collins <[EMAIL PROTECTED]> wrote: > No. Just 'not in a trust slot'. > > Consider two setup.ini's. One lists: > 1.4 = prev > 1.6 = curr > the next lists > 1.4 = prev > 1.5 = curr > > Whichever becomes curr of 1.5 and 1.6, the other won't be in a trust > slot, but will still be newer than prev. Oh. I need to rethink. Probably just make 'other' a less violent colour. It's not exactly the common case. > Or perhaps a customisable / / . Yep, > options are needed :]. is excessive. I'll go for boolean, or tri-state (none||) if you think that is a good idea. >> 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? > > My 2c: Command line options, defaulting to off. OK. People can always use Windows shortcuts as their 'options store' for the short term. Max.
Re: Sorry Robert, your bugfix hasn't entirely worked.
On Mon, 2002-11-25 at 12:54, Max Bowsher wrote: > Robert Collins <[EMAIL PROTECTED]> wrote: > > 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? No. Just 'not in a trust slot'. Consider two setup.ini's. One lists: 1.4 = prev 1.6 = curr the next lists 1.4 = prev 1.5 = curr Whichever becomes curr of 1.5 and 1.6, the other won't be in a trust slot, but will still be newer than prev. > > 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. K. I don't know that we need to wait that long :}. > > I'd rather mark the version > > with , , 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. Yes. Or perhaps a customisable / / . Yep, options are needed :]. > 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. Which is on the TODO list. The package picker can decompose itself into a grid of controls. We are going there long term ;]. > 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? My 2c: Command line options, defaulting to off. Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- signature.asc Description: This is a digitally signed message part
Re: Sorry Robert, your bugfix hasn't entirely worked.
Robert Collins <[EMAIL PROTECTED]> 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 , , 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.
Re: Sorry Robert, your bugfix hasn't entirely worked.
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. 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. Secondly, for colour insensitive or colour blind folk, this may be more of an annoyance than anything else. I'd rather mark the version with , , than use colours. Thats then able to be read out by screen readers in the future, and won't play visibility games with folk. We can do both in fact - would you like to get setup to do both and resubmit? Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- signature.asc Description: This is a digitally signed message part
Re: Sorry Robert, your bugfix hasn't entirely worked.
On Mon, 2002-11-25 at 11:16, Max Bowsher wrote: > setup.exe CVS, just fetched, v2.294: > > I've got the [exp] libtool-devel and libltdl3 packages installed. I do too (now). > setup-2.294 tries to downgrade (known problem) one of the to [curr], *and > the other to [prev]*. Hmm, simpler yet, setting trust to test leaves libtool-devel at some other version. Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- signature.asc Description: This is a digitally signed message part
