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

[Chris Toshok]

Not to toot our own horn here too much, but you'd probably get a lot
more out of using an existing technology here - moonlight
specifically.  we already have apis for posting user events (although
the api currently uses gtk events, there's nothing stopping you from
creating them and passing them in, and at some point in the future
we'll likely abstract things a bit more), and we already draw to an
offscreen pixmap that you can use as a texture.

And all of this is likely to be far less work for you (and be far less
distasteful for the rest of the community) as something like Swing.

Chris

On Sat, Feb 7, 2009 at 9:23 PM, BGB <cr88192 at hotmail.com> wrote:
>
> ----- Original Message -----
> From: "Jerry Maine" <crashfourit at gmail.com>
> To: <mono-devel-list at lists.ximian.com>
> Sent: Sunday, February 08, 2009 2:29 PM
> Subject: Re: [Mono-dev] idea summary: Swing in Mono?...
>
>
>> -----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.
>>
>
> interesting...
>
> so, you can put buttons on 3D rendered surfaces?...
>
>
>> 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?
>>
>
> I was digging around in GNU ClassPath's implementation of Swing and AWT, and
> am a little less confident...
>
> it looks like a bit of a tangled mess, and it looks like it is typically
> built to direct its output to a built-in backend (apparently x-peer,
> gtk-peer, or qt-peer, ...). it looks like all of this is intended to be
> controlled by the central configure script, for which I am unable to get to
> work...
>
>
> my idea would likely require a custom implementation, such as:
> there is a special Canvas object, which is a pure interface implementing a
> subject of OpenGL (maybe a subset of OpenGL 1.0 or 1.1, plus any extensions
> for handling getting input backto the framework).
>
>
> interface BaseGL {
>    ...
>    const GL_TEXTURE_2D ...
>    ...
>
>    ...
>    void glBegin(int tag);
>    ...
>    void glEnd();
>    ...
>    void glVertex2f(float x, y);
>    ...
>    void glTexCoord2f(float s, t);
>    ...
> }
>
> interface BaseInput {
>    ...
>    void submitKeys(char[] keys);
>    void submitMouse(float x, float y, int state);
>    void update();
>    void draw();
>    ...
> }
>
> class BaseSurface {
>    ...
>    BaseGL gl;
>    BaseInput client;
> }
>
>
> so, the GUI API draws via an object implementing BaseGL, and provides an
> object implementing BaseInput, and BaseSurface is used to coordinate them...
>
> on top of this, a GUI is built, and in the frontend implements an interface
> resembling SWT or Swing...
>
>
> or, apparently, it may be partly required to rework GNU's implementation to
> be closer to that of Sun's, in particular, actually doing the rendering by
> sending output to a Canvas, ... rather than offloading/sharing most of the
> machinery with AWK...
>
> although, it looks like there is an OpenGL backend in ClassPath, so it may
> be possible to strip most of the rest (GTK, QT, ...) out and just use this
> as the starting point...
>
>
> but, I guess the first step would be getting the thing to build (proving to
> be a bit of a problem, as the ClassPath source uses generics and both GCJ
> and CSCC are refusing to accept generics...).
>
> or such...
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>