Re: Migrating Windows CI to Qt 6.7 - Roadblocks
On Sat, 25 May 2024 13:02:41 +0200 christ...@cullmann.io wrote: > Now that frameworks is QDBus free on Windows and macOS I would even > propose that in a next update of the stuff we really not have QtDBus > around at all on these systems and make the use optional for the apps > that want to support them. > > We go to great lengths to avoid that dbus stuff is ever called, even > deleting the dll and the most freezes you will get if that is not > done is just dbus related. > > It would be great if people could join the effort to get that right. > > https://invent.kde.org/packaging/craft-blueprints-kde/-/issues/17 Asking mostly out of curiosity, but do you have a link to a writeup / thread on the problem, and / or suggested replacements? I noticed before that you were skeptical of dbus on Windows over at kate, but since it essentially seemed to work for us in RKWard (for the very limited use-case of reusing a running instance), I never bothered to follow suit. Now I see how you replaced dbus for that use-case in kate, and I guess that'll be easy enough to copy. But if dbus is something to avoid (where possible) in the interest of present and future cross-platform compatibility, some generic guidance might be helpful. Regards Thomas pgpI8Ow1aM7FX.pgp Description: OpenPGP digital signature
Re: KDE Gear projects with failing CI (master) (21 May 2024)
On Sun, May 26, 2024 at 6:59 PM Volker Krause wrote: > On Samstag, 25. Mai 2024 13:34:53 CEST Ben Cooksley wrote: > > On Sat, May 25, 2024 at 3:09 AM Volker Krause wrote: > > > On Freitag, 24. Mai 2024 12:24:16 CEST Ben Cooksley wrote: > > > > On Fri, May 24, 2024 at 4:13 AM Volker Krause > wrote: > > > > > On Mittwoch, 22. Mai 2024 10:27:07 CEST Ben Cooksley wrote: > > > > > > On Wed, May 22, 2024 at 9:24 AM Albert Astals Cid > > > > > > > wrote: > > > > > > > Please work on fixing them, otherwise i will remove the > failing CI > > > > > > > > > > jobs on > > > > > > > > > > > > their 4th failing week, it is very important that CI is passing > > > > > > > for > > > > > > > multiple > > > > > > > reasons. > > > > > > > > > > > > > > Good news: 8 repositories fixed > > > > > > > > > > > > > > Bad news: 6 new repositories started failing > > > > > > > > > > > > > > > > > > > > > kio-gdrive - NEW > > > > > > > > > > > > > > * > https://invent.kde.org/network/kio-gdrive/-/pipelines/693840 > > > > > > > > > > > > > > * Qt 5.15 is unbuildable because needs libkgapi and we don't > > > > > > have a > > > > > > > > Qt5 > > > > > > > > > > > > CI > > > > > > > build of libkgapi anymore. This is REAL BAD. > > > > > > > > > > > > Looks like kio-gdrive needs to drop the support it has for Qt 5? > > > > > > Can't really see another path forward as libkgapi has no support > for > > > > > > Qt > > > > > > > > > 5 > > > > > > anymore. > > > > > > > > > > > > This is alas one of those very difficult to solve issues, > especially > > > > > > when > > > > > > semi-leaf projects like libkgapi are used more widely. > > > > > > > > > > Would it work to have a kf5 branch rule for libkgapi pointing to > the > > > > > > last > > > > > > > > branch with Qt 5 support (and similar for all its dependencies)? > > > > > > > > Unfortunately not possible i'm afraid - as release/23.08 is no longer > > > > supported (as no further releases are being made). > > > > I therefore terminated all CI support for that branch to ensure that > any > > > > issues like this one were forced to the surface. > > > > > > But do we actually need CI for libkgapi for this? We only need it > > > available as > > > a dependency, so theoretically even distro packages in the CI image > would > > > work > > > (I'm very reluctant to try that though, as that might have all kinds of > > > surprising side-effects due to whatever else that might pull in (e.g. > > > ECM)). > > > Therefore the idea to let the seed job provide it, by means of a kf5 > > > branch > > > rule. > > > > Distribution packages definitely won't work :) > > > > Unfortunately the seed jobs can't help here, as the entirety of > > release/23.08 has been dropped from the CI system. > > There are also rules in place to continually re-drop any release/23.08 > > packages that do appear in the system. > > ah, so the problem isn't that the seed job wouldn't be able to build this, > but > the result wont be persisted? > Correct. That is assuming that libkgapi doesn't have any other dependencies within KDE Gear of course. > > Next idea: add a kf5 branch to libkgapi, pointing to the latest > release/23.08 > state, and change the branch rules accordingly. We did that for a few non- > branched repos during the transition period of their (branched) consumers > IIRC > (e.g. kweathercore, kirigami-addons). > This would work totally fine. For distributions, do we have any kind of release plan for this as they will need this in order to be able to build kio-gdrive? > > > > > The dependency chain is also @same as both are part of KDE Gear so > from > > > > a > > > > technical perspective that doesn't work either. > > > > > > It's @stable and @latest-kf6 depending on the Qt version in kio-gdrive, > > > and > > > inside libkgapi it's @latest for its KF5 dependencies, which seems > correct > > > IIUC? > > > > @stable for the relationship between libkgapi and kio-gdrive isn't > correct > > as they're both within KDE Gear no? > > In general, yes. But practically libkgapi isn't in Gear anymore from a Qt5 > kio-gdrive perspective, so pointing to a specific (older) branch instead > would > seem like something that could help here. > > > > > From a practical perspective, i'm not sure you can really release > > > > > > something > > > > > > > as part of a bundle that needs something from an older release of > that > > > > > > same > > > > > > > bundle in order to build... > > > > > > We already have that mixed scenario anyway in 24.02 it seems, so that > is > > > apparently working. > > > > I'm only aware of one case where that happened, which was a special one > off > > as KF5 apps needed the Qt 5 plugins still? > > (I think this was kio-extras) > > Yeah, KIO workers is one such case. There's also some inter-dependencies > in > edu that are not a problem yet but where different parts seem to be moving > at > different speeds towards Qt 6 (Labplot <-> Cantor, Marble <-> *). > Hopefully > none of that becomes a prob
Re: Migrating Windows CI to Qt 6.7 - Roadblocks
On 2024-05-26 10:49, Thomas Friedrichsmeier wrote: On Sat, 25 May 2024 13:02:41 +0200 christ...@cullmann.io wrote: Now that frameworks is QDBus free on Windows and macOS I would even propose that in a next update of the stuff we really not have QtDBus around at all on these systems and make the use optional for the apps that want to support them. We go to great lengths to avoid that dbus stuff is ever called, even deleting the dll and the most freezes you will get if that is not done is just dbus related. It would be great if people could join the effort to get that right. https://invent.kde.org/packaging/craft-blueprints-kde/-/issues/17 Asking mostly out of curiosity, but do you have a link to a writeup / thread on the problem, and / or suggested replacements? I noticed before that you were skeptical of dbus on Windows over at kate, but since it essentially seemed to work for us in RKWard (for the very limited use-case of reusing a running instance), I never bothered to follow suit. Now I see how you replaced dbus for that use-case in kate, and I guess that'll be easy enough to copy. But if dbus is something to avoid (where possible) in the interest of present and future cross-platform compatibility, some generic guidance might be helpful. I think the guidance is easy: Beside on desktop Linux or BSD, there is just no DBus session or system bus running. Therefore there is nothing to talk to and if you don't ensure yourself one is properly started (like KDE Connect seems to do) it will just not work (and more important: makes no sense). For the re-use of instances you need to use something like https://github.com/KDAB/KDSingleApplication or similar. Any implicit starting of the dbus stuff will often just result in hangs or other misbehavior. It is just like X11: don't use it on systems that don't have it as native windowing system, we guard that the same way. Greetings Christoph Regards Thomas
Re: Migrating Windows CI to Qt 6.7 - Roadblocks
On 2024-05-26 11:42, christ...@cullmann.io wrote: On 2024-05-26 10:49, Thomas Friedrichsmeier wrote: On Sat, 25 May 2024 13:02:41 +0200 christ...@cullmann.io wrote: Now that frameworks is QDBus free on Windows and macOS I would even propose that in a next update of the stuff we really not have QtDBus around at all on these systems and make the use optional for the apps that want to support them. We go to great lengths to avoid that dbus stuff is ever called, even deleting the dll and the most freezes you will get if that is not done is just dbus related. It would be great if people could join the effort to get that right. https://invent.kde.org/packaging/craft-blueprints-kde/-/issues/17 Asking mostly out of curiosity, but do you have a link to a writeup / thread on the problem, and / or suggested replacements? I noticed before that you were skeptical of dbus on Windows over at kate, but since it essentially seemed to work for us in RKWard (for the very limited use-case of reusing a running instance), I never bothered to follow suit. Now I see how you replaced dbus for that use-case in kate, and I guess that'll be easy enough to copy. But if dbus is something to avoid (where possible) in the interest of present and future cross-platform compatibility, some generic guidance might be helpful. I think the guidance is easy: Beside on desktop Linux or BSD, there is just no DBus session or system bus running. Therefore there is nothing to talk to and if you don't ensure yourself one is properly started (like KDE Connect seems to do) it will just not work (and more important: makes no sense). For the re-use of instances you need to use something like https://github.com/KDAB/KDSingleApplication or similar. It would actually be nice to have something like that as framework part. In Kate we use Qt SingleApplication as we need a blocking message and more and more copies of similar stuff creep in. Any implicit starting of the dbus stuff will often just result in hangs or other misbehavior. It is just like X11: don't use it on systems that don't have it as native windowing system, we guard that the same way. Greetings Christoph Regards Thomas
KGeoTag's main window position is not restored
Hi all! I'm a bit lost with this one. Maybe someone with more insight in KXmlGuiWindow could give me a hand about this? Most probably, this is PEBCAK ;-) Currently, KgeoTag's main window position is not restored when closing it and opening it again. The dock arrangement is restored, and also the window size -- but the window always appears always in the middle of the screen. Initially, I used a QMainWindow and stored the windowState() manually, to restore it in the main window's ctor. Later on, I ported the main window to KXmlGui, keeping the manual restore. I now noticed that KMainWindow also stores the window state on closing, although I never called setAutoSaveSettings(), along with some position parameters that are stored differently from what QWidget::saveGeometry() would yield. I now created the "xmlgui" branch, where the duplicate saving of the window state is removed, and setAutoSaveSettings() is called. However, neither with the master branch (without setAutoSaveSettings()), nor with the xmlgui branch (with setAutoSaveSettings(), most probably more the way this is intended to be used), the window's position is restored -- the window always appears in the middle of the screen. At this point, I'm completely out of ideas why this doesn't work and how I can fix it. has anybody an idea?! Thanks a lot for all hints! Cheers, Tobias
Re: KGeoTag's main window position is not restored
It is not possible anymore in Wayland because window coordinates cannot be set. On Sun, May 26, 2024 at 11:37 AM Tobias Leupold wrote: > > Hi all! > > I'm a bit lost with this one. Maybe someone with more insight in KXmlGuiWindow > could give me a hand about this? Most probably, this is PEBCAK ;-) > > Currently, KgeoTag's main window position is not restored when closing it and > opening it again. The dock arrangement is restored, and also the window size > -- but the window always appears always in the middle of the screen. > > Initially, I used a QMainWindow and stored the windowState() manually, to > restore it in the main window's ctor. Later on, I ported the main window to > KXmlGui, keeping the manual restore. > > I now noticed that KMainWindow also stores the window state on closing, > although I never called setAutoSaveSettings(), along with some position > parameters that are stored differently from what QWidget::saveGeometry() would > yield. > > I now created the "xmlgui" branch, where the duplicate saving of the window > state is removed, and setAutoSaveSettings() is called. > > However, neither with the master branch (without setAutoSaveSettings()), nor > with the xmlgui branch (with setAutoSaveSettings(), most probably more the way > this is intended to be used), the window's position is restored -- the window > always appears in the middle of the screen. > > At this point, I'm completely out of ideas why this doesn't work and how I can > fix it. has anybody an idea?! > > Thanks a lot for all hints! > > Cheers, Tobias > >
Re: KGeoTag's main window position is not restored
E-Mail vom Sonntag, 26. Mai 2024, 18:14:12 CEST: > It is not possible anymore in Wayland because window coordinates cannot be > set. I know (from the KMainWindow sources), but I don't use Wayland. Also, e.g. for KPhotoAlbum (which apparently does exactly same), the position is restored as exptected ...
