Qt# Info
He recopilado toda la información referente a Qt# y como lo prometido es deuda, he aquí toda la información para todos aquellos que quieran colaborar con nosotros y unirse al Qt-Developers-Team.
De Marcus <mathpup@mylinuxisp.com>
Enviado Miércoles, Marzo 10, 2004 11:00 pm
Para Adlair <adlair.cerecedo@prodigy.net.mx>
Asunto Qt# info
De
Fecha Wed, 10 Mar 2004 20:46:50 +0000
Para
Asunto Re: Qt#
On Wednesday 10 March 2004 4:01 pm, you wrote:
> I finally found time to get the 0.7.1 version of Qt# working last night,
> are there any nice simple problems you’d like me to look at as a way of a
> gentle introduction to the code?
Basically, things are at a transition point. We have the “old” or “current” —
I’m not sure what to call it. It’s the stuff that’s in QTSHARP-0_7_1_BRANCH.
I branched that off from QTSHARP_0_7_BRANCH because I wasn’t sure if I want
to keep the qmake-based build system. The way that I rigged it to build C#
code isn’t terribly elegant to me. (I’m thinking about writing a csant-like
build system myself.)
In any case, that version relies on QtC, which has not been maintained.
Unfortuantely, the Kalyptus-generated QtC source files still require much
hand-editing to be compilable, which is probably why QtC is incomplete and
has not been kept up.
Also, the core of Qt#, which is Qt.dll, has its source files built from XML
using a module for Kalyptus. Unfortunately, Adam (who started Qt#)
lost/deleted/erased the only copy of that module.
Back when there were several of us working on this, I was working on a
hand-written parser for C++ headers while Adam and Nick were working on a
binding generator called BINGE. Since then I’ve realized that it’s too darned
hard to parse C++ and produce XML, so I’ve switched over to using Doxygen.
I’m not sure that I want to use BINGE because the code seems to be something
of a pain to deal with. So I’ve been working on my own solutions. Let me tidy
up the code a little bit, and then I’ll show it to you. I’m afraid it’ll be a
little confusing and overwhelming right now.
Also I’m going to forward a couple emails to you, but there are some
corrections that should be made. There is also a mailing list, which isn’t
very active: qtcsharp-list@lists.sourceforge.net
> Also I think the INSTALL file instructions need correcting, it talks about
> configure ; make; make install, where as I think you need to do qmake ;
> make ; make install.
I committed a change to INSTALL in CVS recently that corrects that issue.
I’m thinking about releases a new version very soon. The 0.7 version and the
0.7.1_BRANCH in CVS are not much different except that the build system has
been modified not to require Pnet’s csant, and the directories have been
restructured.
By the way, Qt# can be built with Pnet version 0.6.2, which is the latest
official release, but the XML classes in their CVS have been broken for quite
a while since the last release. I’m told that they plan to release their next
version soon and without fixing their XML classes.
The main things that have changed since these messages is that I’m not sure
about salvaging BINGE’s code. Also, Wade is working on updating the website.
I’ll send you some more info later today or tomorow.
Marcus
—– Mensaje original —–
De Marcus
Para qtcsharp-list@lists.sourceforge.net
Asunto Qt# C interface library; movement to Doxygen
I have done some work, research, and documenting lately. These might not sound
terribly exciting because the product isn’t usable code, but hopefully they
will contribute to that.
C Interface Library
My main work has been on an extensible replacement for QtC. QtC is generated
by Kalyptus, which is written in Perl, and I have no desire or aptitute for
Perl. Furthermore, the Kalyptus-generated headers are not directly compilable
by GCC but rather require a great amount of hand-tuning. (Presumably this
could be done by another Perl script.) Also, many functions present in Qt#
(in as DllImport’ed extern methods) are missing from QtC, which creates a
large number of annoying warnings.
The replacement C library will use the same XML description of Qt as the C#
code-generator. The C generator (which is currently called CGen for lack of a
creative name) can correctly generate compilable C code for the QString and
QPushButton classes.
Why a C Glue/Interface Library is Needed on GCC Platforms
I have concluded that some sort of interface between C# and C++ is necessary.
I feel compelled to write it to justify to myself and others why we cannot
simply dispense with the cumbersome concept of an intermediate layer.
If something similar VS.NET’s Managed Extensions for C++ existed for GCC,
a single layer might be written. For GCC, this would require a front-end for
managed-extensions and a back-end capable of emitting ECMA assemblies
containing managed and unmanaged code. Because GCC would “know about'’ Qt
classes (since it is a C++ compiler) and because it also knows how to create
managed classes, many aspects of development would be simplified.
Given the current situation, there at least 4 reasons why an intermediate
layer is needed. First, there is no way to create a new instance of a C++
object from outside C++ unless the C++ library provides an appropriate
function. There is no obvious way to determine how much memory to allocate
for a given C++ object, so even if it were possible to call a C++ constructor
directly to initialize the object, allocating the object in the first place
seems impossible.
Second, C++ compilers use name-mangling to avoid duplication of symbols when
several classes define the same method and when overloaded methods are used.
This mangling is platform dependent. It is possible to use system-specific
utilities to produce a list of mangled and unmanagled names and then match
them up to create a conversion table. So this is more of an annoyance than an
an outright dead-end.
Third, when optimization is specified, C++ compilers frequently inline any
methods those bodies are defined within the class scope (and possibly other
methods as well). Moreover, if every invocation of a method is inlined, some
compilers do not by default emit an out-of-line copy for the method.
Fourth, in several cases, it is desirable to intercept C++ virtual methods and
possibly redirect them to managed code. (This is how Qt# “overrides'’ of
C++-defined methods could be implemented.) Without an intermediate layout,
the only option would be platform-dependent hacking of virtual-method tables.
Movement to Doxygen
A little over a year ago, I wrote parser to handle the minimal amount of C++
needed to cover Qt’s header files. I had examined several existing tools and
found them unsuitable for various reasons. After much gnushing of teeth and
attempting at extending the parser to handle enough of C++ for all Qt’s
headers, I finally re-examined Doxygen. Doxygen is capable of outputting a
variety of formats, including XML. Although its XML format is substantially
different from the current format that my original parser created, being
freed from the burden of having to continue to develop my own little parser
has led me to justify changing formats.
I’m in the process of changing the code for my C interface generator to handle
Doxygen’s format. This will take a bit of time as I adjust but I believe that
this is the best way to go for now.
—————————————————————————————–
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
______________________________________________________________
Qtcsharp-list mailing list
Qtcsharp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qtcsharp-list
—– Mensaje original —–
De Marcus
Para qtcsharp-list@lists.sourceforge.net
Asunto Qt# Help Wanted
I would like to get some help with Qt#. I realize that it is hard to attract
people when there is so little visible forward movement, but there are some
things that could be done to help. Remember that there is a semi-stable
version of Qt# available for download at http://qtcsharp.sourceforge.net
and that it includes examples. I am working on creating a new and better
version of Qt#, but the version available for download is usable.
Some tasks, which vary widely:
1. Update the FAQ on the website
2. Update the website itself to give it more organized appearance. Obviously,
opinions on aesthetics will vary. I believe that the “menu” on the left is
cluttered with too many choices. Nested menu choices or a separate
documentation page might help. Some pretty graphics would also be nice.
3. Write a guide on Qt# for Qt/C++ programmers. The basic idea is the explain
the differences, including capitalization patterns, QString versus
System.String (C# “string”), unicode, C++ 0 versus C# null, enumerations,
namespaces, and so forth. As I recall, the PyGTK would be a good place to
look for hints on this.
4. Continue development on Nick and Adam’s BINGE (Binding Generator), which
generates C# bindings from an XML description of the API. The source code is
in the CVS HEAD branch. Since I’m moving the C Generator to Doxygen, BINGE
should probably move to Doxygen as well. If analyzing, improving, and
rewriting BINGE is too daunting a task, an alternative would be to develop an
original tool to generate C# code. This took could share code with the C
Generator.
5. Write applications, tests, examples, bug reports, comments, or questions.
There’s no need for much formality at this stage. Just post to the mailing
list or email me.
Feel free to join #qtsharp on irc.freenode.net
Marcus
—————————————————————————————–
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
______________________________________________________________
Qtcsharp-list mailing list
Qtcsharp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qtcsharp-list
—– Mensaje original —–
De Marcus
Para qtcsharp-list@lists.sourceforge.net
Asunto Qt#, Portable.NET (aka Pnet), Build System
Just to let people know, the latest versions of Portable.NET (Pnet) are not
capable of producing a working Qt#. The problem lies with bugs in Pnet’s XML
modules. The solution is to switch to Mono: http://go-mono.com
I have also removed the dependency on Pnet’s csant build tool for Qt#.
If you have an earlier release of Pnet with non-broken XML, and you want to
build Qt#, you can still do so by running qmake CSC=cscc CLI=ilrun
and then running make.
—————————————————————————————–
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
______________________________________________________________
Qtcsharp-list mailing list
Qtcsharp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qtcsharp-list
