This is the mail archive of the cygwin 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: How to uninstall Cygwin/X (only)


Dave Korn <dave...win@googlemail.com> writes:

> On 11/04/2010 04:21, Paul Bibbings wrote:
>
>>   For
>> instance, if I click on the view button and select `Not installed',
>> suppose I select a package that I don't have - for example (I'm trying
>> this now), aspell-dev 0.60.5-1.  Then, suppose I merely cycle through
>> the Views and come back to `Not installed'. aspell-dev is no longer in
>> the list, despite the fact that I have not done anything other than
>> change the view.  It is no more installed now than it was before. 
>
>   Well, the way I think of it is that when setup starts up, those displays
> show you the current state of your installation; and what you do is change
> things until they show you how you want it to be after setup completes, and
> then when you've got everything how you want it to be, you hit "Next" to apply
> your changes.

This is, of course, a valid UI motif, and one that users can attach some
familiarity to, which always helps.  However, as I see it, in this  
instance, taking this to be the motif creates inconsistencies 
elsewhere.  Following the idea that that setup shows, after selection,
"how you want it to be after setup completes," I would then expect to
see my newly selected package to show up in `Up to date', and it isn't
there either. Certainly it shows in `Partial', and maybe this is enough,
but this of itself is not consistent with the idea that setup is
reflecting the state of the system *after* completion of setup; I
certainly don't expect to find it "partially" installed.

I am still thinking this through, but at present am still leaning
towards the idea that *where* a package appears - in which view(s) -
should better reflect the state of the system as-is.  The state of the
`Bin?'/`Src?' checks are better suited to handle alone the motif of
"this is how your system will be after setup finishes."  The main
reasons for leaning this way are that, as is, setup sits half way between
showing `as-is' and `will-be' - a selected package appears neither in
`Up to date' nor `Not installed; that if the view that a package appears
in (of these two) reflects the `will-be' state, then the user loses
information (Is this package /actually/ installed, or is it just that it
will be.  The distinction is gone); and that, retaining a selected
package in the `Not installed' list whilst taking the state of the
checks alone to reflect the `will be' state appears to remove all of
these issues.  In this way the user retains information about what is
actually installed, whilst having also a view of how the system will be
after completion of setup, and this without any evident inconsistency
that I can see.

Regards

Paul Bibbings


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


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