On Mar 15, 2006, at 8:40, Peter Dennis Bartok wrote:
I did read these paragraphs. They mention GTK and Wine. IMHO, both are not suited for a native implementation approach. I agree with all that was said about why not to use these frameworks and I could think of a few more. GTK sucks as a cross platform framework to begin with, and basing the forms implementation on it could not possibly make it better. As "better" my definition would be that the Forms application is indistinguishable from a native application on the respective platform. I was thinking about SWT. SWT is a native GUI framework for Java. Eclipse is based on it, and Azureus, too.
That sounds very promising, I will definitely check it out.
Agreed. I could elaborate on why Swing is broken, but that's not the topic here. The important thing is to learn from its failures. There are two basic mistakes in the Swing architecture. These mistakes are conceptual and can not be fixed. I was somewhat afraid that the Forms project is about to repeat these mistakes. #1 - Emulating native looks with theme #2 - Hand-drawing widgets If I can define a Forms theme that just uses the OS for widget-drawing, that might be enough to get around both. But I am concerned because the whole "theme and hand drawing" philosophy wasn't dismissed outright.
That's the problem with all cross platform GUIs. There certainly is validity to it, but the problem is limited in scale. SWT seems to deal with that just fine. It seems to me that you want to achieve two things 1 - Provide Windows.Forms as a means to create a cross platform GUI. You can mark the windows-only functions of the API as "bad, do not use" and developers can develop wonderful cross platform GUIs with no problems by just avoiding these Win32-only things. 2 - Provide Forms as a way to quickly / easily port Windows native applications. This will be hard as MS will "allow" if not encourage .Net developers to dig deep into the Win32 API. The only solution to this is to provide workarounds for this on other platforms where possible, and skip the impossible-to-emulate things. Developers not wise enough to avoid those, or those who simply don't care just cannot be accommodated on other platforms. I, for one, would be happy with just #1. There will always be people who program in a Windows-only way and MS will obviously not prevent them from doing that.
I didn't say it's no good. I can believe it's "fast enough" because on a modern machine almost anything is fast enough and there is differences in perception as to what constitutes fast enough. I have written Swing apps that are fast enough - at least on Windows. The bigger problem is that they stick out as non-native. It is my experience that the Swing approach with themes is plainly wrong. The reason is that while themes are cute, no one really needs them. If you look at Swing themes, there are some nice ones from JGoodies - they are nice, but I would much rather have a 1:1 native look. The only reason I need the nice themes is that there isn't a 1:1 native look that works everywhere. And if you look at the most other themes (including and especially the ones from Sun) they are just horribly ugly. Themes have little value other than to approximate the native look, and at that task, they are always worse than using native in the first place. I have used Swing since it first came out, and written many client applications in it (yes, they can be fast) and never have I had the need to have themes. Every single app though had a problem with not looking exactly like a native app. I didn't find an archive where these questions were discussed in the past. If there is such a thing, please let me know. Best regards, Nik |
_______________________________________________ Mono-winforms-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-winforms-list
