Re: [Mono-list] Gtk# or the future Windows.Forms Mono
Dang, several months ago I sepnt several weeks searching for a charting library that would run under Mono. I found the same problem with the big guys like Dundas, for one thing, they often make registry calls that fail on Mono (because the Wine registry isn't as complete as a true Windows machine I guess??). Also they often make P/Invoke calls to Win32 to support license valdation (apparently). I've contacted several of these big .NET 3rd party control vendors and have been told that Mono is not in their near term plans. This is both unfortunate and potentially very fortunate for some entrprising person/people. NPlot looks cool, I wish I had found it instead of doing the custom charting stuff (basic really). I will defintely look at using it in the next version of our product. Thanks Miguel for your, as always, thougtful and precise responses. --- Miguel de Icaza [EMAIL PROTECTED] wrote: Hello, Thanks to the respondees (sp?) so far. Jonathan's email hits a few nails on the head from what I can see. Unfortunately, I'm unable to locate the Dundas Charting for Gtk#. ;-) Aside from the (apparent) lack of decent GUI desginers other than for Java or C++ on Linux, my previous comment is worthy of consideration. What third party vendors support Gtk# or have pledged support? Also, Dundas currently requires features not available in Mono's System.Drawing, we will work towards completing those, but today it wont work. As for Gtk# you can use NPlot which today has a Gtk+ port. NPlot is nice in that there is a clear distinction between the plotting engine and its user interfaces, today it has three: ASP.NET, Windows.Forms and Gtk#. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Gtk# or the future Windows.Forms Mono
Hello, Dang, several months ago I sepnt several weeks searching for a charting library that would run under Mono. I found the same problem with the big guys like Dundas, for one thing, they often make registry calls that fail on Mono (because the Wine registry isn't as complete as a true Windows machine I guess??). Ah, shame. I only mentioned that on my blog, I did not post it to the mailing lists. miguel ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Gtk# or the future Windows.Forms Mono
Jonathan Pryor wrote: This isn't entirely true; there is also development on Cocoa# for better Mac OS X integration. Well, does this not make the argument for something like wx.NET, which already has pretty decent OSX integration including native look and feel? So the closest to an official position would probably be this: design your code to utilize multiple different front-ends so that you can better integrate with all of your target platforms. This implies having Gtk#, SWF, and Cocoa# GUIs, if desired. Is this more work? Yes. But your users will prefer it. (For proof, just see the history of cross- platform toolkits between Mac OS and Windows. The users tended to prefer Mac-native front-ends in almost all cases. Even now, I hear grumbling from users that Qt programs don't look quite right on the Mac, because buttons are the wrong size and other subtle issues.) Yes, you are right, and why I point out wx.NET as it is a native look and feel. Well, if you are comparing C++ toolkits and their issues, sure you have a point. But Java Swing has managed to create native look and feel applications across all platforms. I think asking a client to use different GUI toolkits on different platforms is asking too much. Playing devils advocate, I suppose at that point my reaction would be, ok, fine, so who pays the software development bills? Windows! Hence it makes sense to code to only Windows and forget the rest. Which at that point raises the question of why Mono? I suppose an answer would be easier development on Linux. Which is acceptable, but if a Linux app does not look and feel good on Windows or OSX, why bother? I am just playing devils advocate here, and find that using an approach like wx.NET I avoid all of these problems in the first place. A question is why not work on making GTK having a native look and feel? I was looking at gtk-osx native port and it seemed to have been stopped in 2002. Why did it stop? Just asking questions and wondering... Christian Gross ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Gtk# or the future Windows.Forms Mono
On Sat, 2005-04-16 at 11:44 +0200, Christian Gross wrote: Jonathan Pryor wrote: This isn't entirely true; there is also development on Cocoa# for better Mac OS X integration. Well, does this not make the argument for something like wx.NET, which already has pretty decent OSX integration including native look and feel? No, because native look and feel is a terrible misnomer. Users claim they want native look and feel, but they really don't. Users want a Real Native Interface. The difference? When the OS vendor changes the look of their UI, Real Native apps update automatically. Native look and feel apps -- anything written with Qt, for example -- will NOT, at least until the rendering engine is updated for the *new* look and feel. See also the change from Windows 3.1 to Windows 95, Mac OS X 10.1 to 10.2 to 10.3 (and presumably 10.4, though I haven't seen it yet), etc. Qt will *always* be behind, as will GTK+/Gtk#, and EVERYTHING that depends upon custom rendering. (This includes Java Swing, except on Mac OS X since Apple distributes the JRE and can thus make sure the Java Mac Look And Feel actually matches the current platform. UI mis-matches will still be true on Microsoft platforms and Linux; Sun's GTK Look and Feel *still* looks like Ass.) wx.NET may be the only one not susceptible to this, as IIRC it uses native widgets everywhere. The downside is, from what I've heard, it offers fewer widgets (the lowest-common-denominator problem), and I don't see it being used by many actual applications. I may be biased. So the closest to an official position would probably be this: design your code to utilize multiple different front-ends so that you can better integrate with all of your target platforms. This implies having Gtk#, SWF, and Cocoa# GUIs, if desired. Is this more work? Yes. But your users will prefer it. (For proof, just see the history of cross- platform toolkits between Mac OS and Windows. The users tended to prefer Mac-native front-ends in almost all cases. Even now, I hear grumbling from users that Qt programs don't look quite right on the Mac, because buttons are the wrong size and other subtle issues.) Yes, you are right, and why I point out wx.NET as it is a native look and feel. And why I'll start claiming that native look and feel is a misnomer, as stated above. Well, if you are comparing C++ toolkits and their issues, sure you have a point. But Java Swing has managed to create native look and feel applications across all platforms. Ha! As mentioned above, it has native look and feel... Eventually. In some cases *years* after the OS shipped. (Java 1.4 Swing on my XP box doesn't look like Windows XP, it looks like Windows 2000, and the menus look *really* funky. Maybe this was fixed for 1.5, but I haven't tested it yet.) Java Swing (and GTK+ and Qt, for that matter) will *always* be playing catch-up with the native platform toolkit. The only place this won't be the case is when they *are* the native toolkit (Gnome KDE). I think asking a client to use different GUI toolkits on different platforms is asking too much. It may be, but nothing has changed over the past 20+ years. The users *always* want a native UI, and developers want a portable UI. This is arguably a reason why Mac OS had fewer apps than Windows -- just porting a Windows UI to the Mac would NOT result in sales, as the users wanted a Mac UI, conforming to Mac UI conventions, that looked proper. Alas, this problem won't go away -- users will *always* want apps that behave properly, follow their conventions, and fit in with their desktop. Time has shown that this problem is too big for a toolkit to handle, which is why you still don't see many portable toolkits being used in commercial software... Playing devils advocate, I suppose at that point my reaction would be, ok, fine, so who pays the software development bills? Windows! Hence it makes sense to code to only Windows and forget the rest. Which is the current situation, and why Mono is implementing SWF support. Because asking for UI re-writes is asking to be ignored, unless the platform becomes big enough that you can't ignore it. With Mono+SWF, you'll be able to run your SWF apps under Mono (perhaps with some work required, if you app uses P/Invoke for Windows-specific functionality), and start gaining a user base. The user base may *hate* your app's look, but if you start seeing a significant number of users requesting native platform support, it may be worthwhile creating a native UI for them. You certainly DO NOT want to create an entirely separate code base for them, so having a program design that permits multiple different UIs from the beginning will make this easier. Plus, as I mentioned before, separating UI from the core makes it easier to write unit tests for the core... Which at that point raises the question of why Mono? I suppose an answer would be easier development on Linux.
Re: [Mono-list] Gtk# or the future Windows.Forms Mono
Hello, Should developers consider Gtk# or the new Mono Windows.Forms (or whatever it will be called) in planning and design phases for new GUI projects? Gtk# will continue to be developed, and will continue to track the Gtk and Gnome development platforms. Windows.Forms should be considered a library for bringing developers from Windows to Linux easily. Windows.Forms has a number of limitations imposed by the commitment to API compatibility with Windows which are particularly annoying for developing international application (and by extension any open source apps that have to be localized). Also keep in mind that Microsoft will move developers to a third toolkit, so Windows.Forms is effectively a toolkit that will not likely grow to address its limitations in next few years. If you are developing a new application today, and you do not mind the Gtk+ dependency, it is a better path to follow as Gtk+ blends nicely to internationalization and is being upgraded to add vector-based rendering with its current API. Windows.Forms is still a useful tool if most of your development will happen on Windows and you will target mostly Windows systems. Miguel. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Gtk# or the future Windows.Forms Mono
Hello, Well, does this not make the argument for something like wx.NET, which already has pretty decent OSX integration including native look and feel? Like Jonathan said, wx.NET is that it always provides the lowest common denominator widgetry. Which means that applications look and feel like native applications, but it will stop you short from tuning the interface to the most minimal details. This is probably OK for many applications, but anyone who wants to make the most out of the native platform will probably prefer to get the extra control that they want. Miguel ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Gtk# or the future Windows.Forms Mono
Hello, Thanks to the respondees (sp?) so far. Jonathan's email hits a few nails on the head from what I can see. Unfortunately, I'm unable to locate the Dundas Charting for Gtk#. ;-) Aside from the (apparent) lack of decent GUI desginers other than for Java or C++ on Linux, my previous comment is worthy of consideration. What third party vendors support Gtk# or have pledged support? Or do the Gtk# people do everything from scratch? We will be adding support for embedding Windows.Forms controls inside Gtk# by the time Mono 1.2 is released (when Windows.Forms becomes ready basically). This will let you write Gtk# applications, and embed your third party controls that matter. Miguel. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Gtk# or the future Windows.Forms Mono
Hello, Thanks to the respondees (sp?) so far. Jonathan's email hits a few nails on the head from what I can see. Unfortunately, I'm unable to locate the Dundas Charting for Gtk#. ;-) Aside from the (apparent) lack of decent GUI desginers other than for Java or C++ on Linux, my previous comment is worthy of consideration. What third party vendors support Gtk# or have pledged support? Also, Dundas currently requires features not available in Mono's System.Drawing, we will work towards completing those, but today it wont work. As for Gtk# you can use NPlot which today has a Gtk+ port. NPlot is nice in that there is a clear distinction between the plotting engine and its user interfaces, today it has three: ASP.NET, Windows.Forms and Gtk#. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Fwd: Re: [Mono-list] Gtk# or the future Windows.Forms Mono
Note: forwarded message attached. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---BeginMessage--- Hello, Thanks to the respondees (sp?) so far. Jonathan's email hits a few nails on the head from what I can see. Unfortunately, I'm unable to locate the Dundas Charting for Gtk#. ;-) Aside from the (apparent) lack of decent GUI desginers other than for Java or C++ on Linux, my previous comment is worthy of consideration. What third party vendors support Gtk# or have pledged support? Or do the Gtk# people do everything from scratch? We will be adding support for embedding Windows.Forms controls inside Gtk# by the time Mono 1.2 is released (when Windows.Forms becomes ready basically). This will let you write Gtk# applications, and embed your third party controls that matter. Miguel. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ---End Message---
[Mono-list] Gtk# or the future Windows.Forms Mono
Should developers consider Gtk# or the new Mono Windows.Forms (or whatever it will be called) in planning and design phases for new GUI projects? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Gtk# or the future Windows.Forms Mono
Dilton McGowan II wrote: Should developers consider Gtk# or the new Mono Windows.Forms (or whatever it will be called) in planning and design phases for new GUI projects? If I may add an third option. I find the wx.NET (http://wxnet.sourceforge.net) option to be very interesting as it uses wxWidgets. The major reason why I like it is that wxWidgets is a mature library that gives a native look and feel on multiple platforms (OSX, Windows, and Linux). Christian Gross ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Gtk# or the future Windows.Forms Mono
Dilton McGowan II wrote: Should developers consider Gtk# or the new Mono Windows.Forms (or whatever it will be called) in planning and design phases for new GUI projects? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list That is also my question. Will Mono abandon (eventually) gtk# and go full force behind SWF once SWF gets matured enough on most major platforms? Thanks Wei ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Gtk# or the future Windows.Forms Mono
I may be crazy, but GTK# is working fine for an app I have created that needs to run on Linux and Windows. With a nice helping of Glade, building a Gtk# app in mono is VERY simple (and quick.) Why abandon what works? Sure supporting SWF is a good thing, but why do so at the cost of (gasp!) a better widget set?? Greg - On 4/15/05, Wei Weng [EMAIL PROTECTED] wrote: Dilton McGowan II wrote: Should developers consider Gtk# or the new Mono Windows.Forms (or whatever it will be called) in planning and design phases for new GUI projects? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list That is also my question. Will Mono abandon (eventually) gtk# and go full force behind SWF once SWF gets matured enough on most major platforms? Thanks Wei ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Gtk# or the future Windows.Forms Mono
On Fri, 2005-04-15 at 15:04 -0400, Wei Weng wrote: That is also my question. Will Mono abandon (eventually) gtk# and go full force behind SWF once SWF gets matured enough on most major platforms? Mono will do that when Microsoft stands behind SWF[1]. :-D Which is to say, No, Never, and You Must Be Kidding, Right[2]? Gtk# is, and will continue to be, the official toolkit of Mono, as much as Mono has an official toolkit, anyway. Why? Because Mono was developed by a bunch of Gnome hackers who wanted to simplify Gnome development, and GTK+ is the toolkit of Gnome. :-) This isn't entirely true; there is also development on Cocoa# for better Mac OS X integration. So the closest to an official position would probably be this: design your code to utilize multiple different front-ends so that you can better integrate with all of your target platforms. This implies having Gtk#, SWF, and Cocoa# GUIs, if desired. Is this more work? Yes. But your users will prefer it. (For proof, just see the history of cross- platform toolkits between Mac OS and Windows. The users tended to prefer Mac-native front-ends in almost all cases. Even now, I hear grumbling from users that Qt programs don't look quite right on the Mac, because buttons are the wrong size and other subtle issues.) Of course, what developer wants to support three (or more) different code bases? None. But that's another matter - Jon [1] Microsoft has stated that Avalon is the future, and SWF has no long- term future. At least, that's my current interpretation of their statements. There will be some work to make it possible to use Avalon from SWF and vice-versa, but Avalon will be preferred, make no mistake. [2] Plus, if Mono dropped Gtk# Mono would be crucified by Free Software users because of the ever-present cry, what about patents?! With Gtk# we can better insulate our users from any potential issues and provide an alternative. Plus, SWF sucks[3] (no box layout, difficult i18n and l10n, and various other issues). [3] Yes, this is intended to start flames. :-) ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Gtk# or the future Windows.Forms Mono
Thanks to the respondees (sp?) so far. Jonathan's email hits a few nails on the head from what I can see. Unfortunately, I'm unable to locate the Dundas Charting for Gtk#. ;-) Aside from the (apparent) lack of decent GUI desginers other than for Java or C++ on Linux, my previous comment is worthy of consideration. What third party vendors support Gtk# or have pledged support? Or do the Gtk# people do everything from scratch? Thanks, Dilton --- Jonathan Pryor [EMAIL PROTECTED] wrote: On Fri, 2005-04-15 at 15:04 -0400, Wei Weng wrote: That is also my question. Will Mono abandon (eventually) gtk# and go full force behind SWF once SWF gets matured enough on most major platforms? Mono will do that when Microsoft stands behind SWF[1]. :-D Which is to say, No, Never, and You Must Be Kidding, Right[2]? Gtk# is, and will continue to be, the official toolkit of Mono, as much as Mono has an official toolkit, anyway. Why? Because Mono was developed by a bunch of Gnome hackers who wanted to simplify Gnome development, and GTK+ is the toolkit of Gnome. :-) This isn't entirely true; there is also development on Cocoa# for better Mac OS X integration. So the closest to an official position would probably be this: design your code to utilize multiple different front-ends so that you can better integrate with all of your target platforms. This implies having Gtk#, SWF, and Cocoa# GUIs, if desired. Is this more work? Yes. But your users will prefer it. (For proof, just see the history of cross- platform toolkits between Mac OS and Windows. The users tended to prefer Mac-native front-ends in almost all cases. Even now, I hear grumbling from users that Qt programs don't look quite right on the Mac, because buttons are the wrong size and other subtle issues.) Of course, what developer wants to support three (or more) different code bases? None. But that's another matter - Jon [1] Microsoft has stated that Avalon is the future, and SWF has no long- term future. At least, that's my current interpretation of their statements. There will be some work to make it possible to use Avalon from SWF and vice-versa, but Avalon will be preferred, make no mistake. [2] Plus, if Mono dropped Gtk# Mono would be crucified by Free Software users because of the ever-present cry, what about patents?! With Gtk# we can better insulate our users from any potential issues and provide an alternative. Plus, SWF sucks[3] (no box layout, difficult i18n and l10n, and various other issues). [3] Yes, this is intended to start flames. :-) __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
