imaginary / applauncher2 Goto Github PK
View Code? Open in Web Editor NEWA graphical application launcher based on web technologies Mk2
License: Apache License 2.0
A graphical application launcher based on web technologies Mk2
License: Apache License 2.0
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.
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).
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.
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.
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.
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.
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
.
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.
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.
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?
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.
Add to the documentation (or make more prominent):
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.
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.