Thanks for the context and discussion. The "approot/manifest.json" solution looks good to me.
Thanks, -ningxin > -----Original Message----- > From: Crosswalk-dev [mailto:[email protected] > project.org] On Behalf Of Alexis Menard > Sent: Friday, May 27, 2016 10:11 PM > To: Staudinger, Robert <[email protected]> > Cc: [email protected] > Subject: Re: [Crosswalk-dev] Intent to Implement : auto start of Crosswalk > applications without command line arguments. > > It will work too. > > On Fri, May 27, 2016 at 6:19 AM, Staudinger, Robert > <[email protected]> wrote: > > Hi Alexis, > > > > what if we just used a hard-coded name for the subdirectory that holds > > the app content? > > > > E.g. > > > > com.example.foo/ > > + xwalk.exe > > + locales/ > > + pak etc > > + wwwroot/ (for lack of a better name, maybe approot/ ... you get > the idea) > > + etc ... > > > > On startup, xwalk would always look for wwwroot/manifest.json relative > > to its own dir. > > > > Do you think that would work? > > > > On 23 May 2016 at 19:51, Alexis Menard <[email protected]> wrote: > >> Hi, > >> > >> [Disclaimer] This intent is meant to start discussion so I'm looking > >> for feedback [/Disclaimer]. > >> > >> The feature is a requirement for Project Centennial support or > >> Crosswalk apps on the Windows Store. > >> > >> In the context of the Windows Store, applications do not take any > >> command line arguments. They have an entry point and there is no way > >> to pass a command line arguments like on old school Win32 apps. They > >> expect to launch themselves and do their work. Of course this does > >> not fit with Crosswalk for several reasons starting with the fact > >> that the manifest used to launch the app is passed as a parameter, > >> also many debug options are passed to the main xwalk executable, or > >> external extensions are specified as a command line argument. Please > >> note that this limitation does not apply to the processes that xwalk > >> spawn as we use the Win32 API to spawn them (for example extension > >> process, render process or gpu process do not suffer that limitation). > >> > >> In my POC to support these apps I've implemented a quick solution. I > >> would like to merge a solution to Crosswalk master so that we're > >> ready for Centennial at the release date (~Summer 2016). > >> > >> Some context is now needed to fully understand the problem. The > >> Crosswalk apps on the Store is achieved using the Centennial tool > >> that Microsoft has released (works only with the latest Windows 10 > >> Insider builds). The tool takes the .msi that app-tools produces and > >> convert it to a UWP App (or to be more exact, it produces an .appx). > >> That app can then be signed and sideloaded on your dev machine (or in > >> the future ready to be uploaded on the Store). > >> > >> Back to the problem, here are the 3 solutions I thought could be > adopted : > >> > >> - Teach app-tools to write the startup path (the manifest) and the > >> command lines arguments to the registry. The registry is emulated in > >> Centennial so it doesn't pollute the main registry. Crosswalk will > >> then read the registry in case there is nothing to launch (nothing > >> was passed as a parameter). This is obviously a Windows only solution > >> and Registry is considered as a legacy from the Microsoft standpoint. > >> If we plan to move that feature to other platforms for some reason, > >> it's not going to work (that said maybe there is no need). > >> > >> - Teach app-tools to create a startup.json file with all the > >> information needed for Crosswalk to start itself (as well as command > >> line arguments specified by the dev) if there are no arguments passed. > >> This file is created when producing the .msi. This is the solution I > >> currently used in my POC. It's working great. The solution could be > >> cross platform if needed. Crosswalk will then read that file when > >> starting. > >> > >> - Modify the .msi structure when installing a crosswalk app so that > >> the developer application is not anymore in a separate directory. For > >> example as of today applications are getting installed in C:\Program > >> Files\myappname where the root contains all xwalk files (xwalk.exe, > >> locales/, ...). The actual application is in a subdirectory > >> myappname/ : developer files are then separated from xwalk files. We > >> could modify that and put all the files inside the root dir of the > >> applications. Then xwalk will just try to read the manifest.json of > >> the app which is located alongside xwalk executable. > >> > >> Thoughts? > >> > >> Thanks. > >> _______________________________________________ > >> Crosswalk-dev mailing list > >> [email protected] > >> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev > > > > > > > > -- > > Intel GmbH - Registergericht Muenchen HRB 47456 - Dornacher Strasse 1, > > 85622 Feldkirchen, Germany > _______________________________________________ > Crosswalk-dev mailing list > [email protected] > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev _______________________________________________ Crosswalk-dev mailing list [email protected] https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
