[email protected]
[Top] [All Lists]

Re: stubbing KStartupInfo -- win32 feedback? (was Re: A little review of

Subject: Re: stubbing KStartupInfo -- win32 feedback? was Re: A little review of kdecore & kdeui
From: Lubos Lunak
Date: Tue, 11 Apr 2006 21:10:05 +0200
Dne Ãterà 11 duben 2006 18:28 Benjamin Reed napsal(a):
> On 4/10/06, Lubos Lunak <[email protected]> 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: [email protected] , [email protected]
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/

<Prev in Thread] Current Thread [Next in Thread>