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: 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?
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: 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: 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: 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 >
