[Kde-bindings] ruby bindings

[Germain Garand]

Le Samedi 19 Juillet 2003 00:50, Richard Dale a écrit :
> On Friday 18 July 2003 19:22, Germain Garand wrote:
> > Le Jeudi 03 Juillet 2003 14:05, Richard Dale a écrit :
> > > I adapted the Qt Designer cppeditor plugin for java as 'javaeditor' to
> > > see what could be customised via a Designer plugin. Unfortunately I
> > > found it isn't possible to customise the lists of signal/slot types
> > > displayed to show java,
> >
> > Ah, interesting... I faced the same issues with the perleditor.
> > Now, if there are more and more people interested in having Designer
> > plugins, things could change fast.
> > I've forwarded most important issues/wishlist items upstream ( bug in the
> > DesignerFormWindow::addFunction() interface, isCpp() locks all over the
> > place, need for a language agnostic function/slot dialog, and more
> > generally better access to the MetaDataBase) and so far had good feedback
> > (though *very* slowly).
> > The only stumbling block left in 3.2 is a one and only isCpp() lock, that
> > was most unfortunately forgotten by Marius B. Monsen when he removed the
> > others (so that's another roundtrip through qt-bugs@ :-(( )
>
> Yes I can confirm the isCpp() problem with java too :( - I've attached my
> currentt javaeditor plugin.
>

nice! I'll definetly send a reminder to Trolltech (one full month has passed 
now) since your plugin will have the same unavoidable problem : the isCpp() 
locks in /designer/resource.cpp prevents a correct output of .ui files
(it only contains UI elements, no connections)

it seems their first idea was : if it isn't Cpp, it should handle all the 
signal/slot definitions right in the editor window, so no need to output any 
signal/slot definitions in the .ui file... I think they didn't suspect people 
would start hacking the uic like crazy...

> This was the method that I found to be a bit of a 'let down' too - i
> expected to be able to 'javatize' the C++ type signatures:
>
> QStrList LanguageInterfaceImpl::signalNames( QObject *obj ) const
> {
>     QStrList sigs;
>     QStrList javasigs;
>     sigs = obj->metaObject()->signalNames( TRUE );
>     sigs.remove( "destroyed()" );
>
> 	for ( QPtrListIterator<char> sit( sigs ); sit.current(); ++sit ) {
> 	QString f( sit.current() );
>
> 	// It looks as though the purpose of this method is to allow the C++
> 	// types in the signals to be changed to another language like java
> 	// by editing the strings as below. However, unfortunately it doesn't
> 	// have any effect :-(
<snip>
> }

I think the only purpose of this method was to allow plugins to complete the 
list of signals with custom ones, based on the content of the editor, just 
like it does for functions (see my remark above about what I think was the 
design idea -or lack thereof- behind the present interface)

>
> How signal/slot type signatures should appear in non C++ languages is a
> tricky problem.

definetly

>
> Marco Ladermann has written an XSLT based java juic tool - I could either
> adapt that for ruby, or hack the C++ in puic.

If you should go the puic way, I'd suggest using the CVS version of puic, but 
maybe wait a bit : I've started merging all the latest uic modifications as 
of 3.2... tedious job because I didn't do it for the 3.1 release, so that's a 
double merge. I'm about 95% done.

> OK I'll have a look - I was just trying to only change code in the
> javaeditor plugin, not is the body of QtDesigner

oh, neither do I... I've restrained my patches to about 5 lines of absolutely 
needed modifications, those that just give the plugin interface a chance to 
actually work, and if they don't go in 3.2, I'll be _very_ upset :-/

> And certainly lets get
> rid of 'windows within windows' MDI in QtDesigner for scripting language
> plugins - horrid!!

#include <aol.h>

dear_god_yes_nod_nod()


>
> -- Richard