[Kde-bindings] Re: Smoke

Richard Dale Richard_Dale at tipitina.demon.co.uk
Sun Apr 3 11:30:01 UTC 2005


On Sunday 03 April 2005 07:31, Luca Fascione wrote:
> Ashley Winters wrote:
> >--- Luca Fascione <lukes at wetafx.co.nz> wrote:
> >>objects in TCL, and afaik the most used is called [itcl] or [incr
> >>tcl]
> >>(which is the TCL form of saying TCL++) the human name would be
> >>"Incremental TCL"). Anyhow I doubt a full Object system would be
> >>necessary, unless subclassing is a non-avoidable direction in Qt.
> >>(You
> >>don't subclass in GTK, unless you define a new widget or object of
> >>your
> >>own).
> >
> >You're not going to easily escape subclassing in Qt. You can avoid
> >implementing the subclassing logic by writing your custom widgets in
> >C++ and telling Smoke to interface them, but the other language
> >bindings support full inheritance.
>
> Well, implementing a full subclassing mechanism looks like a lot of
> (quite dirty) work, isn't it?
> Oviously custom widgets are to be known to Smoke to work, but then
> again, is it so common to have a custom widget? And if it is, wouldn't
> it be nice to be able to add widgets to Smoke by compiling them in some
> kind of .so file that Smoke can then load and add to its databases?
All the dirty work has been done by the Smoke library already. You just need 
to implement a fairly simple callback from the C++ instance. You find the 
corresponding instance in the target language from a hash table, and test 
whether the virtual method has been reimplemented. 

Here's is an extract from the QtRuby code to do that. getPointerObject(ptr) 
retrieves the ruby instance corresponding the the C++ instance 'ptr'. Then 
there is a call to rb_respond_to() to test if it has been overriden. If is 
has the' VirtualMethodCall c()', actually marshalls the args from C++ to ruby 
and actually calls the ruby method instead of the original C++ one

	VALUE obj = getPointerObject(ptr);
	smokeruby_object *o = value_obj_info(obj);
	if(do_debug & qtdb_virtual) 
	    logger("virtual %p->%s::%s() called", ptr,
		    smoke->classes[smoke->methods[method].classId].className,
		    smoke->methodNames[smoke->methods[method].name]
		    );

	if(!o) {
	    if( do_debug & qtdb_virtual )   // if not in global destruction
		logger("Cannot find object for virtual method %p -> %p", ptr, &obj);
	    return false;
	}

	const char *methodName = smoke->methodNames[smoke->methods[method].name];
	
	// If the virtual method hasn't been overriden, just call the C++ one.
	// Special case open() to avoid a clash with the Kernel.open() method	
	if (	rb_respond_to(obj, rb_intern(methodName)) == 0
			|| strcmp(methodName, "open") == 0 ) 
	{
	    return false;
	}
	
	VirtualMethodCall c(smoke, method, args, obj);
...

In PerlQt it's about as simple as this too.

> I am saying that writing a custom widget in TCL doesn't anycase look
> like anybody would do... Do people actually write widgets in Perl or
> Ruby or others?
Yes, it's very common to subclass widgets or other sorts of classes to make 
minor customisations. But not so common to create entirely new custom widgets 
so often.

> What is good of TCL is that it is all runtime, you can
> in any application just open a console and start typing in commands,
> and/or change parts of your sources and reload them at runtime without
> having to stop execution or anything like that... What you pay for this
> is a little speed (less and less noticeable as time goes by) and support
> for this kind of "hardcore" stuff...
You can do that in QtRuby or PerlQt too. It's very useful to be able to type 
in and execute code while the program is running under the KDevelop ruby 
debugger for instance.

> >>Finally, I don't want to bother both of you guys, so it's fine for me
> >>if
> >>you tell me with whom to dialog from now on :-)
I'm interested, but I don't know anything about tcl - so I can't comment on 
that stuff. I've cc'd this to the kdebindings list - I hope you don't mind.. 
That's the best place for a discussion, then there is a public record, and 
someone comes along with questions about PHP or whatever we can refer them to 
any previous discussions and don't have to repeat.

> >QApplication .app
> >QPushButton .w -text "I think we're it"
> >.app setMainWidget .w
> >.w show
> >.app exec
>
> I was thinking in these lines, actually, like:
>
> qt new QApplication -cmd .app
> qt new QWindow -cmd .w
> set layout [qt new QHBox -cmd .w.layout]
> set button [qt new QPushButton -text "New button"]
> .w.layout pack_start $button
> .w show
> .app exec
>
> This means envisioning the qt command as the only real interface to the
> Qt system,
> then the qt command's "new" method would just return a handle to the
> newly created object.
> In Mark Patton's GTK port this handle would be something like
>
> {QPushButton 0x12345678}
>
> i.e. {classname pointer}, which would give you the ability to perform
> some type checking, if needed.
You need to be able to resolve overloaded methods depending on their types. I 
don't know if tcl has strong typing to enable you to do that


>
> As you can see, my knowledge of Qt is still not deep (btw, can you
> suggest a good book on that?), so sorry for all the GTK specific stuff
> you might see...
Programming with Qt by Mathias Kalle Dalheimer. Or there is another book by 
Jasmin Blanchette, which I haven't seen. The Qt docs are very good, and 
include tutorials.

-- Richard



More information about the Kde-bindings mailing list