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

[Jerry Maine]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Well, I have seen SWT and opengl work together. It is possible. And
SWT uses native widgets to do its bidding.

In addition with P/Invoke and the ability call api on mono/.net to
find the underlying system, the new .net gui library can load the
needed drivers on demand giving the ability to keep it as one unified
library that one can move with the application. Makes a better
solution than SWT in java, no?

BGB wrote:
>
> ----- 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...
>
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmOX78ACgkQ1jvea6V8vHLtswCgidGcsOj3pxGI88UkIfeGqnAs
mwYAnRst8YUFQuIkbi48e1SKgeIJ5UUv
=k0DC
-----END PGP SIGNATURE-----