flathub now supports tag, but which id to use for KDE? (was: Re: Defining a developer name for our applications metadata)
Am Dienstag, 30. Januar 2024, 18:34:46 CET schrieb Timothée Ravier: > Hi folks, > > Flathub is now requiring that applications define a "developer_name" tag in > their metadata (see [1], [2]). > > What do folks think would be a good value for our application there? > > Based on the suggestion in the documentation [3], I started making PRs [4] > [5] [6] [7] for our KDE Apps with "The KDE Community" as the > "developer_name" tag. Seems meanwhile flathub maintainers have resolved that on their side, and now also support the non-deprecatd tag, by what I learned in MR https://invent.kde.org/utilities/okteta/-/merge_requests/22 The proposed patch there raises another question here though and some tasks: --- 8< --- KDE --- 8< --- Is "org.kde" (reverse-DNS) to be the official id, and is/could that be documented somewhere? accessibility-inspector currently uses even "https:// kde.org", while others use "kde.org" (non-reverse DNS). Given the purpose of the id is to be unique per group, this should be standardized, no? :) Confusingly enough one doc talks about "tld.domain" as pattern of the id (flathub), while the other talks about "gnome.org" as example (appstream): https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines/#name-summary-and-developer-name vs. https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-developer Tasks for people into this, please: a) decide on an id here b) document that id somewhere (e.g. https://develop.kde.org/docs/packaging/flatpak/ ?) c) ask upstream to change the docs to not use "The KDE Community" as example, but "KDE" (and with no-translate attribute) in the respective docs: https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-developer Cheers Friedrich
Post-MegaRelease projects
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
On 2/22/24 23:57, 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 * 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 Speaking for kwin, there are a few things that I would like us to complete or spend more time on - Fractional scaling - Output layers - Scene: port as much as possible stuff to the Item. It would be nice to add support for animating Items in order to start phasing out AnimationEffect. Also, as we discussed in #kwin, it's worth looking into splitting item and render node trees - Input: input grabs & redirection of input through the scene - Split kwin_wayland and kwin_x11 + further design cleanups and code shuffling - Explicit sync - Triple buffering - Proper output mirror and tiled output support - Try enabling color management by default The list is quite ambitious for 6.1 as it requires a lot of work.
[ANNOUNCE] CMake 3.29.0-rc2 is ready for testing
I am proud to announce the second CMake 3.29 release candidate.
https://cmake.org/download/
Documentation is available at:
https://cmake.org/cmake/help/v3.29
Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.29/release/3.29.html
Release milestone is available at:
https://gitlab.kitware.com/cmake/cmake/-/milestones/136
Some of the more significant changes in CMake 3.29 are:
* The LLVM/Clang GNU-like frontend on Windows ("clang++") may now be
used to compile "CUDA" language sources.
* TI Clang-based compilers are now supported with compiler id
"TIClang".
* The "cmake_language(EXIT)" sub-command was added to terminate "cmake
-P" scripts with a specified exit code.
* The "export(SETUP)" sub-command was added to configure export sets.
Its "PACKAGE_DEPENDENCY" option configures how "find_dependency()"
calls are exported. Its "TARGET" option's "XCFRAMEWORK_LOCATION"
setting specifies the location of a ".xcframework" that can be
substituted for an installed target.
* "install(EXPORT)" and "export(EXPORT)" learned a new
"EXPORT_PACKAGE_DEPENDENCIES" argument, which can be used to
generate "find_dependency()" calls based on what targets the
exported targets depend on.
* The "CMAKE_LINKER_TYPE" variable and corresponding "LINKER_TYPE"
target property were added to specify what linker to use with some
toolchains.
* A "CMAKE_TEST_LAUNCHER" variable and corresponding "TEST_LAUNCHER"
target property were added to specify a launcher to be used by
executable targets when invoked by tests added by the "add_test()"
command.
CMake 3.29 Release Notes
Changes made since CMake 3.28 include the following.
New Features
Command-Line
* "cmake(1)" "-E cat" can now print the standard input by passing the
"-" argument.
Generators
--
* Visual Studio Generators now support selecting between the Intel
oneAPI Fortran compiler ("ifx") and the Intel classic Fortran
compiler ("ifort") using a "fortran=" field in
"CMAKE_GENERATOR_TOOLSET".
File-Based API
--
* The "cmake-file-api(7)" "codemodel" version 2 "version" field has
been updated to 2.7.
* The "cmake-file-api(7)" "codemodel" version 2 "target" object gained
a new "launchers" field.
Compilers
-
* The LLVM/Clang GNU-like frontend on Windows ("clang++") may now be
used to compile "CUDA" language sources.
* Compilers targeting the GNU ABI on Windows (MinGW) may now be used
to compile Objective C ("OBJC") and Objective C++ ("OBJCXX"). These
include GNU compilers ("gcc" and "g++") and the LLVM/Clang GNU-like
frontends ("clang" and "clang++").
* TI Clang-based compilers are now supported with compiler id
"TIClang".
Commands
* The add_custom_command(TARGET) signature now supports adding build
events through Alias Targets.
* The "cmake_language(EXIT)" sub-command was added to terminate "cmake
-P" scripts with a specified exit code.
* The "export(SETUP)" sub-command was added to configure export sets.
Its "PACKAGE_DEPENDENCY" option configures how "find_dependency()"
calls are exported. Its "TARGET" option's "XCFRAMEWORK_LOCATION"
setting specifies the location of a ".xcframework" that can be
substituted for an installed target.
* The "if()" command gained new tests "IS_READABLE", "IS_WRITABLE" and
"IS_EXECUTABLE" to check file or directory permissions.
* "install(EXPORT)" and "export(EXPORT)" learned a new
"EXPORT_PACKAGE_DEPENDENCIES" argument, which can be used to
generate "find_dependency()" calls based on what targets the
exported targets depend on.
Variables
-
* The "CMAKE_INSTALL_PREFIX" environment variable was added to provide
a default value for the "CMAKE_INSTALL_PREFIX" variable.
* The "CMAKE_LINKER_TYPE" variable and corresponding "LINKER_TYPE"
target property were added to specify what linker to use with some
toolchains.
* The "CMAKE__COMPILER_LINKER",
"CMAKE__COMPILER_LINKER_ID",
"CMAKE__COMPILER_LINKER_VERSION" and
"CMAKE__COMPILER_LINKER_FRONTEND_VARIANT" variables were added
to describe the linker used by the language's link step.
* The "CMAKE_PROJECT_INCLUDE", "CMAKE_PROJECT_INCLUDE_BEFORE",
"CMAKE_PROJECT__INCLUDE", and "CMAKE_PROJECT__INCLUDE_BEFORE" variables learned to support a semicolon-
separated list of CMake language files to be included sequentially.
These variables can also reference module names to be found in
"CMAKE_MODULE_PATH" or builtin to CMake.
* The "CMAKE_SKIP_TEST_ALL_DEPENDENCY" variable was added to control
whether the "test" (or "RUN_TESTS") buildsystem target depends on
the "all" (or "ALL_BUILD") target.
* A "CMAKE_TEST_LAUNCHER" variable and corresponding "TEST_LAUNCHER"
target property were added to specify a launcher to be used by
executable targets when invoked by tests added by the "add_test()"
command.
Properties
--
* The "CROSSCOMPILING_EMULATOR"
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: Post-MegaRelease projects
> Another thing I'd like to explore is to have some universal way to > programmatically change KDE settings. [...] Perhaps we can gather all KConfig > files into a CLI tool that has _some_ documentation and can do the config > file editing / reconfigure. This would be incredibly useful for making a KDE environment portable. Maybe one mega-sized TOML or YAML file that records all changes from defaults? It could certainly start simple...
Re: Post-MegaRelease projects
On 23/2/24 08:27, 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 * Unified theming infrastructure for KDE apps, GTK apps, and Plasma. ** Relatedly: QML/JS in themes is dangerous; move away from it Agreed, this will make themes uploaded the KDE Store less likely to contain malicious code * Start adding release notes to our apps' AppStream metadata [2] Regarding this we could add (or improve any existing) linting job to include appdata checks. * 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 Please feel free to CC/invite me on anything related to the store as I manage the servers and have direct contact with the Web team that manages the software. I am always looking for new ways to remove spam, keep the platform secure and any ways to make sure the content is well curated. * Our virtual keyboard situation is not great and needs focused work On this I think it might be worth looking into working with Dobey who works on Maliit. It's used by the Plasma Mobile stack and I think Dobey is the only major contributor to it. It could either be brought under the KDE umbrella or forked to be a KDE specific OSK * 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
Notifications could use some enhancements, like grouping by sending application. Yifan [0]: https://bugs.kde.org/show_bug.cgi?id=440837 [1]: https://bugs.kde.org/show_bug.cgi?id=441906
