From kde-core-devel Tue Oct 23 08:59:07 2007 From: Sune Vuorela Date: Tue, 23 Oct 2007 08:59:07 +0000 To: kde-core-devel Subject: Re: kde3 kde4 coinstallability take two Message-Id: X-MARC-Message: https://marc.info/?l=kde-core-devel&m=119313000822951 On 2007-10-22, Sune Vuorela 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