[Kde-bindings] Qyoto + ARGB... is becoming painful for me.

[Arno Rehn]

Am Freitag 22 Februar 2008 14:41:08 schrieb Richard Dale:
> Hi William
>
> On Friday 22 February 2008 09:31:42 you wrote:
> > Hello I'm William Lahti and I'm working on a project using your
> > Kimono/Qyoto bindings. I have to say that the bindings are very good,
> > quite speedy and stable so far but I'm having one problem: when I
> > started the thing I was *really* looking forward to ARGB windows and I
> > find that  actually using them with Qyoto is a nightmare. You might
> > know that to use ARGB windows on Qt looks like this:
> >
> > 1. open X display
> > 2. find an ARGB visual
> > 3. new QApplication (display, argbVisual, argbColormap)
> >
> > And that seems to be the only way to do it...  well as far as I can
> > see neither Qyoto nor Smoke cover this constructor, which makes things
> > very painful. Before I knew this I figured I could subclass
> > QApplication and call be base "dummy" constructor, then do the Qyoto
> > setup steps like Qyoto_init, CreateProxy (), and finally
> > interceptor.Invoke() but that seemed to be a lost cause because
> > evidently there is only one overload of the QApplication constructor,
> > so my differing 'signature' argument was no-op.
> >
> > I've looked from top to bottom at all the Smoke/Qyoto sources I could
> > find at the Kimono site.... but I could not manage to get Smoke to
> > generate proxy methods for the X11 constructors (at one point I was
> > sure I was supposed to add 'Q_WS_X11' to qtdefines). I tried using new
> > (ptr) QApplication() but GDB informed me that the reason it segfaulted
> > was that the GC handle IntPtr that it passed was 0x3.... obviously not
> > where the data is stored. I found out that libqyoto does the *real*
> > allocation... but due to the lack of API exposure this doesn't really
> > help me.
> >
> > Do you have any tips or pointers for me so I could get this going? If
> > I manage to get something non-hacky working I'd be glad to send you a
> > patch but lack of Smoke/Qyoto documentation hasnt helped. Thanks for
> > any time you can give me, and thanks for making these wonderful
> > bindings so C# guys like me can get in on the Qt4 fun.
>
> Pleased to hear you're using the Qyoto bindings and they work ok. But is
> using X11 specifics calls is tricky. We really don't want to have platform
> specific things in the Qt dll. Or the various dlls that will map onto the
> Qt libs (QtCore, QtGui etc) in the next release of Qyoto when we split the
> Smoke lib and corresponding ddls up a bit.
>
> On the other hand, QApplication is a partial class and it might be possible
> to add the X11 specific stuff in an extra source that wouldn't be included
> in the standard dll. The symbols in the Smoke library aren't exported, and
> so I don't think you can easily create an instance of 'x_QApplication' in
> your own code, or add extra constructors.
>
> But instead you should be able to create an ordinary QApplication with an
> X11 specific constructor and use that. It will mean that you won't be able
> to override QApplication virtual methods in your C# code, but maybe you
> don't need to do that anyway.
>
> Someone recently wanted to do things with event filters and XEvents from
> QtRuby and use QApplication::x11EventFilter(), but that is also missing
> from the Smoke lib.
>
> I'll cc this mail to the kde-bindings list in case anyone there can discuss
> it.
At least there will be more exported C/C++ functions to be used by extensions 
or new modules. So it will be really easy to implement what Richard 
suggested, e.g. a C function that creates an application with the appropiate 
constructor, wraps it in a C# instance and returns a GC handle to it.


-- 
Arno Rehn
arno at arnorehn.de