-
Notifications
You must be signed in to change notification settings - Fork 160
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
Add QML Support using Qt6 #236
base: main
Are you sure you want to change the base?
Conversation
…qtkeychain into feature/Origin_version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great initiative :)
keychain.h
Outdated
@@ -86,7 +94,7 @@ class QKEYCHAIN_EXPORT Job : public QObject { | |||
* | |||
* @see finished() | |||
*/ | |||
void start(); | |||
Q_INVOKABLE void start(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make this a slot
keychain.h
Outdated
@@ -99,7 +107,7 @@ class QKEYCHAIN_EXPORT Job : public QObject { | |||
/** | |||
* @return An error message that might provide details if error() returns OtherError. | |||
*/ | |||
QString errorString() const; | |||
Q_INVOKABLE QString errorString() const; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd add a property for this
keychain.h
Outdated
explicit WritePasswordJob( const QString& service, QObject* parent=nullptr ); | ||
#ifdef BUILD_WITH_QML | ||
//make objecte creatabble from QML - Just to make sure original code will not broke | ||
explicit WritePasswordJob(const QString& service="", QObject* parent=nullptr ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we don't need the ifdef here, I'd just make it const QString &service={}
for both use cases
translations/qtkeychain_de.ts
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please revert the changes to the .ts files (I should really remove these updates from the build)
@@ -92,6 +93,9 @@ if (Qt5Core_FOUND AND NOT BUILD_WITH_QT6) | |||
include_directories(${Qt5Core_INCLUDE_DIRS}) | |||
else() | |||
find_package(Qt6 COMPONENTS Core REQUIRED) | |||
if(QTKEYCHAIN_BUILD_WITH_QML) | |||
find_package(Qt6 COMPONENTS QML REQUIRED) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit unsure how this dependency fits in with distro packages and the like, one can either disable the dependency to not have the qtkeychain package depend on QML, or enable it, and add the dependency. I guess it's maximally annoying for application developers if then some distros enable QML support and some ignore the flag and thus don't.
I'm leaning to enable QML support by default, and let those who want a minimal build do custom builds with the flag set to OFF.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a developer of an offscreen library depending on Qt Keychain I'd rather be happy not to drag the dependency on QML. As for the CMake part, I think there's a way to introduce this dependency down the line in *Config.cmake
file instead and that can even be conditional, but I didn't try it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you relying on distro packages, or are pulling in qtkeychain directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In CI, I pull Qt Keychain from a tag and build it directly because it's the only way to have one unified logic across 3 platforms; but distros packaging my library have all reasons to link it externally.
```QML | ||
WritePasswordJob{ | ||
id: storeJobObject | ||
service: "" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe set something here for demonstration? Or remove the line
``` | ||
|
||
```QML | ||
import QtKeychain 1.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to think about versioning here. Should it follow the qtkeychain versioning (then this would be 0.15), or not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gonna set it to
VERSION "${CMAKE_PROJECT_VERSION_MAJOR}.${CMAKE_PROJECT_VERSION_MINOR}
Becaue the entire QML implementation is in fact the LIbrary so can track the library version.
keychain.h
Outdated
explicit ReadPasswordJob( const QString& service, QObject* parent=nullptr ); | ||
#ifdef BUILD_WITH_QML | ||
//make objecte creatabble from QML - Just to make sure original code will not broke | ||
explicit ReadPasswordJob( const QString& service="", QObject* parent=nullptr ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
think we don't need the ifdef here, I'd just make it const QString &service={} for both use cases
~ReadPasswordJob() override; | ||
|
||
/** | ||
* @return The binary data stored as value of this job's key(). | ||
* @see Job::key() | ||
*/ | ||
QByteArray binaryData() const; | ||
Q_INVOKABLE QByteArray binaryData() const; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd make these properties
I'm wondering if there's a way to make the QML API more declarative, rather than exposing jobs more or less directly? Something like:
The QSettings QML API might also be something to look at for this. |
This can happen if a dependency CMake config module is itself also looking for QtKeychain, which then results in a fatal CMake error. Observed between NeoChat and libQuotient.
Also, the definitions needs to be fully qualified, otherwise this is producing symbols in the top-level namespace instead.
…qtkeychain into feature/Origin_version # Conflicts: # qtkeychain/keychain_android.cpp # translations/qtkeychain_ru.ts
All changes did not affects your iplementation.
Addes some Q_INVOKABLE and Q_PROPERTY + minor changes using #ifdef
Tested for the moment only o Mac but should work everywhere
Only thing you should take in consideration is the set of
SET(CMAKE_AUTOMOC ON)
and remove of
QT_WRAP_CPP(qtkeychain_MOC_OUTFILES keychain.h keychain_p.h gnomekeyring_p.h)
QT_WRAP_CPP iterfer with crating qmltypes
Full informations:
New:
Added QML support on Qt6 using cmake
To activate set the qt6 and qml flags