Mail Archives: cygwin-apps/2002/03/25/19:31:37

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: <>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Subject: RE: prev/curr/test
Date: Tue, 26 Mar 2002 11:31:22 +1100
MIME-Version: 1.0
Message-ID: <>
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-apps AT cygwin DOT com>
X-MIME-Autoconverted: from quoted-printable to 8bit by id g2Q0Vac23373

> -----Original Message-----
> From: Christopher Faylor [mailto:cgf AT redhat DOT com] 
> 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).


- Raw text -

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