Projects/KDE3 KDE4 coinstallability: Difference between revisions

    From KDE TechBase
    No edit summary
    No edit summary
    Line 31: Line 31:
    *(david) Needs a 4 I suppose; systemsettings doesn't include it, and the modules
    *(david) Needs a 4 I suppose; systemsettings doesn't include it, and the modules
    are kde3 or kde4 dependent of course.
    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 ||
    || kdebase || kdebase-runtime || usr/bin/kstart ||

    Revision as of 14:37, 11 November 2007

    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
    • (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) Hmm... 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 KDE 3

    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