This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]