XUL:Command Line Handling: Difference between revisions

Jump to navigation Jump to search
m
Page was broken by the table. I have changed the table with the wiki syntax
m (Page was broken by the table. I have changed the table with the wiki syntax)
 
Line 93: Line 93:
Instead of treating the command-line handler as static information about which XUL window to open, it is a dynamic type that can respond to the "event" of starting the application. Arguments can start with -arg, --arg on *nix, /arg on windows; they will be normalized to -arg before handlers are called. If a unix arg is the form --arg=param, it will be split into two arguments -arg <param>. Handlers are registered with the category manager (currently, you have to register with a contractID prefix and a category, which is kinda silly) and would be run in alpha-order thusly:
Instead of treating the command-line handler as static information about which XUL window to open, it is a dynamic type that can respond to the "event" of starting the application. Arguments can start with -arg, --arg on *nix, /arg on windows; they will be normalized to -arg before handlers are called. If a unix arg is the form --arg=param, it will be split into two arguments -arg <param>. Handlers are registered with the category manager (currently, you have to register with a contractID prefix and a category, which is kinda silly) and would be run in alpha-order thusly:


<table class="data">
{| class="data"
<tr>
|-
   <th>category <th>entry <th>value <th>(description)
   !category !!entry !!value !!(description)
<tr>
|-
   <td rowspan="5">command-line-handler
   |rowspan="5"|command-line-handler
   <td>b-jsdebug <td>@mozilla.org/venkman/clh;1
   |b-jsdebug
   <td>Handles -venkman and -venkman-sync flags to debug JS, even during startup
  |@mozilla.org/venkman/clh;1
<tr>
   |Handles -venkman and -venkman-sync flags to debug JS, even during startup
   <td>c-extensions</td> <td>@mozilla.org/extension-manager/clh;1
|-
   <td>Handles -install-toolkit-extension -install-app-extension -install-profile-extension flags
   |c-extensions  
<tr>
  |@mozilla.org/extension-manager/clh;1
   <td>m-edit <td>@mozilla.org/composer/clh;1
   |Handles -install-toolkit-extension -install-app-extension -install-profile-extension flags
   <td>Handles -edit &lt;URLOrPath&gt;
|-
<tr>
   |m-edit  
   <td>m-irc <td>@mozilla.org/chatzilla/clh;1
  |@mozilla.org/composer/clh;1
   <td>Handles -irc or -chat flags
   |Handles -edit &lt;URLOrPath&gt;
<tr>
|-
   <td>y-final <td>@mozilla.org/app-startup/clh;1
   |m-irc  
   <td>If there is a bare URL/file on the command-line, this opens a browser window with that URI/file. If there are *no* windows open at this point, it opens a default browser window.
  |@mozilla.org/chatzilla/clh;1
</table>
   |Handles -irc or -chat flags
|-
   |y-final  
  |@mozilla.org/app-startup/clh;1
   |If there is a bare URL/file on the command-line, this opens a browser window with that URI/file. If there are *no* windows open at this point, it opens a default browser window.
 
|}


The important thing is that the <strong>same command-line handlers would be used for a remote invocation (DDE or xremote) as an initial startup</strong>. This means that we can get rid of all the app-specific code in the xremote service. Firefox can keep a backwards-compatibility shim to handle the -remote flag. This would give apps equal-opportunity and silent access to argument handling. This is very similar to the way win32 DDEremoting works now, but somewhat different from the xremote model.
The important thing is that the <strong>same command-line handlers would be used for a remote invocation (DDE or xremote) as an initial startup</strong>. This means that we can get rid of all the app-specific code in the xremote service. Firefox can keep a backwards-compatibility shim to handle the -remote flag. This would give apps equal-opportunity and silent access to argument handling. This is very similar to the way win32 DDEremoting works now, but somewhat different from the xremote model.
1

edit

Navigation menu