On Monday, 2013-08-12, Stephan Sokolow wrote: > On 13-08-12 12:10 PM, Kevin Krammer wrote: > > On Monday, 2013-08-12, Stephan Sokolow wrote: > >> On 13-08-12 07:28 AM, Kevin Krammer wrote: > >> I was actually referring more to getting adoption outside LXDE. > >> Obviously, if it's a requirement for LXDE, it'll get packaged, but > >> getting other developers to support it, when they may already be > >> supporting libappindicator and XEmbed, could be tricky. > > > > Ah, I see. Yeah, that could be tricky. > > I guess its full featuredness could be a selling point, i.e. it would > > allow to have one solution that can deliver a full or close to full > > XEmbed feature set, full feature set for DEs with respective host > > implementations but still be able to provide the limited integration > > Unity wants to offer. > > That and it could also advertise "no need to worry about getting the > behaviour just right on the XEmbed fallback" as a selling point. > > ...though, if I'm reading the KStatusNotifierItem documentation > correctly, it'd make a lot more sense to have a method named > "setAssociatedWindow" or "setMainWindow" rather than > "setAssociatedWidget" since it's just going to call parent->window() > anyway if not given a top-level window.
I agree. It is probably just a side effect of "everything" UI in Qt4 being QWidget, including top level windows. > >> Either way, it's more work for developers who may have only just started > >> supporting libappindicator. > > > > True. But they might have run into limitations already and look for > > alternatives. > > Point. It'd probably make more sense to name the library after the spec. > > Then work could be done to teach various developers about how > "AppIndicators" are a restricted subset of the spec and, by using this > library, you get an API that is, for all practical purposes, actually > slightly richer than the APIs offered by XEmbed wrappers like > QSystemTrayIcon, GtkStatusIcon, and wxTaskBarIcon expose while also > automatically giving no-effort support for AppIndicators and "Do The > Right Thing™" support on touchscreens. Right. I assume that the KDE Framework that ends up having KStatusNotifierItem will be advertised similarily. > I say "for all practical purposes" because wxTaskBarIcon gives you an > API that's richer in impractical ways. Specifically, it lets you bind > individually to mouse movement and press, release, and double-click for > left or right mouse buttons. > > aMule uses this facility to provide the only tray icon where not only > does it make the newbie mistake of toggling rather than raising if the > window is present on one of the user's desktops but not visible, it > ignores left clicks and requires you to double-leftclick to toggle > window visibility. Oh, interesting! > > Yeah, that option is often overlooked [1]. I guess early D-Bus libraries > > like dbus-glib were awkward to use, so people started to create > > abstractions on top of it. > > > > After some time people started to forget that the actual interface of a > > D-Bus service is its D-Bus API. > > Probably because they're so used to thinking in terms of bindings to > libraries where the raw C API is so painfully low-level for languages > and frameworks with a higher-level solution. Yeah. C libraries just used to be *the* access layer and it often makes still sense. But for protocols and especially D-Bus there are often nicer ways in a given technology. > It also doesn't help that dbus-python (and, hence, DBus for PyGTK) is > still a pain in the ass to use because whoever designed it was either > inexperienced or lazy. As a result, it's often more comfortable to call > something's D-Bus API via C bindings on a helper library than via > dbus-python. (Even the PyGI-introspected C bindings are much better) Oh, didn't know that. Whenever I came across anything Python it looked really nice and easy to use. I just had assumed the same would apply to it D-Bus support library/module. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
