[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bindings
Subject:    Re: [Kde-bindings] What should I be doing?
From:       Richard Dale <Richard_Dale () tipitina ! demon ! co ! uk>
Date:       2003-08-10 19:03:30
[Download RAW message or body]

On Sunday 10 August 2003 00:24, Ashley Winters wrote:
> No, I'm not looking for suggestions. It's a rhetorical question. :)
>
> In my ongoing effort to develop something which will allow
> PerlQt/KDE/et al. to continue on after I become homeless and/or
> convicted of theft/fraud/embezzlement, I've been working on a way to
> reorganize Smoke to be a universal binding interface. So far, it seems
> to be working out alright. 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.

Also java needs the class hierarchy and methods in a .jar file to compile 
against. I'll be using kalyptus to generate the .java sources at first, but 
for later versions everything apart from comments can be derived from the 
gcc/XML parser info. If we use the to the 'magic URI' technique then I think 
that it's less important to have the comments in the sources than it was. 
Otherwise, you parse C++ headers, generate .java, parse .java with javadoc to 
produce finally produce inflexible html documentation. Magic URIs do that 
sort of thing better, and allow a lot more functionality which wasn't 
possible before.

>
> So, what should the future hold for Smoke? Well, KDE for one thing. The
> Smoke library was designed to be extensible with a separate KDE library
> interface in the same program as Qt, but the code parsers were not. In
> order to do that, it's probably best to use the gcc parser to output
> XML into a machine-readable format so as to extract the interface from
> the compiler itself.
>
> 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.

> So, we need a unified naming system to identify every
> class/method/constant in a library. Amazingly enough, people have
> invented a thing called URIs for just that sort of purpose. Each method
> is a "resource" which is identified by a "URI" and accessed through a
> "mirror" library using a "smoke" scheme/protocol/whatever.
>
> What does it mean? It means everything gets a unique URL, and that URI
> can be used to call functions. Like so:
>
> smoke://qt@libqt-mt.so.3.1.2/QWidget/mapTo;QWidget%2a,const+QPoint%26
>
> Lets break that down RFC2396 style.
>
>     smoke://
>
> Our resource is not accessible through http or any other existing
> internet protocol. The Smoke library provides a distinct protocol of
> marshalling arguments and passing them to functions, as well as a few
> other perks. That is why we have our own URL "scheme".
>
>     <library>@<filename>
>
> The @<filename> is only used when trying to access the library.
> Internally, each library is just referenced as smoke://qt/ or
> smoke://kdecore/ and the filename is "known" through some
> as-yet-unspecified mechanism. On Windows, it would be
> smoke://qt@qt.dll/ of course.
>
>     /<path>/<identifier>;<arguments>
>
> The <path> is the URI-translated absolute name of the class/namespace
> being referenced. All instances of :: in the fully-qualified name are
> replaced with / along the path. ::std::strlen(const char*) would become
> /std/strlen;const+char%2a.
>
> The <arguments> is the encoded argument list of the method. The
> characters ',' and '+' are reserved for use as argument separator and
> space character, respectively. The rest of the argument literal should
> be URL-encoded. For complex template types in argument lists, do this:
>
>    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.

> Note that ',' is only to be used to separate actual function arguments,
> and must be escaped within template parameters!
>
> In order to call a function, you need one hell of a URL. Try this:
>
>     smoke://qt@libqt-mt.so.3.1.2/QWidget/
>     mapTo;QWidget%2a,const+QPoint%26?return=QPoint
>
> Everything before the ? specifies the specific resource (method) to
> call, and everything after the ? specifies the various parameters as to
> how to go about doing it. If you want to override a virtual method,
> perhaps you use ?virtual=override. If you want the size of a QWidget,
> 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?

> About now the question of ``Why?'' may be on your minds. In particular,
> why add all that horrifying complexity and string manipulation to the
> small and lean Smoke? Well, first thing is that the URI scheme is just
> a representation of the Smoke interface, and I don't expect it to be
> used at runtime (although the facilities to do so will be available).
> The reason it's important is to allow each method to be described as a
> resource through RDF. Simply having URIs for everything doesn't
> describe the relationships between them. QWidget has to know it's
> derived from QObject and QPaintDevice.
>
> That's where RDF comes in. It will be the way in which the various
> relationships are specified. Sadly, RDF is highly verbose and n3 is
> somewhat cryptic, but here's a psuedo-example of the information which
> would be available through RDF. Only a tip of the iceberg.
>
> QWidget inherits (QObject, QPaintDevice)
>
> QWidget/topLevelWidget returns (pointer to QWidget)
> QWidget/topLevelWidget thisPointer (pointer to (constant QWidget))
> QWidget/topLevelWidget documentation "Returns the top-level widget for
> this widget, i.e. the next ancestor widget that has (or could have) a
> window-system frame."
>
> QWidget/QWidget constructs QWidget
> QWidget/QWidget returns (pointer to QWidget)
> QWidget/QWidget parameters ((pointer to QWidget, default of 0),
> (pointer to C-type-char, default of 0), (C-type-unsigned-int, default
> of 0))
So maybe arg names would be available here, and the problem above would be 
solved.

> Of course, all this information would be automatically pulled from
> gcc's parser, but having a universal identifier for "QWidget"
> (specifically, smoke://qt/QWidget) across every library makes things
> flow together much more smoothly.
> 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?

> 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.

> 2. replicate the current Smoke method of switch()-based method
> resolution
Although java is static, I'll actually end up doing dynamic despatch by 
matching the java arg types against the C++ SMOKE possibilities - a very 
similar approach to PerlQt and QtRuby. It won't be done at .java code 
generation time.

> 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.

> 4. steal some JIT code and generate wrapper functions on the fly using
> method #1
I can't see a need for this one - unsuitable for a 'low bugdet epic' like 
SMOKE in my opinion. And likely to be hard to debug and go wrong a lot..

> How libsmoke is implemented in the future is not my concern; however, I
> personally plan to implement #3.
>
> Method #3 requires the creation of a set of mirror libraries, one for
> each library interfaced. This mirror library would wrap every function
> in the library and make it available by its URI (I plan to md5sum the
> URI and use that as the symbol name).
>
> This mirror library would be generated using the RDF description of the
> resources available in the target library. Ideally, there will be a
> central repository of Qt/KDE library RDF models which will know how
> various #define flags affect the interface (like QT_NO_TRANSLATION) and
> would change the mirror library appropriately.
>
> I'm not sure how the actual code generation will work. I don't
> particularly want to make gccxml.org's program a requirement to compile
> PerlQt (only a requirement to develop) since it's out-of-date,
> hard-to-fix, slow-to-progress, and it doesn't run cleanly on my system.
> Instead, I'm considering just creating my own RDF specification of Qt
> and KDE in the kde.org CVS using gccxml and shipping that, while
> requiring people to install Redland RDF if they want to expand it.
> *shrug*
>
> Implementation is a whole other issue which I'll tackle while I'm doing
> it. Comments? Suggestions? Offers to do all this for me? Job? Money?
A kde version of SMOKE mk 1 would be really good, so we could carry on doing 
language adaptors which would still be forwards compatible api with SMOKE mk 
2. Then if I came across any problems with mk 1, we would be able to fix it 
in mk 2 as it was developed.

Otherwise, everyone will have to wait for SMOKE mk 2 before we can get 
anything moving.

> Until the next time James Michael DuPont provides me the imspiration to
> embrace-and-corrupt one of his ideas, farewell. :)
>
> Ashley (Got Smoke?) Winters
Nice! I tried 'Go SMOKE!' but I think 'Got Smoke?' may be better.

-- Richard
_______________________________________________
Kde-bindings mailing list
Kde-bindings@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread]