[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: kde3 kde4 coinstallability take two
From: Sune Vuorela <nospam () vuorela ! dk>
Date: 2007-10-22 21:39:02
Message-ID: slrnfhq63m.ntj.nospam () sshway ! ssh ! pusling ! com
[Download RAW message or body]
On 2007-10-22, Thiago Macieira <thiago@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: // argum> ent 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.
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>
> 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.
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é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.
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
> trouble.
>
> Can't distributions handle this case by using an "alternatives"-style
> 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
> 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>
> 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. M> y
> 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
> kprinter, they should use the C++ classes. Are there any cases of KDE
> applications using this? (These are, by definition, non-GUI applications an> d
> 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
> 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
> 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.
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>
> uses them.
According to Riddell, systemsettings does not use 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 -- y> ou
> 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.
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>
> 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.
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
> 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic