[PyKDE] KTrader woes?
jbublitz at nwinternet.com
Thu Sep 11 18:53:00 BST 2003
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
> 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.
More information about the PyQt