[Mono-dev] idea summary: Swing in Mono?...
cr88192 at hotmail.com
Tue Feb 10 21:55:05 EST 2009
----- Original Message -----
From: "James Mansion" <james at mansionfamily.plus.com>
To: "Chris Toshok" <toshok at gmail.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Wednesday, February 11, 2009 7:06 AM
Subject: Re: [Mono-dev] idea summary: Swing in Mono?...
> Chris Toshok wrote:
>> err, I meant: "cross VM, cross platform, cross ui framework toolkit
>> of some kind"
> Like wrapping Qt or wxWidgets would do then?
this here assumes that Qt or wxWidgets were linked into the app...
to be a fully portable framework (between different implementations of the
NET VM), all of the internal machinery would have to be written in managed
code (in this way, both the frontend and backend are simply interfaces, and
it is possible to make objects implementing these interfaces to glue the
framework to the underlying implementation...).
of course, OTOH, this would make the framework only really usable for
managed code, meaning that unmanaged code would likely have to use a
different framework (AKA: several frameworks running in the same app).
I guess, there is another possibility:
to settle on a standardized API, and otherwise leave nearly all the details
to the implementation (this being a little closer to the more traditional
approach, although in both the JVM and .NET VM, it is typical to implement
APIs and frameworks with a mix of both managed and unmanaged code, rather
than enforce a strict point of division between them).
so, it becomes common that people only focus on a single side of the
the front-end API;
all of the internals and the backend are then left as "implementation
but, how about, if the entire framework, including all of the frontend API,
the internal workings, and the backend API/system dependent features, are
all fully specified?... AKA: all of the internals are specified down to the
level of individual objects, methods, and interfaces, although the exact
contents of method bodies would be left as implementation dependent, and it
would also be allowed to replace objects with others which implement the
same interface. this way, it is possible to have both fine-grained control
and allow multiple implementations.
of course, as a downside, this would preclude the use of native widgets or
toolkits, and necessarily fragment the effort from any other frameworks
which do use native widgets. as another cost, it would somewhat hinder the
level of individual freedom on the part of implementations.
but, for some things, this would be a worthwhile tradeoff (because very
precise control is allowed, reducing the cases where the user is left having
to write their own framework).
I guess it is a difference of mindset though (by analogy):
rather than think of the problem as a single and overall piece of machinery
for completing a task, we think of it instead as a big collection of grears,
mounts, nuts, and bolts. we then specify all of these nuts and bolts (such
as their specific sizes and threadings), the size and type of every gear,
in this way, rather than having some black box the user is just expected to
use (the typical approach to GUI toolkits), we have a piece of machinery
that can be reconfigured as needed (unbolted, parts swapped out, ...), such
as, for example, to conviniently replace the backend, without the user
having to go digging around in C land, or worse... not because all these
things are written into the framework, but because the internals are all
accessible, and formally specified.
it also irks me some, OTOH (in this case WRT APIs that expose native
functionality), that people so often keep writing thin wrappers for
everything, such that one piece of code ends up having to depend on how
another piece is implemented.
IMO, APIs should be specified (likely as a generalization of the possible
implementations), and then glued back onto the existing implementation. this
way, only the glue code needs to be modified during porting, and not the
client code (FWIW it makes Windows/Linux porting easier...).
of course, yes, it does require that people specify things (you don't "wrap"
something, you specify it and then implement it to the specification...).
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list