On Tuesday 30 June 2015 20:33:09 Albert Astals Cid wrote: > El Dijous, 25 de juny de 2015, a les 08:46:07, Martin Gräßlin va escriure: > > On Wednesday 24 June 2015 23:20:21 Aleix Pol wrote: > > > On Wed, Jun 24, 2015 at 9:51 AM, Martin Gräßlin <mgraess...@kde.org> > > wrote: > > > > On Tuesday 23 June 2015 19:35:48 Aleix Pol wrote: > > > >> On Tue, Jun 23, 2015 at 9:42 AM, Martin Gräßlin <mgraess...@kde.org> > > > > wrote: > > > >> > Hi framework-developers and packagers, > > > >> > > > > >> > with two frameworks I'm currently in the need to have something > > > >> > like > > > >> > QPA. > > > >> > I > > > >> > want to make it possible to provide windowing-system specific > > > >> > plugins > > > >> > for > > > >> > frameworks using a private API. The need arises first of all in > > > >> > kwindowsystem to support wayland [1]. To implement it we need a > > > >> > dependency to KWayland, which is currently part of kde-workspace > > > >> > and > > > >> > not > > > >> > yet up to the quality and stability levels needed to make it a > > > >> > framework. > > > >> > The second framework where I need such functionality is > > > >> > kglobalaccel > > > >> > where kwin needs to take over a large part of the functionality of > > > >> > the > > > >> > runtime to make it work on wayland at all. > > > >> > > > > >> > I see the following possibilities to solve the problem: > > > >> > 1.Make it a private API without any ABI guarantee > > > >> > 2. Make it a public stable API with ABI guarantee > > > >> > 3. Make it a private API with so-version changes whenever the ABI > > > >> > changes > > > >> > > > > >> > Option 1 is closest to what Qt's QPA does, but I think this would > > > >> > be > > > >> > a > > > >> > nightmare for packagers. > > > >> > > > > >> > Option 2 could result in a nightmare for developers especially in > > > >> > the > > > >> > plugin infrastructure itself. With releases every month that could > > > >> > quickly end in classes like KWindowSystemPrivate32 and result in an > > > >> > unmanageable runtime check system. > > > >> > > > > >> > Personally I think Option 3 is the cleanest solution. Would this be > > > >> > acceptable for everyone? If yes are there any suggestions for where > > > >> > to > > > >> > install headers to, for naming the libraries, etc? > > > >> > > > > >> > Looking forward for your input, > > > >> > > > > >> > Cheers > > > >> > Martin > > > >> > > > > >> > [1] And obviously also other windowing systems if > > > >> > distributions/OSes > > > >> > want > > > >> > to add support for it. > > > >> > _______________________________________________ > > > >> > Kde-frameworks-devel mailing list > > > >> > Kde-frameworks-devel@kde.org > > > >> > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > > > >> > > > >> Hi Martin, > > > >> We already have something similar with frameworksintegration, maybe > > > >> it > > > >> would make sense to integrate what you need there? > > > > > > > > Frameworksintegration doesn't really help as it's still part of > > > > frameworks > > > > and thus cannot depend on workspace libraries like kwayland. Also it's > > > > absolutely no solution for the problem of kglobalaccel (that feature > > > > must(!) be provided by kwin, there is no other way). > > > > > > > >> The biggest problem I see is that you want it in kde-workspace and > > > >> it's really complex to use a changing library within 2 different > > > >> release cycles. It will make things break on one side or another. > > > >> > > > >> What you can do is a stable plugin API and then provide the Wayland > > > >> plugins from Plasma releases. X11 and others can remain within > > > >> frameworks. > > > > > > > > That's option 2 from above. As said above I fear that this will be > > > > problematic due to the very short release cycle of frameworks and will > > > > create many subclasses just to keep it ABI stable. Of course it's > > > > doable, > > > > but well... > > > > > > Well, these aren't completely new abstractions I guess, they're just > > > not public interfaces yet. If you start with wayland and X11 backends > > > (and ideally win/mac too), it should be a solid-enough interface > > > already so it doesn't need to change on the very next iteration. > > > > This assumes the API is done and is no longer extended. That's not the > > case, the API got extended at a constant pace over the last few months. > > Each addition to the API will need an addition to the "private" API in > > measure of adding a new virtual method. > > There's ways to workaround the virtual method BIC issue, first lame one that > comes to mind is using meta object system instead of the C++ virtual stuff > if it's not a hot path, afaik our Binary Compatibility page list a few > others (virtual_hook).
Another way to achieve the same was implemented by Christoph Cullmann in the KatePart/Kate/KTextEditor based on KF5. Essentially, the interfaces are non- virtual and delegate calls to some actual implementation via QMetaObject::invokeMethod. See e.g. KTextEditor::MainWindow. The advantage is that the public headers can be extended at will (adding non- virtual functions keeps source and binary compatibility). The downside is that there is a small performance penalty (which could be somewhat reduced by using static QMetaMethod and invoking them). And, probably more important, there is no compile-time check that the invoked methods are available in the implementation side. Bye -- Milian Wolff m...@milianw.de http://milianw.de _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
