Calling arbitrary D-Bus apis. Feel free to limit it to D-Bus calls that are listed in .desktop (or other file) and thus known at install-time, but just don’t limit what people want to do with D-Bus.
I suspect this needs work in the compositor. Which brings us to the problem of it. Even with xdg-shell added -which solves the app issue- it doesn’t address a huge amount of missing features which i suspect could also be also used for Jollas automotive venture. (ie multiscreen).
I really wish predictive text could be simply toggled on and off without having to uninstall the whole thing. Some applications don’t play nice with it.
Well, the build of libsailfishapp library would need to register the stub object for the DBus interface. Of course there’s the problem with the naming of the interface; but maybe, just maybe there’s a way around it (via an external / weak ref in the libsailfishapp for example). Assuming this could work, the libsailfishapp could then provide (via script run in the app’s spec file) the templates for on-the-fly generation of stub headers / source files to be built in the code base of the actual application; of course the developer would maybe need to provide some info in the spec file (Organization Name / Application name); “maybe” because it appears the booster takes the name of the exe file as app name… maybe possible; then again; on linux, very many things that seem impossible end up being actually possible
Sorry but Nightish is just not an alternative. It turns the entire screen yellow (or another specified color), so if you are using an OLED it actually makes the screen brighter at night.
EDIT: wlsunset is nice, I’ve been using it for years on my Linux desktops.
