From: "Robert Collins" <robert.collins@itdomain.com.au>
To: "Max Bowsher" <maxb@ukf.net>, <cygwin@cygwin.com>
Subject: RE: setup.exe (cinstall) bugfixes + minor new feature
Date: Mon, 04 Mar 2002 05:29:00 -0000 [thread overview]
Message-ID: <FC169E059D1A0442A04C40F86D9BA76008AB08@itdomain003.itdomain.net.au> (raw)
> -----Original Message-----
> From: Max Bowsher [mailto:maxb@ukf.net]
>
>
> > I was thinking that
> > If the setting is absent it prompts,
> > if the setting is on it always creates, overwriting the
> current one if
> > the setting is off it never creates.
>
> > Rob
>
> Hmm - I'm not sure I understand this.
>
> Current behaviour is that setup checks the boxes by default,
> if it does not find the shortcuts. The user can manually
> check the boxes to run the creation code even if they already
> exist. I find it mildly annoying to have to uncheck both
> boxes each time I run setup. (My desktop shortcut is called
> something different, and I don't want a start menu one)
> Therefore, I would like setup to remember the fact that the
> user has deliberately unchecked the boxes. I don't understand
> why anyone would want the shortcuts deleted and recreated
> every time the run setup?
I can think of reasons :}. The first one being that as a sysadmin I
might want to force every user to get shortcuts - without being
prompted. Now a shared cygwin install does not imply shared profiles -
desktop and start menu locations - so the ability to turn off the prompt
and always create is thus useful.
> I will proceed with fixing that bug, and investigate the use
> of a setup.conf file. Are there any objections to using
> windows {Get,Set}PrivateProfileInt API calls? Or should I
> investigate the setup.ini parsing code, and try to use that?
Neither :}. I've a model in mind for persistence for all the currently
diverse setup options. Seriously though, for now, code it with
Get|Set... And I'll get my model documented and into code at some point.
Rob
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
next reply other threads:[~2002-03-04 13:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-04 5:29 Robert Collins [this message]
2002-03-04 8:18 ` Max Bowsher
-- strict thread matches above, loose matches on Subject: below --
2002-03-04 13:11 Robert Collins
2002-03-04 2:34 Robert Collins
2002-03-04 3:32 ` Max Bowsher
2002-03-04 2:32 Robert Collins
2002-03-04 5:01 ` Max Bowsher
2002-03-04 2:08 Max Bowsher
2002-03-03 13:15 Robert Collins
2002-03-03 10:01 Max Bowsher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=FC169E059D1A0442A04C40F86D9BA76008AB08@itdomain003.itdomain.net.au \
--to=robert.collins@itdomain.com.au \
--cc=cygwin@cygwin.com \
--cc=maxb@ukf.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).