https://bugs.kde.org/show_bug.cgi?id=516460
Christian (Fuchs) <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |CONFIRMED --- Comment #2 from Christian (Fuchs) <[email protected]> --- Nate, (In reply to Nate Graham from comment #1) > > - renaming of some private imports > Private imports have no stability guarantee, not even an implicit one. If > you develop software against private API, you have to live with breakage as > a necessary consequence; every developer knows this, or should. Not a bug. As I wrote both on the reddit threads where users complained and the plasma development channel: IFF there was an alternative to use, I'd let that count. But we simply don't offer one. So third party developers have two options: rely on a private import, or not write their plasmoids at all. Thi sis imho not an option. This is why I suggested a couple of things to d_ed for long term solutions. This, however, is more for the short term and current situation. > > - distributing plasmoids as non-editable, compiled shared objects > This was intentional for efficiency and memory optimization reasons. I > understand it broke experts' ability to live-patch their systems without > setting up a formal development environment, but this was something that was > never advertised or supported; it was an implementation detail. As such no > one should have been relying on it, and everyone who was should have known > that it was fragile and could break at any time (as it did in the past even > before this). Not a bug. In all honesty, doing something for 11 years and then changing it in a minor release is imho not breakage people would expect. However, as per past discussions with you on such subjects, I'd rather spend my time on something productive, you are not going to change your mind but based on my experience rather close this report, so I won't even try. > > - New packaging that doesn't allow plasoids with certain imports, e.g. > > import plasma.applet.org.kde.plasma.pager or import > > plasma.applet.org.kde.plasma.taskmanager > Can you elaborate on this? It sounds like it it might be a bug; I'm aware of > no intentional plan to prevent importing those. As elaborated in the development channel, trying to import these simply results in a "module not installed" error unless the original plasmoid (and thus the import) are already loaded in memory. As I am not deeply into Qt or our new packaging with the new CMAKE macro, I can't say where this is coming from, but solving that would potentially already solve half of the problems, since then it would be easier again to override the .so plasmoids we ship with custom .qml ones in the same directory structure, but the XDG_DATA_HOME. > Can you provide examples of 3rd-party widgets that broke purely because of > using those imports? According to reddit at very least kara (https://github.com/dhruv8sh/kara), which now ships with a custom install bash script that (without checking for dependencies and other issues, but that's a sidenote) compiles a backend and overrides some environment variables and restarts plasma. This, of course, completely breaks the store / get new plasmoids integration. Then we have compact pager (https://github.com/tilorenz/compact_pager), which worked around some of it, but as of today still lacks some functionality due to the imports. Then Fastfetch, which I have to admit I have no idea what it is, but it appears that some users on reddit aren't happy. And then of course every single copy of the original plasmoid that you place as qml in XDG_DATA_HOME in order to test / do minor changes without having to recompile every time. Which is more of a third party developer than actual user issue, but one that imho hurts our reputation if we want to advertise plasma as open for third party developers. -- You are receiving this mail because: You are watching all bug changes.
