dcop auto-overuse

[Chris Humphries]

Most home-came-from-windows-joe-users will probably be running
kde or gnome, most likely kde. there is no point that i can see,
other than for those that do not run kde and run kde apps, to
spend all this time tweaking code for this issue.

If you are running something light, like ratpoison, you can
start the dcopserver before hand, or just wait the couple of
seconds. it is just a couple of seconds, and kde apps run best
in the environment they were designed for.

it is like complaining that a geo prism gets stick in off-road,
when it wasnt designed for that. sure you can put chains or 
something of the like on the tires, but is that something that
should be done automagically? 

optimizing this situation would be best left to the user, in my
opinion. most users run kde apps in kde, the environment they
were designed to work best in. seems like a "port" or something
of the like to hack the code to work outside kde, well in the
way described in this thread.

why run kde apps in a lite x environment anywho? seems ironic.
kde apps, though alot of them are nice and designed well, alot
of them are relatively slow. in lite x environments, such as
with ion and ratpoison, seems like rxvt, mutt, and links/dillo/lynx
fit the bill more instead of konsole, kmail, konq. 

My opinions,
Chris Humphries
BurstNet Technologies, Inc.
Software Development Lead


On Wed, 2003-12-10 at 09:07, Oswald Buddenhagen wrote:
> On Wed, Dec 10, 2003 at 01:14:26PM +0100, Lubos Lunak wrote:
> >  This is just begging for trouble. If there will be dozens of places
> >  where one will have to do this manually, at least in some of the
> >  places this will be wrong.
> > 
> i think you're exaggerating the issue ... synchronization with a
> dcopserver startup in the background (and for that matter, even
> launching one) can be done transparently in the dcop classes - just like
> it is now, only further down the invocation graph.
> 
> >  I think a sufficient solution for this could be one or both of: 
> > - clearly document and make people know the fact that they can run
> > 'kdeinit' manually and then all daemons will stay in memory and KDE
> > apps will start quickly
> >
> i suggest a reality check on this idea ...
> 
> > - make longer the interval between the time when dcopserver detects
> > there's no KDE app running and the time when klauncher shuts down
> > kdeinit+daemons (it's only 10 seconds now, kdelibs/dcop/dcopserver.cpp
> > DCOPServer::removeConnection()).
> > 
> that's pretty much pointless without libCrystalBall. ;) the only viable
> solution would be not terminating at all till the x connection breaks
> down, but as a kde-nonuser i'd absolutely hate that.
> it wouldn't help with first startup anyway (and that matters for a first
> impression when somebody tries a new app).
> btw, the delayed shutdown at it is now sucks big time if you run an app
> from the command line.
> 
> greetings
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.kde.org/pipermail/kde-optimize/attachments/20031210/4d40372f/attachment.pgp