Remaining KDE3/KDE4 coinstallability issues (kde3base + kde4libs + kdepimlibs + kdebase-runtime)
|KDE3 Module||KDE4 Module||File Name||Comments|
|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|
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.
be good for kde4 apps, we need both installed.
are kde3 or kde4 dependent of course.
someone can clarify it.
Should kinfocenter instead be moved to kdebase/applications? Maybe even outside kdebase?
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.
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.
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.
kdebase/runtime. Well, at least it's certainly a hack ugly enough not to be used by other apps.
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.
will do, which one gets called isn't important. handled by distros
application. Move to libexec.
trash.desktop which uses Exec=ktrash -empty. %f is implied...
- but trash.desktop does not seem to be found ?
Is it actually used anywhere?
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||
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.
|kdebase||kdebase-runtime||usr/share/icons/hicolor/*/apps/khelpcenter.png and knetattach.png||
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.
they could be used by distributions?