[Mono-dev] Qt anyone?

[BGB]

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

IMO: groan...

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 
structured...).

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

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



> Robert
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>