Create io.github.leolost2605.extension-manager.json #495
Conversation
|
Hm yeah I think it might be better to instead create some kind of official path for publishing extensions in AppCenter |
|
Sure if you want I'll start working on some kind of ExtensionsBackend in AppCenter. Would something like this be accepted? If not I can just go to flathub to make it less of an "official" feature with appropriate expectations 🤷 |
|
@leolost2605 I think we have a few layers of problems to think about: Most important is that we don't have any API guarantee for anything that currently uses extensions and it's probably worth considering if we want to create the expectation of an extension API. We've broken API a lot in Code for example, the panel API will break soon when we port to GTK 4, and settings API has also broken and I'm planning to break it again. AFAIK the only 3rd party extension for settings has been tweaks which imo should be its own separate app. We originally had the idea that OEMs might write extensions for settings but this never materialized and they typically ship separate 3rd party settings tools. Another one of the driving reasons that we used extensions was because we were used xembed originally to make up for the fact that we didn't have all of our own settings panes. So this decision is rooted in some ideas and constraints that we don't have anymore and it might be worth reconsidering the value of even having extensions at all in settings. So I think the first thing to think about is which things do we even want to support extensions in. Another issue is that peas extensions run in-process which makes them a security and stability problem and I'm not sure how feasible it is to distribute them in Flatpak. Not distributing them in Flatpak would create further distro lock in which is a major trade off to consider. For the panel, if we're considering supporting 3rd party extensions, we should probably support a dbus API so these can be out of process rather than supporting in-process extensions. Which practically probably means just supporting ayatana OOTB. I don't feel great about adding 3rd party indicators because apps should really be using more purposeful API and historically we see a lot of abuse here, but I'd rather go down that road because it's at least theoretically cross-distro and already in use. Which kind of brings up another point about being good open source citizens and we should be doing our best to make sure API we encourage developers to adopt is not distro locked and something we can at least propose to freedesktop. I do think there is merit to making more things extensible though. We still have gaps in our portal coverage which would solve some issues with indicators. I think there's value in considering some kind of ongoing task or activity API like iOS which would solve more of the gap of what developers want from indicators. We probably could/should support some kind of search providers API like the GNOME one maybe. I'm not sure what other demands for extensibility there are but we should definitely look at those and see if we can solve them in a way that's cross-desktop and out of process |
This is a little flatpak app I put together that easily allows you to manage extensions for gala, wingpanel and switchboard. It basically works by telling the user to add a curated PPA and then using package kit and a list of known extensions with some extra information to show the user a list of extensions they can install and uninstall.
Ok so I know this might get rejected because it violates quite a lot of publishing requirements (first and foremost by basically being an appstore and adding and removing software, others like name and icon can of course be changed) however I think as it doesn't compete with AppCenter it might still be worth considering. Since many elementary apps like wingpanel, settings, gala, files, etc. have plugin systems built in I think there is a potential for a lot of extensions that can't be shipped natively because they go against design but are still very useful (e.g. lenemter/wingpanel-indicator-namarupa). IMO this currently is most hindered by not being able to easily find and install such extensions but instead having to look across github repos, add many ppas, or download debs etc.
So I'll take my chances on this one, let me know if there is the possibility of this getting accepted :)
Oh and btw if that's something that would be preferred I'm open to making it official however as I don't know how long this app will work (looking at immutable file systems coming) I'm not sure whether officially commiting to it is the right move 🤷
Review Checklist
AppData
Flatpak