imaginary/applauncher2

A graphical application launcher based on web technologies Mk2

applauncher2's Issues

Support config.yml files outside the cfg directory

Currently, the configuration supplied via index.html?cfg=mylauncher is resolved to the path cfg/mylauncher.config.yml. This requires the configuration to be part of the applauncher subtree, i.e. it is not possible to host the applauncher separately from the configuration.

It would be very usefuI to be able to specify an arbitrary location (URL) for the config file. Either absolute or relative to the index.html. Other files should be resolved with respect to that config file, not with respect to the cfg folder.

A frequently occurring use case is to host a launcher on github. The repository contains the applauncher config and all necessary files (icons, themes, plugins). The applauncher is linked into the repository by means of a git submodule. Now it is possible to serve the repo automatically via GitHub pages. GitHub will automatically checkout the submodule for us, but the submodule does not contain a valid config. So far, an install script is required that copies the config into the cfg folder, but this install script can not be used by GitHub's automatic deployment mechanism. So being able to specify a config outside of applauncher's directory would just solve the issue.

Another use case would be to host the applauncher separately from its config and just link it together via URLs, e.g. https://rawcdn.githack.com/IMAGINARY/applauncher2/v1.9.2/index.html?cfgFile=https://myhost.com/config.yml. In this case, specific version of the applauncher could directly be served via e.g. https://raw.githack.com/ CDNs (CloudFlare ATM).

Using a new URL parameter like ?cfgFile would make the change backwards compatible. Precedence rules for ?cfg and ?cfgFile have to be defined.

Allow language codes with longer ids

The following regexp is used to validate language code:

AppLauncherLoader.validLangQS = /^[a-zA-Z]{2}(-[a-zA-Z]{2})?$/;

This was done thinking about lang-country formulas such as es-ES and es-AR, but it could be changed to support other language codes such as zh-Hant, or sr-Latin.

Change the limit of the second part, but still have one (e.g. 10-12 characters).

Back/exit button for executable apps

Currently, external executable apps need to provide their own way to exit to get back to the applauncher. Most executable apps don't provide such a mechanism because they rely on the window system to deal with that and workarounds like qclosebutton are not ideal and quite annoying to work with.

The back button introduced in #4 could be used as a close/exit button so we could have the same visuals for all kind of apps. I imagine implementing this by opening an additional BrowserWindow of the kiosk browser/electron that is semi-transparent, always-on-top and covers only a small part of the screen. This should be implemented by some plugin I guess because it would only work from within an electron based browser with node integration. On the other hand, the executable apps are currently implemented within the applauncher. So I am not sure about the best place to implement this.

Locale propagation to apps

If a specific locale has been set for the applauncher, how is this setting propagated to iframe apps? I can see it being forwared via LANG for executable apps, but iframe apps?

Also interesting for nested applaunchers.

Configuration via single file

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.

Return to menu on idle

After some time idle the launcher should return to the main menu. This might not be easy because of the use of frames not to talk even about launching external apps.

... A screensaver could be used that on launch sends a signal to the appLauncher / kiosk browser and then exits.

Support icons other then icons/icon.png

PNG is not always the appropriate image format. E.g. photos respectively any image containing fine detail or a lot of noise can not be compressed well using the PNG format.

It would be good if the applauncher could also use icons like icons/icon.jpg, icons/icon.gif etc.

Another addition would be a config option for app.json to provide arbitrary URLs (remote, relative, absolute) for the icon. The above defaults (icons/*) should be used if the icon option is not present in app.json.

Support web browser back button to exit an app

I didn't test this thoroughly, but go to https://imaginary.github.io/applauncher2/, select an app and hit the back button it your browser. It's not leaving the app and going back to the main applauncher menu. Not sure if this is easy to implement (history.pushState() + onpopstate event?), but IMO it would be the expected behavior.

Fullscreen apps

Many apps are supposed to run full screen and not within the applauncher. Mostly, they just look weird, because they are designed to run in FullHD 16:9.

It would be great to be able to run certain apps inside an <iframe> that covers the whole screen and that is overlay-ed with some kind of back button whose location should be configurable in app.json (e.g. top-left, top-right, bottom-left, left, none etc). That button should be themeable as usual.

Apps maintained by us could also check for applauncher integration via the global IMAGINARY property and provide a back button themselves at an appropriate position within their UI (themed like the app itself). But it is unlikely that we will ever manage to do so and also doesn't work for apps hosted by a third party.

idea: background image

I think it will look cool if one would be able to use some background image instead of the single-color background.

It should work nicely with application icons since they are required to have a transparent background.

I would specify that image in a theme file instead of background color.

What do you think @porst17 ? Or is it already possible to do?

Title not correctly resized in Safari

If the appLauncher is opened in a new / empty tab in Safari and the title is long (e.g. "Matemáticas para tocar", the spanish language title of "Math to Touch" / Cindy) it doesn't get properly resized. Resizing the window or reloading the page fixes it.

If local fonts instead of web fonts are used the problem does not present itself.

This bug is properly due to a timing issue where the title is set and resized before the web fonts get loaded. An attempt was made to fix this by resizing on document.fonts.ready, but it didn't fix it... perhaps because this is called before the actual rendering of the title.

Document requirements better

Add to the documentation (or make more prominent):

• The need for an electron browser with nodeIntegration: true, or kiosk-browser for launching executable apps.
• The need for a web browser.

Race condition in plugin loading

I ran into a race condition related to plugins. See this example config:

{
  "id":  "con-espressione-launcher",
  "version": "v1.0",
  "scripts": [
    "../../../lib/webmidi.js/2.3.2/webmidi.js",
    "../../../src/js/configParser.js",
    "../../../src/js/midiBackendProxy.js",
    "js/con-espressione-launcher.js"
  ]
}

The first three scripts are libraries and utilities. The last one depends on the other ones to be loaded. In some rare cases, certain objects that should be defined through the libraries were not present when con-espressione-launcher.js was executed. Adding console.log statements to all the scripts revealed that the order of execution is not deterministic and that con-espressione-launcher.js is sometimes executed first, probably because it is rather quick to load compared to the WebMIDI library.

The issues seems to arise from the loop in src/applauncher.js. The <script> tags are all created and inserted at the same time, but each <script> tag should probably only be inserted after the load event of the previous one has been emitted. This will probably cause some delays because fetching the scripts isn't done in parallel anymore, but I don't see any other option to prevent non-deterministic loading.

Pick up users default language when no lang is set via config.yml or URL parameter

If no default language is supplied in config.yml or via the URL parameter lang (respectively, unset via index.html?lang=), the chosen language should be based on navigator.language.

The main use case for this is hosting applauncher instances online where the default language is more likely to change frequently compared to local setups.

Add URL parameters to overwrite/invalidate config options

It should be possible to overwrite certain config options like e.g. lang such that it is easy to switch the default language even if one has already been specified in config.yml.

For lang, it would also make sense to be able to invalidate the value supplied in config.yml via e.g. ?lang= such that the default language would be picked up by the system settings (window.navigator.language). I can also open a separate issue for this detect-reasonable-defaults feature.

Not sure about other URL parameters besides lang. That's currently the only one that comes to my mind.

Use separate namespace for user-defined variables in app.json

When writing remote plugins, it is possible to add arbitrary properties to app.json to be used from within the plugin (forwarded via function run(appCfg, lang, onClose) to the plugin). In order to avoid name clashes, plugins would usually add some kind of prefix to their properties, but I don't think it is good practice because you have to make sure that the prefix will never be used by applauncher.

Providing a dedicated scope for user defined properties would solve this. I imagine something like

{
  "id": "my_app_id",
  "version": "v1.0",
  "type": "remote",
  "main": "my_plugin",
  "userdata": {
    "property1": "value1",
    "property2": "value2"
  }
  "name": "A cool app name",
  "description": {...}
}

Since arbitrary properties can already be defined by the user, I would probably suffice to document somewhere that the scope userdata is safe to put user-defined stuff there.

The name userdata is subject to discussion. I am fine with anything as long as it's fixed and documented.