[Kde-perl] Short term plans

[Richard Dale]

On Thursday 05 December 2002 5:19 pm, Germain Garand wrote:
> Le Jeudi 05 Décembre 2002 00:31, Ashley Winters a écrit :
> > Germain is about to ship a maintenence release, which is good.
>
> Yeah, I've been silent on the list, but I'm working hard on this. I'll post
> a something today describing the current status/change log/todo...
>
> > Afterwards, I want to get as many missing features as possible tacked
> > into PerlQt. I especially want to get overloaded operators working
> > finally, especially for QPoint and friends.
> >
> > Next step is to switch Smoke from being generated by Kaluptus to being
> > generated by a -fdump-t-u to XML converter. This gains us template
> > classes for free (yay!).
What about adding an '-fdump -t -u' as a first pass in kalyptus? It could 
write to the same AST based structure. Then parse the header files and add 
further annotations, such as document comments (important for the java 
bindings) and parameter names.

> As for the XML parser, do you want to go Perl, C or C++ ?
> Having toyed with the Qt XML classes for puic, I have to say they are
> amazing... it might be a good choice ? (even from PerlQt :-P)
>
> G.
>
> > As for coordinating development efforts with other Qt bindings, I've
> > gone from believing that "they should all use Smoke" to "everyone
> > should be using QtC, even Smoke. Too bad it's crippled; let's rewrite
> > it." Once the Qt# people come to their crossroads (trust me, they'll
> > hit a crossroads), I'll Embrace and Extend (tm) whatever they have
> > working at the time for use by Smoke and ParrotQt.
I'd like to confirm I'm carrying on as before anyay - I think the needs of the 
java bindings are slightly different from scripting languages. Nothing wrong 
with XML, but I don't see that it adds anyway that can't already be done with 
the different sort of parse tree in kalyptus. And if you don't parse the 
headers, and just '-fump' you lose stuff. Does XML make it easier to merge 
two or more parse trees derived by different means?

Sorting out better virtual method callbacks is the main priority - I think 
smoke seemed to be pretty good at that -  but it is the trickiest bit. For 
java - just need to generate delegate methods for all possible virtual method 
type signatures, and add calls to them as I do for event handlers now. David 
Faure has added better argument parsing, so I hoping that if I use the method 
generationg code will  be a lot less messy.

-- Richard