[PyKDE] Re: Panel Applet Problem

[David Boddie]

On Thu, 18 Sep 2003 00:26:33, Jim Bublitz wrote:

> On Wednesday September 17 2003 22:47, Troy Melhase wrote:

> > On Wednesday 17 September 2003 21:21, Jim Bublitz wrote:

> > > but if kicker starts them automatically they run under
> > > kicker's pid), and David has identified at least one
> > > possible fix. Unfortunately that involves hacking kicker.
> >
> > can't you do the double-fork unix trick and thus end up with a
> > unique pid?

I considered that you might try to create an appletproxy in the library
that runs the Python applet but haven't looked at that yet.

> I'm not sure at the moment - doing it in the Python part of the
> applet would make writing applets more complicated and a little
> weird, so I don't like that. kicker loads a .so file (the same
> for every applet) which in turn loads Python and the applet, so
> forking that might be possible. It's still necessary to return a
> pointer from the actual (Python) applet to kicker though, so it
> gets a little messier.

I need to look at how its external applet loader does this. You may be
able to perform the same trick in your loader library.

> > i have a real lack of understanding of many things
> > unix-posix-whateveritscalled, but i thought the double fork
> > produced a process detatched from any console (terminal?) and
> > with a unique pid.
>
> Another possibility is looking at how kicker loads "trusted" vs.
> "untrusted" applets. I believe that's where the appletproxy
> loader comes in, and it might be possible to force/trick kicker
> into using that (that's how loading takes place when you use the
> kicker menu, I believe). That probably turns out to be pretty
> similar to your suggestion too.

The "are we starting up" check short-circuits this. That's why I had to
hack kicker. I don't even know if kicker uses the concept of trusted applets
anymore (in 3.1) - I couldn't find any way of configuring it to distinguish
between applets in this way.

> There might be some way (parameter, putting applets in a
> different location, ??) to alter the loading process too - I'm
> just not familiar enough with it at the moment to know. I
> haven't really looked at the kicker code much (just the basic
> applet loading code).

The main action occurs in kdebase/kicker/core/pluginmanager.cpp where:

In PluginManager::createAppletContainer :

    A call is made to
    PluginManager::trustedPlugin - This determines whether it should "trust"
                                   the applet based on whether it is in its
                                   list of trusted applets. Unfortunately,
                                   the loadingPolicy variable short circuits
                                   this for a panel which is starting up.

    If the plugin is trusted (always on startup, it seems) then an
    InternalAppletContainer (container_applet.cpp) is created, otherwise
    an ExternalAppletContainer is created.

I suppose that it might be possible to try and transplant the code from this
latter class's constructor to Jim's panel applet launching library.
Specifically, these lines might be adapted:

    // init QXEmbed
    _embed = new QXEmbed( _appletframe );
    connect ( _embed, SIGNAL( embeddedWindowDestroyed() ),
	      this, SIGNAL( embeddedWindowDestroyed() ) );

    KProcess process;
    process << "appletproxy"
	    << QCString("--configfile")
	    << info.configFile()
	    << QCString("--callbackid")
	    << objId()
	    << info.desktopFile();
    process.start(KProcess::DontCare);

    connect( this, SIGNAL(alignmentChange(Alignment)),
             this, SLOT(slotAlignmentChange(Alignment)) );

The ExternalAppletContainer appears to act as an intermediary between kicker
and the external process, communicating over DCOP rather than directly using
signals like the InternalAppletContainer. Presumably, it would be useful to
transplant much of the ExternalAppletContainer to the launching library.

Of course, you might need some way of checking which of these containers is
being used to avoid too many layers of indirection. On the other hand, you
might not really care about the overhead; how bad can it really be?

David