Per Arneng wrote:
So i was thinking if it would be possible to try to make a swing library on top of GTK# or something. Im not sure but i think that java.swing is built on top of java.awt. So mayby it is best to build awt on top of gtk# and then swing on top of that.
Well, the fact that Swing is based on AWT is simply legacy. Swing would need only a very simple interface to the platform windowing system: some clipped, overlapping region to draw on and some source to get all kinds of input events from. In addition, swing needs some 2D drawing capabilities, especially if you need true unicode font support and fast drawing.
I don't know GTK that well, but if it provides some canvas to draw on, you could certainly create something like Swing upon that. However, Swing is a _large_ framwork with some 2000 classes and ten thousands of methods. As mono's JIT is probably not that fast than Suns hotspot VM, a swing-like framework on top of GTK would suffer from the same problems as Swing: a reputation of beeing slow (which isn't already true at all but people believe it). Besides the VM speed, the penality for doing native calls would be the other factor that can make a Swing-like API fast or slow.
This can later be merged with ex gnu:classpath in some way when and if a java frontend is added to mono.
An interesting idea would be to try to compile a Swing written in Java with an abstraction layer that allows one to put it on top of different windowing apis to CIL so that both projects could profit from. However, why don't we add a proper MVC (or MVP which is a variant I like better, google for Dolphin Smalltalk and MVP for more details) to GTK#? If Dolphin Smalltalk can do this for the Windows API, it should be possible to do for C# and GTK#, too. bye -- Stefan Matthias Aust // www.3plus4software.de // Inter Deum Et Diabolum Semper Musica Est _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
