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

List:       kfm-devel
Subject:    Re: KDesktop: KOMApp vs. KWMModuleApp
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-06-07 16:01:54
[Download RAW message or body]

On Mon, 7 Jun 1999, David Faure wrote:

> On Mon, Jun 07, 1999 at 01:32:58PM +0200, Simon Hausmann wrote:
> > I think we need (Q,K)Application. See KOMApplication::processNextEvent
> > why.
> Ok. I see. Then the problem we have is simply that
> KOMApplication::processNextEvent has to call a different parent
> method (QApplication::processsNextEvent or KWMModuleApp::...)
> we miss Java's "inherited" keyword :)
> Well it's a joke since the inheritance tree changes as well.

Since we're using a template we know our parent, so we should be able
to do
T::processNextEvent
Or? 

> I'm still wondering whether the template is the only solution.
> I mean, KOMApplication doesn't do much in processNextEvent,
> it simply tests quit_now (and quits if true), and this is marked as a hack

Hmmmmmm
The only thing that comes to my mind is to connect to the aboutToQuit()
signal, emitted by QApplication, in order to avoid the processNextEvent
hack.

Another thing is the processNextEvent call in QtDispatcher::run, but we
should be able to "emulate" this via QApplication::processOneEvent() .

> The real stuff is done in exec()...
> Can't we put this in an object constructor and let it do the
> corba-related stuff we need (and let the object be destroyed when the application
> exits, thus releasing the necessary ressources ?) ?

Hmmm
The problem I see is: exec() is a "true" replacement of QApp:exec() . I
mean: We may not enter Qt event processing, but enter the ORB event loop
instead.
We could hack the exec() stuff in an extra class/function, but:
Then we have to change _all_ exec() calls in all apps using KOM...

Ideas?

Well, nevertheless I see your idea, and I would really like something like
KOMDispatcher instead of KOMApplication.

But wait: We'll run into more problems...
QApplication is the next candidate, because it reimplements the
x11EventFilter.


BBBBUUUUTTTTHHH: Why not be tricky by reverting the whole process?
I mean: Currently we put Qt event handling "above" the ORB event loop, but
why not revert it?
There are methods like ORB::perform_work() and ORB::work_pending() , which
should do it.
We could just start a null QTimer and call perform_work() in the timeout
slot!

According to what I saw in the mico sources this should be fine, so this
_COULD_ solve the problem.

But it doesn't help if you have OPApplication and KWMModuleApp :-(

> > But where could we put this template class? ...I'm as clueless as Steffen
> > (because he had the same problem) .
> > I guess creating an extra mini library would be bloat, or?
> Well, if we don't find another solution :
> libkom is the lowest-level library using corba,
> I think libkom would be the right place.
> KOMApplication would become CorbaApp<KApplication>
> and we would also provide CorbaApp<whateverKApplicationChild> this way.

Ok.

Ciao,
  Simon

--
Simon Hausmann       <hausmann@kde.org>
http://www.kde.org/  <tronical@gmx.net>

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