This is the mail archive of the cygwin-apps@cygwin.com 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: Welcoming Brian Dessent as setup maintainer


[snip]

> 
> Bug Fixes / New Features
> (in no particular order)
> ------------------------
> 

[snip]

> - setup is already fairly cryptic, it does not help that 
> there are absolutely no help buttons.  We have to keep it as 
> a single monolithic executable (so no external help files), 

I'm not sure that is a precondition.  Cygwin setup could very easily be
packaged up with InnoSetup into a single downloadable exe, but it would be a
regular Windows installer, and setup.exe and any number of support files it
might require could be installed just like any other application.  In fact,
it seems to me that even it did stay a single exe, having a regular
installation process like this would be good, if only to eliminate the
question of "where do I put setup.exe?"

Adding HTML help, when it's a separate file anyway, is dead simple.

[snip]

> - The user mode/system mode mount thing seems to be wearing 
> out its welcome.  Seems like for a lot of people, system 
> mounts are the way to go and there's no reason complicating 
> it for them.  But there will still be cases -- be it lacking 
> admin permissions, or desire to support multiple users -- 
> where you still want user mounts.  So we can't just rip it 
> all out, but it does seem reasonable that we could first 
> check for admin privileges, and if they exist then assume 
> system-wide mounts for new installs.  Existing installs would 
> keep whatever they're set to, and we'd need some way for 
> people that want to use user mode mounts to easily do that - 
> maybe a command line switch, or a setting in a file.
> 

Many of the new programs I've installed recently ask the very similar
question of "Do you want to install for all users of this computer, or just
the current user?", albeit usually for different reasons, so I don't see
anything fundamentally wrong with the status quo.  I think simply clarifying
this functionality (along with the DOS/UNIX mounts etc) and/or not asking it
every time (as I believe others may have already suggested) would
essentially solve any current issues there (UI issues anyway).

> - If the user has entered by hand a mirror location or is 
> using an ancient mirror, it could really detract from their 
> experience if they're getting stale packages.  Setup should 
> probably warn or gently prod the user if it detects that the 
> mirror they're using isn't on the cygwin.com list.  (cgf 
> pointed me towards this issue.)  Again, I'm sure there are 
> lots of people out there that are legitimately using mirror 
> locations not on the official list, so I'm thinking of 
> something along the lines of a warning message with an option 
> to "don't ask me again", or at least "don't ask me again 
> unless I enter a new url that's also not on the list".
> 

I still maintain that the whole "Select a mirror" thing is not something
that should normally be user-visible.  By far the most common use case is
the user trying to update their current Cygwin installation with updated
and/or new programs, and they absolutely don't care which mirror they're
coming from.  They certainly shouldn't be expected to know which ones are
current, nor which ones are "better" than the others, nor which are
currently available, because they simply won't know.  Some automatic means
of deciding this stuff should exist, and be the default way mirror selection
works.  "Install from a specific mirror" or whatever can require the user to
press another button or two, or set an "Options" checkbox somewhere, as it
should.

[snip]
> - Very minor cosmetic thing, but we should include a manifest 
> with the .exe.  With that one change you get the updated 
> common controls that were added in XP.  You can see this in 
> the screen shots above actually, I've been building it that 
> way for a while now.  Now, I'm fully prepared for the jokes 
> about XP looking like fischer price ("My first OS!") but it 
> doesn't hurt to spruce up the appearance a little bit since 
> that kind of thing matters to a lot of people.  It's 
> essentially a free change, you just add the manifest and 
> that's it, you don't have to maintain anything.  I would of 
> course want to test it on all the older 9x systems but I'm 
> fairly sure they degrade fine (the manifest I used was more 
> or less the boilerplate one from the SDK.)
> 

I was never able to get this to fully work, as the resource compiler wasn't
able to handle manifest resources.  Are you sure that this is really working
for you?  I was fooled for a while, because if you have the manifest file in
the same directory Windows will use that and it will work fine, but move the
exe and it suddenly is back to the non-themed olde-tyme controls.  (Maybe
another reason to go to an InnoSetup installer?)

I think I recall doing some not-insignificant work on the SDK boilerplate,
for reasons that are lost to the fog of time.  I can dig that up if you
think you might be able to make use of it.

[snip]

One thing you didn't explicitly state, but is implied by many of your
points, is that the UI and business logic badly need to be disentangled.
Max, myself, and others have picked away at that over the years, but last I
checked there still was not a clear division.

>  If you have a short attention span, allow me to summarize 
> how I feel about this as follows:
> 
> *********************************************************************
> ** The current user experience of setup.exe is needlessly harsh,   **

I don't think anybody can disagree with that.

> ** and I think we can improve that without _too_ much effort.

Small improvements, probably so.  Big-picture improvements... Nobody's sure
what a new Big Picture should even look like, so I don't know if you can
really say that.  Maybe what setup is trying to do really can't be done
materially better in some other way, in which case the requirements need to
be reevaluated.

-- 
Gary R. Van Sickle


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