[Mono-dev] Qt anyone?

[BGB]

----- Original Message ----- 
From: ""Andrés G. Aragoneses"" <knocte at gmail.com>
To: <cr88192 at hotmail.com>
Sent: Saturday, February 07, 2009 12:19 PM
Subject: Re: Qt anyone?


> BGB wrote:
>> ----- Original Message ----- 
>> From: "Robert Jordan" <robertj at gmx.net>
>> To: <mono-devel-list at lists.ximian.com>
>> Sent: Saturday, February 07, 2009 1:33 AM
>> Subject: Re: [Mono-dev] Qt anyone?
>>

<snip>

>>
>> oh well, probably most people would not be so compelled by such an idea, 
>> but
>> it is worth a try I guess...
>
>
> Your idea already exists. I don't know about AWT architecture, but a
> current technology that does this is XUL, and I believe Nokia is
> expanding it to add Qt into the mix (currently renders on Cocoa, Gtk,
> and Windows...).
>

so, XUL is accessible from Mono and without involving a dependency on 
Mozilla's code?...

this would be a critical factor (again, I have not looked into this).


it is much like, one could argue, Swing exists, but it doesn't do people 
much good since it exists on the JVM and would have to be ported over... 
(likewise, me not being that terribly fammiliar with Canvas, which I would 
have to look into...).

or Morphic exists, but it is the same situation...


but, alas, something like this would be a good deal of effort defining and 
specifying things, followed then probably by implementing interfaces and 
then later implementing default components, ...


I guess a much lighter-weight and simpler option would just be to do a 
custom C#-based GUI framework based on OpenGL, and blow off the larger 
problems (such as integrating with existing widget frameworks, or trying to 
provide a common frontend API with other frameworks).

but, alas, I mostly develop things in C land anyways, so all this would not 
do me much good, me better off using my existing custom C-based GUI stuff... 
(when I was a good deal younger, I used GTK some, but IMO GTK was far more 
inconvinience and pain than it was worth, and it was much less effort to 
forsake it and draw my own widgets...).


so, in my case (how it is approached):
the app requests input state (keyboard and mouse state);
this is passed to the GUI in a big "update yourself" call (the input is then 
passed to the widgets, which handle whatever input is directed to them);
..

typically, here it does any internal stuff, like other update calls (for 
example: camera, console, world, ...).
then the 3D world is set up and drawn (main scene graph or whatever else), 
..

later on, the app sets up the GL state (glOrtho, ...);
draws any generic (non-GUI) overlays, ...

calls the GUI's "draw yourself" handler, which then recursively tells all 
the widgets to draw themselves, ...
..

(but, alas, this approach is widget-based rather than layer-based, so is 
arguably less ideal...).


but, at least, my GUI stuff is more uniform and functional than my app's 
Scene-Graph support (where it proves problematic to have both a game-like 
"live state" while at the same time allowing a uniform interface to 3D 
modeling tasks, resulting in the creation of different specialized tools for 
different parts of the modeling, animation, mapping, ... process, even 
though the backend code is mostly shared...).


but, oh well, whatever I guess...


> Regards.
>