[PyKDE] KPart problem

[Phil Thompson]

On Tuesday 26 July 2005 8:26 am, Jim Bublitz wrote:
> On Monday 25 July 2005 14:03, Roberto Alsina wrote:
> > >> Well, that works fine and I get a terminal, but I run into another
> > >> problem.
> > >>
> > >> To use the TerminalInterface-specific functionality, you need a
> > >> TerminalInterface like this:
> > >>
> > >> TerminalInterface* t = static_cast<TerminalInterface*>( p->qt_cast(
> > >> "TerminalInterface" ) );
> > >
> > > If TerminalInterface has Python bindings, sip.cast () might work. If it
> > > has a
> > > DCOP interface, that might also work.
> >
> > This seems to be the best path, but I think it doesn't. Any chance of it
> > being added in the future? I know this is pretty much the outer fringes
> > of the bindings, and I would probably be the only one using it.
>
> The konsole DCOP interface doesn't seem to do what you need.
>
> I should have looked at kdelibs in the first place rather than just
> checking to see if TerminalInterface was already in PyKDE. I don't believe
> TerminalInterface actually generates any code - I couldn't find it in any
> lib. It has no methods that aren't pure virtual and no base class. I'm not
> completely sure that sip would do anything useful with a class of that type
> (by itself), since there's no underlying lib to link to as far as I can
> tell.

SIP (current snapshot anyway) should do the right thing. A corresponding 
Python class will be created which can be passed as an argument and 
sub-classed - it just can't be instantiated.

> It is, however,  the abstract base class for konsolePart in kdebase. Since
> you're creating a konsolePart in the first place, it wouldn't seem to be a
> problem to do bindings for konsolePart and use that instead of
> TerminalInterface - it inherits the TerminalInterface methods but
> additionally is also a QObject. In that case, the cast would be unnecessary
> - the subclass would seem more useful.
>
> I don't think there'd be any problem with bindings for konsolePart, unless
> the TerminalInterface base class causes a problem - doesn't seem it would
> though. It'll probably take longer to add it to the build machinery for
> PyKDE than to actually do the bindings. konsolepart.h isn't in the
> kde3/include hierarchy, so I need to supply the .h file as part of PyKDE,
> but that might make things easier if I do run into a problem (I can modify
> the .h file if needed). It would probably be easier to make it part of the
> PyKDE kparts module than to make it a standalone module. I'll probably hide
> TerminalInterface altogether in PyKDE and just expose konsolePart.
>
> I'll see if I can put something together in the next few days.
>
> Jim

Phil