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 20:02:03 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-apps AT cygwin DOT com
Subject: Re: prev/curr/test
Message-ID: <20020326010203.GD27207@redhat.com>
Reply-To: cygwin-apps AT cygwin DOT com
Mail-Followup-To: cygwin-apps AT cygwin DOT com
References: <FC169E059D1A0442A04C40F86D9BA76008AB9D AT itdomain003 DOT itdomain DOT net DOT au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <FC169E059D1A0442A04C40F86D9BA76008AB9D@itdomain003.itdomain.net.au>
User-Agent: Mutt/1.3.23.1i

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