[Kde-bindings] Qyoto ARGB windows using C++ QApplication hack: crashes

[Richard Dale]

On Saturday 01 March 2008 18:00:21 Arno Rehn wrote:
> Am Samstag 01 März 2008 18:37:10 schrieb Richard Dale:
> > On Saturday 01 March 2008 10:46:05 Arno Rehn wrote:
> > > Am Samstag 01 März 2008 09:08:46 schrieb Richard Dale:
> > > > On Friday 29 February 2008 20:42:22 Arno Rehn wrote:
> > > > > Am Freitag 29 Februar 2008 19:43:07 schrieb Richard Dale:
> > > > > > On Friday 29 February 2008 17:59:11 Arno Rehn wrote:
> > > > > > > Am Montag 25 Februar 2008 19:47:53 schrieb William Lahti:
> > > > > > > > I still think it is perfectly acceptable for Qyoto to provide
> > > > > > > > access to the X11 constructors themselves--- that wouldn't
> > > > > > > > preclude using Qyoto on another platform any more than using
> > > > > > > > QX11Embed would..... QX11Embed and numerous other X11 only
> > > > > > > > oddities are already provided in Qyoto so I just don't see
> > > > > > > > why we need to ignore quite possibly *the* most interesting
> > > > > > > > X11-specific feature out there.......
> > > > > > >
> > > > > > > I most admit you got a point here... Maybe we should re-think
> > > > > > > about this.
> > > > > >
> > > > > > William's idea of pulling out all the X11 specific stuff into
> > > > > > subclasses like QX11Application seems good to me. And then put
> > > > > > them all in one X11 specific dll, so that the other pure Qt dlls
> > > > > > will be the same on all platforms.
> > > > >
> > > > > We could also put the stuff into the normal assembly, but create
> > > > > some #if's and thus only compile the code if Q_WS_X11 is set.
> > > >
> > > > Yes we could, and I did suggest that to William when we were chatting
> > > > about it on irc, but he said then the dlls wouldn't be identical
> > > > across platforms. Would that affect the code that we compile against
> > > > those different dlls, and would it need recompiling against each
> > > > slightly different set of dlls? Maybe not - I'm not sure about what
> > > > the rules are. So I prefer the subclassing scheme best.
> > >
> > > I just randomly commented out some code of the Qt classes and
> > > recompiled it. t14 (compiled against the old code) still works. So I
> > > believe you don't have to recompile against the changed assembly. You
> > > don't have to recompile your assemblies if you update Mono itself, too.
> > > It would be kind of funny if you had to.
> >
> > OK, it doesn't sound much of a problem compared with BIC problems in C++.
> > I know there are complicated rules in Java about what you can and cannot
> > change in a library which I never quite understood. I still prefer the
> > sub-classing scheme I think because the pure Qt dlls are then
> > cross-platform, and there is no possibility of mixing up a dll that was
> > built with X11 support and one which wasn't.
>
> Well, another possibility would be to simply include the X11 stuff in the
> assembly. If you're on Windows, simply don't use the X11 specific
> calls/classes. If the methods won't be called there won't be an error or
> crash.
I don't know if platform specific dlls are regarded as problem by mono/c# 
programmers. As long as the code you write and compile against the qyoto dlls 
is platform independent, then maybe it isn't really a problem. By the time 
the C# code is generated the original C #ifdef's have been lost and it 
wouldn't be possible to know which methods were X11 specific. So kalyptus 
would have to add a 'X11-only' property to those methods.

Someone needs to work on wrapping Display, XEvent etc, there is more work 
there than adding extra x11 method calls to qyoto.

> > Another thing I've been meaning to ask is how does the smoke2 C# code
> > generation compare with the trunk. I'm a bit concerned that they are
> > diverging now you've been working on the KDE classes. Have you brought it
> > up to date with the code generation in the trunk, and the branch was done
> > quite a while ago? I assume the modular smoke2 doesn't require the c#
> > code to be a different - is that right?
>
> The kalyptus code for generating smoke2 is nearly up-to-date and only
> contains the changes for a modular smoke. I haven't transferred the
> QT_NO_CAST_TO_ASCII fix you commited yesterday yet, but otherwise it should
> be up-to-date.
That's good news. I read in one of your commits about generating a lot of 
partial classes for kde/kimono, and I remembered adding support for 
generating nested classes in the same c# source file, and I wondered if we 
were moving in different directions.

> The C# code doesn't need any changes to work with Smoke2, per se. However
> I've introduced some fixes to make the KDE classes compile. This doesn't
> affect the Qt C# stuff, though.
> Tomorrow I'll look through my code for any bugfixes and will transfer them
> to branch. Should I port them to trunk, too, or will the whole smoke2 thing
> be moved to trunk soon anyway?
Yes it should be moved soon. But maybe we should do a Qt 4.4 monolithic smoke 
release for both qtruby and qyoto before the merge. I am adding some more qt 
4.4 classes to qyoto at the moment once I have fixed some code generation 
issues.

Neither of us are writing blogs about this stuff (eg qt webkit support, 
modular smoke, plasma c# bindings), but it is really newsworthy I think. I 
will try to start writing blogs soon anyway. Your commits do get mentioned in 
the commit digest. What is happening on the qyoto site in the forums and so 
on, I haven't been paying attention?

-- Richard