[Kde-bindings] What should I be doing?

[Ashley Winters]

--- Richard Dale <Richard_Dale at tipitina.demon.co.uk> wrote:
> On Sunday 10 August 2003 00:24, Ashley Winters wrote:
> > The Ruby/Qt bindings look very functional, and Richard's idea
> > for integrating Java/Qt with Smoke looks entirely
> > feasable to me.
> Yes, the only problem with SMOKE/Java is that you can't dynamically
> add signal methods to a java class. I'll need to use the current
> QtJava java slot/signal proxies, and special case any methods
> with actual or implied slot/signal args. But then I don't want to
> see C++ types in the connect statements, so I would have needed to
> special case C++ -> Java slot/signal type signature 
> translation anyway.

*ahem*

Might I propose something? :)

Okay, here's my thought. How does one declare a signal in Java? Chew on
this.

class Foo inherits Bar {  // whatever. I don't know Java
    protected Signal signalSomething;
    public Slot foo;
    Foo() {
        signalSomething = new Signal(...);  // dunno how to do this
        foo = new Slot(slotFunction);  // or something?

        // now we do a connect...
        signalSomething.connect(someobject.someSlot);   // easy!
    }
    public void doSomething() {
        signalSomething.emit(bleh);    // emit our signal
    }
}

:)

Please place all donations in the cookie jar on your way out.

Will this may every object hugely giant thanks to all the stub
Signal/Slot objects which will be inherited from superclasses? Yes. So
what? It's too beautiful to ignore. *sniff*

> > However, each Smoke library attempts to be a self-contained unit
> > containing its own "meaning" of every class. The smokekdecore
> > library would have its own dataset entries for QObject and
> > friends, even though it wouldn't provide an interface for them.
> > This imprecise duplication of information leads to a coordination
> > nightmare and a Tower of Babel type situation when attempting to
> > communicate a simple thing like "QWidget pointer" between kdecore
> > and kdeui and qt.
> I didn't know about this problem. I thought it all came down to
> deciding how to allocate the base offsets for the various lookup
> tables in each library, by leaving plenty of space in between each
> of the ranges allocated.

No. Each library has no insight into the numbering scheme of another.

There is a mapping from classnames to numbers internally which makes
things happy.

QWidget => 1
QObject => 2
QPaintDevice => 3

Internally, smoke only references the numbers, but every time you
recompile, the numbers (presumably) change. For two libraries to
communicate something like "QWidget pointer" the plan is to have them
convert the number back to a string, pass that string to another
library, and then convert the string into a number again using the
other library's mapping. A tower of babel indeed. It was a convenient
solution at the time, though.

> >    func(const foo<bar::baz<int,const char*> >&, int)
> >    func;const+foo%3cbar%3a%3a%3cint%2cconst+char%2a%3e+%3e%26,int
> Ah, but for Objective-C and Smalltalk we'll need the argument names
> as part of the api, so that virtual method callbacks work. And what
> do we do about ugly arg naming conventions like Hungarian? Yuck,
> yuck! Bad enough in C++, but in Smalltalk it doesn't look too good
> at all.

That scheme is only for C++. The only requirement is that every
function be given unique identifier. For C, it's perfectly reasonable
to have smoke://c/strlen to access strlen(const char*) in libc, even
though it has arguments. The extra gobbledegook is to provide a
globally unique identifier in C++, which makes heavy use of function
overloading. If argument-names are required for objc, then let it be
so!

Also, languages probably need to be specified in the URI. Like:

smoke://DBI:perl/DBI/connect

As for retrieving argument names from the C++ in order to create
matching ObjC functions, you can do that. The URI itself may contain
information, but it will be unnecessary to ever parse that URI to
understand it. In fact, that URI could just as easily be smoke://123456
so long as that number had the information tied back to it as to
name/class/arguments. Which it will, through the information scheme I'm
cooking up. However, my scheme is better for debugging and showing as
the location bar in konq. Also, this way I don't have to worry about
having a central numbering authority for every time a function is
added. :)

> > perhaps you use smoke://qt/QWidget?info=sizeof or something. I
> dunno.
> > It's yet to be specified.
> Is that 'qt/QWidget' or 'qt/Widget' in  there, do we need the extra
> Qs?

Again, it's just a globally unique identifier (which means it's
qt/QWidget). It doesn't mean anything about how it's represented in the
target language. Feel free to chop off the Q when binding it. :)

> > As for implementation, there would no longer be separate
> > smokeqt/smokekde libraries. There would be a single libsmoke
through
> > which any library would be accessed. It could be implemented in 
several
> > ways:
> But what about people who only want to use the Qt part?

PerlQt => libmirrorqt => libsmoke
PerlKDE => libmirrorkde => libsmoke

where => is 'requires' in the RPM hell sense.

> > 1. create the mangled C++ symbol names from the URLs and call 
> > through that way
> I don't like mangled C++ names, and they aren't very standard. I 
> believe MS encode the access into the mangled name which might
> mess up calling protected methods via smoke.

I agree 100% there.

> > 3. wrap every method in a C function through a
> > libmirrorqt/kdecore/kdeui/etc library
> I've been having a look at the HBasic code. It currently uses QtC to 
> wrap Qt, so it might be a good candidate for this approach. I
> think you need to build a description file mapping every basic
> method name onto the Qt equivalent. I was very impressed with
> HBasic, and it would be nice if SMOKE mk 2 could cater for it.

I hadn't heard of HBasic before. I will look at it.

I've sort of backed away from using gccxml.org's program entirely.
*sigh*

I'll let you all know what I ended up using after I end up using it, k?
:)

Ashley Winters

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com