Projects/KDE3 KDE4 coinstallability

Remaining KDE3/KDE4 coinstallability issues (kde3base + kde4libs + kdepimlibs + kdebase-runtime)

KDE3 Module	KDE4 Module	File Name	Comments
kdelibs	kdebase-runtime	usr/bin/ksvgtopng	(sune) a dev tool, but iirc renamed by dfaure. => handled by kde already.
kdebase	kdebase-runtime	etc/xdg/menus/kde-information.menu	handled by distros
kdebase	kdebase-runtime	usr/share/desktop-directories/kde-information.directory	handled by distros
kdebase	kdebase-runtime	usr/bin/kdebugdialog	(sune) Seems to be a user application - append 4 ? (thiago) No. kdebugdialog modifies a shared config file: kdebugrc. You only need one application installed: no need for both from KDE 3 and 4. I guess this is kdebase/applications instead (not workspace, not runtime). Except that distribution packagers are HIGHLY encouraged to install it.
kdebase	kdebase-runtime	usr/bin/khelpcenter
kdebase	kdebase-runtime	usr/bin/kinfocenter
kdebase	kdebase-runtime	usr/bin/kstart	(sune) user application to start programs with weird args. Append 4 ? (thiago) I guess not, since there might be user scripts out there that use it by name. First of all, is this runtime material or workspace? I.e., does it work with other WMs than kwin? Most of this application's options are related to the window placement, so how is it communicating that information to the Window Manager? If it's native WM hints, then either kstart would work just fine in either environment. If it's using DCOP/D-Bus, then distributions will need to replace this with a shell script that detects the running environment and execs the correct one. Meaning: you need to rename the KDE 3 one too. (kevin) From a quick look at the code I'd say it is using direct X11 communication with the window manager, so it should work with other window managers as well and there is probably no difference for a script if it calls the KDE3 or KDE4 version. (thiago) If that is so, then my take is that we don't rename it. Distributions fix this through an "alternatives" mechanism, so that "kstart" always works. Which one is run doesn't matter. Worst case scenario, you're triggering the load of the wrong libraries into memory. (lubos) Correct. However it's a user script and I don't think it belongs to kdebase/runtime. Well, at least it's certainly a hack ugly enough not to be used by other apps. (david) User scripts do belong in a "always installed runtime" package, so that user scripts do work on any kde installation. There was an old discussion (mainly between Aaron and me iirc, on this list), about whether or not to split kdebase/runtime into "runtime for apps" and "runtime for scripts", but whether it's split out or not, the problem is the same: it must be there, so it will conflict with the equivalent 'runtime' of earlier kde versions. (sune) Seems from the rest of the thread that either kde3 kstart or kde4 kstart will do, which one gets called isn't important. handled by distros
kdebase	kdebase-runtime	usr/bin/ktrash	(sune) trash handler helper. Seems to be used by kio trash. Append 4 ? move to libexec ? (thiago) It doesn't do anything when run here, so my guess is it's not a user application. Move to libexec. (sune) kioslave/trash/ktrash.cpp: // This hack is for the servicemenu on trash.desktop which uses Exec=ktrash -empty. %f is implied... - but trash.desktop does not seem to be found ? Is it actually used anywhere?
kdebase	kdebase-runtime	usr/bin/kreadconfig and kwriteconfig	(sune) Related programs - but seems to be not used by anything else - append 4 ? (thiago) No. Overwrite the KDE 3 ones. See the other threads about KConfig issues: the new backend is more powerful and less prone to errors. It can handle saving and storing better, without corruption. And it should technically be able to read and write KDE 3 config files too. (sune) handled by distros
kdebase	kdebase-runtime	usr/share/icons/hicolor/*/apps/khelpcenter.png and knetattach.png	(sune) Can't kde3 versions be used by distributiotns? or are they planned to be moved away? (thiago) No idea. I have a vague memory that those icons weren't from the icon theme per se, but installed by applications. So we have to make sure that the Oxygen version of them exists and then simply remove the icon from application.
kdebase	kdebase-runtime	usr/share/locale/*	(sune) seems very much like the kde3 version. Maybe they could be used by distributions? (thiago) Yes, good idea. Move those to a separate package that is shared by both KDE 3 and 4.
kdebase	kdebase-runtime	usr/share/sounds/KDE_*.ogg	(sune) maybe kde3 versions could be used ? (thiago) Same as the icons above.