KDE

That's correct!

We don't have a spy that's for sure!

In fact there are already quite a few Wayland-only features. You can read about them on https://community.kde.org/Plasma/X11_Known_Significant_Issues.

Something that's often not mentioned is that C++ with Qt is often a very different beast to use compared to C++ with the stdlib and other GUI frameworks. IMO Qt takes a lot of the pain out of C++, such that the criticism becomes blunted and mostly articulated by people looking in from outside who haven't tried it yet.

Some of the plasmoids are implemented in JavaScript I think, but personally I'd love to see Dart as a consideration for that "high level language" choice.

It already does a great job at gluing high level rendering abstractions with low level rendering libraries within the Flutter SDK, and supports a lot of useful paradigms in UI development such as first class functions, null safety, enhanced enumerators, etc.

I can see why it's given a wide berth from FOSS since it's associated with JavaScript AND Google (two controversial terms in programming to say the least...) but working with it daily really does remind me how well it lends itself to frontend development.

I have some very, very, very, very WIP KDE widgets for Dart/Flutter in a project running. Currently it has almost nothing but it already automatically switches color theme when you switch color schemes in KDE for example 😄

Don't expect too much of that though, it's very unofficial and something I'm doing whenever I feel like it.

Neon unstable/testing already contains the relevant branches. Neon user edition should receive it as normal when it releases. When Neon will update its Ubuntnu base is a question for Neon developers.

Is there a dedicated page tracking updates specifically to KDE Connect?

It is part of KDE Gear, so generally in the gear release announcement. The last few releases were not that big in term of feature but the next one includes some goodies.

Does Connect use BTLE?

KDE Connect will have the Bluetooth backend enabled by default with the next gear release (24.02). I'm not sure if this is BTLE or normal Bluetooth.

Could you guys implement an auto tethering option between phone/PC?

No idea :(

How instant are notifications synced?

For me it is pretty instant. I never miss my Bereal notifications thanks to it :)

Do notifications disappear on one side or the other when viewed on one or the other platform?

Yes

Maybe implement a “link to KDE” notification toggle to mirror the “link to windows” functionality of Android?

No idea :(

just had dinner, therefore, great :D

Relaxed at the moment :)

@kellyaster @Bro666 Pretty hungry but I'm cooking a ratatouille right now to fix this issue :)

Feeling just fine. :)

to me, the new kwin tiling that first appeared on 5.27, but this will probably change, as feature development on it is about to reopen :)

It has not been developed in the last few years but always krunner! A recent-ish feature that was already in Plasma 5 is to bind key presses to your extra mouse buttons or tablet tool buttons

Plasma Vaults! It's the best implementation of having a little encrypted bucket to put your important files in that I've ever used, on any platform. It's very well integrated into Plasma as a 1st-party supported feature, and it works wonderfully.

To just test out without any risk and not touching any running system i would suggest a live image such as KDE Neon Unstable which has dailiy updated snapshots of our software stack

as moving to Qt6 from a developer POV, It has been remarkably uneventful. there are api changes for sure (Especially on the QML side of things) but the changes are not as great as say, Qt4 to Qt5.

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

Neon Testing in a VM (or on bare metal if you're adventurous). Arch with the kde-unstable repo is good too, but that also includes a snapshot of the unreleased Qt 6.7 which introduces more bugs.

What has been the hardest problem to solve moving to Qt6?

Personally I'd have to say the large number of API and behavior changes in QtQuick that Qt 6 has brought. We use QtQuick very heavily throughout KDE, so this has required a lot of mandatory porting work, more than in our QtWidgets-based software. And there have even been changes between Qt 6.5, 6.6, and 6.7, so it's still a bit of a moving target

In addition to the obvious answer of "because our software is really good!", IMO an under-appreciated reason is that KDE really is an anarchic and largely volunteer-run community. As long as there are passionate volunteers, there will be KDE; you don't have to worry about it just dying one day should some big corporation pull the plug for some reason. We ave all become so accustomed these days to software being disposable, but KDE really does give you a measure of longevity and continuity that you're unlikely to get elsewhere, especially without paying a lot of money for it.

I think everyone has different preferences on how they use their machine. However I would invite to just try Plasma out. One thing where it stands out is in my opinion that you can tailor it to your wishes and use case.

One of the most visible ones for me is that most common multimonitor workflows Just Work™ in the Wayland session now. There are still edge cases, but we've put a huge amount of effort into this.

It may be not user visible and technically not a Plasma but Qt change but I find the work so that apps survive the compositor restarting amazing. See http://blog.davidedmundson.co.uk/blog/qt6_wayland_robustness/

For me personally, it's the updated breeze theme. But I might not be completely objective here, since I drove this effort quite a lot :)

Some screenshots to see the difference: https://invent.kde.org/websites/product-screenshots/-/merge_requests/51

Actually Plasma is generally more popular than GNOME every time surveys are conducted. However we have to keep in mind that the direct consumers of a DE is actually not the end users, but rather the distributors who package and distribute it. There are a number of historical reasons why distributors ended up picking GNOME over Plasma including accessibility, corporate sponsorship, and an easier packaging experience. So what you end up with is the vendors shipping GNOME despite pent-up desire for Plasma.

And I think that pent-up desire is being unleashed these days due to various changes in our ecosystem. You see an increasing number of hardware vendors who have a strong financial incentive to listen to their customers picking Plasma over GNOME. In addition, KDE's accessibility game is ramping up hugely, and we have more robust corporate sponsorship than we used to with Valve and Blue Systems putting tons of resources into KDE. Finally, GNOME seems to be becoming more hostile to their downstreams, causing them to need to do more of their own development or else migrate to be a fork or skin of Plasma. Interesting developments.

We do aim to improve our design and usability further as much as possible, however, one of the nice things of free software is really this big choice. There are different projects and one size never fits all, if some people find the software written by our friends over GNOME more suited with their needs, that's totally fine.

It would also be interesting hearing on the motivations for this choice tough, as it always help us improving

We sure do plan of moving more and more of our app to the new convergent ui toolkit made with QML and Kirigami, in the future more and more of our apps should become mobile ready

In addition to that Josh said, we have a list of mobile friendly first party applications here: https://plasma-mobile.org/ It's not completely up to date and is missing some newer additions.

Josh says: "Yes, we are always interested in making our applications mobile-ready and almost every new KDE application uses Kirigami our convergent framework. Some of our older applications such as Okular, Dolphin, etc need more work on mobile but this is something that's being worked on."