Request for help for developing new XDG StatusNotifier/AppIndicator spec for KDE+GNOME
Hello all, As many of you know, I am one of the leads for the Fedora KDE Special Interest Group (SIG), which develops the Fedora KDE spin[1] and the new Fedora Kinoite[2]. What you may not know is that I'm also a member of the Fedora Workstation Working Group (WG), which develops the Fedora Workstation Edition[3] and Fedora Silverblue[4]. The Fedora Workstation WG has become convinced we need to have status notifiers supported in GNOME in order to properly support cross-platform applications that leverage status notifiers as core to using them. However, the GNOME developers are not interested in supporting the existing KSNI/AppIndicator specification due to several perceived issues around sandboxed applications. In order to resolve these issues and finally standardize the method in which all desktops support status notifiers, I would like to invite interested folks maintaining and developing KSNI in KDE Plasma to help us develop the spec to unify support around status notifiers in KDE Plasma and GNOME. The new specification development has been kicked off with an issue on the xdg-specs repository: https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/84 Most of the detailed background information is linked from the xdg-specs issue, so I encourage you to read that for more information. If you have any questions, concerns, or comments, feel free to reply and ask. Thanks in advance and best regards, Neal [1]: https://kde.fedoraproject.org/ [2]: https://kinoite.fedoraproject.org/ [3]: https://getfedora.org/workstation/ [4]: http://silverblue.fedoraproject.org/ -- 真実はいつも一つ！/ Always, there's only one truth!
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
On Sun, Mar 6, 2022 at 9:52 AM Fabian Vogt wrote: > > Moin, > > Am Freitag, 4. M�rz 2022, 01:35:14 CET schrieb Albert Astals Cid: > > The KDE Patchset Collection has been rebased on top of Qt 5.15.3 > > > > Some patches have been droped, some are still needed since we carry patches > > newer than 1 year old. > > > > Since this are rebases (to clearly show which patches are "ours", i.e. > > those on top of the v5.15.3-lts-lgpl tag) > > the kde/5.15 branches have been force-pushed to, don't get scared when > > fetching tells you that a force-update happened. > > With the rebase, the connection between the 5.15.2 and 5.15.3 states has been > lost, which broke all branches (and thus MRs) based on that, and the > non-linearity of the history makes it hard to get an accurate list of changes > (added, removed and changed commits). GC might eventually also break links to > particular commits on the old branch. > > Would it be possible to just cherry-pick the patches from upstream's 5.15 > which > were missing from kde/5.15 instead? I imagine that wouldn't be too hard, and > grant a better overview. > > If not, could you please publish a full list of changes caused by the rebase > of > affected repositories? > It should have been done as kde/5.15.2 and kde/5.15.3 branches, but here we are... -- 真実はいつも一つ！/ Always, there's only one truth!
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
On Sun, Mar 6, 2022 at 11:00 AM Albert Astals Cid wrote: > > El diumenge, 6 de març de 2022, a les 16:12:37 (CET), Neal Gompa va escriure: > > On Sun, Mar 6, 2022 at 9:52 AM Fabian Vogt wrote: > > > > > > Moin, > > > > > > Am Freitag, 4. M�rz 2022, 01:35:14 CET schrieb Albert Astals Cid: > > > > The KDE Patchset Collection has been rebased on top of Qt 5.15.3 > > > > > > > > Some patches have been droped, some are still needed since we carry > > > > patches newer than 1 year old. > > > > > > > > Since this are rebases (to clearly show which patches are "ours", i.e. > > > > those on top of the v5.15.3-lts-lgpl tag) > > > > the kde/5.15 branches have been force-pushed to, don't get scared when > > > > fetching tells you that a force-update happened. > > > > > > With the rebase, the connection between the 5.15.2 and 5.15.3 states has > > > been > > > lost, which broke all branches (and thus MRs) based on that, and the > > > non-linearity of the history makes it hard to get an accurate list of > > > changes > > > (added, removed and changed commits). GC might eventually also break > > > links to > > > particular commits on the old branch. > > > > > > Would it be possible to just cherry-pick the patches from upstream's 5.15 > > > which > > > were missing from kde/5.15 instead? I imagine that wouldn't be too hard, > > > and > > > grant a better overview. > > > > > > If not, could you please publish a full list of changes caused by the > > > rebase of > > > affected repositories? > > > > > > > It should have been done as kde/5.15.2 and kde/5.15.3 branches, but > > here we are... > > Why? > > You don't get to act all "you're doing it all wrong" without giving an actual > single reason. > Because it's impossible for us to figure out the changes since you rebased and mangled the history. If something needs to be debugged, it's a lot harder to do. Also, the refusal to tag checkpoints has also made this difficult, but it was manageable until this point. Especially when KDE developers say that Fedora is broken because we don't have the KDE Qt patchset. It's incredibly unhelpful and we can't figure out what we're working with. This whole situation has been pretty bad and I've been very unhappy about it and said as much in other venues. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
On Sun, Mar 6, 2022 at 12:56 PM Albert Astals Cid wrote: > > El diumenge, 6 de març de 2022, a les 17:36:26 (CET), Neal Gompa va escriure: > > On Sun, Mar 6, 2022 at 11:00 AM Albert Astals Cid wrote: > > > > > > El diumenge, 6 de març de 2022, a les 16:12:37 (CET), Neal Gompa va > > > escriure: > > > > On Sun, Mar 6, 2022 at 9:52 AM Fabian Vogt > > > > wrote: > > > > > > > > > > Moin, > > > > > > > > > > Am Freitag, 4. M�rz 2022, 01:35:14 CET schrieb Albert Astals Cid: > > > > > > The KDE Patchset Collection has been rebased on top of Qt 5.15.3 > > > > > > > > > > > > Some patches have been droped, some are still needed since we carry > > > > > > patches newer than 1 year old. > > > > > > > > > > > > Since this are rebases (to clearly show which patches are "ours", > > > > > > i.e. those on top of the v5.15.3-lts-lgpl tag) > > > > > > the kde/5.15 branches have been force-pushed to, don't get scared > > > > > > when fetching tells you that a force-update happened. > > > > > > > > > > With the rebase, the connection between the 5.15.2 and 5.15.3 states > > > > > has been > > > > > lost, which broke all branches (and thus MRs) based on that, and the > > > > > non-linearity of the history makes it hard to get an accurate list of > > > > > changes > > > > > (added, removed and changed commits). GC might eventually also break > > > > > links to > > > > > particular commits on the old branch. > > > > > > > > > > Would it be possible to just cherry-pick the patches from upstream's > > > > > 5.15 which > > > > > were missing from kde/5.15 instead? I imagine that wouldn't be too > > > > > hard, and > > > > > grant a better overview. > > > > > > > > > > If not, could you please publish a full list of changes caused by the > > > > > rebase of > > > > > affected repositories? > > > > > > > > > > > > > It should have been done as kde/5.15.2 and kde/5.15.3 branches, but > > > > here we are... > > > > > > Why? > > > > > > You don't get to act all "you're doing it all wrong" without giving an > > > actual single reason. > > > > > > > Because it's impossible for us to figure out the changes since you > > rebased and mangled the history. If something needs to be debugged, > > it's a lot harder to do. > > There are no changes in the patch set before and after the rebase (commit > dc01793b3b194302a0174921cc30bfc15c985bf4 in [1]), the same patches remain on > top (except the ones that are part of Qt 5.15.3 are not patches on top > anymore, they are just part of Qt 5.15.3 thanks to the magic of git rebase > detecting the patches that are no longer needed) > > > Also, the refusal to tag checkpoints has also made this difficult, but > > it was manageable until this point. > > You're going to need to use terms i can understand, what's a checkpoint? > > > Especially when KDE developers say > > that Fedora is broken because we don't have the KDE Qt patchset. It's > > incredibly unhelpful and we can't figure out what we're working with. > > I still don't understand what is the problem, what do you mean "what we're > working with" ? You just need to package the tip of the kde/5.15 branches, > what else is there to "work with"? > And that changes over time, and because there are no Git tags for anyone to depend on, it's *really* difficult to coordinate. We get blamed regularly for having broken things in KDE Plasma because it turns out we need some missing patch that's important for KDE Plasma to work properly. But there's no way for us to know that until we go back and find out. > > This whole situation has been pretty bad and I've been very unhappy > > about it and said as much in other venues. > > You have been complaining in the wrong places to the wrong people, I'm one of > the people most involved with the patchset and this is the first time i hear > any complain from you. > Not true. I complained in the thread on kde-devel[1] last June. In particular I suggested a tag versioning convention[2]. This whole thing has been a terrible mess and it's extremely frustrating. It's caused problems for the development of the last couple of Fedora releases, too. [1]: https://mail.kde.org/pipermail/kde-devel/2021-June/000498.html [2]: https://mail.kde.org/pipermail/kde-devel/2021-June/000508.html -- 真実はいつも一つ！/ Always, there's only one truth!
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
On Sun, Mar 6, 2022 at 2:10 PM Albert Astals Cid wrote: > > El diumenge, 6 de març de 2022, a les 19:32:57 (CET), Neal Gompa va escriure: > > On Sun, Mar 6, 2022 at 12:56 PM Albert Astals Cid wrote: > > > > > > El diumenge, 6 de març de 2022, a les 17:36:26 (CET), Neal Gompa va > > > escriure: > > > > On Sun, Mar 6, 2022 at 11:00 AM Albert Astals Cid wrote: > > > > > > > > > > El diumenge, 6 de març de 2022, a les 16:12:37 (CET), Neal Gompa va > > > > > escriure: > > > > > > On Sun, Mar 6, 2022 at 9:52 AM Fabian Vogt > > > > > > wrote: > > > > > > > > > > > > > > Moin, > > > > > > > > > > > > > > Am Freitag, 4. M�rz 2022, 01:35:14 CET schrieb Albert Astals Cid: > > > > > > > > The KDE Patchset Collection has been rebased on top of Qt 5.15.3 > > > > > > > > > > > > > > > > Some patches have been droped, some are still needed since we > > > > > > > > carry patches newer than 1 year old. > > > > > > > > > > > > > > > > Since this are rebases (to clearly show which patches are > > > > > > > > "ours", i.e. those on top of the v5.15.3-lts-lgpl tag) > > > > > > > > the kde/5.15 branches have been force-pushed to, don't get > > > > > > > > scared when fetching tells you that a force-update happened. > > > > > > > > > > > > > > With the rebase, the connection between the 5.15.2 and 5.15.3 > > > > > > > states has been > > > > > > > lost, which broke all branches (and thus MRs) based on that, and > > > > > > > the > > > > > > > non-linearity of the history makes it hard to get an accurate > > > > > > > list of changes > > > > > > > (added, removed and changed commits). GC might eventually also > > > > > > > break links to > > > > > > > particular commits on the old branch. > > > > > > > > > > > > > > Would it be possible to just cherry-pick the patches from > > > > > > > upstream's 5.15 which > > > > > > > were missing from kde/5.15 instead? I imagine that wouldn't be > > > > > > > too hard, and > > > > > > > grant a better overview. > > > > > > > > > > > > > > If not, could you please publish a full list of changes caused by > > > > > > > the rebase of > > > > > > > affected repositories? > > > > > > > > > > > > > > > > > > > It should have been done as kde/5.15.2 and kde/5.15.3 branches, but > > > > > > here we are... > > > > > > > > > > Why? > > > > > > > > > > You don't get to act all "you're doing it all wrong" without giving > > > > > an actual single reason. > > > > > > > > > > > > > Because it's impossible for us to figure out the changes since you > > > > rebased and mangled the history. If something needs to be debugged, > > > > it's a lot harder to do. > > > > > > There are no changes in the patch set before and after the rebase (commit > > > dc01793b3b194302a0174921cc30bfc15c985bf4 in [1]), the same patches remain > > > on top (except the ones that are part of Qt 5.15.3 are not patches on top > > > anymore, they are just part of Qt 5.15.3 thanks to the magic of git > > > rebase detecting the patches that are no longer needed) > > > > > > > Also, the refusal to tag checkpoints has also made this difficult, but > > > > it was manageable until this point. > > > > > > You're going to need to use terms i can understand, what's a checkpoint? > > > > > > > Especially when KDE developers say > > > > that Fedora is broken because we don't have the KDE Qt patchset. It's > > > > incredibly unhelpful and we can't figure out what we're working with. > > > > > > I still don't understand what is the problem, what do you mean "what > > > we're working with" ? You just need to package the tip of the kde/5.15 > > > branches, what else is there to "work wit
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
On Sun, Mar 6, 2022 at 2:14 PM Albert Astals Cid wrote: > > El diumenge, 6 de març de 2022, a les 20:10:38 (CET), Albert Astals Cid va > escriure: > > where N is the number of packages on top, so for qtlocation is r0 and for > > qtwayland is r40. > > packages on top -> patches on top > > I re-read that email like 10 times and still had a huge mistake like this, > sorry :/ > > No worries, I figured out what you meant. :) -- 真実はいつも一つ！/ Always, there's only one truth!
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
On Sun, Mar 6, 2022 at 5:01 PM Albert Astals Cid wrote: > > El diumenge, 6 de març de 2022, a les 20:16:31 (CET), Neal Gompa va escriure: > > On Sun, Mar 6, 2022 at 2:10 PM Albert Astals Cid wrote: > > > > > > El diumenge, 6 de març de 2022, a les 19:32:57 (CET), Neal Gompa va > > > escriure: > > > > On Sun, Mar 6, 2022 at 12:56 PM Albert Astals Cid wrote: > > > > > > > > > > El diumenge, 6 de març de 2022, a les 17:36:26 (CET), Neal Gompa va > > > > > escriure: > > > > > > On Sun, Mar 6, 2022 at 11:00 AM Albert Astals Cid > > > > > > wrote: > > > > > > > > > > > > > > El diumenge, 6 de març de 2022, a les 16:12:37 (CET), Neal Gompa > > > > > > > va escriure: > > > > > > > > On Sun, Mar 6, 2022 at 9:52 AM Fabian Vogt > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Moin, > > > > > > > > > > > > > > > > > > Am Freitag, 4. M�rz 2022, 01:35:14 CET schrieb Albert Astals > > > > > > > > > Cid: > > > > > > > > > > The KDE Patchset Collection has been rebased on top of Qt > > > > > > > > > > 5.15.3 > > > > > > > > > > > > > > > > > > > > Some patches have been droped, some are still needed since > > > > > > > > > > we carry patches newer than 1 year old. > > > > > > > > > > > > > > > > > > > > Since this are rebases (to clearly show which patches are > > > > > > > > > > "ours", i.e. those on top of the v5.15.3-lts-lgpl tag) > > > > > > > > > > the kde/5.15 branches have been force-pushed to, don't get > > > > > > > > > > scared when fetching tells you that a force-update happened. > > > > > > > > > > > > > > > > > > With the rebase, the connection between the 5.15.2 and 5.15.3 > > > > > > > > > states has been > > > > > > > > > lost, which broke all branches (and thus MRs) based on that, > > > > > > > > > and the > > > > > > > > > non-linearity of the history makes it hard to get an accurate > > > > > > > > > list of changes > > > > > > > > > (added, removed and changed commits). GC might eventually > > > > > > > > > also break links to > > > > > > > > > particular commits on the old branch. > > > > > > > > > > > > > > > > > > Would it be possible to just cherry-pick the patches from > > > > > > > > > upstream's 5.15 which > > > > > > > > > were missing from kde/5.15 instead? I imagine that wouldn't > > > > > > > > > be too hard, and > > > > > > > > > grant a better overview. > > > > > > > > > > > > > > > > > > If not, could you please publish a full list of changes > > > > > > > > > caused by the rebase of > > > > > > > > > affected repositories? > > > > > > > > > > > > > > > > > > > > > > > > > It should have been done as kde/5.15.2 and kde/5.15.3 branches, > > > > > > > > but > > > > > > > > here we are... > > > > > > > > > > > > > > Why? > > > > > > > > > > > > > > You don't get to act all "you're doing it all wrong" without > > > > > > > giving an actual single reason. > > > > > > > > > > > > > > > > > > > Because it's impossible for us to figure out the changes since you > > > > > > rebased and mangled the history. If something needs to be debugged, > > > > > > it's a lot harder to do. > > > > > > > > > > There are no changes in the patch set before and after the rebase > > > > > (commit dc01793b3b194302a0174921cc30bfc15c985bf4 in [1]), the same > > > > > patches remain on top (except the ones that are part of Qt 5.15.3 are > > > >
Re: New releases for bugfixes
On Sat, Sep 10, 2022 at 5:41 AM Reindl Harald wrote: > > > > Am 09.09.22 um 11:42 schrieb samuel ammonius: > > Thanks. I hadn't thought of a lot of these issues before. > > > > I think the biggest one is that If there's an update that the package > > manager didn'tknow about, the user would have to update right after > > installing, and > > the bug would come back if the user re-installed or updated the app. Sorry > > everybody > no the biggest issue on the userside is that nobody wants every random > application tamper the system > > if i want applications asking me about updates i could have stayed at > windows and "yum upgrade" was the main reason for Linux > > when you open that can of worms imagine where it ends > > security wise it's a nightmare because you not only have the > distribution you need to trust - intrusion on any upstream would > directly hit you at any random point in time while distribution updates > are usually tested at least by some people and changes reviewed by > downstream maintainers > > and who does the work and deal with bugreports "the update of kate > destroyed it on my system and i don't know why nor how i revert it" > > with the package manager i type "dnf downgrade kate", file a bug against > the distribution and kde upstream isn't involved at all > > upstream opensource developers write the code, that's it, they don't and > shouldn't need to care about every downstream distribution and it's > pitfalls - it's wasted time because that's what downstream component > maintainers are for > > the fedora maintainer from kde likely has no knowledge about Gentoo, > Ubuntu, SuSE for good reasons and you think blow that load to upstream > developers would help anybody? > Well, actually, most of us do know each other and we do collaborate from time to time. I personally know Fabian Vogt (the maintainer of the KDE stack in SUSE distributions) and I talk to Rik Mills (the Kubuntu maintainer) every once in a while. Same goes for Mageia, OpenMandriva, Debian, and others. Admittedly, I don't know who works on KDE Plasma for Gentoo, but I'm peripherally aware of their work. As maintainers of KDE software in our respective distributions, it's our job to bring our concerns upstream as needed. But also, when distributions have a conflict, we *all* have to work together to figure out a solution. If we don't, we risk a situation where KDE eventually evolves into other similarly-sized desktop environment projects where they give the downstream stakeholders the finger because they don't trust them. Also, many of the upstream KDE Plasma developers are in fact distro developers. It's not the majority anymore like it was in the old days, but a good chunk of them are. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: "Gardening" old bugreports
On Fri, Jan 27, 2023 at 4:57 PM Justin Zobel wrote: > > Thanks for the feedback, everyone. > > Given the distribution of positive vs negative feedback, we plan to > resume automatic bug triage of old non-wishlist bugs that have not > been updated in over 2 years. If you would like to opt your product > out of this initiative because you're able to keep on top of the > manual bug triage work, please let us know and we'll be happy to > accommodate you. > > Exclusions so far: > - okteta > - krita > - any bug reported by sit...@kde.org > Hold up, what? Why is Harald being excluded? -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Bringing Cantata under the KDE umbrella?
On Mon, Feb 20, 2023 at 7:18 AM Aleix Pol wrote: > > On Mon, Feb 20, 2023 at 12:28 AM Heiko Becker wrote: > > > > On Sunday, 19 February 2023 23:36:22 CET, Albert Astals Cid wrote: > > > El diumenge, 19 de febrer de 2023, a les 16:29:24 (CET), Heiko Becker va > > > escriure: > > >> Cantata is a Qt based MPD client, which was archived by its > > >> original author > > >> [1]. I started some porting to Qt6 but I wondered (and was asked in > > >> #kde-devel today) if it would make sense to move it to KDE's > > >> infrastructure? Despite being archived, it still works quite > > >> nicely. And ... > > > > > > My only 2 concerns are: > > > > > > * Is anyone going to work on it? I guess you? > > > > Yes. > > Part of the incubation process is to gather what's the team working on it. > https://community.kde.org/Incubator/Projects/DescriptionTemplate > > It feels wrong to incubate a project that is already out of > development. Especially when we already have a number of music > players... > It's not without precedent though, didn't it happen with NeoChat, which forked from Spectral? -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Bringing Cantata under the KDE umbrella?
On Mon, Feb 20, 2023 at 5:30 PM AnnoyingRains wrote: > > Let's keep things civil here, this is just a mail client configuration > issue, gmail does all of this by default. > If I just clicked "reply" to this message on gmail, it would only > reply to you, as gmail does not understand mailing lists at all! > This is configurable in Gmail, you can change it to "reply all" by default when multiple recipients are in the email you're replying to. -- 真実はいつも一つ！/ Always, there's only one truth!
xwaylandvideobridge as a KDE app, when?
Hey all, Two weeks ago, David Edmundson posted on his blog about xwaylandvideobridge[1], which is a super-cool and exciting app to make Plasma Wayland an even better experience when dealing with legacy X11 apps. In that timeframe, I've gotten a lot of inquiries about when we'll ship it in Fedora KDE. I personally am super-excited about this too, as it resolves a huge pain point around the Plasma Wayland session for us. When will we see it released as a KDE app that I can ship? Thanks in advance and best regards, Neal [1]: http://blog.davidedmundson.co.uk/blog/xwaylandvideobridge/ -- 真実はいつも一つ！/ Always, there's only one truth!
First round of feedback from Fedora 40 KDE Plasma 6 (Wayland-only) discussion
Hey all, So unless you've been living under a rock for the past week, you might have noticed a bunch of buzz about Fedora KDE proposing to drop the X11 session with Plasma 6[1]. Those of you who were at Akademy last year[2] or this year[3] knew that this was coming. For the rest of you... 🤭 Over the past few days, I've gotten a deluge of use-cases and needs that would be useful to sort through and figure out actions to move forward on. Some of them, I've got ideas, others less so. The first thing that came up was that KiCad seems to need help and has had a bad experience interfacing with some folks over resolving their issues moving into a Wayland world. * https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/6KLDR4WM7PMJ7VJTP4LH2HA4RAMCR6UJ/ * https://groups.google.com/a/kicad.org/g/devlist/c/-glHquy0b20/m/nSBa_ntOAAAJ I don't have any particular suggestions here, though David Edmundson mentioned in the Fedora KDE Matrix room the idea of creating a new protocol to support their particular need of positioning and plumbing it through to Qt so that wxQt can use it. Also, some dedicated outreach might be a good idea to get them to be more amenable to the Wayland world. Session restore has come up a few times. It actually came up during the initial discussion within the SIG too, and has come up again during the proposal discussion in Fedora. * https://pagure.io/fedora-kde/SIG/issue/347#comment-856399 * https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/D76KHIPEPS6N7N3QHX6KBVDQ4RF5NVYO/ GNOME designed a protocol for their use, can we reuse this as an initial way to solve this problem? What's stopping us from doing something here? Barrier/Input-Leap has come up as well. Seamless keyboard and mouse handoff across computers is in demand. * https://discussion.fedoraproject.org/t/89794/6 * https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12 The necessary portal frontends have landed in xdg-desktop-portal and so we're just missing the requisite backend in xdg-desktop-portal-kde. Something that was a little surprising to find out is that kwin's support for the number pad seems to be in less than ideal condition. * https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/5VHB34MWX5UTJE3CLOINE6OBREQIX4RY/ This doesn't seem huge to fix, but I don't know a lot about key maps... A rather dominating part of the discussion has been color management (or the current lack thereof). * https://discussion.fedoraproject.org/t/89794/12 * https://discuss.kde.org/t/fedora-kde-40-plans-to-completely-drop-x11/5047 * https://invent.kde.org/plasma/kwin/-/issues/11 This one seems to have been dragging on upstream in wayland-protocols for years now. Could we consider shipping the draft as a kde namespaced protocol (similar to what the Chrome OS folks did for aura-shell) and migrating to the finalized version later? (As a sidebar, I'm extremely disappointed in how poorly wayland-protocols governance is going right now. I count seven wayland-protocols proposed by folks I know are from KDE that are in varying states of being stuck, with all but three 6+ months old and in varying levels of decay. This is seriously hampering the development of Plasma Wayland from my point of view. And it's not just protocols from KDE that benefit KDE. Even ones from GNOME developers that we want are in similar ruts.) The lack of functioning support for host-guest clipboard copy-paste in Plasma Wayland with SPICE was also brought up as a problem. Not just for regular virtualization use, but also because it hampers testing workflows. * https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/AERH56JOMVKMNJA6MDKCFFC7DKGIRV53/ * https://bugzilla.redhat.com/show_bug.cgi?id=2016563 * https://gitlab.freedesktop.org/spice/linux/vd_agent/-/issues/26 I am not sure what should be done here, but it clearly kind of sucks to have this problem. It's not currently on our list of Plasma Wayland "Showstoppers", maybe it should be listed there? Semi-related but not necessarily in the land of KDE, I got feedback on the Fediverse about the lack of a method for pre-authorizing applications to access portals means that certain classes of applications are functionally impossible to use in a Wayland environment. The example I was given was Veyon, which allows teachers to control school computer labs and monitor them while they're in use. This is a much more interesting variation of the automatic headless remote integration case for IT support systems software. * https://mastodon.tedomum.net/@lebout2canap/111074670912414830 * https://github.com/flatpak/xdg-desktop-portal/issues/1105 This is probably a solution that needs to be handled at the xdg-desktop-portal level, but I wanted to highlight it here for everyone. So you might think that with this list that it's all bad news, but it's not! The good news is that most of these were already captured
Re: First round of feedback from Fedora 40 KDE Plasma 6 (Wayland-only) discussion
On Mon, Sep 18, 2023 at 1:21 PM Laura David Hurka wrote: > > On Monday, September 18, 2023 6:44:28 AM CEST Neal Gompa wrote: > > Hey all, > > > > So unless you've been living under a rock for the past week, you might > > have noticed a bunch of buzz about Fedora KDE proposing to drop the > > X11 session with Plasma 6. > > Well, in this respect I am living in a subway tunnel... > I knew that this day will come. > > > Barrier/Input-Leap has come up as well. Seamless keyboard and mouse > > handoff across computers is in demand. > > * https://discussion.fedoraproject.org/t/89794/6 > > * https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12 > > The necessary portal frontends have landed in xdg-desktop-portal and > > so we're just missing the requisite backend in xdg-desktop-portal-kde. > > Besides Barrier, there are also Synergy, x2x, and dozens of actual remote > desktop applications. > As soon as xdg-desktop-portal(-kde) supports programmatic handling of > keyboards and screens, does that mean we can easily make applications like > wayland2wayland? > Indeed it does. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: First round of feedback from Fedora 40 KDE Plasma 6 (Wayland-only) discussion
On Mon, Sep 18, 2023 at 8:42 AM David Edmundson wrote: > > On Mon, Sep 18, 2023 at 5:45 AM Neal Gompa wrote: > me of them, I've got ideas, others less so. > > > > The first thing that came up was that KiCad seems to need help and has > > had a bad experience interfacing with some folks over resolving their > > issues moving into a Wayland world. > > Given I'm quoted, I said we shouldn't rush clients to not be on Xwayland. > These are just Kicad's known issues, it'll be longer to fix all the > issues that come up after they're ported. > That's what Xwayland is for, and we've put a lot of effort into it. > They seem to be under the impression that KiCad can't run effectively under XWayland either and refuse to support it because of that. I'm quite fine with convincing them to be comfortable with XWayland too. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: First round of feedback from Fedora 40 KDE Plasma 6 (Wayland-only) discussion
On Wed, Sep 20, 2023 at 8:53 AM Niels De Graef wrote: > > Hi everyone, > > Thanks Neal for including me! > Thanks for joining in the conversation! > (For the people who don't know me, I work for Red Hat as the product > owner in the GPU team, which has maintained (and some time ago > deprecated) Xorg, as well as maitning other graphics APIs such as > Wayland, OpenGL, Vulkan etc. I'm also a GNOME contributor in my free > time and sometimes do Wayland advocacy in local communities.) > > I'll put my answers inline so we can keep things a bit structured here. > > On Mon, Sep 18, 2023 at 6:45 AM Neal Gompa wrote: > > > > Hey all, > > > > So unless you've been living under a rock for the past week, you might > > have noticed a bunch of buzz about Fedora KDE proposing to drop the > > X11 session with Plasma 6[1]. Those of you who were at Akademy last > > year[2] or this year[3] knew that this was coming. For the rest of > > you... 🤭 > > > > Over the past few days, I've gotten a deluge of use-cases and needs > > that would be useful to sort through and figure out actions to move > > forward on. Some of them, I've got ideas, others less so. > > Before deep-diving: thanks for writing this up! It's good to have some > discussions going on each topic > > > The first thing that came up was that KiCad seems to need help and has > > had a bad experience interfacing with some folks over resolving their > > issues moving into a Wayland world. > > * > > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/6KLDR4WM7PMJ7VJTP4LH2HA4RAMCR6UJ/ > > * > > https://groups.google.com/a/kicad.org/g/devlist/c/-glHquy0b20/m/nSBa_ntOAAAJ > > I don't have any particular suggestions here, though David Edmundson > > mentioned in the Fedora KDE Matrix room the idea of creating a new > > protocol to support their particular need of positioning and plumbing > > it through to Qt so that wxQt can use it. Also, some dedicated > > outreach might be a good idea to get them to be more amenable to the > > Wayland world. > > In terms of general outreach to the KiCad project: I looked into it a > while ago after a friend of mine pointed out that they thought it was > a shame it didn't have Wayland support. > > Basically, the community had closed the issue for Wayland support as > WONTFIX due to the belief that Wayland wouldn't fix their issues, so I > tried to clear up some of the confusion: > https://gitlab.com/kicad/code/kicad/-/issues/7207#note_1356840266 . At > the very least it _looks_ like things improved since then, but it > still needs a bit of "massaging" to keep mindsets in a positive > environment. At the very least, it seems like some of their features > might be unblocked, and they reopened the issue as well. > > FWIW: I'm a contributor to GIMP as well, and I had to work through a > similar mentality, where people have/had similar negative attitudes > towards Wayland. The problem is that also for them, it takes patience > and understanding the problems they face, as they fall into an "XY > problem" (https://en.wikipedia.org/wiki/XY_problem): "I need to have > global positioning" (which is a WONTFIX current for most Wayland > developers) vs "I want to restore the positions of my toplevel > windows" (which would be solved with the xdg-session-management > protocol that's proposed upstream). > > > Session restore has come up a few times. It actually came up during > > the initial discussion within the SIG too, and has come up again > > during the proposal discussion in Fedora. > > * https://pagure.io/fedora-kde/SIG/issue/347#comment-856399 > > * > > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/D76KHIPEPS6N7N3QHX6KBVDQ4RF5NVYO/ > > GNOME designed a protocol for their use, can we reuse this as an > > initial way to solve this problem? What's stopping us from doing > > something here? > > In case anyone's interested, Philip Withnall (who worked on this) made > a blog post about it at > https://tecnocode.co.uk/2023/08/07/guadec-2023/ , which also contains > a link to the video & slides of his talk. > > > Barrier/Input-Leap has come up as well. Seamless keyboard and mouse > > handoff across computers is in demand. > > * https://discussion.fedoraproject.org/t/89794/6 > > * https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12 > > The necessary portal frontends have landed in xdg-desktop-portal and > > so we're just missing the requisite backend in xdg-desktop-portal-
Re: First round of feedback from Fedora 40 KDE Plasma 6 (Wayland-only) discussion
On Thu, Sep 21, 2023 at 8:11 PM Neal Gompa wrote: > > On Wed, Sep 20, 2023 at 8:53 AM Niels De Graef wrote: > > > > Hi everyone, > > > > Thanks Neal for including me! > > > > Thanks for joining in the conversation! > > > (For the people who don't know me, I work for Red Hat as the product > > owner in the GPU team, which has maintained (and some time ago > > deprecated) Xorg, as well as maitning other graphics APIs such as > > Wayland, OpenGL, Vulkan etc. I'm also a GNOME contributor in my free > > time and sometimes do Wayland advocacy in local communities.) > > > > I'll put my answers inline so we can keep things a bit structured here. > > > > On Mon, Sep 18, 2023 at 6:45 AM Neal Gompa wrote: > > > > > > Hey all, > > > > > > So unless you've been living under a rock for the past week, you might > > > have noticed a bunch of buzz about Fedora KDE proposing to drop the > > > X11 session with Plasma 6[1]. Those of you who were at Akademy last > > > year[2] or this year[3] knew that this was coming. For the rest of > > > you... 🤭 > > > > > > Over the past few days, I've gotten a deluge of use-cases and needs > > > that would be useful to sort through and figure out actions to move > > > forward on. Some of them, I've got ideas, others less so. > > > > Before deep-diving: thanks for writing this up! It's good to have some > > discussions going on each topic > > > > > The first thing that came up was that KiCad seems to need help and has > > > had a bad experience interfacing with some folks over resolving their > > > issues moving into a Wayland world. > > > * > > > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/6KLDR4WM7PMJ7VJTP4LH2HA4RAMCR6UJ/ > > > * > > > https://groups.google.com/a/kicad.org/g/devlist/c/-glHquy0b20/m/nSBa_ntOAAAJ > > > I don't have any particular suggestions here, though David Edmundson > > > mentioned in the Fedora KDE Matrix room the idea of creating a new > > > protocol to support their particular need of positioning and plumbing > > > it through to Qt so that wxQt can use it. Also, some dedicated > > > outreach might be a good idea to get them to be more amenable to the > > > Wayland world. > > > > In terms of general outreach to the KiCad project: I looked into it a > > while ago after a friend of mine pointed out that they thought it was > > a shame it didn't have Wayland support. > > > > Basically, the community had closed the issue for Wayland support as > > WONTFIX due to the belief that Wayland wouldn't fix their issues, so I > > tried to clear up some of the confusion: > > https://gitlab.com/kicad/code/kicad/-/issues/7207#note_1356840266 . At > > the very least it _looks_ like things improved since then, but it > > still needs a bit of "massaging" to keep mindsets in a positive > > environment. At the very least, it seems like some of their features > > might be unblocked, and they reopened the issue as well. > > > > FWIW: I'm a contributor to GIMP as well, and I had to work through a > > similar mentality, where people have/had similar negative attitudes > > towards Wayland. The problem is that also for them, it takes patience > > and understanding the problems they face, as they fall into an "XY > > problem" (https://en.wikipedia.org/wiki/XY_problem): "I need to have > > global positioning" (which is a WONTFIX current for most Wayland > > developers) vs "I want to restore the positions of my toplevel > > windows" (which would be solved with the xdg-session-management > > protocol that's proposed upstream). > > > > > Session restore has come up a few times. It actually came up during > > > the initial discussion within the SIG too, and has come up again > > > during the proposal discussion in Fedora. > > > * https://pagure.io/fedora-kde/SIG/issue/347#comment-856399 > > > * > > > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/D76KHIPEPS6N7N3QHX6KBVDQ4RF5NVYO/ > > > GNOME designed a protocol for their use, can we reuse this as an > > > initial way to solve this problem? What's stopping us from doing > > > something here? > > > > In case anyone's interested, Philip Withnall (who worked on this) made > > a blog post about it at > > https://tecnocode.co.uk/2023/08/07/guadec-2023/ , which also contains
Re: Reviving lightdm-kde-greeter upstream
On Wed, Nov 22, 2023 at 9:10 AM Justin Zobel wrote: > > There's a long running discussion [1] going on about incubation SDDM into KDE. > > * 1 https://invent.kde.org/plasma/plasma-desktop/-/issues/91 > > On Wed, 22 Nov 2023, 19:19 Anton Golubev, wrote: >> >> Hello! >> >> I am involved in the development of the ALT Linux distribution. Some >> time ago we started developing the lightdm-kde-greeter fork and I am >> currently maintaining it[1]. I also push it on gitlab[2]. In addition to >> porting to Qt5, some features have been added, such as choosing a >> keyboard layout and connecting to the network. This greeter is currently >> used by default in our KDE-based builds. >> >> I was given the idea to revive this project in the upstream[3]. >> Personally, I like the idea, and might look into it if someone else >> finds it useful, and I will be given appropriate access. >> >> Regards, >> >> [1]: https://git.altlinux.org/gears/l/lightdm-kde-greeter.git >> [2]: https://gitlab.com/golubevan/lightdm-kde-greeter >> [3]: https://invent.kde.org/unmaintained/lightdm I think that given someone is actively working on the LightDM greeter and wants to use it, it should be fine to get it hosted in KDE infrastructure. LightDM has some issues itself though, notably that Canonical has more or less abandoned it and it doesn't yet support running without X11. And I suppose the LightDM Qt bindings need to be ported to Qt 6 too... -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Reviving lightdm-kde-greeter upstream
On Tue, Nov 28, 2023 at 1:47 AM Anton Golubev wrote: > > It would hardly be convenient for me to maintain several similar > repositories in parallel, so if it is located in the KDE infrastructure, > I will commit there for sure. > > But could you please specify more precisely where the requirement to > "kill" forks is described? It seems that I looked through the entire > tree of links that drop down to the one you specified, and did not find > any prohibitions. And the GPL* license does not seem to prohibit the > existence of forks. > > This is important because in particular [1] is a special repository with > instructions for building packages into an ALT repository, "Sisyphus" > (located in the .gear folder), and it must continue to exist in some > form. If the project develops inside KDE, will I be able to merge the > changes back to [1]? > That is allowed. Debian does the same thing with their packaging. I personally think it's a bad thing to use forks of the source code for packaging rather than having a pure packaging Git repo, but if that's the way you want to do it, sure. The main point of killing the forks is to prevent confusion about where things are actively developed. It is not a requirement per-se, but something that is generally expected so that there is a clear communication and understanding of where it is developed. When Qupzilla became Falkon in KDE, it went through that process as well. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: KDE Plasma 5.27 on OpenBSD
On Tue, Dec 26, 2023 at 9:26 AM Rafael Sadowski wrote: > > Hi, > > I am pleased to announce that KDE Plasma is available on OpenBSD > alongside all KDE Gear 23.08.4 applications as well as Frameworks > 5.113.0. > > Today the 26.12.23 it was enabled and will be available in the next > release (or in -current rolling release). > > - https://twitter.com/sizeofvoid/status/1739641916050792882 > - https://marc.info/?l=openbsd-ports-cvs&m=170359681610856&w=4 > - https://marc.info/?l=openbsd-ports-cvs&m=170359673610818&w=4 > Congratulations! Out of curiosity, do you have KDE Plasma Wayland working yet? I saw recently that the basic Wayland stack was ported to OpenBSD and now that the Sway stack works on OpenBSD[1] and I know that it works on FreeBSD already[2]. [1]: https://homepages.laas.fr/matthieu/talks/wayland-openbsd.pdf [2]: https://euroquis.nl/kde/2021/04/30/wayland.html -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Feature freeze exception request (plasma-workspace MR 3734)
On Sat, Jan 6, 2024 at 5:32 AM Prajna Sariputra wrote: > > Hello Plasma developers, > > I'd like to request a feature freeze exception for > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3734, which > adds a new switch to set the wallpaper for all screens in one go, and has > been requested by users in bug 436001 > (https://bugs.kde.org/show_bug.cgi?id=436001). Nate Graham suggested that I > should try to apply for this exception. > > As I am not subscribed to this mailing list, please use "Reply All" rather > than "Reply List". > I certainly would like to see this land, because it's so small and provides such a high impact to the user experience. I know it annoys me that I've had to do it one by one in a multi-monitor setup. And at one point I worked on something with a large number of monitors, and I regretted having to change the wallpaper on each screen manually. I'm all for it. :) -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Post-MegaRelease projects
On Thu, Feb 22, 2024 at 4:57 PM Nate Graham wrote: > > Hello everyone, > > Congrats to the entire KDE community on the impending launch of the KDE > 6 MegaRelease! I'm so impressed with how folks came together to make it > amazing. It's a very impressive release and I think people are gonna > love it. > > I've started pondering post-megarelease projects. We've spent so long on > porting and bugfixing that I think it might be useful to shift gears to > feature work, and I'd like to brainstorm potential large-scale projects > and gauge the level of interest in putting resources into them soon. > > Here are some ideas of mine to get the creative juices started: > > * David's input method playground stuff [1] is amazing and needs to be > developed and productized > * GNOME's Libadwaita app platform has been a runaway success for them; > evaluate our offerings in comparison and see what we can do better I think it really helps that they got their act together about their developer documentation and experience. It's coherent and easy to follow all from https://developer.gnome.org/. We've started building an equivalent at https://develop.kde.org/, but we're not quite there yet. Additionally, my last go-around with KDevelop didn't exactly get me "started" with making a KDE application like how GNOME Builder does with its templates. This problem is going to be much worse with KDE Platform 6, since KDevelop has not yet been updated for it. > * Unified theming infrastructure for KDE apps, GTK apps, and Plasma. > ** Relatedly: QML/JS in themes is dangerous; move away from it I've heard from people over the years that they'd love to have easy SVG/CSS style theming that has complete coverage (like Kvantum but actually works everywhere), do we have a task to track making this possible? > * Start adding release notes to our apps' AppStream metadata [2] > * Finish up and ship the new Breeze icons > * HIG is outdated and mostly ignored, and needs an overhaul to make it > useful Yes, I've noticed that it's somewhat inconsistent with what we do for KDE apps these days... -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Post-MegaRelease projects
On Fri, Feb 23, 2024 at 8:06 AM Carl Schwan wrote: > > * Rework our online account integration > > An idea I have is to move away from KAccounts/signond/account-sso since it's a > standard that is used only by anyway and instead provide Qt Plugins that setup > Akonadi/NeoChat/Nextcloud/Tokodon/GDrive/ here>/... and are provided by the app themselves so that we don't have to > duplicate all the login logic in the app and in the online account KCM. > signond/accounts-sso is also used by Pantheon/elementary OS, so it's not just us. That said, GOA (GNOME's equivalent) is also in a bit of disarray too... https://andyholmes.ca/posts/goa-and-stf-part-1/ -- 真実はいつも一つ！/ Always, there's only one truth!
Re: APIs for persistent remote access and headless/hybrid sessions
On Tue, Feb 27, 2024 at 2:52 PM Erik Jensen wrote: > > I'm on the Chrome Remote Desktop team at Google, and I am working to > add support for Wayland-based desktop environments. While our initial > focus will be on getting it to work with GNOME, we'd love the > functionally to be based on standardized APIs that can be used across > desktop environments, so I'm reaching out here to see what interest > there might be on the KDE side. > > There's been a bit of discussion[1] on the GNOME Discourse, but to > summarize, while the existing Portal APIs are great for remote > assistance use cases where there is a local user to approve the > session and mirroring the local display(s) makes sense, they are > lacking functionality needed for the persistent remote access use > case, where: > > * Connection should be possible immediately after boot. > * For security, the session should operate in a headless mode while a > remote connection is active and the physical seat should remain > locked. > * Virtual monitor layout should be configurable by the remote desktop > tool to match the client, rather than mirroring the physical layout of > the host. > > GNOME is currently pursuing an approach where the remote access tool > runs as a system service, and connecting presents a login screen where > the user can select a session and log in. Some handoff mechanism is > then used for a process running in the resulting session to take over > the connection. > > The current GNOME implementation is based on unstable, GNOME-specific > APIs. As far as I understand it, there are three main pieces that > would need to be standardized for this approach to work in a > desktop-agnostic fashion: > > * An expanded remote desktop API for the compositor. Unlike the > Portals API, this API would only be exposed to trusted processes and > would not require a prompt for each session. Additionally, it would > provide support for configuring virtual monitor resolutions, layout, > and DPI, as well as support for accessing the clipboard. Jonas Ådahl > has been working on creating a standard spec for this functionality, a > draft of which is available at [2]. > * An API for requesting a new remote display from the greeter, which > the remote desktop tool could then attach to using the above API to > allow the user to log in. This would also provide a method for the > remote access tool to identify the resulting session. > * A protocol by which the greeter can instruct the desktop > environment to launch in headless mode for remote access, or > (eventually) transition into/out of headless mode so the user can > attach to the same session locally or remotely. Desktop Environments > would presumably signal their support for headless / hybrid sesssions > via an entry in their respective .desktop file. > > Of course, there are other approaches one could take, such as > expecting the remote desktop tool to handle PAM authentication and > session creation directly, rather than relying on the system greeter, > or allowing individual users to set up a remote desktop tool as a user > service that can only launch sessions on behalf of that user (which > would require linger and wouldn't work with encrypted home > directories, but would be more similar to how Chrome Remote Desktop > currently works). > > Is such persistent remote access functionality something KDE would be > interested in having? Do folks have thoughts on what they'd like to > see such APIs look like? > > Thanks! > > [1]: https://discourse.gnome.org/t/persistent-remote-desktop-access-api/19415 > [2]: https://gitlab.freedesktop.org/jadahl/xdg-specs/-/merge_requests/1 (Sorry if you have two, I sent with the wrong address initially...) I can't speak for everyone in KDE, but I am certainly interested in seeing this in KDE Plasma. Last year, I held a talk with David Duncan at Flock discussing the concept of "Fedora Cloud KDE"[1]. To that end, I've been playing around with KRdp[2] and other things. It became very apparent that we have some gaps, and I think they align quite closely to what you've observed. What I would like to see is a specification that display managers could implement to support headless/virtual remote desktop. Then we don't have to do weird things with PAM, and more importantly, we can support either protocols that do login directly (RDP) and those that don't (VNC). This would also likely require extending the wayland-sessions desktop file format to offer attributes to declare support for headless login and specific protocols. I will point out that the pre-authorization problem with portals[3] is at this point backend-specific (and I think the KDE portal backend automatically authorizes RemoteDesktop portal for system installed software). What we need is to push for the frontend-side (xdg-desktop-portal) to provide a way to consistently apply pre-authorization policy. It's a major usability problem and will affect future portals too (such as the accessibility portal b
Re: APIs for persistent remote access and headless/hybrid sessions
On Fri, Mar 15, 2024 at 7:52 PM Erik Jensen wrote: > > Thinking about this more, I'm not really sure extending the existing > Portal API makes sense. > > Given that remote assistance (well served by the existing API) wants > > * Explicit user consent to share > * To allow the local user to select what to share > * To mirror the selected existing displays / windows > > while remote assistance wants > > * Persistent access > * To ensure the session is curtained or headless to prevent > observation and interaction from the local console > * Full control over the virtual monitor layout and the ability to > capture all of it > > It seems like a unified API would have enough special cases depending > on which access mode is in use that it wouldn't really be worth it, > especially given that the actual capture (PipeWire) and input > injection (libei) would be the same either way. E.g., even with > persistent permission tokens, the existing ScreenCast portal doesn't > really fit the remote access use case, and a separate API to control > the layout and get the resulting PipeWire streams without user monitor > selection likely makes more sense. > > > I suspect we might need Plasma Login Manager to exist first before > > we can achieve this, though. The kind of integration that GDM and > > GNOME Shell have allowed them to pull off what they did there, I'm > > not sure how to do it without that integration. > > Ideally, I'd like to have a standard protocol that is both lightweight > and flexible enough that it wouldn't require any deep integration > between the login manager and desktop environment, but could be > implemented by even lightweight login managers. I would like that too, but we currently don't even have a standard specification for display managers themselves. I thought we did, but then I did the research about the protocol that SDDM implements[1], and it turns out that it was created by LightDM over a decade ago[2] and was never documented as a standard in the first place. GDM's protocol is quite a bit more sophisticated (but also not standardized). So that's a problem that we might need to address first. Also, it looks like there's a draft spec[3] being worked on by Jonas Ådahl about a remote desktop protocol (presumably based on what GNOME has been working on). [1]: https://github.com/sddm/sddm/commit/069f1d7d91bca55673d78cbace448942d46965d6 [2]: https://github.com/canonical/lightdm/commits/main/src/display-manager.xml [3]: https://gitlab.freedesktop.org/jadahl/xdg-specs/-/merge_requests/1 -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Should we stop distributing source tarballs?
On Thu, Apr 4, 2024 at 9:52 AM Harald Sitter wrote: > > On Thu, Apr 4, 2024 at 3:38 PM Tobias Leupold wrote: > > > > Am 04.04.24 um 13:25 schrieb Harald Sitter: > > > On Thu, Apr 4, 2024 at 12:57 PM Tobias Leupold wrote: > > >> Just what comes into my mind at once. A release is not always only a git > > >> tag. > > > > > > Doesn't that make your source tarball a derived work from the source > > > in your git tag? > > > > Yes, of course! this was the point of what I wrote ... > > But then it's no longer **the** source. The source was your tag. A lot of distributions can't really easily consume Git as a source for software for packaging, and because Git has no immutability guarantees, it's not exactly ideal as an input either. That said, some of the issues that came up with xz-utils compromise are things we can more easily mitigate. We can be more vigilant about CMake scripts and CMake modules. We should treat them at the same level as source code itself for code review if we don't already. Another thing to think about is maybe switching from xz compression to zstd compression, as the compression ratio is generally quite close to xz and decompression is significantly faster and cheaper than xz. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Should we stop distributing source tarballs?
On Thu, Apr 4, 2024 at 10:18 AM Jin Liu wrote: > > > Neal Gompa 于 2024年4月4日周四 22:09写道： > > and because Git has no immutability > guarantees, it's not exactly ideal as an input either. > > Commits and trees in git are immutable. Refs like tags and branches are not. That's fair, but they are not permanent and can be reaped when they're not referenced by anything anymore. And it's still a pain to deal with anyway. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Proposal unify back our release schedules
On Fri, Apr 19, 2024 at 11:35 AM Volker Krause wrote: > > On Freitag, 19. April 2024 11:04:33 CEST Carl Schwan wrote: > > * We currently don't have a stable branch for Framework and it takes often > > up to one month for fixes to be deployed. The Framework releases is also > > not in sync with either Gear nor Plasma while these two modules heavily > > make use of Framework and contribute to Framework. > > The fast feature-releases of KF have major advantages though, comparing to how > things worked prior to 5. They allow apps to work against released (and thus > distro-packaged) frameworks while still making it practical to contribute > needed features to KF directly. > > The alternatives are: > * Depend on KF master (like Plasma does), significantly increasing the > threshold of entry for new contributors, especially for more self-contained > apps, where you'd now have to build 70+ repos rather than a few. > * Depend on the latest release but develop new features locally rather than in > KF. I'm not sure whether we have meanwhile finally cleaned up all the forked > kdelibs classes in PIM from the 3 and 4 era due to that. > * Depend on the latest release and wait for new features to become available > before making use of them in the app, effectively increasing the delay to > reach > users to twice the release cycle. > > Ie. this makes contributing to KF less attractive from an app developer > perspective. > > > The main issues with out-of-sync KF and Plasma should have been solved with > some frameworks being moved to Plasma with KF6, if there is more of this > remaining we should look at the specific cases, for the vast majority of > frameworks I don't think we have a problem there. > > > * Helps with outside usage of our frameworks. These didn't get as much > > success as we were hoping when splitting. I think having a stable branch > > for Framework might help but this is only a guess. It would be interesting > > to know of cases where people considered using some Framework and to know > > why they decided against or for it and if this proposal would helps or not. > > I disagree with the often repeated statement that this wasn't successful. It > might not happened as widely and visibly as we might want, but KF is most > certainly used vastly more often than kdelibs ever was. And the release > schedule isn't the impediment here, it's things like dependencies and the > build system making it hard to vendor copies. > > > In effect this proposal would mean: > > > > * We do one major release every 4 months and then minor releases with a > > frequency based on the Fibonacci numbers as this releases cycle works very > > well for Plasma. Naming could be either YY.MM or Major.Minor.Path. We could > > unify that for one or the other one. Or let each component keep their > > current versioning scheme depending whether we want to merge Plama and Gear > > as product or keep it separate. I'm a bit undecided about this. > > From my app developer perspective that is fine, Fibonacci rather than > equidistant patch releases look like an improvement to me. However, assuming > the feature release interval basically remains the same. > > AFAIK Plasma is discussing a 6 month interval though, and I do understand > longer cycles are better for promo, but it means users have to wait longer for > features. It therefore also matters whether we are tying Plasma's release to > Gear or Gear's releases to Plasma here. > > > * "KDE Framework" will still exists as an entity and its ABI and API > > compatibility requirement. Only change is the release frequency and the > > introduction of a stable branch in sync with the other components. > > That part I'm against for the above mentioned reasons, KF's release frequency > is a major feature of it. > As a distribution, I found it tremendously helpful to integrate and qualify the MegaRelease. That doesn't mean that we need *every* release of KF and Gear to be MegaReleases. One way I think that would work well would be to realign the schedules so that when Plasma shifts to semi-annual releases, Frameworks and Gear would be re-aligned so that there *would* be a release that lines up with it. That doesn't mean both can't continue to have more releases separately, but having a release that lines up for Plasma would help things considerably. The monthly release of KDE Frameworks has its downsides, and I think in one conversation elsewhere, I suggested that KF moves to a quarterly release cadence, where two of the releases line up with Plasma to become MegaReleases. Gear already releases three times a year, and switching to four times might not be so bad. But even if KF doesn't change and remains monthly, then it still can work. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Proposal unify back our release schedules
On Mon, Apr 22, 2024 at 2:29 PM Nate Graham wrote: > > > > On 4/22/24 19:19, Albert Astals Cid wrote: > > El dilluns, 22 d’abril del 2024, a les 17:12:46 (CEST), Nate Graham va > > escriure: > >> Now, let's say we make Gear use Plasma's current release schedule by > >> syncing up the feature releases and adopting the Fibonacci bugfix > >> releases. If we don't end up changing Plasma's own release schedule then > >> we already make our promo store more coherent by letting the marketing > >> team do three big glossy announcements of user-facing products a year, > >> rather than being stretched thin for 6. Even if we make Plasma go down > >> to 2 releases a year, then we have two synced Gear+Plasma > >> "mega-releases" and 2 independent Gear releases--down from 6 to 4. Both > >> of these options would improve the promo story IMO. > >> > >> --- > >> > >> Moving on, the biggest points of contention I see revolve around > >> Frameworks. Personally I want to push back a bit on the idea of > >> developing an app against released frameworks. > > > > I disagree. > > > > In my ideal world, applications should be able to be built against a one > > year > > old frameworks, before the Qt6 port, Okular's minimum requirement was Ubuntu > > 22.04, which makes sure virtually everyone can contribute to it without > > having > > to build the world. > > > > There's virtually no need in Okular to depend against any new frameworks > > shiny > > feature, the existing features are more than enough. > > > > Cheers, > >Albert > > This is true for Okular, but we can't guarantee it for other apps. > > However I was fortunate enough to be sitting across a table from Volker, > who explained this point to me in a way that my tiny brain was capable > of understanding: :) that having a fast Frameworks release cycle allows > people developing apps with features in Frameworks to not have to live > on master like we do in Plasma. > > I'd love to have everywhere in my slide of KDE what Albert has for > Okular, but I there are other barriers to it that we need to overcome. > > As a result I'll rescind my idea to slow down Frameworks feature > releases. I do still think Frameworks could benefit from un-branched > bugfix releases a week after the feature releases--after which point > feature development would be open again. > > And I still support unifying or aligning the Gear and Plasma release > schedules. > Then I think we're back to my idea of monthly frameworks, quarterly Gear, and semi-annual Plasma with semi-synchronized schedules. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Reviewers needed for distro-deps/ files
On Sun, Aug 25, 2024 at 6:44 AM Steve Cossette wrote: > > Good morning Ben, > > Question about this if you don't mind. I was checking the Fedora list, and > noticed that there was potentially some old packages from Qt5 that > potentially don't need to be there. On top of that, I assume that maintaining > that list is quite taxing as dependencies change every release. > > Is there a plan to maybe use the package manager to download the build > dependencies instead? For example, in our case, you can install a package's > build dependencies with dnf (dnf builddep). We could provide you with a list > of frameworks/gear/plasma packages. > > This would make it virtually foolproof. > It's not necessarily foolproof. There are two cases where that would fail: * New dependencies * Qt/KF stack version upgrades (5->6, 6->7, etc.) Providing the list there allows those dependencies to be added as soon as they're needed with the added benefit of distributors having a reference to understand what they need to have for the stack to build. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Redundant packaging mailing lists
On Tue, Jul 28, 2020 at 9:59 AM Nate Graham wrote: > > Howdy folks, > > I just discovered that we have two mailing lists about distro packaging: > distributi...@kde.org and kde-distro-packag...@kde.org. The archives for > both show recent activity. Feels like we should collapse one into the > other to avoid this confusing redundancy. > > Any suggestions? I'd been only following the distributions@ mailing list. I did not even know about the other one... -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Supported C++ standard (aka compiler version) Overview Table for various distros?
On Wed, Oct 14, 2020 at 5:33 AM Milian Wolff wrote: > > Hey all, > > I would like to push for C++17 usage in KDevelop to make it more fun to > develop there. This is an extragear app, so I believe we can take this > decision separately from the surrounding KDE ecosystem. > > Does anyone know if there's an overview page similar to [1], but for Linux > distributions? > > [1]: https://en.cppreference.com/w/cpp/compiler_support > > I.e. I would like to know which distro versions we would potentially lose by > moving KDevelop master to C++17. I seem to recall that there existed such an > overview page somewhere, but I cannot find it anymore. > > If it doesn't exist, then I would love if we could all together create such a > table on our techbase wiki. > Fedora 32 and 33 are using GCC 10, and Fedora 34 will be using GCC 11. Red Hat Enterprise Linux/CentOS 8 is using GCC 8, but there is access to GCC 9 and soon GCC 10 too. openSUSE Leap 15.x is using GCC 7. openSUSE Tumbleweed is using GCC 10 right now. Mageia 8 will be using GCC 8. OpenMandriva Lx is currently using Clang 9 (and GCC 9). I think you'll be generally fine. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Synchronized release schedule for Plasma
On Thu, Nov 26, 2020 at 10:25 AM Aleix Pol wrote: > > On Tue, Nov 24, 2020 at 5:10 PM David Edmundson > wrote: >>> >>> As distribution package maintainers, we would like Plasma developers to >>> slightly alter the release schedule to align releases with a more >>> distribution friendly cycle. You could consider shortening one release >>> cycle (and then keep the 6 month schedule) to align releases. >> >> >> We have in the past shuffled things slightly to line up things up with >> distros on request, particularly LTS releases. We can certainly explore that >> on a one-off basis. >> >> >With this schedule in place, we would also benefit from more beta releases >> >over a slightly longer period. They would be packaged into the beta and RC >> >releases of those distributions thus enabling more pre-release testing. >> >> We did have 6 month release cycles in the past. >> >> The rationale for moving at the time was twofold: >> - people rushed in changes towards the feature freeze as otherwise it would >> be aages till their changes reached users >> - the more changes we have in a release, the more testing and inevitable >> regression fixes we need to do, spreading that out should result in things >> being more stable >> >> Initially we did every 3 months (which arguably still aligns) then it slowly >> slipped to 4. >> >> My personal impression is that releases have gotten better as a result of >> those changes, so I'm hesitant about reverting that decision. >> > > > Makes sense. With Qt being less of a moving target though, it could make > sense to reevaluate our cadence though, both because we might start looking > into the future and because the system we support should not be changing as > much. > If we don't want to move to 6 months, pulling back from 4 months to 3 months would make it easier for us to not miss Plasma releases. That being said, with Qt6 now being a thing, wouldn't that mean Qt is more of a moving target again? -- 真実はいつも一つ！/ Always, there's only one truth!
RFC: Split out project version in CMakeLists into a separate file to simplify downstream snapshot builds
Hello all, In the Fedora KDE SIG, we're working on setting up a process to build nightly snapshots of KDE software so that we can build and test changes across the stack easily. However, a hurdle that we've encountered early on is that it's difficult to pull out the version from the CMakeLists and use it to prepare a snapshot version for RPMs because they need to be evaluated by CMake to generate the correct value. What I'd like to ask is to consider splitting out the version into a simple text file that CMakeLists would source to set the version. This makes it much easier for us to parse it to generate the snapshot version string for our spec files when we're dynamically updating them for new snapshot builds. I've seen a few projects do this, so I know that it's possible. It's just more of a question if this is something we can have as a style thing for KDE projects to make it simpler to be able to continuously build KDE software for testing. I'm also open to better ideas if there are any, too. :) Best regards, Neal -- 真実はいつも一つ！/ Always, there's only one truth!
Re: RFC: Split out project version in CMakeLists into a separate file to simplify downstream snapshot builds
On Mon, Apr 12, 2021 at 3:17 PM Albert Astals Cid wrote: > > El dilluns, 12 d’abril de 2021, a les 20:39:26 (CEST), Neal Gompa va escriure: > > Hello all, > > > > In the Fedora KDE SIG, we're working on setting up a process to build > > nightly snapshots of KDE software so that we can build and test > > changes across the stack easily. However, a hurdle that we've > > encountered early on is that it's difficult to pull out the version > > from the CMakeLists and use it to prepare a snapshot version for RPMs > > because they need to be evaluated by CMake to generate the correct > > value. > > I don't understand why running cmake to get the version is hard but writing a > script to parse a file is easy. > > They are both "running binaries", so if you can just run binaries why not > just do the cmake thing that requires no changes on our side? > > Cheers, > Albert > > P.S: If the problem is you don't know how to get the version from cmake we do > this in various places, one being > https://invent.kde.org/sysadmin/release-tools/-/blob/master/tools/python-kde-release/kde_release/cmake.py > you basically run cmake with --trace-expand and parse the verison out of it. > Well, I didn't know about this functionality, so that would be why. :) Marc, would this work for you for your automation? -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [kdiff3] [Bug 436826] kdiff3 has no window, wayland, gnome
On Sun, May 23, 2021 at 2:13 PM Michael Reeves wrote: > > Could some familaur with Wayland/gnome client side decorating have a look at > this? I have a suspicion gnome is trying to force this feature on kdiff3. > > On Sun, May 23, 2021, 4:27 AM wrote: >> >> https://bugs.kde.org/show_bug.cgi?id=436826 >> >> solot...@gmail.com changed: >> >>What|Removed |Added >> >> Version|1.8.5 |1.9.2 >> >> --- Comment #1 from solot...@gmail.com --- >> this is valid for kdiff3-1.9.2 as well >> I assume that is related to this: https://gitlab.gnome.org/GNOME/mutter/-/issues/217 -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [kdiff3] [Bug 436826] kdiff3 has no window, wayland, gnome
On Sun, May 23, 2021 at 3:50 PM Michael Reeves wrote: > > Based on https://gitlab.gnome.org/GNOME/mutter/-/issues/217 > > I am terminating support for gnome/wayland unless and until gnome > stops force client side decoration on everyone. > If QGnomePlatform[1] is installed and configured, then this problem does not occur. [1]: https://github.com/FedoraQt/QGnomePlatform -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Can we get tags and tarballs for the KDE Qt patch collection
On Mon, Jun 7, 2021 at 4:52 PM Albert Astals Cid wrote: > > El dilluns, 7 de juny de 2021, a les 20:46:25 (CEST), Nate Graham va escriure: > > Hello folks, > > > > The Fedora packagers were mentioning to me today that it would be a lot > > easier for them to ship Qt with our patch collection if we made tags and > > tarballs. Is this something we could look into doing? > > We explicitly do not want to make releases > https://community.kde.org/Qt5PatchCollection#Will_there_be_releases.3F > > Making a release means having to use of a version number, and any version > number we use will be wrong. > > Don't think this as a product, think of it as a central place where patches > are collected. > > If they want a tarball because using git is a problem, they can always use > https://invent.kde.org/qt/qt/qtbase/-/archive/kde/5.15/qtbase-kde-5.15.tar.bz2 > ? > You *already* are using version numbers and bumped it to 5.15.3: https://blog.neon.kde.org/2021/06/04/kde-neons-qt-is-now-built-from-kdes-git-branches/ This is unreasonable if you're going to make us need fixes from there. I'd rather we didn't pretend this is something other than what it is: a community maintained uplift of Qt 5.15 while Plasma works to move to Qt 6. Also, that URL is unstable, you'd get different things each time you'd fetch from it based on the HEAD of that branch. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Can we get tags and tarballs for the KDE Qt patch collection
On Tue, Jun 8, 2021 at 9:04 AM Nate Graham wrote: > > On 6/8/21 5:20 AM, David Redondo wrote: > > Am Dienstag, 8. Juni 2021, 12:51:35 CEST schrieb Neal Gompa: > >> You *already* are using version numbers and bumped it to 5.15.3: > >> https://blog.neon.kde.org/2021/06/04/kde-neons-qt-is-now-built-from-kdes-git > >> -branches/ > > KDE did not bump the version number, the 5.15 (and kde/5.15) branch contains > > the commits from > > TQtC that increased the version number before it was closed. > > > > David > > > That being the case, what is the problem with us tagging it as 5.15.3? > We would not be using our own version number but rather the one set by > upstream. If the issue is one of not wanting to mislead people into > thinking that this is some kind of officially sanctioned thing, could it > be something like "5.15.3-kde-patches"? > "5.15.3.kde.N" would be the convention I'd recommend (to avoid issues with various distribution version consumption mechanisms), but yeah, having snapshot releases would make life *much* simpler. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Can we get tags and tarballs for the KDE Qt patch collection
On Tue, Jun 8, 2021 at 9:22 AM Ahmad Samir wrote: > > On 07/06/2021 22:52, Albert Astals Cid wrote: > > El dilluns, 7 de juny de 2021, a les 20:46:25 (CEST), Nate Graham va > > escriure: > >> Hello folks, > >> > >> The Fedora packagers were mentioning to me today that it would be a lot > >> easier for them to ship Qt with our patch collection if we made tags and > >> tarballs. Is this something we could look into doing? > > > > We explicitly do not want to make releases > >https://community.kde.org/Qt5PatchCollection#Will_there_be_releases.3F > > > > Making a release means having to use of a version number, and any version > > number we use will be wrong. > > > > Don't think this as a product, think of it as a central place where patches > > are collected. > > > > If they want a tarball because using git is a problem, they can always use > > https://invent.kde.org/qt/qt/qtbase/-/archive/kde/5.15/qtbase-kde-5.15.tar.bz2 > > ? > > > > Cheers, > >Albert > > > Alternatively they could treat it like backported kernel patches? > https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/Patchlist.changelog > I don't know the > details but it's doable is what I am saying. > > The thing is, IIUC the KDE Qt patch curators don't want to create a release, > just a set of > "important" patches on top of the last open-source Qt release, i.e. deal with > it like any other > project whose upstream hasn't made any new releases in a long time, but there > are new commits in > git; I am sure most distro packagers have seen one or two cases as such. > The kernel has a weird, special workflow that no other package does. It's because the RHEL kernel and Fedora kernel sources are merged and non-upstream RHEL-ish changes are now always present in the source tree. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Can we get tags and tarballs for the KDE Qt patch collection
On Tue, Jun 8, 2021 at 6:36 PM Ömer Fadıl USTA wrote: > > Please don't get me wrong but naming these patches under name of KDE will > make people confuse. > That will lead people to think that it is just KDE-related. So my suggestion > is naming is something like > qt-15.3-communityN that will let everyone take these patches whether if they > are using KDE or not. The branch is already "kde/5.15", so that ship has kind of sailed... 5.15.3.kde.N would at least maintain that relationship info. -- 真実はいつも一つ！/ Always, there's only one truth!
