[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: libkio & libksycoca
From:       Lubos Lunak <l.lunak () sh ! cvut ! cz>
Date:       2001-11-28 8:46:24
[Download RAW message or body]

On Wed 28. November 2001 01:22, Waldo Bastian wrote:
> job.cpp:2486 says:
>
>    If source isn't local and target is local, we ignore the original
>    permissions Otherwise, files downloaded from HTTP end up with -r--r--r--
>    But for files coming from TAR, we want to preserve permissions -> we use
>    default perms only if from remote The real fix would be
>    KProtocolInfo::inputType(protocol) == T_FILESYSTEM, but we can't access
>    ksycoca from here !
>
> Wouldn't it be a solution to merge both libksycoca and libkio into libkio,
> mark libksycoca obsolete and provide a dummy libksycoca for backwards
> compatibility?
>
> I would almost be inclined to say that we should move all of
> "kdecore/kdeui/kio/ksycoca/kfile/kparts" into a single libkde since this is
> all pretty much generic functionality. That way we could also use e.g.
> KMessageBox in kdecore for error-reporting (when kapp is available).
>
> This is also motiviated by the fact that when you don't have kdelibs
> sources installed it is far from clear which libs you should link against,
> since most include files end up in $KDEDIR/include (only libkparts uses an
> include dir of its own, libkio uses include/kio for _some_ of its include
> files, but not all)
>
> Cheers,
> Waldo

 Actually, I was about to propose something similar, just not as drastic. I'd 
like to merge some libs into one where it doesn't really make sense to have 
separate rather small libs. Could somebody please say why each of these libs 
is a separate lib and what exactly is it supposed to do (I e.g. don't really 
understand the difference between libkio and libksycoca, and why we have 
separate libkfile).

[seli@seli seli]$ ldd /opt/kde3/bin/kdeinit | grep kde
        libDCOP.so.4 => /opt/kde3/lib/libDCOP.so.4 (0x40000000)
        libkparts.so.2 => /opt/kde3/lib/libkparts.so.2 (0x40039000)
        libkfile.so.4 => /opt/kde3/lib/libkfile.so.4 (0x4006c000)
        libksycoca.so.4 => /opt/kde3/lib/libksycoca.so.4 (0x40112000)
        libkio.so.4 => /opt/kde3/lib/libkio.so.4 (0x401c6000)
        libkdeui.so.4 => /opt/kde3/lib/libkdeui.so.4 (0x4028f000)
        libkdesu.so.4 => /opt/kde3/lib/libkdesu.so.4 (0x40475000)
        libkssl.so.4 => /opt/kde3/lib/libkssl.so.4 (0x40497000)
        libkdecore.so.4 => /opt/kde3/lib/libkdecore.so.4 (0x404cc000)
        libkdefx.so.4 => /opt/kde3/lib/libkdefx.so.4 (0x40dd0000)

 I'm not that sure putting everything in libkde is a good idea, but having 
kdecore(=DCOP+kdecore), kdeui(=kdeui+kdefx), 
kio(=kio+ksycoca+kssl+kdesu+kfile), kparts(=kparts) should solve some of the 
problems above and IMHO wouldn't cause any real trouble (I mean, is there 
anybody who links to kssl without linking also to kio?). Also, the reason why 
I myself came to this idea is that this should save some KiB memory per app 
and probably also improve startup time a bit. Memory saved would be >=8KiB 
per dropped standalone lib, so it's >=48KiB saved.  It's not that much, but 
as I said, this arrangement of libs wouldn't IMHO really change anything.
 As for the message boxes in kdecore, I think it would be probably better to 
do something like this :
kdecore:
void kde_error() { fprintf(stderr,"Ooops!\n");}
kdeui:
void kde_error() { KMessageBox( "Ooops!" ); }
 We already depend on this ELF feature somewhere anyway, don't we? I'm afraid 
one big lib would cause too much trouble :(.

-- 
 Lubos Lunak
 llunak@suse.cz ; l.lunak@kde.org
 http://dforce.sh.cvut.cz/~seli

[prev in list] [next in list] [prev in thread] [next in thread]