-
Notifications
You must be signed in to change notification settings - Fork 92
Description
we have discussed many times already, that we don't want to wrap everything in CXX-Qt-lib.
As the maintenance burden of this would be quite high.
However, like with KDToolBox
, we could have a repository of useful things that people have already done, but may not have the time to maintain.
This would be what CXX-Qt-lib-extra
is.
A collection of wrapped Qt types that we don't really maintain ourselves, but just add whatever we or others find useful.
The barrier to add types here should be quite low, not every part of the API has to be wrapped, just adding stuff is useful, even if it's not complete.
On a technical level, I propose the following:
- Add a
CXX-Qt-lib-extra
independent repository toKDABLabs
. - Have
CXX-Qt-lib-extra
depend on the current stable release of CXX-Qt. (we don't want to have to drag every part of CXX-Qt-lib-extra through every internal CXX-Qt change). - Ideally have CXX-Qt-lib-extra depend on
cxx-qt
for the bridges (currently blocked on WIP: examples: create a multi project to test multiple crates #598 - After we release a new version of CXX-Qt, only migrate what still works, fix up anything that's easy to fix, drop support for everything that no longer works... People that need those wrappers can still look the code up in previous versions. After 1.0, this should not happen anymore.
For a draft guideline of when to add something to CXX-Qt-lib directly vs. just to CXX-Qt-lib-extra:
- Default to adding anything you think may be useful to CXX-Qt-lib-extra
- Only add types to CXX-Qt-lib directly, if they're either:
- Hard to wrap optimally (i.e. should be trivial/templates, etc.)
- Are often used as parameters/return values within the Qt codebase
- We can then always promote types from
lib-extra
tolib
, if/when it turns out this type is used regularly.
Looking forward to hear about your opinions :)
Metadata
Metadata
Assignees
Labels
Type
Projects
Status