[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-bindings
Subject: [Kde-bindings] Common work for Qt4 bindings
From: Eric Jardim <ericjardim () gmail ! com>
Date: 2005-09-10 2:18:39
Message-ID: 432ec6c5050909191824c47c19 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi,
I just finished reading Richard's article:
http://wiki.kde.org/tiki-index.php?page=Language+Bindings+Talk
and realised that we have a lot of points in common.
He is right when he says that we have enough information in the C++ headers,
but we have not a smart C++ parser to generate everything to you. And that
manual generation is not good if it will bring a lot of headache.
On the other hand, I don't think Smoke will solve everyones problem, but a
"smart" C++ parser, that generate a intermediate XML (or some descriptive
structured data), that is common for all bindings would be good for
everyone, including Smoke.
The main problem is that each language has each own need, and being very
general would lead us to create boring bindings. The bindings needs to be
attractive to each bind language. Python binding need's to be "pythonic",
Ruby bindings needs to be "rubish" ;)
What I am saying is, intead of just creating a super-library (Smoke) we
could create some rules that each binding should follow, in term it still
get usable not only for one binding, but for other things also.
In my case, I expect my Python extended QObjects to work back with embedded
C++ code, and still be integratable with QtDesigner. This would avoid us to
create new "QtDesingers". Besides, we must face that "uic" is *dead*. We now
have QFormBuilder that acts like libglade for GTK. But, differetly,
QFormBuilder can be extendend to generate our extended bindings objects. And
don't forget about (the evil) threads. People love them, even when they
don't what they are doing.
I still don't now what would be the definitve solution for this, but if we
don't do it now and do it right, people will not use it. One of KDE weakness
is poor binding. I admit Gnome bindings are not perfect, but are much better
that KDE's.
An interesting thing to do is a survey of the "bindable" languages and needs
of each of them. With this, we can think better how Smoke would be like,
good for everyone. If not, just a few will use it and everybody will loose.
That's what I am saying, we have to find this "optimum point" for everyone.
I think the smart C++ parser, that recognise Qt macros (Q_PROPERTY,
Q_INTERFACE, Q_CLASSINFO, Q_ENUM, ...) would be a start for everyone, with
or without Smoke.
I know that exists a c++ parsers called "gccxml" but it is not a complete
parser (it does not read templates). But maybe it is a start:
http://www.gccxml.org/HTML/Index.html
There is also the Boost.Spirit project, that is a very interesting way of
creating parsers (with c++ templates):
http://spirit.sourceforge.net/
There is another project called synopsis, that is used for doc generation,
but have bigger goals:
http://synopsis.sourceforge.net/
Well, maybe I am talking too much ;)
What do you think of it.
What is being done right now in sense of common work?
Thanks,
[Eric Jardim]
[Attachment #5 (text/html)]
Hi,<br>
<br>
I just finished reading Richard's article: <br>
<a href="http://wiki.kde.org/tiki-index.php?page=Language+Bindings+Talk">http://wiki.kde.org/tiki-index.php?page=Language+Bindings+Talk</a><br>
and realised that we have a lot of points in common. <br>
<br>
He is right when he says that we have enough information in the C++
headers, but we have not a smart C++ parser to generate everything to
you. And that manual generation is not good if it will bring a lot of
headache.<br>
<br>
On the other hand, I don't think Smoke will solve everyones problem,
but a "smart" C++ parser, that generate a intermediate XML (or some
descriptive structured data), that is common for all bindings would be
good for everyone, including Smoke.<br>
<br>
The main problem is that each language has each own need, and being
very general would lead us to create boring bindings. The bindings
needs to be attractive to each bind language. Python binding need's to
be "pythonic", Ruby bindings needs to be "rubish" ;)<br>
<br>
What I am saying is, intead of just creating a super-library (Smoke) we
could create some rules that each binding should follow, in term it
still get usable not only for one binding, but for other things also.<br>
<br>
In my case, I expect my Python extended QObjects to work back with
embedded C++ code, and still be integratable with QtDesigner. This
would avoid us to create new "QtDesingers". Besides, we must face that
"uic" is *dead*. We now have QFormBuilder that acts like libglade for
GTK. But, differetly, QFormBuilder can be extendend to generate our
extended bindings objects. And don't forget about (the evil) threads.
People love them, even when they don't what they are doing.<br>
<br>
I still don't now what would be the definitve solution for this, but if
we don't do it now and do it right, people will not use it. One of KDE
weakness is poor binding. I admit Gnome bindings are not perfect, but
are much better that KDE's.<br>
<br>
An interesting thing to do is a survey of the "bindable" languages and
needs of each of them. With this, we can think better how Smoke would
be like, good for everyone. If not, just a few will use it and
everybody will loose.<br>
<br>
That's what I am saying, we have to find this "optimum point" for
everyone. I think the smart C++ parser, that recognise Qt macros
(Q_PROPERTY, Q_INTERFACE, Q_CLASSINFO, Q_ENUM, ...) would be a start
for everyone, with or without Smoke.<br>
<br>
I know that exists a c++ parsers called "gccxml" but it is not a
complete parser (it does not read templates). But maybe it is a start:<br>
<a href="http://www.gccxml.org/HTML/Index.html">http://www.gccxml.org/HTML/Index.html</a><br>
<br>
There is also the Boost.Spirit project, that is a very interesting way of creating \
parsers (with c++ templates):<br> <a \
href="http://spirit.sourceforge.net/">http://spirit.sourceforge.net/</a><br> <br>
There is another project called synopsis, that is used for doc generation, but have \
bigger goals:<br> <a \
href="http://synopsis.sourceforge.net/">http://synopsis.sourceforge.net/</a><br> <br>
Well, maybe I am talking too much ;)<br>
What do you think of it. <br>
What is being done right now in sense of common work?<br>
<br>
Thanks,<br>
<br>
[Eric Jardim]<br>
_______________________________________________
Kde-bindings mailing list
Kde-bindings@kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic