[Kde-bindings] Replacing kalyptus

Mauro Iazzi mauro.iazzi at gmail.com
Wed Oct 3 16:41:18 UTC 2007


well, between my keyboard and gmail something happened that destroyed
the last sentences... I'm sorry.

they were:

>Even if you decide to use the moc, I would suggest looking at the
GCC-XML output for an idea of >what to produce (and because lqt would
work on it easily, I admit it :).
>
>Parsing an XML output is a breeze, I know well. I had very little
difficulties and got a code that is >very brief and very simple. I'm
sure it would be a good move to XML in any way. I hope you decide >so.
>cheers,
>
>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.

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.

mauro

On 03/10/2007, Mauro Iazzi <mauro.iazzi at gmail.com> wrote:
> Hi Arno,
>   having used such a system myself I'd like two put my two cents on the table.
>
> I tried to understand kalyptus code, before deciding to use GCC-XML.
> Given that I'm no perl wizard I could not even read that. So it was
> simpler to find another solution.
>
> I also tried using unmodified Qt's moc, to bind the slot-signal
> system, just as QtScript. This worked well, and the result is bundled
> with lqt (in http://repo.or.cz/w/lqt.git though I didn't announce it
> yet because I'm busy at the moment).
>
> Looking at the moc's source I had the impression that transforming it
> into a fully fledged C++ to XML  parser was beyond my possibilities.
> However it seems a viable solution, as the moc is very good (as usual
> from trolltech).
>
> I would like to suggest considering also the possibility to use
> GCC-XML. While it would be an external dependence, I feel it would
> have a lot of pros too.
> First it is developed from the same company of cmake, so that it is
> backed as a project by active developers, though the actual project is
> evolving slowly at this time.
> Second it is already what you would need and is usable right now. I've done it.
> Third, even if it is secondary for now, it would be a great push to
> the development of GCC-XML, and that could benefit other open source
> projects as well and ultimately be a push to merge it into gcc itself
> (where I think it belongs).
>
> Parsing an XML output is a breeze, I know well. I had very little
> difficulties and got a code that is very brief and very simple. I'm
> sure it would be a good move to XML in any way. I hope you decide so.
>
> Even if you deeeeI would suggest looking at the GCC-XML output for a good idea
>
>
>
> On 03/10/2007, Arno Rehn <arno at arnorehn.de> wrote:
> > Am Mittwoch 03 Oktober 2007 17:15:22 schrieb Arno Rehn:
> > > Hi,
> > >
> > > Since it's pretty obvious that kalyptus is merely maintainable [...]
> > Er, that should be a 'barely'...
> >
> > --
> > Arno Rehn
> > arno at arnorehn.de
> > _______________________________________________
> > Kde-bindings mailing list
> > Kde-bindings at kde.org
> > https://mail.kde.org/mailman/listinfo/kde-bindings
> >
>



More information about the Kde-bindings mailing list