[PyKDE] KTrader woes?

[Jim Bublitz]

On Thursday September 11 2003 06:54, Sundance wrote:
> > Nah - you got a segfault. Just not a very delicate warning.
> > :)
>
> Yeah. You'd think it would at LEAST have the grace of saying
> something like, "Ooh, something bad happened, sir, I'm gonna
> have to crash, but beforehand I wish to beg you to accept my
> apologies! *blarg*"
>
> This being said -- any remote chance that we could be able to
> install a signal handler, so that we can tell the user,
> "Whoops, something bad happened in method <blah> of class
> <doubleblah>. Did you think of creating a KApplication
> instance before calling this?" or something like that?

Probably not. KDE, as you've found out, only emits SIGSEGV in 
this instance, and that doesn't localize the cause.  The other 
problem stems from the way PyKDE is done - I don't "write" 
PyKDE, it writes itself. I'd have to figure out which of 636 
classes/9653 methods need this kind of error reporting and how 
to create and install the code automatically (otherwise it 
becomes a major maintenance nightmare - there's a new KDE about 
every 3 months).

Lastly, it's likely to add overhead on *every* call - your 
problem was with a static method call for example, not 
constructing an object with no KApplication instance running.

> And then there's KApplication itself, where checking that the
> first argument is a non-empty list ought to be relatively
> trivial, no...? Or does the way sip works prevent such checks
> at the Python level?

> Or maybe it's just not worth it at all. I don't know. *g*

At the moment it doesn't appear doable. That could change.

> > Seems pretty difficult - my guess would be the most
> > appropriate route would be a tutorial/better docs/more
> > example programs - that's in the works, but takes a while to
> > accomplish.

> That, and at least a basic knowledge of how to do things, and
> how not to. I suppose the right way to go about this would be
> to define a set of 'typical' apps (I'm thinking, for instance,
> small but potentially useful tools such as a 'universal'
> viewer based on KParts, a RSS newsticker panel applet, maybe a
> Konqueror sidebar plug-in showing info about the selected
> files based on their type, etc) and tutorialize their coding.

What PyKDE has as templates is much lower level than that at the 
moment, and probably will remain that way for quite a while. I 
do regularly solicit contributions here.

> Does that sound like a good idea? I mean, for the latter two,
> is extending KDE with Python stable enough that it can be done
> at all? I know there were threads this summer about problems
> related to panel applets...

Panel applets are in 3.8rc2, which is on sourceforge now. The 
first question on panel applets came up over a year ago, and a 
lot of the work on it was done by someone other than me.

At some time in the future, you should be able to write panel 
extensions, io slaves, KParts and other similar stuff from PyKDE
as well.

> If at all possible, I think I'll give it a try once I know
> more about PyKDE. It really deserves to be better known!

> > The KDE
> > libs classref docs are pretty good, even if C++ oriented.
> > You find them at http://www.kde.org in the documentation
> > section, along with a lot of tutorial stuff.

> Yeah, I know, I've already started browsing the lot of them.
> Way interesting stuff, and very impressive. KDE is even better
> under the hood than it looks!

I really appreciate the feedback. While at the moment it doesn't 
appear there's much that can be done about it realistically, 
there are a number of things that got into PyKDE 6 months after 
someone brought them up here, just because it became apparent 
how to implement the suggestion easily. In fact I'm working on 
some stuff related to docs right now that follows from a 
discussion here a few weeks ago (and something I've wanted to do 
for quite a while before that) - it just became apparent how to 
do it easily/automatically within the last week or so.

Jim