[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 11:29:56
[Download RAW message or body]



On Wed, 5 Apr 2000, David Faure wrote:

> On Wed, Apr 05, 2000 at 01:05:37PM +0200, Simon Hausmann wrote:
> > 
> > 
> > On Wed, 5 Apr 2000, David Faure wrote:
> > 
> > > > I did some little testing and changed Makefile.am to put all code into
> > > > libkonqueror (including main() ) and copied libkonqueror.so to
> > > > konqueror.so in my $prefix/lib . That made kdeinit dlopen konqueror.so
> > > > (instead of exec'ing konqueror) .
> > > Didn't you have to change konqueror.desktop too ?
> > > (I thought you had to specify the libname there - unless perhaps kdeinit
> > > figures it out from the app name).
> > 
> > AFAIK kdeinit tries to load app_name.la and falls back on
> > exec( app_name ) if that fails.
> 
> Yup, thought so.
> 
> > > > It might be easily possible that I got the wrong impression, but for me it
> > > > made the startup approx. 2/3 seconds faster.
> > > > 
> > > > Could that be possible?
> > > 
> > > Definitely. Loading all those shared libs takes time, and kdeinit 
> > > frees you from that. Commit :)
> > 
> > There's one problem left:
> > KLauncher uses the Exec field to determine the service's command. This is
> > passed over to kdeinit.
> > 
> > That means we cannot launch libkonqueror, and changing the Exec= entry in
> > konqueror.desktop to libkonqueror seems wrong, or? ;-)
> > 
> > (and we cannot rename libkonqueror to konqueror in Makefile.am, as the
> > "builtin" views link against libkonqueror (and specifiying konqueror.la
> > instead of libkonqueror.la makes libtool bail out)
> 
> hihi - stupid naming problem, heh ? :)

yes ;-)

> > Possible solutions:
> > 
> > 1) Add a second konqueror.desktop (different name) , with
> > Exec=libkonqueror
> > 
> > 2) Hack kinit to also look for appname.la and libappname.la when trying to
> >    dlopen the service.
> 
> 3) Define a konqueror.so which includes main and links to libkonqueror.so

That is what I tried, too, and I get:
automake: konqueror/Makefile.am: `konqueror.la' is not a standard libtool
library name
make: *** [Makefile.in] Error 1

This seems to be related to the fact that we have libkonqueror.la and
konqueror.la, which libtool doesn't seem to like.

Another possible solution: Move the code which is current in libkonqueror
to libkonq and get rid of libkonqueror. (that way we can create
konqueror.la I think)

(it seems...well..strange to me anyway to have libkonq and libkonqueror
:-))

> This is how kdeinit currently intends to find shared libs: they have to
> be the same as the app and to include everything the app includes,
> but we want libkonqueror.so as a normal shared lib too, so it can't
> be the same file. You probably don't want to put a symbol called
> main in a real shared lib (one that apps could link against)...

Yes, you are right

> > > And speaking about konqueror startup time:
> > > it starts the cookiejar on startup. Shouldn't we do that only when
> > > the HTML view is loaded for the first time ? I surely don't need
> > > a cookie jar for browsing my local drive !
> > > Perhaps putting that in KHTMLFactory (whatever it's called) is the answer ?
> > 
> > I 100% agree. Perhaps even kio_http should try to launch kcookiejar
> > itself?
> Hmm, are cookies HTTP or HTML specific ?
> I'd say HTML, but OTOH we don't want cookies in an HTML mail, as
> somebody pointed out... :)

Hmm, I don't know :-) It seems to me that it is HTTP specific, as it's
kio_http which is the cookie client (I can't find any cookie code in
khtml)

But I don't know anything about cookies. I _EAT_ them :-))


Ciao,
 Simon

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