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'm assuming that's used to abstract away a unified, bug-free
implementation of "If the window is already open but on another desktop
or buried behind one of the windows on this desktop, raise it rather
than hiding it." If not, that should be included too.)
...which reminds me. Speaking of bugs related to multiple workspaces,
where am I supposed to complain about PCManFM's naïve "open as new tab
in existing window" behaviour? The "Bugs" section of the SourceForge
issue tracker?
The one potential gotcha I can see there is the "toggle vs.
raise/switchDesktop" code. It should be be available independently in a
very general form so developers don't have to reinvent the wheel if they
want something like a global hide/show keybinding. (I say "very general
form" because, if it's going to be the universal implementation of the
"do we hide, show, raise, or move it to the current desktop" logic, it
has to be flexible enough that projects like Yakuake don't shun it for
having an API incompatible with glitz like their animations.)
>
> Are there many project that target Debian stable with newer releases of
> themselves?
>
I don't know about explicitly targeting it, but I do remember
occasionally bumping into projects where Debian Stable compatibility was
one of the factors considered when deciding whether to make a change.
For Slackware, the biggest reason it's relevant is that converted
Slackware packages are the main way people add new applications to the
popular Slax and Porteus LiveCD/LiveUSB distros... and I'm not sure
about Slax, but Porteus offers both RazorQT and LXDE ISOs.
(And, prior to their new ISO-building system, they let you choose LXDE
as an alternative to the default desktop on boot)
>> If you make it a drop-in replacement for libappindicator, then Ubuntu
>> may patch it or install it in a non-standard location to keep it from
>> blocking the install of libappindicator. If you make it different, then
>> you need to get apps to explicitly support it.
>
> Hmm, while reading this thread I came to the conclusion that appindicator as a
> name is already quite "tainted", i.e. a lot of developers seem to associated
> it with "too restricted/limited".
>
> Doesn't mean that is has to have a very different API, a different enough
> library name should suffice.
>
>> 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.
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.
(It also doesn't provide a facility to let my monochrome system icon
theme override the tray icon, but that's an unrelated flaw.)
>
> 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.
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)
(PyGI relies heavily on Python's support for indirection and dynamism so
that things like help(), dir(), "x in y", and "object.member" just work
as you'd expect while dbus-python requires you to do everything in a
much more Java-esque manual style.)
For example, the most compact way I've found to get a callable D-Bus
method from a bus you've connected to as "sess_bus" is as follows:
obj = sess_bus.get_object('org.mpris.MediaPlayer2.audacious',
'/org/mpris/MediaPlayer2')
if = dbus.Interface(obj, dbus_interface='org.mpris.MediaPlayer2.Player')
playPause = if.PlayPause
(I usually write a wrapper around that)
Introspection is an even bigger pain. You have to manually figure out
the low-level D-Bus introspection APIs (which seem to have little
Google-visible example code) and then manually parse the XML description
they return.
I haven't had time to try it on other MPRIS clients, but here's the mess
I ended up writing to provide a generalization-friendly API for adding
tracks to Audacious Media Player via the MPRIS D-Bus spec.
https://github.com/ssokolow/profile/blob/master/home/bin/lap#L280
------------------------------------------------------------------------------
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
