On 13-08-11 05:01 PM, Kevin Krammer wrote:
> On Sunday, 2013-08-11, Stephan Sokolow wrote:
>>
>> The latter. libappindicator does do an automatic XEmbed fallback which
>> some applications rely on but it locks you into the Unity-like behaviour
>> I mentioned before.
>
> Ah, interesting, I would have guessed it just does the appindicator stuff.
As far as I can tell, it was their way of getting adoption when "XEmbed
does the job perfectly well" for applications which already provide tray
icons.
("Port over to our library and you support both the old and the new with
a single implementation.")
>
> Do you think they would be interested in having a non-crippled implementation?
>
Something to ask about. I'm just describing the impression I got while
wandering through the issue tracker and community site shortly after
support was added.
Deluge is a PyGTK application, so it'll be using the manual
libappindicator bindings for the Python2+PyGTK combination rather than
the automatic bindings that come free with the PyGI-based approach to
accessing GTK+.
>
> I don't know about Ubuntu but usually that shouldn't be a problem. The reason
> libraries get packaged is usually that there are applications using it. I
> doubt they would patch all applications using an alternative implementation
> just to avoid a library that would behave differently on a different
> workspace.
>
> Even if they did I find it hard to believe all non-Unity variants would apply
> the same changes, given that the alternative would give a better integration
> into their respective choice of workspace.
Still a bit of a chicken-and-egg problem to get the effort made though.
>
> Have to take your word for that, I have zero insights into what GTK+ library
> requirements would be. But I regularily read people claiming that
> introspection is basically trivial these days and bindings come virtually for
> free.
Bindings come virtually free because the introspection system provides
an API description more on the level of Java or C# that things like PyGI
can use to bind at runtime.
However, last I checked, you couldn't use both PyGI and PyGTK in the
same process because you can't mix classes from the PyGTK and PyGI
wrapper hierarchies... and most Python 2.x apps still use PyGTK (partly
because, in some places, the docs recommend it over PyGI for apps which
run only on Python 2.x and GTK+ 2.x).
...that means that, for PyGTK apps, you'll need manual bindings using
whatever your preferred method is. (Cython, SWIG, Raw C, etc.)
I suppose a case could be made for offering up a patch set for
libappindicator to make the API richer and then maintaining a fork with
instructions on keeping your app backwards-compatible if the patches are
refused.
------------------------------------------------------------------------------
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
