Feature #1202
closed
Add support for dynamically loading features.
100%
Description
A plugin API is needed to allow an app to install in the launcher.
The app will show up in the status bar. Order will depend on app-name sorting, left justified.
The launcher should limit the number of plugins allowed - start with 6 so the time bar and network status are not squished.
The plugin API will use dynamically loaded objects.
- https://hackaday.com/2018/07/12/its-all-in-the-libs-building-a-plugin-system-using-dynamic-loading/
- https://tldp.org/HOWTO/Program-Library-HOWTO/dl-libraries.html
Don't use glib features. Keep it simple. We just need an API that retrieves the icon filename and a function called "go()" that gets called when the use touches the icon in the status bar.
Related issues
Updated by Hammel 22 days ago
- Blocks Feature #1201: Add Pairing apps to launcher in imrest added
Updated by Hammel 21 days ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
I don't think I want a plugin API because it requires cross-references between apps. I want apps to be independent when compiling.
The way around this is to extend the XML structure that apps configure themselves with in the launcher.
<?xml version="1.0" encoding="ISO-8859-1"?>
<launcher>
<appName> [APP NAME] </appName>
<author> Michael J. Hammel </author>
<contact> mjhammel@graphics-muse.org </contact>
<command> [path to program] </command>
<icon> [path to icon under launcher config dir] </icon>
<icon2> [path to icon under launcher config dir] </icon2> -- new
<icon3> [path to icon under launcher config dir] </icon3> -- new
<splash> [path to splash image, if used.] </splash>
<description> ... </description>
<type> [1: launcher, 2: status bar (defaults to 1 if not listed) </type> -- new
<hash> [8 characters] </hash>
</launcher>
The icon is displayed at config time.
When the icon is selected the app is launched via appmgr.
The selected app connects to launcher unix domain socket at /var/run/launcher.socket, sending 8 character id and icon ID to change the icon. ID is 1 (use default icon), 2 or 3 to select icon or 0 to animate icon between 1,2 and 3.
By using a domain socket there is no need for cross-reference in app building, just configuration in xml.
Note that the read in launcher on the domain socket must timeout so launcher doesn't get stuck if the other app locks up or goes to sleep or something.
Updated by Hammel 16 days ago
I'm not sure I really want to do this after all. It seems overly complex. An app can add multiple icons with multiple xml's. Each can have an app command that routes through appmgr. PiNet, for example, can have command line options to "down" or "up" network interfaces. Launcher can query network interfaces (it already does that, but could be expanded to query both wired and wireless interfaces).
This task is for enabling pairing from the launcher via the status bar. So we just need an app that is run by pressing the status icon to enable pairing by signaling imrest to enable it. The updated xml is much simpler for this.
<?xml version="1.0" encoding="ISO-8859-1"?>
<launcher>
<appName> [APP NAME] </appName>
<author> Michael J. Hammel </author>
<contact> mjhammel@graphics-muse.org </contact>
<command> [path to program] </command>
<icon> [path to icon under launcher config dir] </icon>
<splash> [path to splash image, if used.] </splash>
<description> ... </description>
<type> [1: launcher, 2: status bar (defaults to 1 if not listed) </type> -- new
</launcher>
Updated by Hammel 11 days ago
So this needs to be a little different than the separate drawing areas of the main launcher icons.
It's a single row, so I can calculate how many icons I can draw (displayWidth/2 / STATUS_H).
I then draw the network icon first, then iterate over the remaining icons up to the max available.
The left half of the status bar is the date/time.
Touches on the status bar can identify the icon by computing the offset, identifying the square of the icon and computing the index into the appStatusBar list.
Updated by Hammel 11 days ago
- % Done changed from 20 to 30
This is implemented. It needs to be tested with some fake apps installed.
The code for handling status bar touches is also not implemented yet. The iconTouchGTK() just needs to test if the ABS position is < STATUS_H. If it is, then the touch is in the status bar and can be handled separately.
Updated by Hammel 9 days ago
- % Done changed from 40 to 70
Tested on hardware and bugs fixed. Basically works but configured app is not run so I added test scripts to run instead.
Need to rebuild pkg to pick up new test scripts and rerun tests for completeness.
Also need to rebuild rpi2 libpibox to pick up fixes for touchProcessor.
Updated by Hammel 7 days ago
This is now working with the test apps in the status bar, but it's not enough.
When the app completes, appmgr notifies launcher with a simple SIGUSR1. Launcher then updates all icons when it gets that signal.
The test apps need to have "on" and "off" icons with a symlink from "default" to "off" initially, with "default" being the icon name in the xml config. When they toggle, they change the symlink.
When the test apps exit that causes appmgr to signal launcher. Launcher currently updates the drawing_area icons only. It can be updated to add a g_timeout() that calls status_exec(), which will update the status bar icons.
However, the status bar icon images are not currently dynamic. So status bar apps will need to reload their icons and rescale them every time launcher is signaled by appmgr. Since they should be small this shouldn't be a problem. To just reload the app that just ran the SIGUSR1 could be changed to a UNIX_DOMAIN socket and the appmgr could simply say which command it ran. Then launcher could search for that one, reload it before updating the status bar icons in the display.