stubbing KStartupInfo -- win32 feedback? (was Re: A little review of kdecore & kdeui)

Lubos Lunak l.lunak at
Tue Apr 11 20:10:05 BST 2006

Dne úterý 11 duben 2006 18:28 Benjamin Reed napsal(a):
> On 4/10/06, Lubos Lunak <l.lunak at> wrote:
> >  Non-X11 platforms should implement their own KStartupInfo, with most
> > functions being no-op I'd presume. Is there any problem with that?
> I started doing this, but realized I'd be re-implementing half of the
> "convenience" bits that are already in kstartupinfo.cpp, so I ended up
> just #ifdef'ing it instead.  I'd like some feedback from you and maybe
> anyone involved in the win32 port before I commit it, though.
> It basically chops out anywhere there are actual KXmessages passed
> around, but leaves things otherwise alone, including the
> state-tracking.

 That seems right, although I'd say just creating your own KStartupInfo copy 
with more or less empty bodies should do as well. Just do nothing and always 
claim success.

> Could KXmessages perhaps be replaced by something qt-based
> (signals/slots or some other IPC mechanism)?

 Probably not, because this is not about the IPC but about the whole  
mechanism. Does MacOS X (or Windows) have any concept of launch feedback or 
focus stealing prevention? I.e. if you e.g. launch a new app and continue 
working with another one that's already open, does the new one interrupt that 
when it's ready or does the system prevent that like in KDE/X11?

 If there's nothing like that, you don't need at this at all. If there is (and 
I'm quite sure there is at least in Windows), you need to find out how it 
works. More precisely, if there's any API to control that or if it manages to 
handle things on its own somehow. In the latter case again you don't have 
much to do (although then I wonder what will happen in more complicated cases 
where I haven't found any automatic way in KDE, and I tried quite hard). In 
the case of any API for this, you need to map the functionality.

> Or is it enough to just 
> have the apps think they're able to track this basic state and be done
> with it for now?

 Tracking of the state should be only done by desktop components like kwin or 
kdesktop, you shouldn't need to care about that. Normal apps should just send 
info to these desktop components.

 PS: You might also want to have a look at 
kdelibs/kdecore/README.kstartupinfo, which is pretty outdated by now, but the 
principle is still the same, if it helps.

Lubos Lunak
KDE developer
SuSE CR, s.r.o.  e-mail: l.lunak at , l.lunak at
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic

More information about the kde-core-devel mailing list