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

[Arno Rehn]

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.

> 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.
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?

-- 
Arno Rehn
arno at arnorehn.de