From: Kevin K. <kr...@kd...> - 2013-08-11 16:22:48
|
On Sunday, 2013-08-11, Stephan Sokolow wrote: > On 13-08-11 06:25 AM, Kevin Krammer wrote: > > I see. > > I guess there is very little point in using a wrapper library written for > > a different tool stack, basically using an abstraction that can easily > > be achieved directly using the tools at hand (qdbusxml2cpp). > > > > [...] > > > > Sure, but it is always the responsibility of an application developer to > > chose libraries based on their capabilities. If a library only > > implements a subset of a given spec and the application developer wants > > to have all options available the developer will simply not use that > > particular implementation. > > > > I don't see a chicken-and-egg problem there. Applications that want to > > offer full capabilties for hosts that make use of all capabilities will > > just do that. > > A host implementor who wants to provide all capabilities will to just > > that independent of whether some applications only use a subset. > > I'm more concerned about application developers either mistakenly > resigning themselves to a crippled API because they don't know or > choosing it because they don't want to screw around with reinventing > libappindicator for their GTK+ app. Ah, I think I understand the problem a lot better now. I was mostly considering this from a point of view of the tray implementor who would not be affected by that. > For example, I use Deluge as my torrent client but I use their legacy > tray icon support because their libindicator support seems to only > provide a context menu. Not all developers maintain a legacy-mode toggle. Sounds to me like the GTK world needing something like KStatusNotifier, which encapsulates traditional XEmbed icon and D-Bus interface so application developers don't have to do that all by themselves. However, I admit that I don't know anything about GTK based application development, maybe using separate APIs explicitly is the preferred way and the thing that is missing is a fixed/extended version of libappindicator or a library implementing the spec with less focus on Unity. > >> The reason I asked about the KDE one is that KDE is a big enough target > >> that, if they offer an alternative with a richer API, then there's hope > >> that it could gain enough inertia to catch on as the de facto standard > >> apps support if available. > > > > Right. I don't know if it is an extension or already part of the > > specification. > > It looked like part of the normal interface to me. > > I looked into it a bit and it seems that listening to scroll events and > binding a secondary action ARE supported by libappindicator... the > problem is that libappindicator's API docs claim that it will enforce > that the primary action is a GtkMenu and will only activate the > GtkWidget passed as the secondary action when it's present as a > non-hidden, non-inactive entry within that menu. Interesting. The way I read the KDE implementation is that it consideres the context menu as secondary activation by default, probably overridable to offer primary activate, secondard activate and menu. Hmm, maybe libappindicator is just too focused on Unity and GTK application development needs something that implements status notifier more independently. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |