On Wednesday, July 6, 2016 12:16:09 AM CEST Albert Astals Cid wrote: > El dissabte, 2 de juliol de 2016, a les 15:25:39 CEST, Martin Graesslin va > > escriure: > > On Saturday, July 2, 2016 11:41:11 AM CEST David Faure wrote: > > > On lundi 6 juin 2016 11:26:58 CEST Aleix Pol wrote: > > > > On Mon, Jun 6, 2016 at 8:32 AM, Martin Graesslin <mgraess...@kde.org> > > > > wrote: > > > > > Hi framework-developers, > > > > > > > > > > in Plasma we have a repository called kwayland-integration. It > > > > > provides > > > > > a > > > > > plugin for: > > > > > * KWindowSystem > > > > > * KIdleTime > > > > > > > > > > using the KWayland client API. Thus it makes these frameworks > > > > > functional > > > > > on > > > > > windowing system Wayland. > > > > > > > > > > I want to move the plugins into frameworks and are wondering how to > > > > > do > > > > > that > > > > > and where to move them to. > > > > > > > > > > I see the following options: > > > > > 1. Integrate directly into kwindowsystem and kidletime > > > > > 2. Merge them into frameworks-integration > > > > > 3. Create a new framework kwayland-integration > > > > > 4. create a new framework "kwindowsystem-wayland" and > > > > > "kidletime-wayland" > > > > > > > > > > Option 1 is I think an absolute no-no as it would turn kwindowsystem > > > > > and > > > > > kidletime from tier 1 to tier 2 and that would affect a huge amount > > > > > of > > > > > other frameworks. For everything which is not in tier 1, I think > > > > > it's > > > > > the > > > > > way to go. > > > > > > > > > > Option 2 is something I don't want to do as that would combine > > > > > windowing > > > > > system integration code with random other stuff and would result in > > > > > weird > > > > > dependencies. (To use KIdleTime on Wayland one needs X11 and > > > > > Phonon?) > > > > > > > > > > The same actually also applies to Option 3, though it is just two > > > > > frameworks and all dependencies would be tier 1. > > > > > > > > > > So personally I think option 3 or option 4 are the way to go. > > > > > > > > > > What do you think? Better ideas? > > > > > > > > I agree ideally it's 3 or 4. Where do you have it now? Are they > > > > already separate repositories? If so, just moving them to frameworks > > > > could make sense. > > > > > > > > In Purpose I have a similar problem (and I know the discussion is also > > > > relevant for other frameworks). We usually don't want plugins to raise > > > > the tier of your base framework, but you still need them to be > > > > distributed together and either way you need to make sure the plugins > > > > will be available when the system is deployed (which is actually much > > > > easier in option 1). > > > > > > The alternative is to use option 1 with a cmake option to disable the > > > kwayland-based plugin. This offers benefits because > > > - on systems with wayland enabled, you are sure the plugin is present > > > (no > > > bug report like "idle detection doesn't work" (because of a missing > > > package)) - on systems where dependencies should be kept to a minimum > > > (e.g. > > > an X11-based embedded system) one can easily compile without the > > > kwayland > > > dependency > > > > > > Application developers using KIdleTime or KWindowSystem do expect it to > > > work on all platforms where the application works, so surely a > > > dependency > > > on kwayland can't be a problem on wayland. > > > > That's actually not the case. Both KIdleTime and KWindowSystem (runtime) > > depend on additional Wayland protocols currently only provided in KWin/ > > Wayland. That means your KIdleTime based application won't work in e.g. > > GNOME. > > > > Given that the real world benefit of option 1 is not that large. > > I'm confused by this, rsibreak uses "KIdleTime::instance()->idleTime()" when > you say it won't work in GNOME, you mean "GNOME Wayland" or "any GNOME at > all"?
GNOME Wayland. Cheers Martin
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
