RE: prev/curr/test
> -Original Message- > From: David A. Cobb [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 28, 2002 4:04 AM > A thought: mandate that every package tarball contain a > standard-named > install script - similar in concept to the Micro$quash > setup.inf. Then > simply keeping the old tarball would supply the user the mechanism to > drop back to that version. It's simpler than that... allow command line package file selection. setup -i foo.tar.bz2 Rob
Re: prev/curr/test
Christopher Faylor wrote: >On Mon, Mar 25, 2002 at 08:27:04PM -0500, Brian Keener wrote: > >You don't. You find some other method for reverting to software that >is <1 revision old. This is not a hardship. AFAIK, setup has never >allowed you to do more than prev/curr/test. > A thought: mandate that every package tarball contain a standard-named install script - similar in concept to the Micro$quash setup.inf. Then simply keeping the old tarball would supply the user the mechanism to drop back to that version. > >>I like the simpler approach for sure but let my option I select tell me >>everything - don't give me 4 different buttons and umpteen combinations >>to choose from to get where I want to be - talk about confusing. >> > >And how do you know when you've hit the current version? You see it >scroll by and remember that you want "1.4.9-1 bin" and then click the >mouse ten more times to get back to that. That's really not user >friendly, IMO. > >cgf > -- David A. Cobb, Software Engineer, Public Access Advocate "By God's Grace I am a Christian man, by my actions a great sinner." -- The Way of a Pilgrim; R. M. French, tr. Life is too short to tolerate crappy software. .
Re: prev/curr/test
Brian Keener wrote: >Christopher Faylor wrote: > >>evil and should be abolished. The only way to get old versions >>should be at a macro level. You click a button and get all of >>the old stuff, you click another button and get all of the current >>stuff, you click another button to get all of the test stuff. >> >>I think that Robert is right that if you click on test you should >>only get packages that have test versions. Ditto for prev. Ditto >>for curr. >> > >Sorry guys, > >I still like the idea of keeping Prev,Curr and Test but as a means of limiting >the maximum version I want to see - IE if I didn't select Test I won't see any >test but I will see prev and Current. > >Then I suggest we do away with the Source Box and nix the idea of a bin box and >simply use the clickable version and within the version we have such entities >as the following (assume the version installed is 1.4.3 and there is a current >of 1.4.4 and I have curr selected on the radio buttons): > Nah! I found the source/bin boxes a great addition. My problem with the spinner-only selection was that sometimes I had to run around the cycle once to see what versions were available. >keep/skip (obviously skip if nothing were installed), uninstall (would only >exist if package installed), 1.4.4 bin&src, 1.4.4 bin, 1.4.4 src, reinstall >bin&src (would reinstall both for 1.4.3), reinstall bin (reinstall bin for >1.4.3), reinstall src (reinstall src for 1.4.3), retrieve bin&src (retrieves >installed bin and src), retrieve bin (retrieves installed bin), retrieve src >(retrieves installed src), retrieve 1.4.4 bin&src ... > Looks far to complex for me as a simple-minded user While we're chewing on this, consider an easy (one-click) way to obtain all "new" packages; i.e. the one's that are now marked "Skip" and for which I have to do a manual hunt now. Again, a very personal opinion: I would rather simply have Prev(_) Curr(_) Test(_) selections for each package. Normally, I don't much care what the revision string is. > > >The retrieve options would be available as opposed to the reinstall or install >options if we were doing a download only as opposed to an install. As an added >goody as part of the text for each option you add if it is the prev, curr, >test, or just on that is available. > >I originally posted this idea in a discussion with Rob on March 5 - but is sort >of died with the thread as the message. So I'll try again. Just an alternate >thought. > >bk > > > -- David A. Cobb, Software Engineer, Public Access Advocate "By God's Grace I am a Christian man, by my actions a great sinner." -- The Way of a Pilgrim; R. M. French, tr. Life is too short to tolerate crappy software. .
RE: Setup/prev/curr/test/metapackages/another screen/etc
> -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 27, 2002 3:40 PM > It's an interesting idea but I don't like glumping what used > to be prev/curr/test with the concept of packages or meta > packages. You lose some functionality that way. Yes. > I really wish we had never even come up with the concept of > prev/curr/test. Maybe the prev release should be a > completely separate release, ditto test. Yes. This is how I've been suggesting they get managed for a while now. Not to the same extent of separation that debian has, but separate. > test/latest > test/contrib > > curr/latest > curr/contrib > > prev/latest > prev/contrib I think that the file locations are orthogonal to the versions considered 'active' in test/curr/prev. Debian (to use the old example), once had fully separate directories, but changed to be a single directory structure, with separate indexes - and those indexes are ~= setup.ini. Rob
Re: Setup/prev/curr/test/metapackages/another screen/etc
On Tue, Mar 26, 2002 at 10:22:27PM -0600, Gary R. Van Sickle wrote: >How about this. Replace the current "prev/curr/test" radio buttons with a >drop-down list box containing not "metapackages" but "installation templates", >with names like: > >Workstation >Heavy-Duty Workstation >Server >Bare Bones Setup >Bleeding Edge >Maintenance > >Everything else stays the same. Selection of one of the "templates" sets the >suggested installs/uninstalls/whatever, but then you can change them however you >want just like it is now. After the initial installation, it defaults to >"Maintenance", which sets things to update whatever you already have to the >latest version, but not add or subtract anything. If you initially did a >"Server" install and try switching to say a "Workstation" install, maybe it >gives you a warning box before it uninstalls half your stuff. It's an interesting idea but I don't like glumping what used to be prev/curr/test with the concept of packages or meta packages. You lose some functionality that way. I really wish we had never even come up with the concept of prev/curr/test. Maybe the prev release should be a completely separate release, ditto test. You choose it early on in the setup process and have setup.exe select from. test/latest test/contrib curr/latest curr/contrib prev/latest prev/contrib I know this doesn't allow one to go back 47 revisions but, er, um I think I've already weighed in on that one. cgf
Setup/prev/curr/test/metapackages/another screen/etc
How about this. Replace the current "prev/curr/test" radio buttons with a drop-down list box containing not "metapackages" but "installation templates", with names like: Workstation Heavy-Duty Workstation Server Bare Bones Setup Bleeding Edge Maintenance Everything else stays the same. Selection of one of the "templates" sets the suggested installs/uninstalls/whatever, but then you can change them however you want just like it is now. After the initial installation, it defaults to "Maintenance", which sets things to update whatever you already have to the latest version, but not add or subtract anything. If you initially did a "Server" install and try switching to say a "Workstation" install, maybe it gives you a warning box before it uninstalls half your stuff. No new screens, everybody's happy and less confused. -- Gary R. Van Sickle Brewer. Patriot.
RE: prev/curr/test
> -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 27, 2002 12:29 AM > To: [EMAIL PROTECTED] > Subject: Re: prev/curr/test > > > On Wed, Mar 27, 2002 at 12:01:11AM +1100, Robert Collins wrote: > >cgf wrote: > >> Ok. So, this is recent then. It certainly never allowed it > >> prior to this. > > > >It -sortof- did. If you *don't have* a setup.ini, then it > scanned for > >everything.. > > I wrote the code. I know what it did. There were only three > buckets to put things in. You couldn't go back to revision n > - 57 to get older revisions. I'm not sure why we're arguing > about this. Yes. Sorry - I wasn't meaning to argue per se. Rob
Re: prev/curr/test
On Wed, Mar 27, 2002 at 12:01:11AM +1100, Robert Collins wrote: >cgf wrote: >> Ok. So, this is recent then. It certainly never allowed it >> prior to this. > >It -sortof- did. If you *don't have* a setup.ini, then it scanned for >everything.. I wrote the code. I know what it did. There were only three buckets to put things in. You couldn't go back to revision n - 57 to get older revisions. I'm not sure why we're arguing about this. cgf
RE: prev/curr/test
> -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 26, 2002 11:54 PM > To: [EMAIL PROTECTED] > Subject: Re: prev/curr/test > > > On Tue, Mar 26, 2002 at 07:27:57PM +1100, Robert Collins wrote: > >> You don't. You find some other method for reverting to > >> software that is <1 revision old. This is not a hardship. > >> AFAIK, setup has never allowed you to do more than prev/curr/test. > > > >Not from the net. It does locally though FWIW. > > Ok. So, this is recent then. It certainly never allowed it > prior to this. It -sortof- did. If you *don't have* a setup.ini, then it scanned for everything.. It became a lottery what was visible. Rob
Re: prev/curr/test
On Tue, Mar 26, 2002 at 07:27:57PM +1100, Robert Collins wrote: >> You don't. You find some other method for reverting to >> software that is <1 revision old. This is not a hardship. >> AFAIK, setup has never allowed you to do more than prev/curr/test. > >Not from the net. It does locally though FWIW. Ok. So, this is recent then. It certainly never allowed it prior to this. cgf
RE: prev/curr/test
> -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 26, 2002 1:09 PM > >But a big deal at one point in time was the ability to get to > >packages/versions that were in the local directory and > install those - > >how else can you do this if you limit your self to prev, curr, and > >test. > > I don't know who this was a big deal for. It isn't for me; > especially if we would be confusing the people who want to > use setup.exe for its normal use at the expense of people who > have additional requirements. Someone somewhere got bitten by an upgrade IIRC. Certainly it's not the key focus of setup. And once setup is command line driven, this should be less of an issue: if you know that you want version foo, just ask for it. > I think the whole cycling through versions thing was a big > mistake. I don't know of any other setup utility that allows > this kind of thing. Heck, I believe that you actually need to > specify a different repository entirely if you want to > install non-current packages in debian. > > Is this correct, Robert? Yes. Well kinda. Debian's automatic system - apt and dselect - only allow grabbing the most recent version, or staying on your current version. They then have three parallel distributions, one Stable, one Testing, and one Unstable. Stable -never- breaks, Testing make break, and Unstable... well it's your risk. For a given machine, you typically only ever point apt at one distribution. > You don't. You find some other method for reverting to > software that is <1 revision old. This is not a hardship. > AFAIK, setup has never allowed you to do more than prev/curr/test. Not from the net. It does locally though FWIW. > And how do you know when you've hit the current version? You > see it scroll by and remember that you want "1.4.9-1 bin" and > then click the mouse ten more times to get back to that. > That's really not user friendly, IMO. Exactly. Rob
Re: prev/curr/test
On Mon, Mar 25, 2002 at 08:27:04PM -0500, Brian Keener wrote: >Christopher Faylor wrote: >>Sorry, but I really don't like this. Adding a whole bunch of new >>things for a user to cycle through (or even select from a pulldown) is >>moving in the wrong direction, IMO. > >But a big deal at one point in time was the ability to get to >packages/versions that were in the local directory and install those - >how else can you do this if you limit your self to prev, curr, and >test. I don't know who this was a big deal for. It isn't for me; especially if we would be confusing the people who want to use setup.exe for its normal use at the expense of people who have additional requirements. I think the whole cycling through versions thing was a big mistake. I don't know of any other setup utility that allows this kind of thing. Heck, I believe that you actually need to specify a different repository entirely if you want to install non-current packages in debian. Is this correct, Robert? >What if the current setup.ini has a prev version and a current version >but I still have the one prior to the prev version and it was right the >two most recent are wrong and I want to roll back to it - How do I do >this under you folks way of thinking. You don't. You find some other method for reverting to software that is <1 revision old. This is not a hardship. AFAIK, setup has never allowed you to do more than prev/curr/test. >I like the simpler approach for sure but let my option I select tell me >everything - don't give me 4 different buttons and umpteen combinations >to choose from to get where I want to be - talk about confusing. And how do you know when you've hit the current version? You see it scroll by and remember that you want "1.4.9-1 bin" and then click the mouse ten more times to get back to that. That's really not user friendly, IMO. cgf
Re: prev/curr/test
Um. Could you guys stop Cc'ing me, please. I don't know how my name got on the Cc list but please remove it. I set the Reply-To for a reason. cgf
RE: prev/curr/test
> -Original Message- > From: Brian Keener [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 26, 2002 12:02 PM > Sorry guys, > > I still like the idea of keeping Prev,Curr and Test but as a > means of limiting > the maximum version I want to see - IE if I didn't select > Test I won't see any > test but I will see prev and Current. That's an approach that could be taken. I think it will confuse people more: "Jason said a new postgresql was available, but I can't see it". That's just my 2c of course. > Then I suggest we do away with the Source Box and nix the > idea of a bin box and ... > (retrieves installed src), retrieve 1.4.4 bin&src ... Ouch. I'm going to put my iron-fisted maintainer hat on here: There is no way that GUI code structed like that is going into setup.exe for the following reasons: 1) That increases the number of clicks to install a given version by 2 to 3 times. 2) It is no more nor less clear than what we have. 3) We started off with that sort of approach... and it does not work well. Modal design - which that is an extreme example of - is easy to pick up and use, but almost impossible to use fast or effectively. Look back in the mailing lists, the majority of the pre-categories questions where about "why is it so *hard* to get setup to do what I want to". Not "How do I get setup to do what I want". While your suggestion solves the current "how do I" questions, it does so by reverting to the "why is it so hard" behaviour. I think we are a little hard to use, and that needs to change, but not by swinging all the way back. And please note: you actually have *two* proposals (1- curr and test limit to become upper limits on whats visible and 2- have a click-forever approach) here. It would probably help your case to address them separately. Rob
Re: prev/curr/test
Christopher Faylor wrote: > Sorry, but I really don't like this. Adding a whole bunch of new things > for a user to cycle through (or even select from a pulldown) is moving > in the wrong direction, IMO. But a big deal at one point in time was the ability to get to packages/versions that were in the local directory and install those - how else can you do this if you limit your self to prev, curr, and test. What if the current setup.ini has a prev version and a current version but I still have the one prior to the prev version and it was right the two most recent are wrong and I want to roll back to it - How do I do this under you folks way of thinking. I like the simpler approach for sure but let my option I select tell me everything - don't give me 4 different buttons and umpteen combinations to choose from to get where I want to be - talk about confusing. Just my thoughts and .02 worth.
RE: prev/curr/test
> -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 26, 2002 12:02 PM > To: [EMAIL PROTECTED] > Subject: Re: prev/curr/test > > > >> And when you just don't want a package? What do you click to > >> get the equivalent of skip? > > > >Don't click either? In this example perhaps the bin column should be > >labelled "install". > > But, if I make a mistake, my ability to correct it is > somewhat hampered unless we tri-state the box. so don't make mistakes ? :}. > >Ahh, so if you don't want to update you can stay put. Hmm. > What about > >[X] - install [H] - hold > >[ ] - uninstall > > > >I know, it's heading back to the circular clicking thing :[. > > Yeah. Or we could do a radio button triplet - Binary Install Hold (don't change at all) Uninstall (or skip if not installed) = (*)()() > How does it remove that? Click on the install next to a > package name (All in this case). I must be confused. I thought that of the layout: prev/curr/test bin src package version [] [] description ... that only the bin and src and prev/curr/test would be clickable. Categories wouldn't change, but they don't allow specific version selection anyway. Are you suggesting that version be clickable as well? In which case I don't see how it's different from what we have today (barring the removal of reinstall). > >It would remove the need for the state machine code, but > that is very > >stable now anyway (see package_meta if you are interested). > > It wasn't all *that* unstable when I left it (except for the > auto uninstall thing which people are still reporting, > apparently). I just think the idea of states is needlessly > complicated. Which is why it got removed :}. My phrase above 'state machine code' was actually inaccurate - I should have said 'version selection code'. There isn't any state machine per se anymore, simply a collection of versions, and bin/src selection. Rob
Re: prev/curr/test
On Mon, Mar 25, 2002 at 08:02:17PM -0500, Brian Keener wrote: >Christopher Faylor wrote: >>evil and should be abolished. The only way to get old versions should >>be at a macro level. You click a button and get all of the old stuff, >>you click another button and get all of the current stuff, you click >>another button to get all of the test stuff. >> >>I think that Robert is right that if you click on test you should only >>get packages that have test versions. Ditto for prev. Ditto for curr. > >Sorry guys, > >I still like the idea of keeping Prev,Curr and Test but as a means of >limiting the maximum version I want to see - IE if I didn't select Test >I won't see any test but I will see prev and Current. > >Then I suggest we do away with the Source Box and nix the idea of a bin >box and simply use the clickable version and within the version we have >such entities as the following (assume the version installed is 1.4.3 >and there is a current of 1.4.4 and I have curr selected on the radio >buttons): I really think that cycling behavior of the current setup is a major source of confusion for most people. >keep/skip (obviously skip if nothing were installed), uninstall (would >only exist if package installed), 1.4.4 bin&src, 1.4.4 bin, 1.4.4 src, >reinstall bin&src (would reinstall both for 1.4.3), reinstall bin >(reinstall bin for 1.4.3), reinstall src (reinstall src for 1.4.3), >retrieve bin&src (retrieves installed bin and src), retrieve bin >(retrieves installed bin), retrieve src (retrieves installed src), >retrieve 1.4.4 bin&src ... Sorry, but I really don't like this. Adding a whole bunch of new things for a user to cycle through (or even select from a pulldown) is moving in the wrong direction, IMO. cgf
Re: prev/curr/test
Christopher Faylor wrote: > evil and should be abolished. The only way to get old versions > should be at a macro level. You click a button and get all of > the old stuff, you click another button and get all of the current > stuff, you click another button to get all of the test stuff. > > I think that Robert is right that if you click on test you should > only get packages that have test versions. Ditto for prev. Ditto > for curr. Sorry guys, I still like the idea of keeping Prev,Curr and Test but as a means of limiting the maximum version I want to see - IE if I didn't select Test I won't see any test but I will see prev and Current. Then I suggest we do away with the Source Box and nix the idea of a bin box and simply use the clickable version and within the version we have such entities as the following (assume the version installed is 1.4.3 and there is a current of 1.4.4 and I have curr selected on the radio buttons): keep/skip (obviously skip if nothing were installed), uninstall (would only exist if package installed), 1.4.4 bin&src, 1.4.4 bin, 1.4.4 src, reinstall bin&src (would reinstall both for 1.4.3), reinstall bin (reinstall bin for 1.4.3), reinstall src (reinstall src for 1.4.3), retrieve bin&src (retrieves installed bin and src), retrieve bin (retrieves installed bin), retrieve src (retrieves installed src), retrieve 1.4.4 bin&src ... The retrieve options would be available as opposed to the reinstall or install options if we were doing a download only as opposed to an install. As an added goody as part of the text for each option you add if it is the prev, curr, test, or just on that is available. I originally posted this idea in a discussion with Rob on March 5 - but is sort of died with the thread as the message. So I'll try again. Just an alternate thought. bk
Re: prev/curr/test
On Tue, Mar 26, 2002 at 11:31:22AM +1100, Robert Collins wrote: >> >Tick Bin to install foo. Untick Bin to remove foo. Tick Source to >> >trigger a download of the source (download only mode) or extraction >> >(install from x mode). >> >> And when you just don't want a package? What do you click to >> get the equivalent of skip? > >Don't click either? In this example perhaps the bin column should be >labelled "install". But, if I make a mistake, my ability to correct it is somewhat hampered unless we tri-state the box. (Hey I verbed something) >> Given your above comments, I think we still need another >> clickable "thing" next to the Bin/Source, unless you have >> some way of getting the equivalent of a "skip/keep". > >Ahh, so if you don't want to update you can stay put. Hmm. What about >[X] - install >[H] - hold >[ ] - uninstall > >I know, it's heading back to the circular clicking thing :[. Yeah. >> >However, I think some folk will want the current interface, >> so perhaps >> >we offer a 'basic' and 'advanced' download of setup, or a [Advanced] >> >button somewhere on the chooser. (To start with I'd suggest two >> >downloads because the chooser doesn't use a factory yet, so I can't >> >parameterize the display at runtime. That is a goal though.) >> >> I don't see any gain in keeping the old interface if we make >> the above changes. There is equivalent functionality and, >> imo, better clarity. You always get into trouble when you >> start trying to maintain disparate views. > >Actually there is less functionality - no one-step reinstall, no >selection of arbitrary versions. Currently I can install any version >found on my hard disk, these proposed interfaces remove that ability. How does it remove that? Click on the install next to a package name (All in this case). >>I haven't looked into the code recently, but I think this gets rid of >>some of that state machine stuff that (used to?) was never quite right. >>I think that nuking that logic would be a big enough goal for going to >>a plan like this. > >It would remove the need for the state machine code, but that is very >stable now anyway (see package_meta if you are interested). It wasn't all *that* unstable when I left it (except for the auto uninstall thing which people are still reporting, apparently). I just think the idea of states is needlessly complicated. cgf
RE: prev/curr/test
> -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 26, 2002 11:21 AM > >Hmm. I think that unclicking bin should uninstall - leaving it there > >would be counter-intuititive. > > If you have the word install next to a box, I don't think it > follows that it will be uninstalled. Of course, my turn for stupidity :} > >Tick Bin to install foo. Untick Bin to remove foo. Tick Source to > >trigger a download of the source (download only mode) or extraction > >(install from x mode). > > And when you just don't want a package? What do you click to > get the equivalent of skip? Don't click either? In this example perhaps the bin column should be labelled "install". > Given your above comments, I think we still need another > clickable "thing" next to the Bin/Source, unless you have > some way of getting the equivalent of a "skip/keep". Ahh, so if you don't want to update you can stay put. Hmm. What about [X] - install [H] - hold [ ] - uninstall I know, it's heading back to the circular clicking thing :[. > >However, I think some folk will want the current interface, > so perhaps > >we offer a 'basic' and 'advanced' download of setup, or a [Advanced] > >button somewhere on the chooser. (To start with I'd suggest two > >downloads because the chooser doesn't use a factory yet, so I can't > >parameterize the display at runtime. That is a goal though.) > > I don't see any gain in keeping the old interface if we make > the above changes. There is equivalent functionality and, > imo, better clarity. You always get into trouble when you > start trying to maintain disparate views. Actually there is less functionality - no one-step reinstall, no selection of arbitrary versions. Currently I can install any version found on my hard disk, these proposed interfaces remove that ability. > I haven't looked into the code recently, but I think this > gets rid of some of that state machine stuff that (used to?) > was never quite right. I think that nuking that logic would > be a big enough goal for going to a plan like this. It would remove the need for the state machine code, but that is very stable now anyway (see package_meta if you are interested). Rob
Re: prev/curr/test
On Tue, Mar 26, 2002 at 08:57:43AM +1100, Robert Collins wrote: > > >> -Original Message- >> From: Christopher Faylor [mailto:[EMAIL PROTECTED]] >> Sent: Saturday, March 23, 2002 5:19 PM >> To: [EMAIL PROTECTED] >> Subject: prev/curr/test >> >> >> I think I've seen the light. > >... >> I think that Robert is right that if you click on test you >> should only get packages that have test versions. Ditto for >> prev. Ditto for curr. > >Woohoo! > >> There are no skip, keep, reinstall, or source options. Just >> install and uninstall. If you want to install source, you >> select the install action and click on source. If you only >> want the source and bin is checked, uncheck bin. This won't >> cause an uninstall. It will only cause bin not to be installed. > >Hmm. I think that unclicking bin should uninstall - leaving it there >would be counter-intuititive. If you have the word install next to a box, I don't think it follows that it will be uninstalled. >> We could use colors in the Bin field to indicate things like >> "installed due to dependency" (blue) or "uncheck me at your >> peril" (red). > >I'm red-green colour insensitive, which isn't quite colour blind, but >heading in that direction. If we do colour to indicate things, we should >only do it is a backup strategy - there should be some other primary >indicator. Ok. Of course, this is a stupid idea. It's why you can never use color keys for important things like this. >> I think this would simplify things a lot and maybe cut down >> on use confusion. >> >> Actually, we could even get rid of the individual actions and >> add another button on the top to flip between the install and >> uninstall views. > > >How about: >> prev ( ) curr (.) test (.) >> >> Package BinSource Description >> bash 2.05a[X][ ] Blah, blah >> fileutils 4.1-1 [ ][X] Blah, blah >> make 3.79.1-5 [x][ ] Blah, blah > > >Tick Bin to install foo. Untick Bin to remove foo. Tick Source to >trigger a download of the source (download only mode) or extraction >(install from x mode). And when you just don't want a package? What do you click to get the equivalent of skip? >I think it's a good idea to have multiple interfaces - that's why 90% >of the coding effort I've been putting in has been aimed at separating >out the UI and the engine, to allow fast changes like this. I can have >the above layout in place in about 30 minutes, if you want to see it. Given your above comments, I think we still need another clickable "thing" next to the Bin/Source, unless you have some way of getting the equivalent of a "skip/keep". >However, I think some folk will want the current interface, so perhaps >we offer a 'basic' and 'advanced' download of setup, or a [Advanced] >button somewhere on the chooser. (To start with I'd suggest two >downloads because the chooser doesn't use a factory yet, so I can't >parameterize the display at runtime. That is a goal though.) I don't see any gain in keeping the old interface if we make the above changes. There is equivalent functionality and, imo, better clarity. You always get into trouble when you start trying to maintain disparate views. I haven't looked into the code recently, but I think this gets rid of some of that state machine stuff that (used to?) was never quite right. I think that nuking that logic would be a big enough goal for going to a plan like this. cgf
RE: prev/curr/test
> -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED]] > Sent: Saturday, March 23, 2002 5:19 PM > To: [EMAIL PROTECTED] > Subject: prev/curr/test > > > I think I've seen the light. ... > I think that Robert is right that if you click on test you > should only get packages that have test versions. Ditto for > prev. Ditto for curr. Woohoo! > There are no skip, keep, reinstall, or source options. Just > install and uninstall. If you want to install source, you > select the install action and click on source. If you only > want the source and bin is checked, uncheck bin. This won't > cause an uninstall. It will only cause bin not to be installed. Hmm. I think that unclicking bin should uninstall - leaving it there would be counter-intuititive. > We could use colors in the Bin field to indicate things like > "installed due to dependency" (blue) or "uncheck me at your > peril" (red). I'm red-green colour insensitive, which isn't quite colour blind, but heading in that direction. If we do colour to indicate things, we should only do it is a backup strategy - there should be some other primary indicator. > I think this would simplify things a lot and maybe cut down > on use confusion. > > Actually, we could even get rid of the individual actions and > add another button on the top to flip between the install and > uninstall views. How about: > prev ( ) curr (.) test (.) > > PackageBinSource Description > bash 2.05a [X][ ] Blah, blah > fileutils 4.1-1[ ][X] Blah, blah > make 3.79.1-5 [x][ ] Blah, blah Tick Bin to install foo. Untick Bin to remove foo. Tick Source to trigger a download of the source (download only mode) or extraction (install from x mode). I think it's a good idea to have multiple interfaces - that's why 90% of the coding effort I've been putting in has been aimed at separating out the UI and the engine, to allow fast changes like this. I can have the above layout in place in about 30 minutes, if you want to see it. However, I think some folk will want the current interface, so perhaps we offer a 'basic' and 'advanced' download of setup, or a [Advanced] button somewhere on the chooser. (To start with I'd suggest two downloads because the chooser doesn't use a factory yet, so I can't parameterize the display at runtime. That is a goal though.) Rob
prev/curr/test
I think I've seen the light.
I think that selecting individual version numbers in setup is
evil and should be abolished. The only way to get old versions
should be at a macro level. You click a button and get all of
the old stuff, you click another button and get all of the current
stuff, you click another button to get all of the test stuff.
I think that Robert is right that if you click on test you should
only get packages that have test versions. Ditto for prev. Ditto
for curr.
So, I think the presentation should be something like:
prev ( ) curr (.) test (.)
Package Action Bin Source Description
bash 2.05a install [X] [ ] Blah, blah
fileutils 4.1-1 uninstall [ ] [X] Blah, blah
make 3.79.1-5install [x] [ ]
^^^
gray because
it is already
installed
There are no skip, keep, reinstall, or source options. Just install and
uninstall. If you want to install source, you select the install action
and click on source. If you only want the source and bin is checked,
uncheck bin. This won't cause an uninstall. It will only cause bin not
to be installed.
We could use colors in the Bin field to indicate things like
"installed due to dependency" (blue) or "uncheck me at your
peril" (red).
I think this would simplify things a lot and maybe cut down on
use confusion.
Actually, we could even get rid of the individual actions and add
another button on the top to flip between the install and uninstall
views.
Install (.) Uninstall ( ) prev ( ) curr (.) test (.)
Package BinSource Description
bash 2.05a [X][ ] Blah, blah
fileutils 4.1-1 [ ][X] Blah, blah
make 3.79.1-5[x][ ] Blah, blah
So?
cgf
