Description: "kde5" doesn't exist. "KDE" is the name of the community, and "Plasma 5" is the name of the fifth version of our desktop environment. But there has never been a "kde5", and there never will be. :) Therefore to reduce confusion and improve consistency I recommend renaming the "kde5" CVL to be something more accurate, such as just "kde". If adding a version into the name is important, it could be "kde_kf5" maybe, since the thing you're actually linking against is the KDE frameworks (= kf5) Thanks for your consideration! Steps to Reproduce: Look at VCL name Actual Results: Name is "kde5" Expected Results: Name should be something difference because "kde5" isn't a thing Reproducible: Always User Profile Reset: Yes Additional Info:
the nomenclature used in about LibreOffice dialog is internal from LibreOffice and stands for the VCL environments used here https://cgit.freedesktop.org/libreoffice/core/tree/vcl/unx. IMHO -> NOTABUG
I personally don't have hard feelings about it. Thing is the gtk3 backend also isn't called gnome. The kde5 backend is also used on haiku. Don't know if that should matter or not. Changing the displayed string from kde5 => kf5 is easy enough, even renaming the plugin binary, or adding an alias in the plugin loader to match kde5 => kf5. I wouldn't rename the source files for easier git blaming. My earlier classes were renamed from KF5 to Qt5 FWIW.
If there is indeed an option to do this, I would recommend keeping "kde" in the string somewhere if only for recognizability's sake. e.g. "kde_kf5", "kde_qt5", etc.
it's not a bug and wontfix
Which is the actual problem solved by this? is there any positive result other than some manhours wasted and some users confused because the familiar plugin name stopped working (and some commit noise, which some hate ;-))? Where is that user who was confused with current naming, so that it prevented work being done? There may not be "kde5" in some other project, but currently there *is* kde5 in this project, which doesn't try to convince anyone with anything, but is just a codename of one of plugins; changing that is just some purism imo.
(In reply to Jan-Marek Glogowski from comment #2) Just to make it more clear, my suggestion is to rename libvclplug_kde5lo.so => libvclplug_kf5lo.so and display kde5 => kf5. I hope gtk3_kde5 will fade out over time, so leave that as it.
After thinking about it for a while, I'd currently prefer to stay with the name as is, if this is OK for everybody involved. While I do understand that "kde5" maybe wasn't the best choice for the naming, it'd rather be confusing to change it now. (In reply to Jan-Marek Glogowski from comment #6) > Just to make it more clear, my suggestion is to rename libvclplug_kde5lo.so > => libvclplug_kf5lo.so and display kde5 => kf5. But in case we rename it, I think it's better to rename it everywhere, since I think it would be rather counter-produtive wrt the intent mentioned in the initial report ("reduce confusion and improve consistency") to have it called "kde5" at some places and "kf5" at others. 'git blame' should be no problem, since 'git help blame' says: "The origin of lines is automatically followed across whole-file renames (currently there is no option to turn the rename-following off)." > > I hope gtk3_kde5 will fade out over time, so leave that as it. As probably will kde5 once qt6 takes over? :-) So maybe that would be a good point to start with a proper name just from the beginning?
(In reply to Michael Weghorn from comment #7) > 'git blame' should be no problem, since 'git help blame' says: "The origin > of lines is automatically followed across whole-file renames (currently > there is no option to turn the rename-following off)." Ah nice. Missed that. So we would need an explicit rename commit without further changes in the source and git could handle that transparently. Normally you rename the file and change all the class stuff in one go, so that's probably why I had the impression that everything was treated as a deleted + new file instead of a rename. So no problem, if done right.
@Michael, @jmux, should the topic be discussed in the ESC meeting ?
(In reply to Xisco Faulí from comment #9) > @Michael, @jmux, should the topic be discussed in the ESC meeting ? Yeah - I just forgot about it the last two weeks.
@Nate: Can you give a hint how important it is from your respective to get it renamed for the kf5 life cycle? In reply to Michael Weghorn from comment #7) > But in case we rename it, I think it's better to rename it everywhere, since > I think it would be rather counter-produtive wrt the intent mentioned in the > initial report ("reduce confusion and improve consistency") to have it > called "kde5" at some places and "kf5" at others. Though another thought I had while thinking about it a little more in the last weeks was that if we rename it from "kde5" everywhere, this would require action at several levels, like * other developers, and config for builders like Jenkins/tinderboxes (if we change build option name) * distros, to take into account the new build option and library name(s) Given that, I currently see following options: 1) Rename everywhere + Consistency inside LO and with KDE project's naming for kf5 - most action required on different levels 2) Rename it in some places/keep old name around to some extent + consistent with KDE project's naming for kf5 in UI - inconsistent inside LO (different terms used), may be confusing 3) Keep name "kde5", rename with next major version + no effort at all for now - inconsistent with KDE project's naming until qt6/kf6 is there Any more ideas on this? (In reply to Jan-Marek Glogowski from comment #10) > (In reply to Xisco Faulí from comment #9) > > @Michael, @jmux, should the topic be discussed in the ESC meeting ? > > Yeah - I just forgot about it the last two weeks. jmux: Are you taking the topic there? (I think it might just be fair if a person that's a bit more convinced than myself at the moment would suggest that...) @Nate: ESC call is public and everybody can join, so if you and/or others from KDE want to join, please do. :-) It takes place Thu, 16:00 CEST via Jitsi at [1]. [1] https://meet.jit.si/TDFESC
Not at all important for me. If the easiest path forward is leaving this as-is right now and renaming it in the Qt/KF 6 timeframe, let's just do that IMO.
Patch: https://gerrit.libreoffice.org/#/c/75313/ Doesn't touch gtk3_kde5.
Good news. :) This was discussed in today's ESC call. From the minutes: > * Renaming kde5 VCL plugin to kf5 - tdf#125922 (Michael W) > + Just as the gtk3 plugin isn't named GNOME, rename kde5 to kf5, as it is > based on the KDE frameworks 5 libraries and used by other OSs too. > + also renames detected desktop from kde5 to plasma5 > + most code already moved from kde5 to qt5 > + https://bugs.documentfoundation.org/show_bug.cgi?id=125922 > + Patch: https://gerrit.libreoffice.org/#/c/75313/ > diff: +255, -406 (drops ~100 lines unused code – can be separated) > + bike-shedding, but a minor issue (Jan-Marek) > + not much reason not to rename it. > + makes-work for packagers I guess (Michael) > + need work for the new version anyway (Jan-Marek) > + renaming the option > + may impact the release config, and some autogen.inputs > => people need to update their configs > => will add an alias configure switch (Jan-Marek) > => apply the renaming patch.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/d3c6ac6d0f23df56644008ccb6aa2c8fa37ab1b5%5E%21 tdf#125922 rename kde5 to kf5 + plasma5 It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Current in my /etc/environment file I have: SAL_USE_VCLPLUGIN=kde5 Do I need to change it now? Thanks.
(In reply to S. from comment #16) > Current in my /etc/environment file I have: > SAL_USE_VCLPLUGIN=kde5 > Do I need to change it now? Thanks. Please use SAL_USE_VCLPLUGIN=kf5 instead. (The old one still works as a fallback right now, but that will be removed in some future version.)