#2036 Setup: Setting shortcut preferences in profile.xml

INSTALLER
open
Feature
none
Unknown
False
2014-10-06
2013-09-07
Cesar Strauss
No

Here are some suggestions for handling shortcut preferences in mingw-get-setup and mingw-get-gui.

1) In mingw-get-setup, we are asked to choose how and where to install program shortcuts. My suggestion is to record these choices in profile.xml, in the already existing keys. In the same way, mingw-get-gui could have a settings menu to control this.

Right now, the msys.bat shortcut in msys-core-ext post-install (see [#2008]) would not be created when installing from the gui, because of this.

2) Given 1), let the mingw-get-gui package install its own icons.

Right now, it seems mingw-get-setup is responsible for installing mingw-get-gui icons. Besides the duplication of code from the mingw-get-gui post-install, the installed icons are not exactly the same. For instance, by running "mingw-get --reinstall --desktop upgrade mingw-get-gui", I end up with two desktop shortcuts, differing by name.

3) I was looking for a "MinGW" category in the start-menu, but it seems the be gone now. The shortcut is created right at the top level instead (I was so confused, I thought shortcut menu creation wasn't even working...).

My suggestion is maybe having our own category again, because we can have a number of shortcuts:
- MinGW Installation Manager
- MinGW Shell
- MinGW Enhanced Shell (mintty)
- MSYS Developer Shell

Otherwise, congratulations on your great work on mingw-get.

Thanks for your attention,

Cesar

Related

Issues: #2008

Discussion

  • Keith Marshall
    Keith Marshall
    2013-09-18

    • labels: --> gui, options
    • status: unread --> open
    • assigned_to: Keith Marshall
     
  • Keith Marshall
    Keith Marshall
    2013-09-18

    In mingw-get-setup, we are asked to choose how and where to install program shortcuts. My suggestion is to record these choices in profile.xml, in the already existing keys.

    That would require "on-the-fly" editing of the data stream copied from defaults.xml to profile.xml, at mingw-get-setup.exe run time. Seems like a job made for sed, but we cannot rely on sed being available, so we'd need a sed-like filter either embedded within mingw-get-setup.exe (or mingw-get-setup-0.dll), or a native sed.exe (or equivalent) implementation to ship alongside mingw-get-setup-0.dll, (and perhaps to be deleted along with it after use). Would you care to help with the development of that?

    In the same way, mingw-get-gui could have a settings menu to control this.

    Yes, I've always planned that as a feature ... eventually.

    Right now, the msys.bat shortcut in msys-core-ext post-install (see [#2008]) would not be created when installing from the gui, because of this.

    Actually, it would not do it because of [#2052].

    Right now, it seems mingw-get-setup is responsible for installing mingw-get-gui icons. Besides the duplication of code from the mingw-get-gui post-install,

    The code isn't actually duplicated; mingw-get-setup.exe calls the same shlink.js helper as used by the post-install script; it just does it directly, rather than going via the Lua interpreter.

    the installed icons are not exactly the same. For instance, by running "mingw-get --reinstall --desktop upgrade mingw-get-gui", I end up with two desktop shortcuts, differing by name.

    That must be classified as a bug, I think. Perhaps it would be better not to bypass the Lua interpreter, to avoid such inconsistencies.

    I was looking for a "MinGW" category in the start-menu, but it seems the be gone now. The shortcut is created right at the top level instead (I was so confused, I thought shortcut menu creation wasn't even working...).

    My suggestion is maybe having our own category again, because we can have a number of shortcuts ...

    Makes sense. It would need a modification in shlink.js, to ensure that the requisite subdirectory exists, or to create it if not, before installing the shortcut into it. Perhaps you could provide a patch, please?

     

    Related

    Issues: #2008
    Issues: #2052

  • Keith Marshall
    Keith Marshall
    2013-09-20

    Right now, the msys.bat shortcut in msys-core-ext post-install (see [#2008]) would not be created when installing from the gui, because of this.

    Actually, it would not do it because of [#2052].

    Of course, with [#2052] fixed, we still have the issue that the GUI doesn't read preferences from anywhere. Thus, I've modified both it and the CLI to support separate assignment of pre-configured preferences for each through profile.xml, and added an appropriate configuration section to the defaults.xml distribution of profile.xml, which if incorporated into the user's local profile.xml, will ensure that the GUI does create the shortcuts, in the user's start menu, and on his desktop; (at his option, he may change this behaviour, by editing profile.xml).

     

    Related

    Issues: #2008
    Issues: #2052

  • Keith Marshall
    Keith Marshall
    2014-05-07

    I was looking for a "MinGW" category in the start-menu, but it seems the be gone now. The shortcut is created right at the top level instead (I was so confused, I thought shortcut menu creation wasn't even working...).

    My suggestion is maybe having our own category again, because we can have a number of shortcuts ...

    Makes sense. It would need a modification in shlink.js, to ensure that the requisite subdirectory exists, or to create it if not, before installing the shortcut into it. Perhaps you could provide a patch, please?

    In the absence of any other patch, I'll take a look at this myself. So far, I've come up with this

    diff --git a/scripts/libexec/shlink.js b/scripts/libexec/shlink.js
    --- a/scripts/libexec/shlink.js
    +++ b/scripts/libexec/shlink.js
    @@ -18,13 +18,17 @@
      *             unless --start-menu or --desktop is specified)
      *
      *   --desktop create the shortcut on the desktop of the current
      *             user, (or for all users, with --all-users)
      *
    - *   --start-menu
    + *   --start-menu[=submenu_relative_path_name]
      *             create the shortcut in the user's start menu, (or
    - *             all users' start menu, with --all-users)
    + *             all users' start menu, with --all-users); if the
    + *             optional submenu_relative_path_name argument, (a
    + *             relative path name), is specified, the shortcut
    + *             will be placed in the named subdirectory of the
    + *             appropriate start menu.
      *
      *   --arguments="argument list ..."
      *             specify arguments to be passed to the command
      *             invoked by the shortcut
      *
    @@ -60,11 +64,11 @@
      *
      *
      * This file is a component of mingw-get.
      *
      * Written by Keith Marshall <keithmarshall@users.sourceforge.net>
    - * Copyright (C) 2012, MinGW Project
    + * Copyright (C) 2012, 2014, MinGW.org Project
      *
      *
      * Permission is hereby granted, free of charge, to any person obtaining a
      * copy of this software and associated documentation files (the "Software"),
      * to deal in the Software without restriction, including without limitation
    @@ -131,13 +135,14 @@ if( (i > 0) &&  (cmdName.substr( i ) == 
    
     /* Initialise all options to "unassigned" state.
      */
     var target = -1;
     var lnkname = -1;
    +var allusers = -1;
     var desktop = -1;
    -var allusers = -1;
     var startmenu = -1;
    +var submenu = -1;
     var verbosity = -1;
     var unassigned = "+++unassigned+++";
     var assigned = Array( options.length );
     for( var k = 0; k < assigned.length; k++ )
     {
    @@ -175,21 +180,41 @@ for( var k = 0; k < assigned.length; k++
      * as specified, or relative to current working directory.
      */
     var prefix = "";
    
     var j;
    +var optequ;
     function assign_option( name, value )
     {
    +  /* Determine the value, if any, which is to be assigned as
    +   * argument to the named option.
    +   */
       switch( name )
       {
    +    /* "--start-menu" is a special case; it may take an
    +     * optional argument, which MUST be attached to the
    +     * name of the option by an assignment operator...
    +     */
    +    case "start-menu":
    +      if( (submenu = optequ) > 0 )
    +       /*
    +        * ...in which case, we return the assigned value...
    +        */
    +       return value;
    +
    +    /* ...otherwise, fall through to handle it as any of the
    +     * following named options which do not take an argument...
    +     */
         case "desktop":
    -    case "start-menu":
         case "all-users":
         case "verbose":
           j = i;
           return "set";
       }
    +  /* ...or, in the case of any other option, an argument is
    +   * mandatory, so return the requisite value.
    +   */
       return value;
     }
    
     /* Parse the command line.
      */
    @@ -200,15 +225,17 @@ for( i = 0; i < argv.length; i++ )
       {
         /* Handle arguments specifying options...
          */
         if( (optind = argv( j = i ).indexOf( "=" ) + 1) > 3 )
         {
    +      optequ = 1;
           optnam = argv( j ).substr( 2, optind - 3 );
           optarg = argv( j ).substr( optind );
         }
         else
         {
    +      optequ = 0;
           optnam = argv( j ).substr( 2 );
           if( ++j < argv.length )
            optarg = argv( j );
           else
            optarg = unassigned;
    @@ -290,19 +317,75 @@ if( (suffix != ".lnk") && (suffix != ".u
    
     /* Add the appropriate prefix for '--desktop' or '--start-menu' shortcuts.
      */
     if( assigned[desktop] != unassigned )
     {
    +  /* In the case of '--desktop', (which precludes '--start-menu')...
    +   */
       if( assigned[startmenu] != unassigned )
         complain( -2, "options '--desktop' and '--start-menu' are incompatible" );
    +
    +  /* ...the appropriate prefix is simply the "desktop special folder"
    +   * path name...
    +   */
       else prefix = WinShell.SpecialFolders( (assigned[allusers] == unassigned)
           ? "Desktop" : "AllUsersDesktop" ) + "\\";
     }
     else if( assigned[startmenu] != unassigned )
    +{
    +  /* ...while for '--start-menu', it is the corresponding "start-menu
    +   * special folder" path name...
    +   */
       prefix = WinShell.SpecialFolders( (assigned[allusers] == unassigned)
           ? "StartMenu" : "AllUsersStartMenu" ) + "\\";
    +  if( submenu > 0 )
    +  {
    +    /* ...which may be qualified by appending a sub-menu relative
    +     * path name.
    +     */
    +    var submenu_path = prefix + assigned[startmenu];
    
    +    /* The sub-folder associated with any sub-menu MUST already
    +     * exist, BEFORE we can create the shortcut.
    +     */
    +    var FileSystem = WScript.CreateObject( "Scripting.FileSystemObject" );
    +    function mkdir_recursive( pathname )
    +    {
    +      /* This recursive function emulates the unix 'mkdir -p ...'
    +       * command, checking whether this sub-folder does exist, or
    +       * if not, attempts to create it...
    +       */
    +      if( (pathname == "") || FileSystem.FolderExists( pathname ) )
    +       /*
    +        * ...returning the equivalent of TRUE, as soon as we
    +        * find an existing folder, (noting that "" effectively
    +        * represents "current folder", which must exist)...
    +        */
    +       return 1;
    +
    +      /* ...otherwise, we recurse through the sequence of parent
    +       * folders, until we find one which does exist...
    +       */
    +      if( mkdir_recursive( FileSystem.GetParentFolderName( pathname ) ) )
    +       /*
    +        * ...whence we attempt to create the entire sub-tree
    +        * path, as we unwind the recursive call stack...
    +        */
    +       return FileSystem.CreateFolder( pathname );
    +
    +      /* ...but ultimately, return FALSE if we fail to create
    +       * any missing component of the sub-menu path.
    +       */
    +      return 0;
    +    }
    +    if( mkdir_recursive( submenu_path ) )
    +      prefix = submenu_path + "\\";
    +
    +    else
    +      complain( 0, "cannot access sub-menu '" + assigned[startmenu] + "'" );
    +  }
    +}
     else if( assigned[allusers] != unassigned )
       complain( -2,
           "option '--all-users' also requires '--desktop' or '--start-menu'"
         );
    

    but it will need a complementary change in unlink.js, before I actually commit it.

     
    Last edit: Keith Marshall 2014-05-07