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

[BGB]

----- 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?
>
> James
>

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 
problem:
the front-end API;
all of the internals and the backend are then left as "implementation 
dependent".


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


or such...


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