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

Add QML Support using Qt6 #236

Open
wants to merge 18 commits into
base: main
Choose a base branch
from

Conversation

CMGeorge
Copy link

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

-DBUILD_WITH_QT6=ON -DQTKEYCHAIN_BUILD_WITH_QML=ON
import QtKeychain 1.0
WritePasswordJob{
        id: storeJobObject
        service: ""
        onFinished: {
            console.debug("Store password complete")
        }
    }
    ReadPasswordJob{
        id: readJobObject
        service: ""

    }
storeJobObject.key = "username";
storeJobObject.setTextData("password");
storeJobObject.start();

readJobObject.key = "username"
readJobObject.finished.connect(function (returnedPassword){
                console.debug("Password is: "+returnedPassword.textData())
})
readJobObject.start();

Copy link
Owner

@frankosterfeld frankosterfeld left a 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 Show resolved Hide resolved
keychain.h Outdated
@@ -86,7 +94,7 @@ class QKEYCHAIN_EXPORT Job : public QObject {
*
* @see finished()
*/
void start();
Q_INVOKABLE void start();
Copy link
Owner

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;
Copy link
Owner

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 );
Copy link
Owner

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

Copy link
Owner

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)
Copy link
Owner

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.

Copy link
Contributor

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.

Copy link
Owner

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?

Copy link
Contributor

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: ""
Copy link
Owner

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
Copy link
Owner

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?

Copy link
Author

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 );
Copy link
Owner

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;
Copy link
Owner

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

@vkrause
Copy link
Contributor

vkrause commented May 26, 2023

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:

KeychainStore {
  id: password
  key: "myAccount"
}

TextField {
  id: passwordEdit
  text: password.textData // async reading of key chain data via property binding
}

Button {
  text: "Save"
  onClicked: password.textData = passwordEdit.text // assigning a new value triggers a write job
  enabled: password.state == KeychainStore.Loaded // state properties for indicating errors/progress/completion
}

The QSettings QML API might also be something to look at for this.

vkrause and others added 11 commits June 1, 2023 10:38
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants