xfce4-dockbarx-plugin
xfce4-dockbarx-plugin copied to clipboard
HugLifeTiZ
Future direction
Okay, so. XFCE4 is currently working on the move to GTK3, and I'd like to have some sort of plan for handling it. It might simply be a thing of using the GTK3 vapi instead of the GTK2 one, but it probably isn't. Not to mention XFCE4's vala bindings were unmaintained last I checked, which meant every new XFCE version carried the risk of them breaking. Luckily, they didn't, but major changes are in the pipes for 4.14 so I don't know if we're gonna get off lucky this time.
So here's something I was thinking. The plug already does a lot of work. Most of the work, really. The vala socket is really just a glorified embed plugin with a config dialog. And we already have an embed plugin in the goodies package. (Although it's not in Xubuntu's repos.) So what I was thinking about doing for a potential future direction is just to make this only a plug, designed to work with the embed plugin and, if possible, utilize its xfconf space for its own configuration. Which means this component would be nothing more than a python program, which then means it can be included in the official DBX distribution.
So basically it's try to catch up with the moving target 4.14 represents in order to keep being our own thing, or drop the socket entirely and focus on the plug, which means we depend on xfce4-embed-plugin but we can be included in DBX. Does anyone have any input on what would be preferable?
There is actually one thing that the vala plug provides that can't be duplicated in the embed plugin: autohide inhibition. The embed plugin would need some way to inhibit autohide if we were to depend on it, and some way to tell it "do inhibit right now please" and "you can stop inhibiting now". A dbus interface would be great for that.
Another thing that would be nice to have but I don't know if it does is a way for the embed plugin to tell anything it runs its plugin id. The plug currently uses this to determine what xfconf properties to write. I could see any embeddable application being able to make use of this, so I might make a feature request on the bug tracker.
A dbus inhibition interface might be a good feature for any program that wants to be able to pop itself into the panel via the embed plugin. Right now the embed plugin is meant to be agnostic toward the applications it embeds, which I think is great, but considering xfce4 bindings are pretty much nonexistent for every language but Vala, integrating facilities for talking to the panel into the embed plugin might be a good cause, as that would allow panel plugins to effectively be written in any language.
+1 on all of this. Quick question: why can't we just use vanilla DockbarX with xfce4-embed-plugin?
It won't blend in with the panel whatsoever. It draws its own background when it's run as DockX, so special care would be needed to make a dock theme that blends in. It also would manage its own size and probably not fit at all. And its orientation would be set independently of the panel orientation.
When you see the example of the Pidgin buddy list blending in perfectly with the panel, that happens because there is a gtkrc style that matches Pidgin's buddy list and forces it to blend. Embedded applications don't take any widget or style information from its parent. So it just has to match every Pidgin buddy list. If the buddy list were opened independently of the panel with that gtkrc style still in use, it'd be the same color as the panel.