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

Update runtime to 6.2 #10

Merged
merged 3 commits into from
Dec 29, 2021
Merged

Update runtime to 6.2 #10

merged 3 commits into from
Dec 29, 2021

Conversation

travier
Copy link
Member

@travier travier commented Dec 2, 2021

This is the KDE Runtime with Qt 6.2 but no KDE libraries for now.

Let's try this one and see if it works. This is a bigger change than #9 thus careful testing might be needed.

This is the KDE Runtime with Qt 6.2 but no KDE libraries for now.
@flathubbot
Copy link

Started test build 69378

@flathubbot
Copy link

Build 69378 failed

@pedrolcl
Copy link
Collaborator

pedrolcl commented Dec 2, 2021

There isn't support for qt5compat in the KDE 6.2 SDK.

Maybe, in future releases of VMPK, the 'qt5compat' module could be dropped. But for other programs like dmidiplayer the problem is the absence of text codecs other than Unicode. MIDI files can contain text metadata (as lyrics) using a variety of encodings.

@travier
Copy link
Member Author

travier commented Dec 2, 2021

There isn't support for qt5compat in the KDE 6.2 SDK.

That might be needed by other apps too. Maybe we should add it to the SDK.

@pedrolcl
Copy link
Collaborator

pedrolcl commented Dec 2, 2021

There isn't support for qt5compat in the KDE 6.2 SDK.

That might be needed by other apps too. Maybe we should add it to the SDK.

I agree. Maybe it was already considered and excluded for some reason? What do you think @aleixpol?

@hfiguiere
Copy link
Collaborator

when I suggested the 6.2 SDK I assumed that it was because you had a port to Qt6 (from previous mentions). But if you don't there is no point in using that runtime.

@pedrolcl
Copy link
Collaborator

pedrolcl commented Dec 2, 2021

when I suggested the 6.2 SDK I assumed that it was because you had a port to Qt6 (from previous mentions). But if you don't there is no point in using that runtime.

I've ported VMPK (and my other programs) to Qt6 using the compatibility module which is part of Qt6, but was not included in the KDE 6.2 SDK for some reason.

@hfiguiere
Copy link
Collaborator

I filed an issue for qt5compat:

https://invent.kde.org/packaging/flatpak-kde-runtime/-/issues/26

@aleixpol
Copy link

Hi @pedrolcl! Long time no see!!

Well I replied there but I can reply here too. It could make sense to keep qt5compat in the app, it shouldn't be too hard to build, we did something similar for Qt 5 anyway for some apps. Otherwise, we can agree that for now everyone is porting so we add it there too, but I'd prefer if it wasn't for the lack of trying.

@pedrolcl
Copy link
Collaborator

There are two use cases for the Qt6 Core5Compat module:

  • To allow a quick and dirty port of some application to Qt6 without fully embracing the new API, perhaps for speed or pure laziness, but maybe to avoid sacrificing compatibility with Qt5. VMPK was still using the old QRegExp class in the last release, but it is replaced now by QRegularExpression, so the compatibility module won't be needed anymore. Most applications that are being ported fit in this use case.
  • To keep functionality that has been removed from Qt6 core modules, but moved to Core5Compat. This is the case of the QTextCodec class, which supports many text encodings. This class is needed by Drumstick::File when decoding standard MIDI files. In fact, all MIDI applications that read standard MIDI files need to decode text metadata (credits, copyrights, lyrics, markers) from virtually any encoding available for the last 30 years. Keeping this functionality is critical for data preservation. The alternative to using Core5Compat in this case is using other libraries like libICU or libiconv, much worse to integrate in a Qt application. @hfiguiere : Rosegarden is also affected by this issue.

The second use case is much more serious, but VMPK has nothing to do with it. The next VMPK release will be able to use Qt6.2 cleanly, bundling only the Drumstick-2.5.0 modules RT+Widgets, without the File module. Meanwhile, let's keep the 5.15 runtime, please.

@travier
Copy link
Member Author

travier commented Dec 13, 2021

The second use case is much more serious, but VMPK has nothing to do with it. The next VMPK release will be able to use Qt6.2 cleanly, bundling only the Drumstick-2.5.0 modules RT+Widgets, without the File module. Meanwhile, let's keep the 5.15 runtime, please.

Definitely. There is no pressure to move here. This was mostly a test / conversation starter. Feel free to update when progress has been made.

Thanks!

@flathubbot
Copy link

Started test build 71989

@flathubbot
Copy link

Build 71989 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/69841/net.sourceforge.VMPK.flatpakref

@pedrolcl
Copy link
Collaborator

pedrolcl commented Dec 22, 2021

I've tested the last build briefly, and seems OK but...

  • Fluidsynth is 2.2.3, and should be 2.2.4 (updated submodule)
  • Qt runtime is 6.2.1, and should be 6.2.2

The drumstick libs is 2.5.0 excluding Drumstick::File explicitly, so the qt5compat module is not required here.

Please test!

@flathubbot
Copy link

Started test build 72086

@flathubbot
Copy link

Build 72086 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/69935/net.sourceforge.VMPK.flatpakref

@pedrolcl pedrolcl merged commit 437c0e5 into flathub:master Dec 29, 2021
@travier travier deleted the patch-1 branch January 2, 2022 14:42
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.

None yet

5 participants