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

[Arno Rehn]

Am Samstag 01 März 2008 20:03:03 schrieb 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.
Oh, I forgot to mention that: I changed kalyptus to make every class partial, 
not only those that are explicitly listed. This makes it easier to have even 
the nested classes in a seperate file. The partial classes don't create 
problems so it should be ok.
Originally I wanted C++ namespaces to be converted to C# partial classes, too, 
so that the C# API would more resemble the C++ one (e.g. that you could write 
Kimono.KIO.SomeMethod() ), but that lead to the gmcs crash we talked about a 
few weeks ago. Now there is an extra class for the namespace methods if there 
are any. So you have to write Kimono.KIO.KIONamespace.SomeMethod() if you 
want to access a method that's in the original C++ KIO namespace. This 'new' 
naming scheme is not applied to the Qt classes to keep the old API and old 
code working.

-- 
Arno Rehn
arno at arnorehn.de