kicker the catter

getting back to development is nice. very nice. kicker is in shreds on one of my machines. the non-KDE app button dialog has a nice, spiffy new (standard) look to it. and i'm a few steps closer getting away from the "main" panel being a hard-coded fact-o-life. loading applets via appletproxies will also likely be hitting the bit-bin, after discussion with John Firebaugh and others. its a nice idea, but causes it's own problems while not providing a complete solution anyways (e.g. kicker still crashes due to the bad applets. look at all the BRs on it!). i must also say that smooth zooming icons look so much nicer than icons that jump from small to big (assuming you've got the right icon sizes around in the first place!).

kjots is also in tatters as i rework the data classes to be independant from the UI and ready for a nicer file format. kscd needs some work after the last few rounds of patch management on it. nx stuff is asking for my eyes. kiosktool has seen some lovin', and hopefully Waldo will be kind on my patches. almost feeling like the good ol' days again.

Vancouver beat Calgary in game one of their divisional playoff series. it's heating up to be a pretty painful series for all involved, methinks. i don't have a TV in the house anymore (by choice), which means i'll just have to catch it at the pub. aw, shucks!


What if there are other aspects of appletproxies being in separate processes that are useful?

The IMApplet I have in kdenonbeta/kimproxy represents a single IM contact per applet, and each has its own DCOP interface, to receive contact status changed DCOP signals. I'm not sure how it would behave in process, and the 'load trusted applets internal' option has gone missing. Although this example could be rewritten, there might be other non-unique applets that depend on being in their own process.

What are the problems the appletproxy causes?

By Will Stephenson at Thu, 04/08/2004 - 19:55

the problems are primarily painting and geometry management related. not to mention the extra overhead.

but the appletproxy binary itself won't be disappearing, just its use as the default loading mechanism of new applets into the panel. to prevent recursive crashing it will have to delay writing the changed config out until some time AFTER the applet loads successfully (which is the next thing i need to do, actually =).

so you will still be able to use the proxy if you mean to, and it will still be there to make debugging applets a less tiresome affair. sorry if i gave the wrong impression =/

as for the "load trusted applets internal" stuff ... i have no idea why/when that went away, but i know it was a while ago ... of course, these days if you say "trusted applet" to your average geek they are likely to think "cryptographically signed and DRM'd away" ;-)

By Aaron J. Seigo at Thu, 04/08/2004 - 20:21