[Kde-java] Qt Designer javaeditor plugin

Richard Dale Richard_Dale at tipitina.demon.co.uk
Thu Jun 26 19:17:47 CEST 2003


Hi Marco

I've been messing around with a javaeditor plugin with Qt Designer today, but 
still haven't quite got it to work completely. The code in 
$QTDIR/tools/designer/designer makes too many assumptions about <form 
name>.ui.h type files only being present in C++ projects. I've attached the 
code anyway - it does have working java code completion now. And it can parse 
java backwards ok.

So I can't really put the javaeditor in the CVS - I was going to put it under 
qtjava/designer/javaeditor. But would you like to put the juic code in the 
CVS under say 'qtjava/designer/juic' - that would be great! - it would make 
the bindings a lot more attractive for KDE 3.2? If you don't have CVS access 
I think you can mail Stephan Kulow telling him what you want to do.

I've added polish() virtual method callbacks to all the QWidget classes in the 
the qtjava bindings in the HEAD branch, and made sure they build against the 
current qt-copy. This code generated from the editbook.ui example should work 
fine in Java now:

/*
 *  Widget polish.  Reimplemented to handle
 *  default data browser initialization
 */
void EditBookForm::polish()
{
    if ( BookDataBrowser ) {
        if ( !BookDataBrowser->sqlCursor() ) {
            QSqlCursor* cursor = new QSqlCursor( "book" );
            BookDataBrowser->setSqlCursor( cursor, TRUE );
            BookDataBrowser->refresh();
            BookDataBrowser->first();
        }
    }
    QDialog::polish();
}

I don't know of any other runtime issues.

On Thursday 19 June 2003 11:57, Marco Ladermann wrote:
> 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.
Yes, that's all you used to be able to do in Qt Designer - I don't remember it 
in the Qt 2.0 version. On the other hand, the <form name>.ui.h files seem to 
be used all over the place in the Qt code, so it looks like Trolltech prefer 
it to the subclassing approach.

> > 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.
I see - perhaps a top level script could convert a <form name>.ui.java file to 
<form name>.ui.xml, and bracket the code with suitable xml tags.

The extension can easily be changed in  languageinterfaceimpl.h:

    QString formCodeExtension() const { return ".java"; }

..to ".xml" or whatever. But it's quite hard to get the plugin to add xml tags 
before and after the java code.

> > 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.
The java bindings have dispose() methods, which allow you to call the 
finalize() method early. So if you added a dispose() method in the generated 
form class, which called the destroy() method in the 'code additions' source, 
then that would would do it. dispose() must be called by the code, it doesn't 
get called automatically like finalize().

-- Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: javaeditor_0.2.tar.gz
Type: application/x-tgz
Size: 25823 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-java/attachments/20030626/381ce7f9/javaeditor_0.2.tar-0001.bin


More information about the Kde-java mailing list