Re: Post-MegaRelease projects
I think telemetry could help in a lot of discussions around UI/UX. Questions: 1. In which project should we create an issue about telemetry? 2. Where can I see current telemetry data? 3. How many users enabled telemetry, at what level? Concerns: 4. Storing more data might raise concerns among users. 5. Storing more data is more privacy-sensitive, so it might require more effort on server side or legal things. Nate Graham 于2024年2月23日周五 05:57写道： > 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 > * Unified theming infrastructure for KDE apps, GTK apps, and Plasma. > ** Relatedly: QML/JS in themes is dangerous; move away from it > * 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 > * Telemetry system has not proved to be very useful and needs an overhaul > * store.kde.org is full of low-quality or broken content; make a push > for KDE people to take ownership of content moderation, QA, etc. Also > any relevant and needed tech improvements > * Our virtual keyboard situation is not great and needs focused work > * KWallet needs an overhaul > * Have KWin (optionally) remember window positions on Wayland > * Build a "System misconfiguration detection hub" app [3] > > Feel free to discuss, and propose your own! > > Nate > > > > [1] > > https://blog.davidedmundson.co.uk/blog/new-ideas-using-wayland-input-methods/ > [2] https://github.com/ximion/appstream/issues/354 > [3] https://invent.kde.org/plasma/plasma-workspace/-/issues/64 >
Re: Post-MegaRelease projects
Another thing I'd like to explore is to have some universal way to programmatically change KDE settings. Currently, I either change settings in KCMs, or manually edit a config file then make a dbus "reconfigure" call. But the latter is mostly undocumented. Perhaps we can gather all KConfig files into a CLI tool that has _some_ documentation and can do the config file editing / reconfigure. Scenarios I'm targeting with this: 1. A "quick setting" widget that allows the user to toggle some setting directly on the panel, even if it's hidden deeply in systemsettings. 2. A "ChatGPT" or "Windows Copilot" like app that allows the user to toggle settings via natural language, typed or speech. The major difficulties I see: some combination of settings might be invalid, and the logic to prevent invalid combos might be in the KCM code. So this tool has the risk of breaking KDE softwares.
Re: resvg
Any example of "process an SVG document in a different way than to render it"? Laura David Hurka 于2024年3月15日周五 05:57写道： > > 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. > > > >
Re: Should we stop distributing source tarballs?
The tree-id of a git commit is effectively a checksum of all files. So you can ask packagers to pull a specific commit and verify either commit-id or tree-id. No extra verification step needed. Sune Vuorela 于 2024年4月4日周四 17:48写道： > On 2024-04-03, Albert Vaca Cintora wrote: > > What's the advantage of providing tarballs? > > I do think there is an advantage in being able to verify that the soure > tarball is the same across distributions. Using a checksum on the > tarball is an easy way of doing it. Different git invocations for git > archive, different tar options and so on can create different checksums > for the same content. > > I do also think it is nice if we get someone else to verify that the > tarball we ship actually matches the tag. I think some people in > distributions have already started looking into verifying that. > > Also, git tags can be moved. > > /Sune > >
Re: Should we stop distributing source tarballs?
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.
Re: Should we stop distributing source tarballs?
Neal Gompa 于 2024年4月4日周四 22:19写道： > > That's fair, but they are not permanent and can be reaped when they're > not referenced by anything anymore. > If you pull these release commits in a "download" server and restrict write access to it, not giving everyone permission to delete a tag, just like what you do with the tarball download server, then it's the same. >
Re: Advice request on how to handle change in how Konqueror stores login information
One more option: Keep the old load code as a fallback to the new load code. You can drop the old save code, but the old load code probably has to be kept forever. -Jin Stefano Crocco 于2024年9月21日周六 14:39写道： > > Hello to everyone, > I'd need an advice on how to proceed with a change I'm going to make in > Konqueror which could lead to data loss for the users. To improve the way > Konqueror auto-fills login information in web pages, I had to change (in a way > which depends on the page content) the name of the entries it uses to store > login information in KWallet. As a consequence, existing entries won't be > recognized anymore and users will have to enter them again the first time they > visit a page so that entries with the new names can be created. > > In theory, this shouldn't be more than an annoyance for users, but I'm > worried that there could be people who only relied on Konqueror to fill > passwords and didn't record them somewhere else: in this case, they couldn't > easily access their passwords anymore. > > I've thought of three possible ways to proceed: > - ignore the issue. This is, obviously, the easiest choice but also the most > user-unfriendly > - display a KMessageWidget with information on how to recover the login > information from KWallet when the user tries accesses a page with login > information stored in the old way > - automatically rename entries when the user accesses a web page with stored > login information. This is the more user-friendly approach, but also the more > complex to code; besides I fear that there's no way to determine which form on > a given page corresponds to the data in the wallet which is correct in every > situation > - display a warning the first time the new Konqueror version is launched > describing the situation and how to manually retrieve login information from > KWallet. This could be a decent compromise between user-friendliness and ease > to code, but I'm not sure what is the best way do display the warning: would a > simple message box be suitable? > > What do you think would be the best way to proceed? > > Thanks in advance. > > Stefano > >
Re: Disallow or discourage use of "AI" tools
Akseli 于2025年5月12日周一 20:53写道： > We should take a more public stance on disallowing all this slop. Lengthy > gitlab issues that are just full of nonsense generated by a bot just take > time out of everyones schedules, trying to decipher if its serious or not. I assume this doesn't include auto-completions done by Github Copilot? Because currently I guess it types ~70% of code and commit messages for me. And I would only accept when it types exactly what's in my mind. So I don't see if that's any different from "traditional" auto-completion in IDE and Chinese IME. -jin
Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)
Nate Graham 于2025年5月17日周六 00:50写道： > This is a complex topic that could go on for ages. If this is a complex (social / political) topic, (and from the length of this discussion, it obviously is), then "not taking a (firm / aggressive) stance" is just what I feel KDE might do in contrast to some "younger" / more "social activist" software projects (according to my short involvement in KDE). I'm fine with the "not obviously AI" rule Nate linked. That's basically "not obviously sub-human level". So if the recent trend is making low-quality contributions with AI, then yeah we can say we don't like that because it's wasting everyone's time. -Jin Liu
Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)
Justin Zobel 于2025年5月18日周日 15:03写道： > I would even be for adding a checkbox in the Merge Request template requiring > users to declare that no AI was used in this contribution. The same can go in > the Bugzilla tickets. > > Justin Well, I hereby declare that AI (Github Copilot specifically) was definitely used in most of my contributions, and I don't mind KDE e.V. removing all of my commits. -Jin Liu
Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)
Justin Zobel 于2025年5月19日周一 08:34写道： > From my understanding (what others have told me), AI generally does not > produce good quality code though. So how is that a benefit to society? >From my personal experience (what I, not others, have personally used Github Copilot for months), AI makes coding a lot more enjoyable. When I type an if branch, it completes the else branch. When I type the first half of a lengthy function call, it completes the rest. My brain spends a lot less time waiting for my fingers. So I'm pretty sure it's a benefit to me personally. Is that a benefit to society? I dunno. And if KDE implements a ban on AI that excludes my usage, then it would make contributing to KDE a lot less enjoyable for me, and I'm pretty sure I'd no longer contribute to KDE and divert my time to other projects without the ban. Is that a benefit to society? I dunno. -Jin Liu
Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)
Justin Zobel 于2025年5月19日周一 13:52写道： > I understand that it makes everything easier. That doesn't matter in the > slightest when you cannot verify the original license of the code allows you > to use said code or that the license is compatible with KDE. I don't think a few (<10) lines of code are licensable. > It's clear a lot of people don't care about theft or the environment and are > happy to use AI without thinking about the true impact. Insult taken. Is that KDE's official stance that because I use AI in coding, so "I don't care about theft or the environment", or just your personal attack on fellow KDE developers? -Jin Liu
Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)
Martin Steigerwald 于2025年5月19日周一 14:56写道： > Everyone: I suggest to assume good intentions. My suggestion is to avoid making assessments on "people", and focus on code or legal or other aspects. - Jin Liu
Re: Disallow or discourage use of "AI" tools (Christoph Cullmann)
Akseli Lahtinen 于2025年5月19日周一 16:14写道： > My original point is to try to get rid of the low-hanging fruit, as in > people who spam bug reports with obviously "AI" generated things. I'm basically with you. That's why I began my first reply with "I assume this doesn't include...", i.e. just a casual confirmation. And I do think "obviously AI" quite cleverly captured the essence. However, in this thread it's quite obvious that we don't have consensus among devs on this matter, and some would like a total ban of AI usage in KDE. So I feel we do need an explicit clarification if KDE will implement such a ban or not. (BTW, luckily we use English here. As I'm a native Chinese speaker, and Chinese input methods have been using Language Model for prediction in the past three decades. The only difference from today's "Large" Language Model is accuracy. So every Chinese sentence I type is "by AI" in the very broad sense that some in this thread seems to be using.) Anyway, I do hope we bring fewer complex and controversial social topics and judgment on people (even if in the general sense, not targeting anyone), to this thread and this mailing list. (I'm perfectly fine with your original mail.) - Jin Liu
Re: Performance improvement
Igor Mironchik 于2025年5月23日周五 00:21写道： > > Hi. > > I'd like to ask you, guys, maybe I'm a dumb a little, and you know how > to optimize a following function. > > inline long long int > skipIf(long long int startPos, const QString &line, > const std::function &pred, > long long int endPos = -1) Since you have a very simple inner loop, changing `pred` from `std::function` (essentially a function pointer) to a template parameter might help a bit with inlining if `pred` is simple.
