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 <ale...@menard.io> 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
> Crosswalk-dev@lists.crosswalk-project.org
> 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
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
