Hacker News new | past | comments | ask | show | jobs | submit login
KDE Plasma development switches to Qt 6 tomorrow (kde.org)
181 points by LorenDB on Feb 27, 2023 | hide | past | favorite | 72 comments



Anyone know how we can provide features and sponsor them for KDE 6.

I've wanted to pin virtual desktops to a specific monitor (same as i3) and be able to independently switch virtual desktops on each monitor.

Its a widely requested feature which hasn't landed, I was hoping to get this on their radar and if necessary pay for this feature. Its something that's been bothering me since KDE 3 days.


I suppose you could mail one of the KDE mailing lists[0] to ask about this. Probably you want either kde or kde-devel.

[0]: https://kde.org/support/mailinglists/


The one thing holding me back from switching to KDE in full. The hacks and Kwin scripts just simply aren’t enough.

If you find out more on this (solutions or ticket to sponsor) please update!


Have you tried to directly run i3 instead of KWin? https://github.com/avivace/dotfiles


Thanks for the link! I had found a few pieces of the repo's Readme but this looks solid, I'll have to give it a try.


If you're on X, there's no reason why you shouldn't just use i3 on the top of Plasma. https://github.com/avivace/dotfiles


Take a look at TDE/Trinity.

I do not know if it does as you wish, but it is a fork of kde2, with enhancements, and they are actually open to actual, usable, needed change.


Are you implying that the KDE devs are not "open to actual, usable, needed change"? That seems disingenuous given the multitude of actual, useable, needed changes they make.


Trinity exists due to unusable, unneeded change that is kde4 and beyond.

So no, they are not open to that path.


Have you even tried recent Plasma versions? Granted, the early KDE4 releases were a train wreck. But there is no reason to have the KDE image tainted by that anymore. Today, it is about as good as KDE3 was.


Until, bound by the same broken reasoning, and senseless logic and push for change, they do it all over again?

For no real beneficial reason?



Right, I misspoke.


Hats off to the KDE team for a really great release cycle. I understand that there were some licensing issues with Qt in the back half, but Plasma 5.27 really pushed the Wayland session into excellence. It's unclear what Plasma 6 is going to look like, but they've got a damn fine launchpad with the current KWin Wayland session.


I thought that Plasma 6 will look exactly like Plasma 5, the only change being the Qt version they depend on.


For the short term. Longer term they will make improving things and following whatever the next fad is - just like everyone else.


Probably, I don't anticipate many changes from what they've got right now.


I personally hope that one of the first new UI changes to land in Plasma 6 is support for rounded window corners in all corners, not just the titlebar ;)


You only seem half-serious, so I suspect there's something I've missed about KDE corner history.

Anyway, 'picom' can at least grind down those edges (or smooth out, depending on your point of view)

    #################################
    #           Corners             #
    #################################
    # Sets the radius of rounded window corners. When > 0, the compositor will
    # round the corners of windows. Does not interact well with
    # `transparent-clipping`.
    corner-radius = 5

    # Exclude conditions for rounded corners.
    rounded-corners-exclude = [
        "window_type = 'desktop'",
        "window_type = 'dock'",
    ]


There's an infamous very, very long dev discussion thread on the quo vadis of bottom corner trimming (with working patches) :-)


Thanks for much hoped for context )


I am mostly serious. I mean, it's not a huge deal, but it would look awesome :)

I guess maybe I could look into picom. There was also a third party kwin plugin that could do the same thing IIRC.


The picom version is kinda brute, basically crop corners right off.

Maybe a KWin plugin would do it more elegantly - but I guess such a plugin would also have an upper limit to radius... ;]


5.27 is the first KDE release in a while that has actually broken things for me. Fedora recently updated to it and the breeze theme broke, causing me constant crashes and glitchy window decorations.


Whenever I hear about completely broken KDE installs, it's Fedora in 90% of cases.


Yeah. In my case, the Discover app didn't fully update all of the packages like it was supposed to. Easy enough of a fix, though I doubt an average PC user would have been able to figure that out.


Discover really has never worked all that well for me when it comes to updating packages. I have used the terminal to install updates for a long time now, with both Ubuntu and openSUSE.


That's probably good practice, though I feel that the updater which pops up in your tray to let you know updates are ready should "just work".


I have a feeling PackageKit is to blame here, since I remember Gnome Software being just as bad.


Do not use GUI package managers except YaST. They are all terrible.


Is this the Qt version that drops the custom metaprogramming stuff for QObject and friends and adopts modern C++ in its place? If so, it's a very cool development! :)


Nope, Qt 6 still uses moc. I don't think modern C++ metaprogramming is quite capable of entirely replacing moc. The closest thing I'm aware of is [0], but it requires additional macros compared to what moc requires, and compilation speed can suffer. Chances are moc won't be dropped until full reflection lands, if ever, and even then if compilation speed is too bad I wouldn't be entirely surprised if moc remains.

[0]: https://github.com/woboq/verdigris


yep, a big part of moc is about generating reflection info and current C++ metaprogramming very simply does not cover reflection and even less custom code generation (think generating a function called "auto foo_info()" from a function "void foo()" automatically - right now the only way to do this if one does not want to use macros is through an external code generator, e.g. in CMake or whatever).


Apart from just not having all the widgets, why do you think CopperSpice falls short? Getting rid of the moc was pretty much the first thing they accomplished.


It is possible to get rid of moc by manually writing out the equivalent code (using macros or not) or gutting out features that require it. Qt uses it to do things that would otherwise not be possible, like expose QObjects to scripting languages. That requires reflection that modern C++ doesn't support and thus needs either redundancy of some kind (to generate the necessary metadata to do 'reflection') or code generation (to generate the necessary metadata to do 'reflection').

MOC was never simply superfluous.


> Getting rid of the moc was pretty much the first thing they accomplished.

but it's not a proper replacement.

With Qt's moc you just annotate the class:

    class Foo {
      Q_OBJECT
      Q_SIGNAL void f(int a, int b);
      Q_INVOKABLE void g(int c, int d);
    };

with CopperSpice (and verdigris, and anything else that does not use an external code generator) you have to repeat all the names and use much more macros:

    class Foo {
      CS_OBJECT(Foo)
      CS_SIGNAL_1(Public, void f(int a, int b));
      CS_SIGNAL_2(f, a, b);

      CS_INVOKABLE_METHOD_1(Public, void g(int c, int d));
      CS_INVOKABLE_METHOD_2(g, c, d);
    };


jcelerier and jchw basically said what I was going to say. All I have to add is that getting rid of moc in and of itself is not the end goal here; it's getting rid of moc without needing to change anything else. Until then, moc is providing something that C++ itself cannot.



Never quite sure why people are so fixated on moc. It's by no means the most annoying thing about Qt and it works well in practice. The signals/slots mechanism is one of the best things about Qt.


So like a decade ago I hated using MOC because it would mess up auto-formatters and source code parsing in all editors, but since clangd/clang-format and its LSP friends, working in Qt and having stuff like the autoformatter work perfectly has since alleviated any problems I have with using the MOC.

Now they're just equally as annoying as any other macros are, which is to say, a lot less annoying than it used to be.


I think it would be interesting from a C++ perspective. That was my point. Qt is awesome as is.


Is this the Qt version that enables custom date formatting? So that one might be able to configure, e.g. YYYY-MM-DD date format, week starts on Sunday, H:i:s time 24 hour time with leading 0, and with the period (dot) decimal separator?


Does Autodesk still only use the LGPL licensed Qt to avoid paying a single cent to The Qt Company?

I think it's weird that big megacorps don't actively support the very foundation their software is built upon.


Someone has to sign the cheque. That number is going to come off of their results. The tragedy of the commons happens within companies as well.


I celebrate these news with a bit of unease. I've heard a lot of criticism regarding Qt 6 licensing policy. And personally I'd rather prefer more stability.


The licensing policy in Qt 6 isn't really changed vs. 5 -- the change that upset the community was the commercial-only LTS releases, which started with 5.15.

KDE has been maintaining Qt 5.15 by itself with the "KDE Qt Patch Collection" since then, as the 5.15.y bugfix releases are commercial-only for a year before they get released as open source.

In Qt 6 the situation is theoretically better as you get a new 6.x feature release faster than that one-year wait period, whereas 5.15 was the end of the line for Qt 5. The commercial-only also only happens after the first two bugfix releases, so there should be no significant waiting periods without releases. If the general quality of Qt releases is sufficiently high, the Patch Collection effort may no longer be needed.

That said, The Qt Company remains a topic of concern, publishing (also on LinkedIn by employees, with lame/thin "does not necessarily represent my employer's opinion" disclaimers) lots of "why open source software is scary" content lately, apparently unaware that the only reason anyone cares about their product is its open source pedigree and credibility: https://www.qt.io/blog/is-open-source-really-free

This is probably a reaction to competition by the BSD-licensed Flutter which has seen a lot of interest from their traditional commercial audience. Doubling down on "we're less open source" as a differentiator vs. _Google_ of all companies is quite a mind-bender. Also considering licensing/open source is why Flutter is getting that attention in the first place, and that Qt could tell a fantastic story here if it wanted to.


> That said, The Qt Company remains a topic of concern, publishing (also on LinkedIn by employees, with lame/thin "does not necessarily represent my employer's opinion" disclaimers) lots of "why open source software is scary" content lately, apparently unaware that the only reason anyone cares about their product is its open source pedigree and credibility: https://www.qt.io/blog/is-open-source-really-free

I don't think that article is really pushing for Qt to go closed source; rather, they're just trying to sell commercial subscriptions in order to make money (after all, the Qt Company has to stay alive somehow). And Schnieder makes it clear that building your stuff opensource is not a bad idea in many situations; he's just promoting Qt's commercial subscriptions (which IMO really are probably nice for corporations who want priority support and who don't want to deal with licensing issues).


The version I linked is an outwardly more measured, balanced take as it's trying to appear academic and researched. Here is what their sales people turn it into:

https://www.linkedin.com/pulse/severe-risks-open-source-soft...

https://www.linkedin.com/pulse/total-cost-ownership-open-sou...

> Additionally the organization has to look at remarkable costs when it comes to hardware and OS porting of the whole software product to be more hardware independent eg. to react on hardware shortages. Commercial software comes with a long list of supported hardware, sometimes with a list of more than 25 different hardware platforms.

Yes, open source software has such a terrible track record at portability indeed.

You're right that with a lot of goodwill, you can choose to interpret all of those publications as "it's good to have a commercial license option and that you can buy support if needed". Which I would agree with for many reasons, including supporting technology you rely on. But the way it's presented is in a fear-mongering style that's detrimental to the open source project that is also Qt, and I believe is vital to its overall wellbeing.


Wow, that first article is really amusing. I've been experimenting with ChatGPT a reasonable amount lately, and the article really perked up my AI writing senses. The enumerated list with consistently, monotonously cautious and non-committal language, the final paragraph with a first sentence to the effect of "Overall, XYZ, but ABC" followed by "It's important to ...".

Just for kicks I asked it to write a list of reasons companies should be cautious of open source software or prefer commercial software, and a couple of points in the first attempt landed pretty close even in language used:

""" 1. Lack of Support: Open source software may not come with guaranteed technical support, which can be a problem for companies that need help with their software.

5. Lack of Documentation: Open source software may have limited documentation, making it harder for companies to understand how to use and configure the software.

6. Integration: Commercial software is often easier to integrate with other systems, since it is designed to work with specific hardware and software configurations. """

I imagine we'll be seeing things in this style a lot more often in the near future.


Those LinkedIn posts indeed show a more negative side of the issue. Still, I have high hopes for the future of Qt, and if they ever go full-on commercial, there is an agreement with KDE regarding that situation (but I'm too lazy to find it right now).


> there is an agreement with KDE regarding that situation

https://kde.org/community/whatiskde/kdefreeqtfoundation/


Yes, there's a solid contract in place to ensure Qt's open source availability that's worth a lot!

I've been working with Qt for going on 20 years, and there's been many episode to its story indeed. There will be more; it remains very capable and useful technology.


>that the only reason anyone cares about their product is its open source pedigree and credibility

That's not really the case. Paying customers don't give a shit about the open source license and the company is growing fast. https://www.qt.io/investors/share-and-financials

Total return 977% in last 5 years. CAGR 46%. https://www.qt.io/investors/share-and-financials/share/


I'm partly responsible for technology selection at one of their larger commercial customers, and I do care and worry quite a bit (and have also shared these opinions in a customer keynote at their last internal sales conf). Upsetting the open source community has been shrinking the talent pool to hire from considerably; it's where your next senior devs/SMEs really get educated on a technology. The non-FOSS LTS has increased integration cost and complexity for us. The divergence between easy to instantiate developer desktops (i.e. Qt from distro) and what we carry in the product is also a headache. It also makes it harder for internal champions to argue for Qt, because open source solutions are very popular and this differentiator is now in widespread doubt.

Business has been growing for them, but this isn't always necessarily on the strength of the product alone, but can also be a combo of inertia and fortuitous circumstances. For example, within the automotive industry the trend has been to merge multiple ECUs into fewer and consolidate technology stacks, and this has counter-intuitively probably resulted in quite a few sales as the OEMs move e.g. instrument cluster UIs from boutique solutions like Kanzi to the Qt stack they already used on the headunit (which is swallowing those other ECUs), or adding on more licenses for QNX guests. That doesn't mean the same customers aren't also already moving part of their HMI to Flutter/Unity/Unreal as the next thing rather than contemplating the port to Qt 6, however.

It's also that making moves to monetize existing customers more does work. For a time.

The effects of strategy changes like this can take many years to become apparent.


The big thing that put me off Qt 6, even though I’ve been a fan of Qt in the past, is that I cannot download the official release, even if the LGPL version, without registering an account, while before you only needed that if you wanted a commercial license or to use their other services.


It depends on what you mean with "official release". This is generally true for binaries, but the official open source source code releases you can find download locations and instructions for on the website sans account requirement, even if it does make it a bit hard and scary from a navigation POV (you have to click through a page on "open source obligations" first and so on).


I guess I meant from the Qt.io website, as when I looked last it wasn’t clear where else I could get it. The link LorenDB posted seems like it would help me with that, though!


https://github.com/miurahr/aqtinstall will help you with that.


Don't be. There is legally binding contract that prevents Qt Company from unilaterally changing the licensing deal (until KDE stops using Qt).

Qt is a great example of how you can force commercial highly profitable company to develop open source against their will even after it's sold multiple times. Trolltech and KDE jointly formed the foundation to make sure that Qt core stays open source.

Licensing agreement has not changed. Qt Company just stopped doing anything not required by the agreement between The KDE Free Qt Foundation and The Qt Company. https://kde.org/community/whatiskde/Software_License_Agreeme...


> And personally I'd rather prefer more stability.

Time flies. Qt 6 has been around for more than two years already! And from what I understand, the change from Qt5 to Qt6 is a much smaller transition than the one from 4 to 5.


Hmm maybe "smaller" but there was more stuff that just didn't exist (or work properly) for a year and a half in the 5->6 transition as there was in the 4->5 transition. I went through both transitions and this one was more of a pain.


Nice!

I was waiting for this to happen so $HOME/.kde would be finally removed for good.


I wonder how long will it take for all major KDE apps to move to Qt 6? Or is this trivial, as they are using KDE libraries?


KDE's apps Plasma use the same set of libraries (KDE Frameworks), and Plasma only made this move after the Qt 6 port of the libraries achieved a certain level of maturity. This in turn has also enabled many app ports already. In a way, the Plasma bits are a somewhat later step in this campaign as some of the hardest to port pieces that need the most supporting infrastructure.

You can check up on overall KDE-wide progress here: https://iskdeusingqt6.org/


Will that finally give me ISO dates in all my kde programs (mainly dolphin)?


Hopefully KDE 6 has a modern theme, Plasma is very 2015.


2015 it's modern enough. I use an IceWM style mimicking Motif and a Solaris 8 theme close to OpenLook/Motif, so anything which came later than 2008 looks the same to me.


Leave KDE alone!

Seriously, it's the last DE that seems to be doing something else but to make everything ever flatter and more whitespacier. I like the slight retro touch to Breeze, makes everthing more visible.


They need to update to modern design, a minimalist Apple GUI aimed at tablets.


Lol, if you think Gnome is an apple copy, you haven't seen any of the new Chinese DEs.

Also from experience, Gnome absolutely destroyes MacOS in usability, macOS is really crappy.


>Also from experience, Gnome absolutely destroyes MacOS in usability, macOS is really crappy.

This isn't exactly a high bar...

Even Windows destroys MacOS in usability.


The authoritarian Windows PC in the workplace didn't let me dial the color the way I want. That was before the recent firings at Redmond. All window managers need to let users adjust the color, especially the absolute #ffffff white. Because eye hurts.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: