[Kde-java] Qt Designer javaeditor plugin

[Marco Ladermann]

Am Donnerstag, 19. Juni 2003 10:28 schrieb Richard Dale:
> On Thursday 19 June 2003 08:02, Marco Ladermann wrote:
> > Am Mittwoch, 18. Juni 2003 22:41 schrieb Richard Dale:
> > My idea was to generate a <some name>.ui.xml file to make it accessible
> > by the stylesheets. This would be much more consistent compared to the
> > hybrid approach of the original Qt Designer .
>
> I'm not sure java programmers would want to customise behaviour by writing
> java embedded in xml though - it sounds a bit ugly to me.

Of course, but it is already ugly to work with Java class fragments. From a 
MVC (Model-View-Controller) point of view it is questionable if code for the 
controller (slot) should go in the view class. As an approximation to a real 
MVC implementation one can use the stylesheets to generate the slot methods 
as abstract and code the buisiness logic in a derived, concrete class.

>
> The idea of the .ui.h file was to allow C++ methods to be added to a class
> generated from a .ui file. If there were init() or destroy() methods added
> in the .ui.h, then calls to them are included in the constructor/destructor
> of the generated class.
>
> So the equivalent in Java would be to have a <some name>.ui.java file
> containing additional java methods. When the java class was being generated
> from the .ui file, instead of a include directive for the .ui.h file, it
> would merge to java methods from the .ui.java into the generated class. I
> would have thought XSLT could do that ok - it doesn't sound complicated to
> me.

To my knowledge the only method/function in XSL to refer to external files is 
the "document" (or "fn:doc" in XQuery 1.0 and XPath 2.0) function. But this 
function(s) can only handle XML files. So one has to use non-standard 
extensions to do this.

>
> If a method called init() had been added to the .ui.java file then the
> constructor would call it. Java doesn't have destructors, so destroy()
> doesn't seem to fit in.

If the finalize() method is not an option, one might consider a reference 
queue to which Qt objects are automatically added (in the JNI base or in the 
constructor?) and which does the job of calling destroy before gc.

Marco