How timely, I use KDE and recently decided to give Wayland a try which meant rewriting some of my existing xdotool scripts as KWin scripts. Since they are written in JavaScript and the documentation for scripts isn't exactly comprehensive, it was an overall poor experience, but at least it worked eventually and without taking too much of my time.
Unfortunately, it seems with the upgrade to Plasma6 (which I got immediately since I'm on Arch) KDE broke completely and I had to switch to XFCE...
It broke for me too, but after a few tweaks to the settings and staying on top of all the bug fixes, is back to usable! I'm in a very similar position, being somewhat unwilling Arch user that accidentally upgraded early, and was prepared to suffer (or even switch distros), but it only took a day or two for my issues to be resolved. Try switching back!
Thanks, I actually tried again today. I still have no panels, no desktop, no keyboard shortcuts and KDE applications have various rendering issues.
I had a few issues on my laptop as well and only upgraded the desktop once the issues on the laptop were resolved (which took a bit more than a week I think?). Was not expecting basically complete breakage.
I think they deprecated the old keyboard shortcuts, had to set mine up fresh. The missing panels is crazy though! Have you tried setting them up from scratch? Ive found it only takes a few minutes to get a nice usable setup (the default panel is great). I'm also sticking to X11 for the foreseeable future, maybe switching to wayland after 6.2 or 6.3
> I think they deprecated the old keyboard shortcuts, had to set mine up fresh.
On my laptop the keyboard shortcuts magically restored themselves after I logged in and out of X11 and Wayland mode a few times. I'd try that on my desktop if I could get the UI for logging out to spawn :) (or the UI to configure the shortcuts)
> Have you tried setting them up from scratch?
I couldn't summon any UI to set them up (remember that there's no panels or desktop to click and that KDE applications in general have rendering issues that can render them unusable). I suspect it won't help though since when I log in I can see them blinking in and out of existence a few times before disappearing permanently, I assume crashing and restarting a few times before giving up on running.
> the default panel is great
I do have quite a bit of customizations on top of the default that I'd rather not lose, but I'll set them up again if I have to. After it looks like it will actually work that is.
Have you tried disabling the compositor (Shift + Alt + F12)? I've found that sometimes fixes graphical issues. No guarantees, but if you haven't already, it's worth a shot.
try creating a new temp user account and try there. Should give you a good idea if there's an issue with the software itself or your customizations. Then you can narrow them down.
Thanks, that's a new idea I haven't thought of and indeed a temporary account works! Doesn't quite solve the problem yet but indeed a good starting point to try and figure it out.
Edit: Was able to temporarily "fix" things (doesn't fix rendering issues, but makes desktop usable again) by reseting the panel configuration, and then some simple fixes to its appearance broke everything again... Sounds like it will be a while before Plasma 6 is ready for me to switch back to it.
Mine broke completely on OpenSUSE Tumbleweed. Turns out I had an old repo that I nuked. Then I logged out of Plasma, logged into an IceWM and reran the `zypper dup` and everything was hunky dory again.
This is so cool! Much nicer than what we had before.
My first Google Summer of Code project (aka my first internship ever during my freshman year of college) was implementing some of the animations (like Grow) in KDE Plasma. I'm not sure I did great work, but it felt awesome to be doing it - KDE 4 had just come out, it was extremely shiny and this was the era of the desktop cube and wobbly windows as desktop compositing had just become a thing in linux!
The organization behind QT (QT Group) has pretty onerous licensing terms.
My understanding is that it's $3,950 per year just to develop using their libraries on your own computer if you ever in the future intend to commercialize your project using QT. Transitioning from the open source license to the commercial license is something you can do but it's not the happy path according to their FAQ.
My understanding is that some of the QT libraries or older forked versions of them are still completely under open source licenses but it seems like a very complicated situation if you have commercial aspirations with your project.
Something like Slint (Rust based but includes CPP and JS bindings) is not as comprehensive (yet) but it's more modern and the licensing terms are significantly more in line with software industry norms.
My interpretation is you can build commercial products with Qt for free as long as you can comply with LGPL. Mostly this means link dynamically (if closed source), only use LGPL components and give attribution.
Lots of GUI native, non-web libraries have been started in Rust, but they are VERY far from being close to what Qt supports. You may get closer using web based libraries (Tauri, etc), but I wouldn’t personally start web based desktop applications.
Exactly! There's always misunderstanding about Qt's license that I believe they should make the LGPL license clearer on their website. I believe many developers are struck down because they think it's not permissive enough where actually it's quite permissive.
Some of it might be misunderstanding, but complication of distribution may also play a role. Making sure that your application is correctly dynamically linked and packaged to run without issues across all supported platforms and configurations can be considerably more involved than statically linking depending on the toolchain in question.
Which on that note, last I knew getting Qt apps correctly stripped and packaged for all platforms was a bit of a bear. In particular I remember building Mac application bundles being messy.
This is true, but then again, these days, it's easy to look up at a popular open source Qt app and copy its CI recipes. For example, anyone that wants recipes for creating binaries for multiple operating systems can copy the GitHub workflows in my open source note-taking app: https://github.com/nuttyartist/notes/tree/master/.github/wor...
That said, I really think Qt should have a separate commercial license that is exactly like LGPL but allows you to link statically and costs much less (without all the enterprisy things).
One problem with Qt is that some modules are under the GPL and it is easy to end up inadvertently with a GPL dependency.
Also it seems the Qt company makes it confusing on purpose.
The only issue though is that Qt does not agree that mobile apps on app stores can use LGPL license due to anti-tivotization clause. Nevertheless they do have a somewhat reasonable pricing for small business of 500$ per year.
I think Slint is quite interesting, but it's licensing model is very similar to Qt, albeit somewhat more restrictive: The open source option is GPL v3 (not LGPL), and then there's commercial licenses, which yes, are cheaper - for now, for a start-up toolkit.
Pricing can change. Yes, there's a perpetual "Buyout" license for $5k, but they can probably just rename the product and claim it's a new one (or add a second product and add commercially relevant eggs to that basket; Qt has tried with things like "Qt for Device Creation" and "Qt for Automotive").
The open source option is not backed by a poison-pill protection like the Free Qt Foundation agreement either.
I know the people behind Slint, and I have a lot of trust toward them. But ownership can change, too.
Based on the discussion with our community, we added a clause in our CLA - https://cla-assistant.io/slint-ui/slint - to ensure that Slint will always be made available under an open source license as well as a royalty-free license.
"We believe that open-source software development and communities are the foundation for a healthy ecosystem of high-quality software, where everyone can learn, improve and give back. We commit to upholding this foundation and pledge by promising to continue to develop Slint in the open under an open-source license compliant with the Open Source Definition.
Further, we commit to provide a royalty-free license for those who develop desktop or web applications and do not want to use open-source components under copyleft licenses."
Slint is under three licenses: There The GPL for open source users, the royalty-free license for proprietary desktop application (which is free of charge), and the commercial license.
The royalty free is even better than the LGPL for Rust because rust doesn't support dynamic linking or even re-linking with object files.
The Qt Company sheds a lot of FUD on their licensing as an attempt to strongarm customers into paying for Qt. For a lot of companies, Qt's LGPL version would work just fine, but Qt will breathe down your neck trying to get you to switch.
> if you have commercial aspirations with your project
1. Nothing in copyleft licenses forbids you from making a living or receiving money.
2. Since the post was about writing an effect for KWin and your alternatives do nothing of sort… perhaps they aren't really valid alternatives, at least in this context.
This comes from different libraries being used for different things. KConfigXT uses XML to generate settings classes. Qt Widgets UI files are also XML based, but that comes from Qt and is separate from KConfigXT. I don't know what uses the metadata JSON files, but I know it's not Qt Widgets or KConfigXT.
If you want to use the same API of an existing web framework, I'm sure that wouldn't work, since QML is exposing C++ objects to js code, so the API is set.
> instead of just writing a JS file with your code and then loading it
If your js does no I/O at all, you can write pure js. But if you want to show some results, there is no way that you can do it without learning the relevant API to do that.
Maybe not implement React, but Qt would benefit from using something like Facebook’s Flux architecture, where state flows down from parent objects to children.
With Qt Widgets, it is annoying to create models (QAbstractItemModel), they are more difficult to implement than what it should and prone to errors. I haven’t done much QML beyond simple sample apps, but it seemed you still have to create Qt models for a lot of use cases.