zeroxoneafour
commented
1 year ago Try master build, QTimer suffered a regression when I updated the script to QML. It's fixed in master.
Closed cig0 closed 1 year ago
zeroxoneafour
commented
1 year ago Try master build, QTimer suffered a regression when I updated the script to QML. It's fixed in master.
cig0
commented
1 year ago Will do!
OT: are you interested in a Containerfile / Nix script for building Polonium?
zeroxoneafour
commented
1 year ago A nix script isn't really necessary to use Polonium, as there's no kcm integration or anything that really needs installation. The official way to get Polonium is still through the KWin Scripts management system, which is distro-agonistic and supported by KDE. I also heard some things about packaging where npm can't be used to build things for certain distros.
That being said, if you would like to publish and maintain a nix script for Polonium yourself, I would have no problems with it. I don't maintain the AUR script either, but I guess people use it.
cig0
commented
1 year ago A nix script isn't really necessary to use Polonium, as there's no kcm integration or anything that really needs installation. The official way to get Polonium is still through the KWin Scripts management system, which is distro-agonistic and supported by KDE. I also heard some things about packaging where npm can't be used to build things for certain distros.
That being said, if you would like to publish and maintain a nix script for Polonium yourself, I would have no problems with it. I don't maintain the AUR script either, but I guess people use it.
Right. That's why I suggested having a Containerfile or a Nix script for building Polonium.
I use many Containerfile build files to build stuff in ephemeral containers and get the artifact(s) delivered to my hosts without installing any tooling locally, messing with versions, etc. In this case, I considered a container image tightly integrated with the Makefile to avoid installing Node/NPM and any build libraries on one's system. You build it, you get the KWin script, and the build container is discarded :ok_hand:
The Nix build environment is a great excuse for me to learn how to do so with Nix, which, IMO, is a pretty good tool for a lot of CI/CD workflows. But yeah, I suppose it is still a bit of a niche tool, so having a Containerfile feels more of a "standard" approach these days.
cig0
commented
1 year ago The official way to get Polonium is still through the KWin Scripts management system
I never got used to installing stuff this way :smile:
I understand this is a very manual way of installing and managing scripts, widgets, and everything else. You must manually check for new versions, then again manually download them, correct? Let me know if I'm getting this wrong.
If there's no automatic handling of new releases when published, then I believe "packaging" (automating the app delivery) adds value here as a way to receive unattended updates without having to take care of that expressly.
zeroxoneafour
commented
1 year ago I don't really see the need for containerization to build Polonium. Builds do not need any specific versions/libraries where they couldn't build across all systems with npm support. If you work on script development, then you probably should have all of those tools installed on your computer anyway. If you don't, you can very easily download the latest build from GitHub actions/releases. Using a containerfile would also add extra complexity to GitHub builds that isn't really needed.
I do fully agree with you on the package management idea. I hate manually upgrading packages as well, and I have almost all of the software on my computer downloaded through the Arch repos/AUR because it is much easier to manage it that way. However, KWin Scripts still remains the only method of script delivery KDE seems to officially support. And until auto upgrading is added to that (would be a great Plasma 6 idea if anyone is listening), it remains the cleanest way to deliver the scripts in the KDE ecosystem.
Describe the bug A lot of times, the tiling will behave erratically -- see attached screenshots.
Additional information that could be useful (or not!):
Polonium options:
krunner, yakuake, kded, polkit, plasmashell, kcalc, org.kde.kcolorchooser, pinentry-qt, org.kde.spectacleBorder all.BTree.Right side.Sys specs:
To Reproduce Steps to reproduce the behavior:
Log See here for how to get a log.
Sure!
Note: I added the
-iflag to ignore case distinctions since there aren't any logs with the original command withPoloniumstarting with a capital p.Screenshots If possible, add screenshots or videos to help explain your problem.
Additional context Nothing I can't think of.
Thanks!