Re: Per project repository snapcraft files?
On Sunday, August 20, 2023 12:47:10 PM CEST Ben Cooksley wrote: > On Sun, Aug 20, 2023 at 12:43 PM Scarlett Moore < > > scarlett.gately.mo...@gmail.com> wrote: > > Only on release! We will not be building from master! We don't want > > unstable snaps. > > Thanks, > > Scarlett > > In that particular case the jobs should be manually triggered only. > > Gitlab CI is really made for building artifacts for a given commit rather > than for a specified version though, so this is definitely going to be a > case of things not fitting quite right. > > Cheers, > Ben > [...] This confuses me too. It seems Scarlett wants to use a “deploy” stage [1] and a job rule [2] to run snap build&release jobs automatically when the release is done. If you mean that Gitlab CI should not be used to automate release jobs, you should elaborate more how binary-factory is meant to be replaced. Otherwise, do you just note that Gitlab CI is suboptimal, or do you recommend to use something else? Like: “Release build: automatic is fine. Release publish: please only manual”? Cheers, David [1] https://docs.gitlab.com/ee/ci/yaml/#stages [2] like this: snap-release-job: rules: -if: $CI_COMMIT_TAG =~ /^v[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]$/ [...] see also: https://docs.gitlab.com/ee/ci/jobs/job_control.html#use-predefined-cicd-variables-to-run-jobs-only-in-specific-pipeline-types
Re: Let's reserve F10 and Shift+F10 for accessibility
Hi Felix, thanks for this discussion! On Wednesday, September 6, 2023 11:27:34 AM CEST Felix Ernst wrote: > [1] I propose that we reserve the F10 key in most/all applications to either > open the first menu in the menu bar or open the hamburger menu (depending > on application). I didn’t know that F10 is standard for the menu bar. I agree that it should work. Applications should not hide the menu bar by default if it contains important actions. Hiding the menu bar requires only 2 clicks or Ctrl+M, and actions can provide the hamburger menu button in the toolbar by default. (Okular does this.) > [2] I propose that we reserve the Shift+F10 key combination to open the > context menu for the item that has keyboard focus. It should have the same > effect as the "Menu" key many keyboards have. Yeah. > About Shift+F10 I am not sure yet at which layer this should be implemented. > Ivan Tkachenko mentioned the idea in chat that it could potentially be > implemented as a Plasma-wide keyboard setting. Pressing Shift+F10 would > then always be identical to pressing the "Menu" key on a keyboard. Qt Widgets applications can use QContextMenuEvent/QWidget::contextMenuEvent(). Qt documentation indicates that the global context menu behavior follows the platform, so Plasma could tell Qt that Shift+F10 shall do the same as Menu. But it seems only some KDE applications support the Menu key. E. g. it works in Konsole, Dolphin, and KMail message view. It doesn’t work in Okular main view and KMail message list. (To try without having a menu key: `sleep 10 && xdotool key Menu` and then focus the relevant widget by clicking it.) Cheers, David
Re: First round of feedback from Fedora 40 KDE Plasma 6 (Wayland-only) discussion
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?
Re: KDE Gear 24.02 bug fix releases and next Gear releases
On Monday, November 27, 2023 8:57:26 AM CET Heiko Becker wrote: > the question of the next Gear release (after 24.02) came up in #kde-devel > yesterday evening. [...] > > a) Continue with the usual dates, eg. 24.04 and 24.08. (or omitting 24.04 > and continue with 24.08 right away) > > b) Continue with the usual interval, so 24.06, 24.10 and so on > > c) Slightly change the interval to come back to the proven schedule with > its nice numbers divisible by 4, so something like, 24.05 and 24.08. Hi, As I remember, there wasn’t a more recent announcement than the below, and the linked wiki page does not discuss releases outside 24.02. So I assume that option a) from above is true. 23.08, 24.02, 24.04, then proceed as usual (every 4 months). But if something has changed since the below announcement, I would be happy to learn it, too. :) On Monday, 2023-09-04T05:50:45z David Edmundson wrote: > [...] > > - The KDE Gear release will move by 2 months to allow for the extra > time needed for testing initial Qt6 changes > > - An Alpha will be made in November (a soft freeze in Plasma terms) > > - Betas/RCs will be made throughout December and January (3 releases, > 3 weeks apart) > > - Final release of all 3 major parts in sync in February > > Due to the delay of KDE Gear by [2 months] an additional patch > release of 23.08 will be made. > > David Edmundson On Saturday, 2023-11-25T11:30:05z Albert Astals Cid wrote: > According to https://community.kde.org/Schedules/February_2024_MegaRelease > feature freeze is 29 November (i.e. next week). > > [...]
Re: KDE Gear 24.02 bug fix releases and next Gear releases
> On Monday, 2023-09-04T05:50:45z David Edmundson wrote: > > [...] The KDE Gear release will move by 2 months [...] I think now I get the confusion: Does this sentence refer to “KDE Gear 23.12” or to the general “KDE Gear release schedule”? I just assumed only 23.12 is delayed, because there was once a discussion about changing the schedule in general, and it was thought to be fine as it is.
Re: Unified internal communications channel
On Thursday, December 7, 2023 6:12:04 PM CET Joshua Goins wrote: > Hi Carl, > > > Adding a new channel that is either a mailing list, rss feed or a forum > > category won't help and will probably only makes it worse. It's also very > > difficult to defines that is an important internal news for the whole > > community is as it will be different for every subproject in KDE. The > > plasma logo discussion would have not been very relevant for any app > > developers. Similarly discussion about the new default database backend > > for > > Akonadi won't be interesting for Plasma developers but might be > > interesting > > for KMyMoney and other non-PIM apps using Akonadi. > > Yeah this is kind of tough to define, and I'm also wondering about the best > way to handle this. Ideally, the communication channel would be low traffic > (hence my suggestion to not allow discussions at all, and point people to a > relevant issue if they're interested) so people won't easily ignore it. I had the idea for such a channel before. But I admit that I did not search whether such a channel already exists. I would subscribe to a channel which is readable via email and has messages like these examples: * KDE Eco project launched. Interesting for developers concerned about ecological impact of KDE software and other software. More info [here]. * KDE community goals: The community goals for [date] to [date] shall be voted on until [date]. Goals can be submitted until [date]. Interesting for anyone seriously involved in the KDE community. More info [here]. * Akademy [year] event announced. This will be a hybrid meeting from [date] to [date], held online and in [place]. Interesting for people interested in KDE’s community and culture, and for those involved in several KDE projects. More info [here]. The four below examples are purely fictional, you did not miss them: * Akademy 2027 event cancelled. Because of urgent issues, Akademy 2027 can not take place. Important for anyone who planned to attend Akademy 2027. More info [here]. This is how an important discussion would be announced: * Discussion about KDE Eco CI jobs: Should energy measurement CI jobs become mandatory for all KDE applications? Interesting for developers and maintainers of KDE software and infrastructure. Join the discussion [here]. * Discussion about KDE Eco CI jobs: The discussion linked at [date] expanded to also cover mandatory energy measurement CI jobs for KDE websites. Interesting for KDE website maintainers. Join the discussion [here]. * Anouncement about KDE Eco CI jobs: Energy measurement CI jobs are now mandatory for most KDE Gear and Plasma projects. Result of the discussion linked at [date]. Interesting for developers and maintainers working on KDE Gear and Plasma. More info [here]. This would probably be a moderated mailing list. Anyone willing to announce something can send an announcement. Moderators only check that the announcement is self-contained, so that all readers can immediately judge the relevance for themselves. > That doesn't solve the scope issue though, but might help anyway. Based on what I have read on kde-devel and kde-community, that gives eligible announcements, the traffic may probably be low enough to ignore the scope issue. After all, you would probably subscribe to this channel to be well informed. I would exclude announcements that fit entirely in the scope of a project with an own communications channel. In my above examples, KDE Eco could not invite to the monthy meetings, and not to discussions about KDE Eco internal stuff of the mentioned CI jobs. Additionally I would put predictable announcements, like all regular releases and KDE Goals and Akademy, in a monthly digest. Cheers, David
Re: Post-MegaRelease projects
On Friday, February 23, 2024 11:12:16 AM CET Sune Vuorela wrote: > On 2024-02-22, Nate Graham wrote: > > 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. > > A bit more from the devops end that I'd love to see people tackle: > > - Ensure frameworks and app unit tests interacting with windows can run >on Windows. >More details: The following fails on our windows CI >https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp >I find it weird that we are spending resources on putting things in >the windows store and making apps available on windows, but we can't >actually have passing tests in our CI. > > - Find a way to run unit tests on android CI. > > - Make autotests guarding on all our CI's. > > - Clazy and clang-tidy and cppcheck on all our repositories in CI > > /Sune To motivate everyone who wants to get into KDE CI, I can report something helpful which I just found: At least since October 2023, there is extensive documentation on the CI system made for KDE projects. If you felt lost before, like me, it is now a good chance to try it again. https://community.kde.org/Infrastructure/Continuous_Integration_System README.md files have also been added to the ci-utilities repository. Thank you for writing this documentation! Cheers, David
Re: resvg
On Thursday, March 14, 2024 2:04:45 PM CET Sune Vuorela wrote: > On 2024-03-14, Igor Mironchik wrote: > > Hello, > > > > What do you think about https://github.com/RazrFalcon/resvg in case of > > processing and rendering SVGs? > > > > Do you have any plans to have this in Craft? > > With the current revitalization of QtSvg, I kind of think we should work > harder with that rather than try to replace it. > It is after all hooked in quite deep in our stuff already, so most of > our svg's needs to be compatible with QtSvg anyways. > > /Sune Well, QtSvg can only render (and create) SVGs, but there is no way to process an SVG document in a different way than to render it on a paint device. For me, this is a good reason to be interested in resvg.
