[Mono-dev] Qt anyone?
cr88192 at hotmail.com
Fri Feb 6 20:40:56 EST 2009
----- 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?
> Daniel Morgan wrote:
>> On a different subject, I wonder if someone would dare replace the
>> glib and other dependencies in mono with qt. Then create clr
>> bindings to qt. With these bindings, you could re-write mono using
>> the clr bindings to qt. Now, that would be interesting.
> Can you elaborate on why glib should be replaced?
I can think of why it should be replaced, but seriously not with Qt...
> For systems that don't support glib or where glib is undesirable,
> mono's eglib could be used instead, which is really tiny, BTW.
oh, I had not known of this one...
maybe then I could get mono to build...
> A large part of mono applications is already relying on glib
> (as part of gtk/gtk#/gnome), so adding just another heavy dependency
> is not an option IMO. Not to speak about having to deal with 2
> message queues, C++, license issues (Novell won't be able to
> re-release the runtime under a non GPL based license anymore).
as I see it, eliminating dependencies is the best.
(sorry if all this is uninteresting or already exists, I have not
investigated all this...).
IMO, I would much rather people abstracted over the whole GUI issue,
providing a generic API which would plug into whatever underlying GUI was
available and it was told to use (and could multiplex the GUIs, unify
message queues, ...).
this could then be compared with AWT or similar, where AWT can go through
Win32/GDI, GTK, Cocoa, or custom, ... (I could compare it to Swing, but I
had largely stopped using Java well before there was Swing, and so have not
really investigated how it works...).
the main difference though is that it would be preferable if the framework
had a separate "frontend" and "backend", so that it would be possible to
swap out the internal machinery and direct the same frontend API to
different GUI frameworks at runtime (much like how the Linux VFS can manage
multiple filesystem types).
the purpose of this could be, for example, an app does most of its GUI as a
custom OpenGL-based GUI (for example, I typically do this in my apps), but
then may choose to pop up a dialog (such as, for example, a load/save
dialog) using the native GUI.
or maybe, the app is just GL based and wants to use its own GUI, not being
plagued with having to be expected to target its output to GTK or similar...
(or, for that matter, the API can provide its own GL-based backend, since it
is usually not so difficult to make one piece of GL-based code cooperate
with another, so long as the app is left with control over the drawing
state, and the framework is not too agressive with how it uses GL).
an example of this usecase could be, for example, allowing the app to direct
the GUI rendering to a render-to-texture context, and directing any input
back in through the "surface", allowing the GUI to exist self-contained
within a surface in a 3D world (meaning, the framework does not directly
access the mouse or keyboard, rather events are fed-in through the backend).
the framework can then be context-based, allowing for any number of separate
"GUI-spaces" to exist.
a render-to-pixel-buffer backend could also be useful (no GL dependencies
allowed here), potentially for cases where neither an existing GUI framework
or GL are available or desirable.
I guess this does leave a slight complexity as to where fonts are stored and
managed, so potentially some generic fonts could be managed by the frontend,
but the backend manages drawing them, as well as other backend specific
fonts. frontend would manage keeping track of widgets and a unified message
gueue, but the backends would be responsible for drawing the widgets and
possibly also for events. ...
in the simple case though, the API could provide utility code to allow much
more easily setting up and managing the GUI, and directing the output to GTK
or Win32/GDI or similar (although, I would request the API not be structured
much like GTK, as personally I find the general approach of GTK trying to
make the app be a "slave" to itself to be a little offensive...).
in my custom frameworks, I often end up with an "update yourself" call, as
well as a "draw yourself" call (maybe N/A or NO-OP for a GTK or GDI based
backend, likely these calls would be directed at the backend context rather
than the frontend context?...). the app could then be responsible for making
sure that these functions are called regularly (potentially per-context).
all of this would allow both the flexibility of a customizable GUI, without
forcing devs to go back to drawing all their own widgets, ... when the
existing frameworks don't exactly work with what they want to do...
this would be sort of like on the XBox/360, where the GUI can be used at the
same time as the running game, and often the games will apparently integrate
parts of the 360's GUI into their own interfaces (although, granted, I have
not looked into the 360 enough to know exactly how there framework is
likewise an app could "hijack" an existing backend, allowing them to
customize behaviors or add customized widgets (for example, for a GL
backend, it could add shaders to the existing buttons, or draw an alternate
slider and buttons made out of animated fire or whatever... while still
keeping the existing behavior methods and other widgets intact), while
otherwise not effecting the frontend's API or behavior (apart from those
effects manifested from the customizations).
my personal GUI framework is nowhere near so ambitious, namely in that it is
GL-only (and for other uses, I explicitly fall back to the GDI), and is
written in C, so it would be more like what I am imagining for in a
using the frontend would be far more conventional, apart from the addition
that none of the calls are "global", but will typically be directed to a
specific context (when the app sets itself up though, it could request a
default GUI context from the framework if needed, then go about creating any
windows or dialogs within this context, and creating and widgets in said
windows or dialogs...).
oh well, probably most people would not be so compelled by such an idea, but
it is worth a try I guess...
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list