[Mono-dev] idea summary: Swing in Mono?...

[BGB]

----- Original Message ----- 
From: "Jerry Maine" <crashfourit at gmail.com>
To: "BGB" <cr88192 at hotmail.com>
Sent: Sunday, February 08, 2009 12:44 PM
Subject: Re: [Mono-dev] idea summary: Swing in Mono?...


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> BGB wrote:

<snip>

> Well, SWT, uses the native widgets it finds on the machine... gdi32 on
> windows... carbon or whatever its replacement on mac and gtk on
> linux/unix.
>
> We can keep the api close simularity to swing... or swt... would make
> it easier for people to learn it. In addition using native widgets....
> on all machines.... will make .net applications look native for the
> machine... and be portable. That and use .net features like delgets
> and events.
>
> And on unsuported platforms we can have a back up drawing of the widgets.
>

well, this works partly, but then there is a problem:
the fact that Swing draws its own widgets is a major blessing as well as a 
curse...

on the major UP side, the code can be made self-contained, and it is 
possible to have a very high level of control over HOW the widgets are drawn 
(this issue being critical in my case, and a major reason for why I draw my 
widgets custom, rather than using GDI).

to have just the API does little here...
it gives the native "look and feel", but costs severely in terms of control 
(AKA: you can create windows and buttons, but you have no control over how 
they are drawn, ...).


for some apps, it is critical that control be retained, and retention of the 
native look and feel is of a low priority...

this depends on the app, where for example, with a plain UI-app, likely the 
retention of native look and feel is the priority, and for another app, such 
as a CAD package or a 3D game/engine, ... control is the critical factor, 
and if there is not control (for example, the framework only uses native 
drawn widgets), then the framework is, simply, not usable... (this being why 
I feel it important that control be retained, and keep stressing the need 
for the ability to render-to-texture and similar...).

back to the examples:
consider, for example, that the UI is coupled with the objects existing in a 
3D scene, for example, a dialog may be "physically" linked to a 3D object, 
and the user input is not comming directly from the OS, but is rather going 
through the 3D world (the user might move the camera over to the control, 
and interact with buttons or sliders inside of the 3D environment).

a very simple example of this UI style could be seen in Doom 3, but it may 
make sense to allow further expanding on this approach to UI's (for example, 
in terms of 3D modeling software, more utility-based 3D worlds, ...).


so, as I see it, the ability to use the API in a custom manner (AKA: 
user-supplied Canvas) should be preserved at all costs (and is an app 
choice, at runtime, NOT a framework choice or library compile-time choice), 
however, the ability to use native widgets would also be a good thing as 
well...

so, my recomendation would be to implement (or port) Swing, but not just as 
the API, rather keeping all the internals as well (including, as the central 
matter, that it draws its own widgets).

then maybe the app can use SWT, GTK#, ... if it needs native widgets and 
control is a less central issue...