From: Kevin K. <kr...@kd...> - 2013-08-11 16:42:16
|
On Sunday, 2013-08-11, Stephan Sokolow wrote: > My main concern is that there are a lot of GTK+ apps out there and, if > that's not a KDE-specific extension, then it may require convincing each > developer to buy into using something other than libindicate since it > doesn't seem to provide a way to access it in the manner you described. I don't know how GTK application developers pick the libraries they want to use but they will probably look at other applications, so leading by example might work. Also, when the switch to Wayland moves away from XEmbed, they might be looking explicitly for an alternative. Whether that is libappindicator or a different library might depend on what features each provides, no? > The AppIndicator class does provide a scroll-event signal but, as far as > I can tell from the API docs, it imposes these rules on toggling main > window visibility: > > 1. The indicator won't be visible unless you register a menu for things > like Unity to display on left-click and right-click using set_menu() I guess that makes sense, i.e. every "icon" should probably have a menu, even if it just contains "show/hide" and "quit". But maybe that could be made configurable. > 2. set_menu() ONLY accepts a GtkMenu object. Sounds reasonable to me. > 3. You can register a "secondary acctivate target" which things like > Unity will bind to middle-click using set_secondary_activate_target() > > 4. The secondary activate target will only be called if it's a visible > and active child of the GtkMenu you passed via set_menu(). > > 5. I can see no way to swap the actions so the menu is the secondary > action and the visibility toggle is the primary one. My best guess is > that ItemIsMenu is a KDE-specific extension. It was my guess as well but to be sure I asked Marco (CCed, thanks a lot for your insights) since he is the original author of the spec. He says "yes, [it] was an extension done together with ubuntu because iirc they wanted the possibility to only open a menu, always (instead of activating the application with left click, menu with right click) and is supported by kde." He further says "the complete api that we expose on dbus (for the StatusNotifier object part) is on the file /kdelibs/kdeui/notifications/kstatusnotifieritemdbus_p.h (with some apidoc as well) thinking about it, [LXDE] could even take those classes and replace K* with Q* since the kde dependencies are not many (in frameworks is already standalone, as tier2, perhaps may be even more stripped to become tier1, don't remember exactly what other tier1 stuff it needs right now)" > bind a non-menu to left-click using libindicate, so I'm guessing that's > a KDE-specific extension. (However, if anyone can demonstrate that > Amarok's indicator works as expected in Unity, then that would indicate > that the restriction is being enforced in libindicator rather than the > panel host) I guess it could be done on either side but that sounds like a good test indeed. Maybe KMix would be an even better test target, it has a left-button popup, a menu and uses scroll handling. > Source: > http://developer.ubuntu.com/api/ubuntu-12.04/c/appindicator/libappindicator > -app-indicator.html > > The KStatusNotifierItem API docs seem to bear this out, since, unlike > AppIndicator, it provides a rich API with methods like > setAssociatedWidget and ordinary signals like activateRequested and > secondaryActivateRequested alongside the more ordinary setContextMenu > method and scrollRequested signal. Being the origin of the idea it is probably the most complete implementation. > In fact, given the documentation for setContextMenu and > setStandardActionsEnabled, it looks like KStatusNotifierItem is designed > around the idea that most applications will want to bind a window to > left-click and just let KDE itself auto-generate a context menu with > actions like "Quit" for the right-click. Yeah, that's the behavior KDE workspace users would expect and from what I've read here seems also what LXDE users do expect. But it still seems to be flexible enough to get a behavior Unity users expect when applications run in Unity. Cheers, Kevin > Source: > http://api.kde.org/4.5-api/kdelibs-apidocs/kdeui/html/classKStatusNotifierI > tem.html > > On 13-08-11 06:33 AM, Kevin Krammer wrote: > > On Sunday, 2013-08-11, Stephan Sokolow wrote: > >> On 13-08-10 01:07 PM, Kevin Krammer wrote: > >>> I am not sure how it does it exactly but it definitely does it. > >>> E.g. left clicking the Amarok icon toggles main window visiblity and > >>> Amarok is using KSystemNotifierItem for its tray integration. > >>> > >>> I did a quick code search and it seems this is communicated via a > >>> property on the D-Bus object. If the property "ItemIsMenu" is true, > >>> left click will call the ContextMenu D-Bus method, otherwise (propery > >>> is false or missing) it will call the Activate D-Bus method. > >> > >> Ok, that's a relief. I checked all of my tray icons and it looks like > >> the developers could implement something comfortably sane with that kind > >> of "one action, but you choose which one" limitation, should they choose > >> to drop the XEmbed implementation. > > > > There are separate calls for "Activate" and "ContextMenu". An application > > can provide both. The host can call Activate on left-click and > > ContextMenu on right-click. > > > >> 1. Pidgin (I don't mind only having "toggle visibility" and the context > >> menu does have a lot of stuff that is used infrequently enough to be > >> only accessed via the main window (eg. shortcuts to the accounts and > >> preferences dialogs), but I can see people complaining about needing an > >> extra click to do things like changing their status to/from > >> Away/Busy/etc.) > > > > Kopete uses both. > > > >> 2. Audacious Media Player (Not everyone uses the global keybindings > >> plugin to toggle main window visibility like I do, I wouldn't want to > >> HAVE to take my hand off the mouse to toggle visibility, and the context > >> menu has useful options like Play/Pause and "quit the damn application > >> so I can re-launch it to get the playlist responding to keystrokes > >> again") > > > > Amarok does both as well. > > > > Just examples of programs I use that offer different functions for > > different mouse button clicks. > > > > Cheers, > > Kevin > > > > > > > > ------------------------------------------------------------------------- > > ----- Get 100% visibility into Java/.NET code with AppDynamics Lite! > > It's a free troubleshooting tool designed for production. > > Get down to code-level detail for bottlenecks, with <2% overhead. > > Download for free and get started troubleshooting in minutes. > > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clkt > > rk > > --------------------------------------------------------------------------- > --- Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |