Platform/shell-integration-application-plugin
I got this idea today as a result of how fragmented the Linux world is becoming, though I'm not such an experienced desktop application developer so please tell me if this isn't going to work.
The problem lies within that there are a multitude of shells for an application designer to target, the following are some of the more popular ones: Unity, GNOME-Shell, KDE, XFCE, LXDE, Cinnamon and soon also Pantheon. If one wants to design for multiple platforms as well, e.g. Mac OS X and Windows - which is highly likely because of GTK's cross-platform capabilities, there are even more things to consider if you want your application to support: Unity Launcher API, Global menu, GNOME-Shell's new AppMenu, Elementary's "cog", Windows jumplists/
All the above is a lot to ask of a developer maintaining several applications. So how about making a shell-integration plugin to either Granite or upstream GTK, which on application startup defines what environment the application is running in (or have this done at compile time) and then integrate the application into the environment appropriately.
It could work by having a folder in the application directory called "integration" and there have sub-directories for each environment it wants to support. The "standard" environment contains a XML-file called menu-bar.xml with hierarchial nodes representing the menu bar. Then "unity" could contain XML-files defining the badges and quicklists. "pantheon" contains a file with the menu and a mapping to a placeholder within the GUI - same for GNOME. If an environment's integration isn't defined it defaults to the “standard” configuration.
All the developer would have to is define these XML-files and run shell_integrati
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- New
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
Sounds like a DE abstraction layer. Might be a good idea. --shnatsel
That's exactly how I'd describe it. Thanks for reading the blueprint! -- Niklas
I think the real solution lies in sharing APIs. For example, when Plank will implement badges and progress bars it'll use the same API as Unity. A developer shouldn't even care about in which DE/shell his app will be running (unless it uses some specific features), he just writes code than renders differently the same concept in different DE/shells.
This a simpler approach, but require works from DEs/shells themselves. If this doesn't happen, probably the solution is to write a layer that converts from standard to that specific DE/shell because is the DE/shell that needs fixing, not the app itself. Even if it's not accepted upstream, a developer that want consistency across DE/shells without writing more code just needs to set the conversion layer as a dependency.
tl;dr: No layer in the middle, just DEs sharing API. --voluntatefaber
@voluntatefaber, what you described only works for shell integration regarding docks, it doesn't take into consideration the different menu systems which are emerging -- Niklas
@Niklas: why? You can apply the same idea to menus as well -- voluntatefaber
@voluntatefaber: Maybe you can, but it would be downright impossible to get GNOME, KDE, Unity, XFCE, LXDE, etc. to implement these changes. If I'm not mistaken you'd have to patch all toolkits as well, but then again, I don't have so much experience in developing desktop applications so I may very well be wrong. -- Niklas
