kde3 kde4 coinstallability take two

[Thiago Macieira]

Are these kdebase 3.x or kdebase/runtime 4.0 files?

Em Sunday 21 October 2007 17:13:05 Sune Vuorela escreveu:
> etc/xdg/menus/kde-information.menu
> etc/xdg/menus/kde-settings.menu

This is kdebase/workspace 4 data. It shouldn't conflict.

> dunno about these.
>
> usr/bin/drkonqi
> Only mentioned here:
>
> kdelibs/kdeui/kdepackages.h:"drkonqi",
> kdelibs/kdeui/util/kcrash.cpp:          // argument 0 has to be drkonqi
> kdelibs/kdeui/util/kcrash.cpp:          argv[i++] = "drkonqi";
> kdelibs/kdeui/util/kcrash.cpp:    execvp("drkonqi", const_cast< char** >(
> argv ));
> kdesdk/kbugbuster/backend/bug.cpp:   else if ( s == "crash" || s
> == "drkonqi" ) return Crash;

Hmm... I'd say drkonqi is a "runtime" application, but it's also not a hard 
dependency. If drkonqi cannot be launched, you simply get no crash dialog.

In any case, KDE 4's drkonqi can be used with KDE 3's applications and 
vice-versa. Actually, both should work for *any* application.

> Should be rename-able - or maybe put in libexec ?

It could move to libexec or it could also be part of kdebase/workspace.

Technically, though, drkonqi is the perfect example of libexec application.

> usr/bin/kdebugdialog
> Seems to be a user application - append 4 ?

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.

> usr/bin/kdeeject
> can't find any uses of this - only mentioned where it is build and such.

I guess this one could actually be removed, but I'll let Kévin comment on it. 
Ejection should be handled through Solid, which in turn goes through HAL 
where available. Where HAL isn't used, it will need to call upon an 
executable (/usr/bin/eject), but I don't know how Solid does it.

> usr/bin/kdesu
> usr/bin/kdesud
> seems to be used some places, but not that many. I dunno about this.
> libexec? - maybe with symlinks from bin/kdesu4 to libexec?

I don't know. Last I heard, trying to rename it would cause a lot of porting 
trouble.

Can't distributions handle this case by using an "alternatives"-style 
approach?

The proper solution would be to use D-Bus and PolicyKit.

> usr/bin/khc_docbookdig.pl
> usr/bin/khc_htdig.pl
> usr/bin/khc_htsearch.pl
> usr/bin/khc_indexbuilder
> usr/bin/khc_mansearch.pl
>
> urgh. is htdig still used? And is it different from the kde3 versions?

libexec. These should never have been placed in ${prefix}/bin because they are 
are not user applications.

> usr/bin/khelpcenter
> usr/bin/kinfocenter
> Has khelpcenter changed at all - and does kde3 khelpcenter actually satisfy
> kde4 ?

No comment from me.

> usr/bin/klocaldomainurifilterhelper
> What is this a helper for?

minicli. I guess we can fix this by not requiring the helper anymore :-)

> usr/bin/knetattach
> user program to mount net shares of some kind. Append 4 ?

It's kio_remote's wizard program. Is it even on the menu?

If it's not, I'd argue this is libexec material.

> usr/bin/kjobviewer

Rafael, comments?

This is definitely runtime material, but like the case above, is it on the 
menu?

In fact, shouldn't the applications from kdebase/runtime be almost all in 
libexec?

> usr/bin/kprinter
> usr/bin/kdeprintfax
> usr/bin/imagetops
> kprinter - to be moved away

Indeed. kdeprintfax is an application, it shouldn't be conflicting. If it's 
not dropped, it should move to kdebase/applications or further down the 
chain.

kprinter -- as a command-line tool that prints PostScript input and shows a 
print dialog -- should be replaced with a full-fledged PostScript reader. My 
take is Okular here. It takes imagetops along with it.

In any case, it's not a runtime issue: KDE applications shouldn't be calling 
kprinter, they should use the C++ classes. Are there any cases of KDE 
applications using this? (These are, by definition, non-GUI applications and 
KDE isn't in the business of writing them!)

> usr/bin/kstart
> user application to start programs with weird args. Append 4 ?

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.

> usr/bin/ksvgtopng
> a dev tool, but iirc renamed by dfaure
>
> usr/bin/ktrash
> trash handler helper. Seems to be used by kio trash. Append4? move to
> libexec?

It doesn't do anything when run here, so my guess is it's not a user 
application. Move to libexec.

> usr/bin/kwriteconfig
> usr/bin/kreadconfig
> Related programs - but seems to be not used by anything else - append 4 ?

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.

> usr/share/desktop-directories/kde-information.directory
> usr/share/desktop-directories/kde-settings-accessibility.directory
> usr/share/desktop-directories/kde-settings-components.directory
> usr/share/desktop-directories/kde-settings-desktop.directory
> usr/share/desktop-directories/kde-settings.directory
> usr/share/desktop-directories/kde-settings-hardware.directory
> usr/share/desktop-directories/kde-settings-looknfeel.directory
> usr/share/desktop-directories/kde-settings-network.directory
> usr/share/desktop-directories/kde-settings-power.directory
> usr/share/desktop-directories/kde-settings-security.directory
> usr/share/desktop-directories/kde-settings-sound.directory
> usr/share/desktop-directories/kde-settings-system.directory
> usr/share/desktop-directories/kde-settings-webbrowsing.directory
> no clue about these.

Those are kcontrol's organisation menus. I have no idea if System Settings 
uses them.

So: if it doesn't, remove them from our installation. Remove kcontrol too, in 
case it hasn't been removed. Alternatively, move kcontrol to an application 
of its own and those files along with it. Mark it as non-coinstallable -- you 
can't install KDE 4's kcontrol while you have any KDE 3.

If those files are needed, then my guess is s/kde-/kde4-/ with the proper 
matching wherever they are referenced.

> Some icons under:
> usr/share/icons/crystalsvg/
> usr/share/icons/hicolor/scalable/
> Can't kde3 versions be used by distributiotns? or are they planned to be
> moved away?

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.

> usr/share/locale/l10n/ad/entry.desktop
> usr/share/locale/l10n/ad/flag.png
> And similar for other locales - seems very much like the kde3 version.
> Maybe they could be used by distributions?

Yes, good idea. Move those to a separate package that is shared by both KDE 3 
and 4.

(In RPM speech, those are "noarch" packages)

> usr/share/sounds/KDE_*
> maybe kde3 versions could be used?

Same as the icons above.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071022/db18d482/attachment.sig>