Re: Where to put QML Bindings for KDE frameworks?
On Tue, Jan 28, 2014 at 7:10 PM, Kevin Ottens er...@kde.org wrote: I don't think we'll get a one size fit all type of solution, that will heavily depend on the nature of the framework. For instance something like KConfig should probably provide it's own imports, it is in the natural order of things as it already provides a core/gui split. KIO is in pretty much the same situation. But for some others it is less clear... For those ones we'll have to decide if we want to change them toward providing several payloads as well (sounds doable for most except the *addons ones), or if we want the import to be in one of the imports provided by KDeclarative. One of the downsides that wasn't mentioned yet (I think) is keeping the imports away from their modules can (and possibly will) cause the imports to bitrot and get behind the modules. Say that someone makes some changes to the framework but forgets/doesn't know about imports in KDeclarative, so those stay unupdated and may even break. Can also lead to not my problem situation when the KDeclarative maintainer will say that's code from kio, talk to kio maintainer etc. So I think it makes sense to keep the code together. Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put QML Bindings for KDE frameworks?
On Wednesday 29 January 2014 09:20:09 Martin Klapetek wrote: On Tue, Jan 28, 2014 at 7:10 PM, Kevin Ottens er...@kde.org wrote: I don't think we'll get a one size fit all type of solution, that will heavily depend on the nature of the framework. For instance something like KConfig should probably provide it's own imports, it is in the natural order of things as it already provides a core/gui split. KIO is in pretty much the same situation. But for some others it is less clear... For those ones we'll have to decide if we want to change them toward providing several payloads as well (sounds doable for most except the *addons ones), or if we want the import to be in one of the imports provided by KDeclarative. One of the downsides that wasn't mentioned yet (I think) is keeping the imports away from their modules can (and possibly will) cause the imports to bitrot and get behind the modules. Say that someone makes some changes to the framework but forgets/doesn't know about imports in KDeclarative, so those stay unupdated and may even break. Can also lead to not my problem situation when the KDeclarative maintainer will say that's code from kio, talk to kio maintainer etc. So I think it makes sense to keep the code together. Definitely. My point was that I'm not convinced we'll be able to do that in 100% of the cases. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com 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: Where to put QML Bindings for KDE frameworks?
So I think there is some agreement that where we have a relevant 1-1 match we put it with the framework. i.e KIO. knotifications(?), kunitconversion, kconfig, kbookmarks, solid... That still leaves a few items where we need imports which don't have a match: - Helper actions for QML - like qtextracomponents/clipboard, qtextracomponents/mouseeventlistener, qtextracomponents/columnproxymodel I think this might be worth making a tier1 module. If there are enough items to warrant it and if there's going to be enough outside interest. Also we should try to upstream these; Digia are currently remaking something like mouseeventlistener; which is just a waste of effort. - Custom QtQuickControl styled widgets that aren't upstream. I don't generally think it makes sense to merge these with the widgets. If you want to build the widgets you wouldn't want the QML imports, if you want the QML imports you don't want to build the widgets. David ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put QML Bindings for KDE frameworks?
On Wednesday, 2014-01-29, 12:22:39, David Edmundson wrote: I don't generally think it makes sense to merge these with the widgets. If you want to build the widgets you wouldn't want the QML imports, if you want the QML imports you don't want to build the widgets. If you meant QtQuick, I agree :) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring 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
Where to put QML Bindings for KDE frameworks?
For a task in Plasma I've had to port KKeySequence to render on QtQuick, using QtQuickControls. I expect over time we will see more KDE widgets having QtQuick implementations as well. Same for a lot of our other frameworks, such as KIO. I can either add these components to KDeclarative, and create a new import. It is already in tier3, but I would need to add quite a few dependencies to this module. We could put these things in plasma, but I don't think that makes sense as it's not really related to Plasma at all. Alternatively we can make a new framework for all KDE bindings. Or we can make an imports directory inside each of the relevant framework. i.e so KIO provides QML bindings too. Advantages are we can then use the relevant private API of a library, but it has the disadvantage of increasing dependencies, and mixing old very stable API with brand new libraries. Original thread on plasma-devel here: http://mail.kde.org/pipermail/plasma-devel/2014-January/028162.html Discuss. David ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put QML Bindings for KDE frameworks?
On Tue, Jan 28, 2014 at 12:58 PM, David Edmundson da...@davidedmundson.co.uk wrote: For a task in Plasma I've had to port KKeySequence to render on QtQuick, using QtQuickControls. I expect over time we will see more KDE widgets having QtQuick implementations as well. Same for a lot of our other frameworks, such as KIO. I can either add these components to KDeclarative, and create a new import. It is already in tier3, but I would need to add quite a few dependencies to this module. We could put these things in plasma, but I don't think that makes sense as it's not really related to Plasma at all. Alternatively we can make a new framework for all KDE bindings. Or we can make an imports directory inside each of the relevant framework. i.e so KIO provides QML bindings too. Advantages are we can then use the relevant private API of a library, but it has the disadvantage of increasing dependencies, and mixing old very stable API with brand new libraries. My preference is each component providing it's own import if it has them. So KIO providing an import with KIO specific QML stuff (org.kde.kio?). But that's just the ideal scenario. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put QML Bindings for KDE frameworks?
On Tue, Jan 28, 2014 at 12:58 PM, David Edmundson da...@davidedmundson.co.uk wrote: For a task in Plasma I've had to port KKeySequence to render on QtQuick, using QtQuickControls. I expect over time we will see more KDE widgets having QtQuick implementations as well. Same for a lot of our other frameworks, such as KIO. I can either add these components to KDeclarative, and create a new import. It is already in tier3, but I would need to add quite a few dependencies to this module. We could put these things in plasma, but I don't think that makes sense as it's not really related to Plasma at all. Alternatively we can make a new framework for all KDE bindings. Or we can make an imports directory inside each of the relevant framework. i.e so KIO provides QML bindings too. Advantages are we can then use the relevant private API of a library, but it has the disadvantage of increasing dependencies, and mixing old very stable API with brand new libraries. Original thread on plasma-devel here: http://mail.kde.org/pipermail/plasma-devel/2014-January/028162.html Discuss. David ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Well, there are many different needs, so we'll probably want to have different solutions for them. Bindings to interact with each framework, I'd say they should be installed by the framework itself, but that's only one case. I think we probably want a KQuickAddons as well, to put the components we create to extend Qt. (for example, this component you created for bindings). Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put QML Bindings for KDE frameworks?
On Tuesday 28 January 2014, Aleix Pol wrote: Well, there are many different needs, so we'll probably want to have different solutions for them. Bindings to interact with each framework, I'd say they should be installed by the framework itself, but that's only one case. I think we probably want a KQuickAddons as well, to put the components we create to extend Qt. (for example, this component you created for bindings). thats what qtextracomponets was created for. is just to see in what repository to put it -- Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put QML Bindings for KDE frameworks?
Hello, On Tuesday 28 January 2014 12:58:01 David Edmundson wrote: For a task in Plasma I've had to port KKeySequence to render on QtQuick, using QtQuickControls. I expect over time we will see more KDE widgets having QtQuick implementations as well. Same for a lot of our other frameworks, such as KIO. I can either add these components to KDeclarative, and create a new import. It is already in tier3, but I would need to add quite a few dependencies to this module. We could put these things in plasma, but I don't think that makes sense as it's not really related to Plasma at all. Alternatively we can make a new framework for all KDE bindings. Or we can make an imports directory inside each of the relevant framework. i.e so KIO provides QML bindings too. Advantages are we can then use the relevant private API of a library, but it has the disadvantage of increasing dependencies, and mixing old very stable API with brand new libraries. Original thread on plasma-devel here: http://mail.kde.org/pipermail/plasma-devel/2014-January/028162.html Discuss. I don't think we'll get a one size fit all type of solution, that will heavily depend on the nature of the framework. For instance something like KConfig should probably provide it's own imports, it is in the natural order of things as it already provides a core/gui split. KIO is in pretty much the same situation. But for some others it is less clear... For those ones we'll have to decide if we want to change them toward providing several payloads as well (sounds doable for most except the *addons ones), or if we want the import to be in one of the imports provided by KDeclarative. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com 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
