While the summary + interview The Register did was decent, when you read the actual paper, the proposal is way more interesting.

Not a fan of mut instead of just plain mutable, though.

Also I sure hope the compiler messages for this feature won't be like the circle examples in the proposal in the end.

A small correction:

For example, there are Kirigami bindings for Python you can use to do a desktop/mobile app.

Kirigami is QML all the way, it doesn't need bindings since you'd be writing in QML either way. The Python part is about the actual business logic. :)

I'd be curious to see a blog post in the future mentioning the challenges you might have faced making the dock work on Wayland, and what was needed for that.

When you search using the Starred filter, usually you get the main project at the top since that's the one with the most stars.

I added a KRunner web shortcut for this that automatically searches using that filter: https://rabbitictranslator.com/kfluff-web-shortcuts/

Looks like an old bug with kscreen that could cause two screens to merge together and would be worked around exactly the same way you did. I used to have that whenever a blackout happened, but only with Plasma 5, and often on X11.

What's used under the hood for this is udisks, the same thing used by other file managers to achieve mounting capabilities. It allows you to mount devices without needing to mess with something cryptic and archaic like fstab and doesn't require root.

You can always keep using fstab of course since it works, but in that case you probably also want to use fstab systemd integration.

The KDE auto mount never worked on plasma 6

Please report your issues on https://bugs.kde.org so they can actually get fixed!

My understanding of Linux programming is that it’s mostly done in a code editor, then compiled on the command line.

That's not really true. You can do that, but with most IDEs (and some text editors) you really don't need to do that. You can do everything from the IDE.

I’m aware that cmake exists, and I’ve used it a bit, but I don’t like it. VS lets me just drop a .h and .cpp file into the solution explorer and I’m good-to-go. Is there really no graphical alternative for Linux?

It depends on the IDE and how it handles project files. Nowadays Qt Creator for example can just create your source code files and automatically add them to the generated project CMake. I'm pretty sure other IDEs or text editors have this functionality when paired with CMake or Meson too.

It must be noted that if the IDE has some custom project file manager (like Visual Studio does with sln and vcproj files) and you use it exclusively, you'll likely restrict your project to one platform and one IDE. Using something like CMake or Meson will make it easier to do crossplatform development and will let your users build the project without needing that specific IDE.

Personally I like modern CMake, the problem is that you'll see a lot of projects in the wild doing old CMake style, which is awful. Meson is okay, although it feels very Pythonic to me and lacks some features I use for Qt stuff.

Everything. It doesn't accurately describe the issue (animation stutter when using an HDD or during heavy I/O) and it doesn't mention the solution (put the cache folder in tmpfs), plus it obviously follows the traditional sensationalist tone used in clickbait.

The point is to be deliberately vague to bait people into watching it.

It's small enough that we actually don't get many things to moderate either. I don't think I've even done any mod action so far. :D

I remember once researching when to use variant and any, and coming up with https://stackoverflow.com/questions/56303939/c-stdvariant-vs-stdany. The naïve summary being:

any is a dressed-up void*. variant is a dressed-up union.

So you'd use std::any for similar reasons to void* (that other commenters already mentioned) while getting some advantages. In that sense it's kinda similar to using a std::span for pointer arithmetic instead of actual C-style pointer arithmetic, it makes a necessary evil safer to do.

can I write modern C++ code using the newer standards and still compile with libraries from older standards?

Yes, but then your project ends up requiring that newer standard as minimum too (which can be fine if that's what you want).

how do I even organize a C++ project?

Well, one way that should be simple and scalable for beginners is leaving the root folder for project configuration/metadata/contribution guidelines/clang-format etc. and putting all source code inside src/.

If it's just an app, you can make smaller library targets in src/ in separate folders with meaningful names, like src/models/, src/settings/ etc. If it's a library, you typically put headers you intend to expose to your users in a src/include/ folder and use target_include_directories() to point to it, otherwise the same principle as apps applies.

It requires writing a few more, smaller CMakeLists, but it does mean you're never lost in your own code.

how do I install dependencies?

We added this recently to KDE's developer documentation, so at least for Linux it's a start: Installing build dependencies: Using build errors to find missing dependencies.

We're always open to doc contributions. Interested in any particular areas? 🐰

What’s the best or recommended way to test out Plasma 6 RC2?

See also: https://community.kde.org/Plasma/Plasma_6#How_to_use/test_it

without the need of the moc

I got a bit of a mind freeze reading that sentence since my first thought was "why would someone deliberately give up on Qt's reflection system" but only then realized they're still using QMetaObject (the thing that actually enables reflection and signals and slots), just building it with something else.

Also, you should only use Layout attached properties when the object you're using it on is a child of a Layout, for example:

ApplicationWindow {
    ColumnLayout {
        anchors.fill: parent // Not a child of a layout, so you use anchors
        Controls.Button {
            Layout.fillWidth: true // It's a child of a layout, so you use Layout.fillWidth
        }
    }
}

So what you want to do is put a Kirigami.SearchField inside the global toolbar created by the Kirigami.Page. It's not a header.

In the first case you're putting it inside the page, and because it's a direct child of a Kirigami.Page, it is automatically laid out for you, which is fine, but not what you want.

In the second case you're putting it in the header of the ApplicationWindow, but you actually want to put in the global toolbar of the page, so it's not what you want.

In the third case you're just putting a SearchField before the initialPage, so it's loaded on the same level as the page, it's not what you want.

You can put it in the header property of the Kirigami.Page, but the header area of the page doesn't include the global toolbar, so they just happen to be close together by chance.

The way I'd have expected to do that would be to override the globalToolBarItem of the Kirigami.Page, but it's read only, so I don't really know how to help you with that. You should ask in the Kirigami Matrix room or in the Discuss forum.

I can't tell you why this is happening, but what is clearly happening is that your apps are being run under a nested kwin_wayland instance. It's as though you were running kwin_wayland krunner.

If anyone’s wondering, my main issue with Wayland was that it wasn’t setting the DISPLAY and WAYLAND_DISPLAY environment variables for some reason, and this would cause all kinds of software like Steam and Firefox to not even launch. I tried setting them manually but that didn’t go do well either.

My guess is that whatever fix you attempted here caused this, so you'd need to be more specific about what you tried.

I was thinking, with the recent news of a contributor to GitLab adding support for forge federation, some time we could see that being enabled in the KDE instance as well, I hope.

It would be cool indeed. It would mean that people on KDE Invent could make issues and MRs directly to the Freedesktop Gitlab, for example, if both were federated.

If, instead, you won’t do it and prefer to keep Bugzilla as the main issue tracking platform, could you tell us why?

Here are the reasons why: https://community.kde.org/Get_Involved/Issue_Reporting/Why_not_GitLab_Issues

The tldr is that Gitlab Issues is limited for users, developers and triagers compared to current Bugzilla, given the current KDE infrastructure. These are just technical issues. The moment Gitlab solves those limitations, KDE would gladly use it.

[...] since they’re right there by the code base.

Note the section "Bugs need to be filed against individual repos". At it stands right now, if a non-technical user finds a plasmashell bug, they can just go to "File a bug":

and they're greeted with this:

And then they can choose Plasma and then plasmashell, both with very descriptive text mentioning what should be reported there. It's not too bad to find the right place to report things, to be honest. And there's an "I don't know" field, which is great. :)

Finding issues can be a bit finnicky, yeah. But you can click on the search field in the first page, type what you want to find, click on Quick Search and you get a list of results based on your keywords, and you can also click on the Search button and then click on Simple Search to look for some keyword in a specific product. Once you know it's pretty simple.

Maybe keep the Overview text and icon color as white for better contrast. The blue background color already conveys selection I think.

Oh, my instance does not show this post like this at all. I wonder if it's some difference in Lemmy versions too.

I think so. I mean, the migration code would still be there afterwards, maybe removed after several versions later.

If the user syncs machines with different application versions I'm not sure there's anything that can be done at the code level though. 👀

I answered something similar elsewhere:

If you mean migrating the files yourself, it's just a matter of copying the file from the old place ~/.config/yourconfigrc to ~/.config/yourapp/yourconfigrc.

If you mean you want the application to manage the migration itself, that's an implementation detail I hadn't thought about yet, but which I assume wouldn't be difficult to do with KConfig.

You can see this bit of code from Konsole showing how to migrate from old entries to new entries in the same config file for example: >https://invent.kde.org/utilities/konsole/-/blob/master/src/main.cpp#L99

The implementation could probably be something similar, with two KConfig/KSharedConfigPtr instances I assume 👀 so:

• if oldConfig exists, create an object for it
• read all oldConfig entries
• if it differs from newConfig, store which ones differ
• write all different oldConfig entries in newConfig object
• sync()

Something like that.

I'm curious. M/M furry games are lovely, but what sort do you want to make?

Can't say I liked it tbh 🤔

Button icons and positioning were generally more sensible though. That made a huge difference.

Searches occasionally render the error "couldnt_find_object" here for me. I can't quite tell if this only started happening after the update or not since I'm quite new here.

For whoever is curious but didn't get to see the post: