On Sunday, 2013-08-11, Stephan Sokolow wrote:
> 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.")Right, makes sense. Also eases transition if one option becomes unavailable (XEmbed not being available on Wayland) or new option arriving. > > 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. Maybe a little bit, but nothing that would be a problem IMHO. Lets say LXDE apps would use it and, as far as I understand, it is packaged in Debian, so it would result in the library being available to others soon after the first release containing it. > 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. My impression was that Python has pretty good support for D-Bus, so it would probably be easy to create a native implementation as well. Might even be easier than writing two C interfaces where one only serves the old binding approach. The KDE classes are basically done that way, i.e. using the D-Bus interface description to generate QtDBus code and putting a very thing wrapper around those to fit into API style guide lines (e.g. camelCase methods).. One of the advantages of a service oriented approach. One doesn't have to find a common subset for all client technology stacks but each technology stack can have a client API that fits perfectly with the stacks programming idioms. 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
