kde3 kde4 coinstallability take two

[Sune Vuorela]

On 2007-10-22, Thiago Macieira <thiago at kde.org> wrote:

Hi people. 

It seems tha many people are positive about this. It looks like it
mostly just needs to be done. I currently don't have commit access - and
for many of these things, I might also feel myself a bit clueless about
how to do it properly.

If I read the freeze guidelines and stuff the right way, it needs to be
done before wednesday 23:59 UTC.
And it would be nice to have it for the next beta/RC  release.

so - who wants to help out?

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

These files should be what is in common of those - meaning they are
both.

>> etc/xdg/menus/kde-information.menu
>> etc/xdg/menus/kde-settings.menu
>
> This is kdebase/workspace 4 data. It shouldn't conflict.

runtime/kcontrol/menus/kde-information.menu
runtime/kcontrol/menus/kde-settings.menu

I wonder if they are installed correctly there ? 


>
>> dunno about these.
>>
>> usr/bin/drkonqi
>> Only mentioned here:
>>
>> kdelibs/kdeui/kdepackages.h:"drkonqi",
>> kdelibs/kdeui/util/kcrash.cpp: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// argum=
> ent 0 has to be drkonqi
>> kdelibs/kdeui/util/kcrash.cpp: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0argv[i++=
> ] =3D "drkonqi";
>> kdelibs/kdeui/util/kcrash.cpp: =C2=A0 =C2=A0execvp("drkonqi", const_cast<=
>  char** >(
>> argv ));
>> kdesdk/kbugbuster/backend/bug.cpp: =C2=A0 else if ( s =3D=3D "crash" || s
>> =3D=3D "drkonqi" ) return Crash;
>
> Hmm... I'd say drkonqi is a "runtime" application, but it's also not a hard=
>=20
> 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=20
> 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.

The easy solution here might be to just append 4 - the alternative is to
move it to libexec and somehow early in util/kcrash.cpp actualy look up
the full path to kcrash.cpp
=> handled by kde


>> usr/bin/kdebugdialog
>> Seems to be a user application - append 4 ?
>
> No. kdebugdialog modifies a shared config file: kdebugrc. You only need one=
>=20
> application installed: no need for both from KDE 3 and 4.
>
> I guess this is kdebase/applications instead (not workspace, not runtime).=
>=20
> Except that distribution packagers are HIGHLY encouraged to install it.

Okay. Can be moved to a kde3-kde4-shared package.
=> handled by distros

>
>> 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=C3=A9vin comment=
>  on it.=20
> Ejection should be handled through Solid, which in turn goes through HAL=20
> where available. Where HAL isn't used, it will need to call upon an=20
> executable (/usr/bin/eject), but I don't know how Solid does it.

Let us remove it then ?
=> handled by kde

>> 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 portin=
> g=20
> trouble.
>
> Can't distributions handle this case by using an "alternatives"-style=20
> approach?

Probably, yeah, but I don't completely understand it. What happes when
kde4-in-kde3 apps wants to use kdesu ?

> 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=20
> are not user applications.

Let us move them there, then. I can't find them mentioned except in some
desktop files under khelpcenter/searchhandlers - and in:
khelpcenter/kcmhelpcenter.cpp:  *mProcess << "khc_indexbuilder";
(and of course in the places under khelpcenter where they are built and
installed)
=> kde handled?
or if it is the exact same as in kde
=> handled by distros

>
>> usr/bin/khelpcenter
>> usr/bin/kinfocenter
>> Has khelpcenter changed at all - and does kde3 khelpcenter actually satis=
> fy
>> kde4 ?
>
> No comment from me.

Anyone else got comments?

>> usr/bin/klocaldomainurifilterhelper
>> What is this a helper for?
>
> minicli. I guess we can fix this by not requiring the helper anymore :-)

couldn't it go to libexec also?
It seems to be generated by 
kdebase/runtime/kurifilter-plugins/localdomain/klocaldomainurifilterhelper.c
and used by
kdebase/runtime/kurifilter-plugins/localdomain/localdomainurifilter.cpp:
QString helper = KStandardDirs::findExe(QLatin1String(
"klocaldomainurifilterhelper" ));

Should be straigt ahead libexec at least.

>
>> 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.

I at least can't find it in my kde3 menu.
has kdebase/runtime/knetattach/knetattach.desktop and
kioslave/remote/remoteimpl.cpp:#define WIZARD_SERVICE "knetattach"
=> move to libexec - handled by kde.



>> usr/bin/kjobviewer
>
> Rafael, comments?
>
> This is definitely runtime material, but like the case above, is it on the=
>=20
> menu?
>
> In fact, shouldn't the applications from kdebase/runtime be almost all in=20
> 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=
>=20
> not dropped, it should move to kdebase/applications or further down the=20
> chain.
>
> kprinter -- as a command-line tool that prints PostScript input and shows a=
>=20
> print dialog -- should be replaced with a full-fledged PostScript reader. M=
> y=20
> take is Okular here. It takes imagetops along with it.
>
> In any case, it's not a runtime issue: KDE applications shouldn't be callin=
> g=20
> kprinter, they should use the C++ classes. Are there any cases of KDE=20
> applications using this? (These are, by definition, non-GUI applications an=
> d=20
> KDE isn't in the business of writing them!)

Isn't kdeprint being moved away fnom kdebase around now?
=> already handled in kde


>> 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 nam=
> e.

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


>> usr/bin/ksvgtopng
>> a dev tool, but iirc renamed by dfaure
=> handled by kde already


>> 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=20
> application. Move to libexec.

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?

>> 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: t=
> he=20
> new backend is more powerful and less prone to errors. It can handle saving=
>=20
> and storing better, without corruption.
>
> And it should technically be able to read and write KDE 3 config files too.

Okay. let kde4 "win" here.
=> handled by distros


>> 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=
>=20
> uses them.

According to Riddell, systemsettings does not use them.

> So: if it doesn't, remove them from our installation. Remove kcontrol too, =
> in=20
> case it hasn't been removed. Alternatively, move kcontrol to an application=
>=20
> of its own and those files along with it. Mark it as non-coinstallable -- y=
> ou=20
> 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=20
> matching wherever they are referenced.

Interesting. There is quite some stuff under runtime/kcontrol - and
systemsettings is located under workspace.
=> probably handled by kde (remove)
but I need a bit more clue.

>> 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=
>=20
> per se, but installed by applications. So we have to make sure that the=20
> Oxygen version of them exists and then simply remove the icon from=20
> application.

okay.
=> should be handled by oxygen people
=> can be handled by distros

>> 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=20
> and 4.
>
> (In RPM speech, those are "noarch" packages)

Sounds like Architecture: all in .deb speech.
=> handled by distros


>> usr/share/sounds/KDE_*
>> maybe kde3 versions could be used?
>
> Same as the icons above.
=> handled by distros

/Sune