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'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 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. 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). Jim _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
