Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CXX-Qt-lib-extra #766

Open
LeonMatthesKDAB opened this issue Dec 15, 2023 · 6 comments
Open

CXX-Qt-lib-extra #766

LeonMatthesKDAB opened this issue Dec 15, 2023 · 6 comments
Assignees
Labels
🤔 discussion Feedback welcome 👷 refactor Something needs to change

Comments

@LeonMatthesKDAB
Copy link
Collaborator

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 to KDABLabs.
  • 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 to lib, if/when it turns out this type is used regularly.

Looking forward to hear about your opinions :)

@LeonMatthesKDAB
Copy link
Collaborator Author

Also note that we may want to move some existing types out of CXX-Qt-lib into extra.
Which remains to be discussed :)

@Montel
Copy link
Contributor

Montel commented Dec 15, 2023

qmargins for example ? Not sure that it's used by default no ?

@ahayzen-kdab
Copy link
Collaborator

Initially I went through the QML basic types https://doc.qt.io/qt-5/qtqml-typesystem-basictypes.html and tried to wrap those as "fundamental types" that we require, note how that has point, rect, size. And then note that QRect has API like QRect::marginsAdded, so margins are a curious one :-)

@Montel
Copy link
Contributor

Montel commented Feb 23, 2024

CXX-Qt-lib-extra lives for the moment in official repo.
We will split after 0.7.
I added QCommandLineParser/QCommandOption/QElipsedTimer.

@Montel
Copy link
Contributor

Montel commented Feb 29, 2024

I added QApplication in #869
In review for the moment we must find a solution for implement inherit class

@Montel
Copy link
Contributor

Montel commented Mar 1, 2024

Add QStandardPaths ?
It can be useful.
We can define setTestModeEnabled

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🤔 discussion Feedback welcome 👷 refactor Something needs to change
Projects
None yet
Development

No branches or pull requests

3 participants