[Mono-dev] Qt anyone?
cr88192 at hotmail.com
Fri Feb 6 22:00:03 EST 2009
----- 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?
>> oh well, probably most people would not be so compelled by such an idea,
>> 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
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...
More information about the Mono-devel-list