kde3 kde4 coinstallability take two

[Sune Vuorela]

On 2007-10-22, Sune Vuorela <nospam at vuorela.dk> wrote:

So what needs to be handled by kde and not by distros - and what is
still unclear:


>

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

The following two are kinfocenter related, according to riddell, so
moved from "other places" in the emails
>>> usr/share/desktop-directories/kde-information.directory
>>> etc/xdg/menus/kde-information.menu

>>> 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/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"


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



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

Some of the icons are actually kdeprint icons which probaby got killed
with kdeprint.
I guess we need to poke oxygen people for the rest.

/Sune