delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-apps/2002/03/25/19:20:41

Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Date: Mon, 25 Mar 2002 19:20:30 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-apps AT cygwin DOT com
Subject: Re: prev/curr/test
Message-ID: <20020326002030.GA27207@redhat.com>
Reply-To: cygwin-apps AT cygwin DOT com
Mail-Followup-To: cygwin-apps AT cygwin DOT com
References: <FC169E059D1A0442A04C40F86D9BA76008AB96 AT itdomain003 DOT itdomain DOT net DOT au>
Mime-Version: 1.0
In-Reply-To: <FC169E059D1A0442A04C40F86D9BA76008AB96@itdomain003.itdomain.net.au>
User-Agent: Mutt/1.3.23.1i

On Tue, Mar 26, 2002 at 08:57:43AM +1100, Robert Collins wrote:
>
>
>> -----Original Message-----
>> From: Christopher Faylor [mailto:cgf AT redhat DOT com] 
>> Sent: Saturday, March 23, 2002 5:19 PM
>> To: cygwin-apps AT cygwin DOT com
>> 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		 Bin	Source		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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019