Projects/KDE3 KDE4 coinstallability

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

Related thread on k-c-d: http://lists.kde.org/?t=119304374500002&r=1&w=2

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. (fathi) not renamed by david. renaming handled by distros until consensus reached.
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	(david) kde3 khelpcenter won't see the .desktop files for kde4 apps so using khelpcenter3 won't be good for kde4 apps, we need both installed.
kdebase	kdebase-runtime	usr/bin/kinfocenter	(david) Needs a 4 I suppose; systemsettings doesn't include it, and the modules are kde3 or kde4 dependent of course. (thiago) There was no conclusion on kinfocenter. Please don't do this change unless someone can clarify it. Should kinfocenter instead be moved to kdebase/applications? Maybe even outside kdebase? (allen) Why not kdeutils?
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 ? (david) No it's not -used- by kio_trash. It's a command-line tool. (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? (david) sounds like I didn't get it to work and hardcoded something in KonqPopupmenu instead, but that's not really flexible. A servicemenu based solution would be better. Anyway, the problem with command-line tools for power users is that they can't move to libexec, and they look ugly with a 4 in the name.OTOH I can't really see why a user would need both ktrash from kde3 and the one from kde4 (the trash system is compatible after all). I won't be able to do any renamings until Thursday though (travelling soon to a customer) so someone else would have to do the above because of the freeze.
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. (sune) should be handled by oxygen people
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 KDE3 and 4. (sune) handled by distros
kdebase	kdebase-runtime	usr/share/sounds/KDE_*.ogg	(sune) maybe kde3 versions could be used ? (thiago) Same as the icons above. (sune) handled by distros