Re: QPA plugin like functionality in frameworks?
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
Re: QPA plugin like functionality in frameworks?
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). Cheers, Albert Cheers Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Re: QPA plugin like functionality in frameworks?
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. 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
Re: Re: QPA plugin like functionality in frameworks?
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. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QPA plugin like functionality in frameworks?
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? 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. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
QPA plugin like functionality in frameworks?
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. 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
