From: Keith M. <kei...@us...> - 2012-04-20 20:27:50
|
I'm thinking primarily of options such as --desktop and --start-menu, (added in mingw-get-0.5), for which users may wish to establish their own preferred default settings. To accommodate this, I propose to add handling for a <preferences>...</preferences> section in profile.xml The implementation will ensure that any option specified on the command line will override a default setting in profile.xml I'd welcome your thoughts on preferred syntax for the XML; which of the following would you prefer? <preferences> <set option="desktop" class="all-users" /> ... </preferences> or <preferences> <option name="desktop" value="all-users" /> ... </preferences> or some alternative tag/attribute combination, conveying the concept? -- Regards, Keith. |
From: Earnie B. <ea...@us...> - 2012-04-21 16:17:55
|
On Fri, Apr 20, 2012 at 4:27 PM, Keith Marshall <kei...@us...> wrote: > I'm thinking primarily of options such as --desktop and --start-menu, > (added in mingw-get-0.5), for which users may wish to establish their > own preferred default settings. To accommodate this, I propose to add > handling for a <preferences>...</preferences> section in profile.xml > > The implementation will ensure that any option specified on the command > line will override a default setting in profile.xml > > I'd welcome your thoughts on preferred syntax for the XML; which of the > following would you prefer? > > <preferences> > <set option="desktop" class="all-users" /> > ... > </preferences> This sounds a bit natural. > > or > > <preferences> > <option name="desktop" value="all-users" /> > ... > </preferences> > or <preferences> <preference desktop="all-users" /> <preference start="mingw" /> </preferences> Since we have preferences we should have a preference. > or some alternative tag/attribute combination, conveying the concept? Ditto. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2012-04-21 17:54:59
|
On 21/04/12 17:17, Earnie Boyd wrote: > On Fri, Apr 20, 2012 at 4:27 PM, Keith Marshall > <kei...@us...> wrote: >> I'm thinking primarily of options such as --desktop and --start-menu, >> (added in mingw-get-0.5), for which users may wish to establish their >> own preferred default settings. To accommodate this, I propose to add >> handling for a <preferences>...</preferences> section in profile.xml >> >> The implementation will ensure that any option specified on the command >> line will override a default setting in profile.xml >> >> I'd welcome your thoughts on preferred syntax for the XML; which of the >> following would you prefer? >> >> <preferences> >> <set option="desktop" class="all-users" /> >> ... >> </preferences> > > This sounds a bit natural. Which would be okay, right? Or did you mean unnatural? >> or >> >> <preferences> >> <option name="desktop" value="all-users" /> >> ... >> </preferences> > > or > > <preferences> > <preference desktop="all-users" /> > <preference start="mingw" /> > </preferences> This would not lend itself well to the implementation. > Since we have preferences we should have a preference. Having played a bit with implementation, I'm now leaning toward: <preferences> <enable option="desktop" [value="all-users"] /> <enable option="start-menu" [value="all-users"] /> ... </preferences> or maybe: <preferences> <enable option="desktop" [preferences="all-users"] /> <enable option="start-menu" [preferences="all-users"] /> ... </preferences> where the general form of the "enable" tag would be: <enable option="option-name" [preferences="attribute[,...]] /> Not a big deal, I guess, but using the same spelling of the keyword "preferences" for both the container element tag, and for the attribute name, saves defining both the singular and plural forms as independent keywords. The idea, for now, is to relieve users of the need to specify the --desktop[=all-users] and the --start-menu[=all-users] command line options, (see 'mingw-get --help' for the mingw-get-0.5-beta release), if they would prefer to always allow post-install hooks to create the associated short-cuts. -- Regards, Keith. |
From: Earnie B. <ea...@us...> - 2012-04-23 11:47:56
|
On Sat, Apr 21, 2012 at 1:54 PM, Keith Marshall wrote: > On 21/04/12 17:17, Earnie Boyd wrote: >> On Fri, Apr 20, 2012 at 4:27 PM, Keith Marshall >> <kei...@us...> wrote: >>> I'm thinking primarily of options such as --desktop and --start-menu, >>> (added in mingw-get-0.5), for which users may wish to establish their >>> own preferred default settings. To accommodate this, I propose to add >>> handling for a <preferences>...</preferences> section in profile.xml >>> >>> The implementation will ensure that any option specified on the command >>> line will override a default setting in profile.xml >>> >>> I'd welcome your thoughts on preferred syntax for the XML; which of the >>> following would you prefer? >>> >>> <preferences> >>> <set option="desktop" class="all-users" /> >>> ... >>> </preferences> >> >> This sounds a bit natural. > > Which would be okay, right? Or did you mean unnatural? > Yes, I meant okay. >>> or >>> >>> <preferences> >>> <option name="desktop" value="all-users" /> >>> ... >>> </preferences> >> >> or >> >> <preferences> >> <preference desktop="all-users" /> >> <preference start="mingw" /> >> </preferences> > > This would not lend itself well to the implementation. > >> Since we have preferences we should have a preference. > > Having played a bit with implementation, I'm now leaning toward: > > <preferences> > <enable option="desktop" [value="all-users"] /> > <enable option="start-menu" [value="all-users"] /> > ... > </preferences> > > or maybe: > > <preferences> > <enable option="desktop" [preferences="all-users"] /> > <enable option="start-menu" [preferences="all-users"] /> > ... > </preferences> > > where the general form of the "enable" tag would be: > > <enable option="option-name" [preferences="attribute[,...]] /> > I can live with this. It is a set it once item so it works. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Charles W. <cwi...@us...> - 2012-04-26 21:42:24
|
On 4/21/2012 1:54 PM, Keith Marshall wrote: > Having played a bit with implementation, I'm now leaning toward: > > <preferences> > <enable option="desktop" [value="all-users"] /> > <enable option="start-menu" [value="all-users"] /> > ... > </preferences> > > or maybe: > > <preferences> > <enable option="desktop" [preferences="all-users"] /> > <enable option="start-menu" [preferences="all-users"] /> > ... > </preferences> > > where the general form of the "enable" tag would be: > > <enable option="option-name" [preferences="attribute[,...]] /> Of the four proposed syntaxes, I prefer #2, in Keith's original RFC: <preferences> <option name="desktop" value="all-users" /> ... </preferences> It clearly represents the intent: the user has certain preferences. Some of those are "options" which have a "name" and "value(s)". There may be other preferences that are not options, which would be represented as other <elements/> within <preferences/>. What sort of preference would not be an option? Maybe auto-triggers (e.g. whenever I do a source action, I *always* want to add "--recurse --download-only" to the option list, but only for that action. <preferences> <action-defaults name="source" type="append-options" value="recurse download-only"/> </preferences> But, since SHTDI, and Keith is the guy who is actually Doing It, I won't object to any of the four current proposals. -- Chuck |
From: Keith M. <kei...@us...> - 2012-04-28 03:23:34
|
On 26/04/12 22:42, Charles Wilson wrote: > Of the four proposed syntaxes, I prefer #2, in Keith's original RFC: > > <preferences> > <option name="desktop" value="all-users" /> > ... > </preferences> > > It clearly represents the intent: the user has certain preferences. Some > of those are "options" which have a "name" and "value(s)". That was my initial preference too, but what if there is no value? <preferences> <option name="desktop" /> ... </preferences> vs. <preferences> <enable option="desktop" /> ... </preferences> when the intent is to create desktop shortcuts for current user only, rather than for all users? It's trivially easy to implement it one way or the other, but I definitely want only one. On balance, I think I still prefer the former; just thinking aloud, in an effort to convince myself that it's no less logical than the latter. > What sort of preference would not be an option? Maybe auto-triggers > (e.g. whenever I do a source action, I *always* want to add "--recurse > --download-only" to the option list, but only for that action. > > <preferences> > <action-defaults name="source" > type="append-options" > value="recurse download-only"/> > </preferences> Hadn't thought of that one. Thanks! Something to maybe bear in mind, for a rainy day... One that I did think of: <preferences> <policy release-status="beta" option="decline" /> </preferences> to indicate that, if I've already installed a better quality release, I'd prefer to stick with it, rather than upgrade to a "beta" (or lesser quality) release on a newer development branch; another possibility for that rainy day. -- Regards, Keith. |