IMAGINARY / applauncher2

A graphical application launcher based on web technologies Mk2
Apache License 2.0
5 stars 1 forks source link

Configuration via single file #12

Open porst17 opened 5 years ago

porst17 commented 5 years ago

The current app.json format kind of requires to have a separate folder for each app. For simple use cases, I would rather prefer a single file containing the whole applauncher configuration such that there is only one config.yml containing everything. Icons could just be specified via the icon property discussed in #6.

This is really just a nice-to-have and probably not too well thought-out. I understand the reasoning for the separate folders and app.json files (modularity), but it is quite cumbersome to replicate this structure if you need to put something together quickly.

elondaits commented 5 years ago

The idea with app.json files is that each exhibit exposes its metadata in a way that any of our meta-apps (launchers, IMAGINARY OS, etc.) can consume it and know more about them... so that's why it is like it is... so I kinda need the standardized name, etc.

... In fact, in an ideal world the app.json files would be in the repository of each app, with their icons. It's a bit accidental that we have a repository of app.json files.

At any rate the current scheme shouldn't be a problem with regular exhibit apps (Mappa Mundi, Cindy Apps, etc.), but I know and understand that it's an issue in "special" cases such as Con Espressione, or the OEIS player where the things we're launching are not actually apps and we're just creating directories with a single app.json file for no other reason than to match the required format (In the OEIS Player I even created a script that generated the app.json files out of a JSON database of songs).

... So I guess that this can be supported in some way. Adding it to config.yml is a possibility but I'm not completely sure it's the best place (although config.yml already allows overriding properties from app.json).

... In any case I'm also thinking about supporting paging and "folders" (two features we felt we needed in the past and would need to use appLauncher as the main menu in IMAGINARY OS), both of which would require a change in the way the list of apps is declared in config.yml. So I'd take a look at this at that point most likely.

elondaits commented 5 years ago

PS: Consider that app.json has data like the app's name translated to every language, the resolution it requires, etc. which you wouldn't remember and needs to be maintained and versioned with the app. Modularity, as in recombining exhibits like LEGO to build new menus is also important, but almost secondary.

The case for having a single config is more related to these cases like Con Espressione or OEIS where the apps are pseudo-apps / triggers.

... Perhaps the solution would be a JSON file (appbundle.json, or app.json with a different internal format) that has an array of app.json definitions inside... so you could cover these cases and even modularly handle combining them.

porst17 commented 5 years ago

What about putting the app definition inline into config.yml? Each entry in the apps section could be a file name or inline app definition like so:

apps:
    - apps/my_app1
    - id: "my_app2"
      version: "v1.0"
      type: "iframe"
       ...
elondaits commented 5 years ago

That's the obvious case I'm not too sure about (but consider, by default). Config.yml already supports overriding app.json properties and there's a case for separating the app definitions and the list which indicates the order in which to display them (+ folders, +paging).