[Kde-bindings] Re: kdebindings/qtruby (silent)

[Richard Dale]

On Saturday 02 August 2003 14:46, Alexander Kellett wrote:
> On Wed, Jul 30, 2003 at 01:45:21PM +0100, Richard Dale wrote:
> > On Wednesday 30 July 2003 15:03, Alexander Kellett wrote:
> > > so, wrt the methods problem (i.e, multiple methods with same
> > > name and different signature), is that likely to be fixed
> > > soon? (assuming that its not already fixed?) it would be
> > > really nice to be able to create popupmenus ;-)
> >
> > Yes, it should work - I haven't tried popups yet. If you have a problem,
> > then the method that does the matching is this one in Qt.rb:
> > 		def argmatch(methodIds, args, i)
>
> oh. aah. this is fixed with your kde cvs import,
> attached is a app using it. maybe interesting,
> doesn't do much yet though :)
>
> > There is some perl code halfway down the method, I haven't converted to
> > ruby yet:
> >
> > 				elsif argtype == 's'
> > ..
> > 				elsif argtype == 'a'
> > ..
> >
> > So a useful thing to do would be to convert it to ruby - I hadn't got
> > round to reading about how ruby reg exp pattern segmenting works yet.
>
> wow, those regexps are wierd. i'll try to
> figure them out later tomorrow evening, its
> just code after all :)
What I did was to put print statements in PerlQt (in Qt.pm) and QtRuby and run 
the same test example in both ruby and perl, and then you just have to make 
sure it does the same thing as perl.

> > Yes, top of the to do list, is writing a to do list :).
>
> hehe ;-)
>
> > The original RubyQt bindings needed both a require and
> > an include, but when I looked at the gtk bindings they
> > just needed a require.
>
> a interesting. to tell you the truth, i like the
> ruby-ish ness of the Qt:: namespace sans the Q prefix
> on the objects them selves. it is very nice that the
> PerlQt documentation should prove to be a good beginner
> doc for new qtruby programmers, so, i'd say stick with
> mirroring PerlQt personally.
I think it probably shouldn't be doing the eval of an include statement in the 
C code - I'll have another look at that - because I was calling init() rather 
than Qt::init(). I think you would only use 'include Qt' if you didn't wan't 
to use Qt:: prefixes, require Qt should still work.

	// Do package initialization
	rb_funcall(qt_internal_module, rb_intern("init"), 0);
Would "Qt::init" work without the include?

> > Do the slots and signals declarations 'look right'?
>
> yes. though noticed a bug. you can't have two slots
> declarations, can't recall if it overwrites or just
> doesn't work at all though.
Well spotted! I wasn't sure if it was possible that a class could be parsed 
multiple times, and the slots/signals lists would keep getting bigger. So the 
easiest thing was to just overwrite, the code is at the end of Qt.rb:
	
	def signals(*signal_list)
		meta = Meta[self.name]
		if meta.nil?
			meta = MetaInfo.new(self)
		end
		meta.signals=(signal_list)
	end

So maybe try appending to the signal_list (and slot_list too), and check in 
the fix if it works ok. PerlQt has a boolean called 'changed' which means 
reset everything in the meta object - something similar might be needed.

> > <snip some already answered q's>
> >
> > How do I get the name to appear on the window when a app is running like
> > PerlQt does?
>
> i'll give this a try tomorrow.
Probably adding the script name to ARGV in the new_application C function.

> > Adapt puic to create a rbuic tool (I was going to do that next I think
>
> juic looks quite well done. haven't checked fully but
> seperation between language and "parsing" looks fairly
> complete. only problem is, i hate xslt :), but, i'd
> like to learn how to make a simple xslt processor with
> ruby. so maybe i'll take a look at writing the ruby
> replacement for bin/juic :)
I think the juic is interesting stuff, but I think the priority with QtRuby is 
getting it moving, so adapting puic is fastest - I started doing that.

> > Yes, the marshalling code would need another two actions like DCOPtoVALUE
> > and DCOPfromVALUE, and I think it should fit in quite nicely - see
> > handlers.cpp - just bigger case statements. If you look at the class
> > hierachy, nearly everything is a subclass of Marshaller - we'd need new
> > classes called 'SendDCOP' and 'ReceiveDCOP' or similar.
>
> those are actually all marshalled with qtextstream
> iirc, so, it should be fairly easy. 
Yes, subclass the classes in handlers. Add extra case statements for the DCOP 
actions, and fall through to the default part of the switch and call the 
superclass in QtRuby which has the 'vanilla' marshalling actions:

    switch(m->action()) {
      case Marshall::DCOPromVALUE:
	{
	}
	break;
      case Marshall::DCOPtoVALUE:
	{
	}
	default:
	{
//		call super with the action to marshall it
	}

> i'm wondering
> how much work it is to get working kde bindings
> using kalyptus/smoke in its current state?
Yes, I'm interested too.. I'd like to call the KDE extension 'Korundum' ie:

require 'Korundum'

a = KDE::Application(ARGV)
..

So that would go under kdebindings/korundum.

http://www.science.uwaterloo.ca/~cchieh/cact/applychem/alumina.html

:)

-- Richard