On Monday, 2013-08-12, Stephan Sokolow wrote: > On 13-08-12 07:28 AM, Kevin Krammer wrote: > > Right, makes sense. Also eases transition if one option becomes > > unavailable (XEmbed not being available on Wayland) or new option > > arriving. > > Speaking of which, have you heard anything about how Wayland plans to > offer non-legacy support things like MPlayer GUIs and gVim-based IDEs > without XEmbed?
No idea, sorry. From an application developer's point of view I would expect QWindow::fromWinId() to work, i.e. be handled by the Wayland QPA. > > 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. > > 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. > (Especially since our option wouldn't make it into Slackware and Debian > Stable for quite a while, which means it wouldn't be something they > could replace their XEmbed implementation with in the near future.) Are there many project that target Debian stable with newer releases of themselves? > 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. > > 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. > > True. I hadn't thought about that. It probably would be simpler to just > use dbus-python (python-dbus on Debian-based distros) for PyGTK. 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. Cheers, Kevin [1] I've even seen Qt application developer create libraries that are basically a wrapper around a GObject library that was a wrapper around a GObject D-Bus client interface instead of having a small "beautification" layer over a Qt-native D-Bus client interface themselves, burdening them with additional build and runtime dependencies. -- 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
