stubbing KStartupInfo -- win32 feedback? (was Re: A little review of kdecore & kdeui)
Lubos Lunak
l.lunak at suse.cz
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 suse.cz> 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 suse.cz , l.lunak at kde.org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
More information about the kde-core-devel
mailing list