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

List:       kfm-devel
Subject:    Re: kdeinit
From:       Simon Hausmann <shaus () helios ! med ! Uni-Magdeburg ! DE>
Date:       2000-04-05 13:22:34
[Download RAW message or body]



On Wed, 5 Apr 2000, David Faure wrote:

> On Wed, Apr 05, 2000 at 02:14:47PM +0200, Simon Hausmann wrote:
> > 
> > libtool: link: libtool library `konqueror.la' must begin with `lib'
> > Try `libtool --help --mode=link' for more information.
> Tried that ? ;-)
> 
> > make[1]: *** [konqueror.la] Error 1
> > 
> > /me clueless :-)
> 
> Hmm, I couldn't find any relevant difference with, say, kcookiejar/Makefile.am
> which defines a kcookiejar.la, and a binary that links to it...
> 
> Indeed, it looks like a name clash - triggering a bug in libtool ?
> (or some code that is there to avoid stupid mistakes like forgetting
> lib when the lib's name starts with 'lib' :)

It was my fault :-) I forgot -module -avoid-version :-)

(hehe, we were both blind when comparing the Makefile.am's :-)

> > > libkonqueror is the stuff that is used to all konqueror views, right ?
> > > (at least the builtin ones). That's the one we could rename
> > > (say to libkonqcore or libkonqgui)
> > > 
> > > and konqueror.so is just a kdeinit trick, we have to stick to that name.
> > > 
> > > But right, this shows we use shared libs for too many things now ;-)
> > > 
> > > In any case, we certainly don't want to merge libkonq and libkonqueror.
> > > Take kicker, for instance. It simply needs the properties dialog
> > > (which needs KonqFileItem). We surely don't want kicker to link
> > > to ALL the konqueror code (including the mainview, childview, all that stuff)
> > > just for that. Same for kfind, etc.
> > > The "file manager construction kit" concept makes sense. The name of its lib not :-)
> > 
> > BTW, libkonqueror does not contain the mainview, childview code. It only
> > contains the shared stuff, like the Konqueror KInstance, the background
> > dialog for the iconview and the props stuff. (well, see yourself :-)
> Ooops, indeed.
> 
> > I can see your concerns of "bloating" libkonq with konqueror-specific
> > stuff, and I also agree that libkonq is a good name for the file
> > management "kit", but OTOH IMHO libkonqueror (the current one) does not
> > contain any heavy/huge code (which would require lots of relocations,
> > etc.) .
> 
> You're right. Some numbers: here, libkonq is 394K, konqueror is 223K,
> and libkonqueror is 69K.
> And htmlsettings will move out or be removed, propsmainview has nothing
> to do in there (!?!), so we could merge the rest

I don't know about propsmainview :-)

> (propsview, events, bgnddlg, and factory) in libkonq, though only
> konqueror views need those...
> This makes me wonder, for each of those, why would the builtin views
> (iconview,listview) need them and not khtmlpart ?

Because they use the Konqueror instance (for like the .rc file) .
Hmmm, sounds weird :)

> If we defined a factory in iconview and listview, the usual way, we could
> avoid putting konqfactory in libkonq, right ?

Yes, I think so. IIRC the only reason for sharing KonqFactory was to save
memory, but I think that was a stupid idea :-)

> > Anyway, you decide :-) . I don't really care if we keep libkonqueror or
> > not. I'm mostly interested in getting konqueror.la, for a faster startup.
> 
> I suggest you rename libkonqueror to libkonqview and we step by step
> remove stuff from it...

I 100% agree. Let's do it step by step :-)
(no need to rename fortunately :)


Ciao,
 Simon

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