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: installer improvements

>> After using cygwin for years, and having some recent difficulty
>> installing, I took a look at the installer to actually try and
>> understand it (a novel concept I know!). Here are my thoughts on the
>> gui - I think it could be made considerably more user friendly with
>> some minor cosmetic changes.
> Personally, as a UI fanatic, I have no problem with it, and I get really
> nitpicky about design. Lets hear your gripes, shall we? :)
>> The View button is being used to do two separate and unrelated tasks.
>> - Switch between category and list view
>> - Choose between partial, up to date, and not installed.
>> I suggest that additional radio buttons be used to select between
>> category and list view.
> They are *not* unrelated. In fact, that button keeps me *sane*

how do you choose full view in category mode, full view in list mode,
partial view in category mode, partial view in list mode, not
installed in category mode, not installed in list mode ?
> What it does is change the perspective of looking at the packages; the fact
> that one view happens to be a tree view ("by category") instead of a
> linear-list ("by is-installed" or "is-downloaded") is a happy 2nd or 3rd
> order effect. *any other way of doing it would be a kludgy look*.
So you are saying that the single button has a second order effect.
Normally, you would put this 'second order effect' on a different gui
component so it could be controlled separately. In effect, the view
button tries to do two things - one is how you see what is currently
selected (list or category), the other is to select what you see. Why
on earth you would want to choose these functions with the same button
I don't know.
>> The terms used are not the clearest (and believe me, things are tricky
>> enough already)
>> Partial ? ? ? ? ? ? ?- ? I suggest change to 'to be be installed' or
>> similar
>> Up to date ? ? ? ?- ? I suggest change to 'already installed' or similar
>> not installed ? ? - ? this is clear, no changes necessary
> Partial: Downloaded (or marked for download/Updatable), but not installed.
> Up To Date: Downloaded, Installed and latest version.
> Not Installed: Self Referential.
Yes, I know you can explain the terms to me, good design however is
self explanatory.
>> The way that (partial, up to date and not installed) is selected, via
>> clicking on a button multiple times is not very common in gui design.
> It sure as hell is. Look at Synaptic: Uses the same ideology; If the debian
> folks were braindamaged (which, frankly, some of them are) they would be
> working on GNOME projects (Except Synaptic, which also has this ability)
Where else? - I don't see it everywhere in all the gui's I use - I do
however see radio buttons and drop down lists everywhere.
>> It doesn't allow you to see all of the available choices at once. I
>> suggest replacing this button either with a group of radio buttons, or
>> a drop down list similar to the way that you can change the view in a
>> windows folder (details, list, icons).
> I believe the view-mode you're looking for is "full"
No, I'm looking for a logical way of selecting the view mode.
>> I suggest that a new column be introduced, indicating whether a
>> package is already installed or not. The installer has this
>> information - it would be nice if it made it available to the user.
> There's already two of those -- they're called "Bin?" and "Src?" -- which
> indicate if the binary and/or source packages are installed.
Well, actually the column that does this is called Current, which was
pointed out to me by Dave Korn.
>> Also, on an unrelated note, it would be very nice, to sort the list of
>> mirrors in order of latency, or auto select the fastest available
>> mirror.
> Lets see, the server list contains 30-50 servers. Setup.exe is
> single-threaded for a reason until you get to the installation, where upon
> it actually forks off some threads to do real work.
> Lets assume that you're not on the greatest of net connections... say
> average ping of 180ms (thats my average ping to the local transfer
> station)...
> 5 [pings] * 180 [~ms] *50 [servers] = ?45000 ms
> thats 45 seconds your machine is *stopped* going and checking latency.
Choosing the fastest server could save a lot longer than 45 seconds in
download time. This functionality would be useful and could be an
option available to users if they wanted to automatically find the
fastest server.

> Inb4 "make the main server report them" -- not a good idea.
> First, the main server's going to be right on the backbone, therefore giving
> *low* pings. This will create a false sense of hope and when it takes
> forever for it down download even though the ping was low, users get grumpy.
> Inb4 "Have a round-robin DNS" -- Again, not a good idea.
> Each server has a *different* set of packages because some of them are
> purely *volunteer* maintained. Its just a sad fact that most (if not all) of
> the people who work on these projects make... $0 maintaining the servers,
> packages and tools.
> AS for gripes about the deterministic-y of the installer: its entirely
> deterministic. What you do, however, is not.
That's a great way of investigating and fixing bugs - just say they
don't exist and it's the users fault. Wow, I wish I could fix my bugs
so easily.
> If you notice, there are three options in the installer for "setup mode" --
> one is normal install off the net, another is download packages only, and
> the third is install from local cache.
> The "download packages only" will churn whatever portion of a package tree
> you wish down into a filesystem *locked to a particular server*.
> that is, if you choose "C:\Cygtemp\" as your "download directory" you will
> find that there's a folder there for the URL of your chosen mirror.
> This lets you back up an entire server then turn around and install it on a
> network-less machine (by pointing it to "cygtemp"'s logical new location)
> Give You A Hint, I at the age of *13* was able to download and install and
> configure Cygwin... 1.3 I think it was... It was definitely about five years
> ago... onto a machine with no internet connection whatsoever.
Clever you. What's that got to do with anything? You see, to end up
with good quality software, you have to search out flaws, and fix
them. Just because you could install 5 years ago, doesn't mean the
installer is the best it could be.

Problem reports:
Unsubscribe info:

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