From kde-core-devel Mon Oct 22 21:39:02 2007 From: Sune Vuorela Date: Mon, 22 Oct 2007 21:39:02 +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=119308922013379 On 2007-10-22, Thiago Macieira 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