Re: [Lxde-list] qCheckGMail for razor-qt

[Stephan S. <gma...@sp...>]

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