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
