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

List:       kde-bindings
Subject:    Re: [Kde-bindings] Replacing kalyptus
From:       "Mauro Iazzi" <mauro.iazzi () gmail ! com>
Date:       2007-10-03 17:00:05
Message-ID: bb4b23320710031000pb84cbd3gdd56925401ce6ffd () mail ! gmail ! com
[Download RAW message or body]

gccxml can accept commandline define like -DFOO="bar". Marking the
attribute "gccxml" will make it visible to it. I still do not know how
this would come out in the xml, but this is the easy bit.

mauro

On 03/10/2007, Arno Rehn <arno@arnorehn.de> wrote:
> Am Mittwoch 03 Oktober 2007 18:41:18 schrieb Mauro Iazzi:
> > in the meanwhile I read of the signal/slot question. It is true that
> > gccxml discards the Qt tags, so they are not avaliable by the binding
> > code, but this could be overcome by using attributes.
> But how can we mark a method with such an attribute without modifying the
> source?
>
> > However I feel that this is not a big issue in any way, because with
> > lqt I can bind QMetaObjects as well, and obtaining those I have all
> > the Qt reflection at my disposal. So if I know the signal (slot) I
> > need at compile time I can write it, If not I can use QMetaObjects,
> > avoiding the duplication of meta-informations in the runtime.
> Projects like Qyoto need the information which methods are signals/slots when
> the sources are generated. So the information should be somehow ready for the
> generator.
>
> --
> Arno Rehn
> arno@arnorehn.de
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings@kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
>
_______________________________________________
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]