The amount of effort required to get an existing Winforms app running on Mono can vary greatly. Although many small apps will run on Mono unmodified, many apps will require some work on the developer’s part to run smoothly on Mono. This guide will attempt to port a non-trivial open source application to document several of the issues a developer may run into while porting their app to Mono.
Porting Winforms Applications to Mono
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSAlert.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
The Mono team is doing an amazing job. Having good Windows Forms support (rendered thru Cairo) on X11 is really great.
In a year or two, I see .NET applications developped by major vendors running natively on *nix.
I was quite surprised by the completeness of Mono. Winforms makes porting very easy and for GUI apps C# is simple and to the point.
I like what the mono team are doing. Now all we need is WinForms project templates to be added to MonoDevelop.
So apparently .NET does not create cross-platform applications by default and you have to invest extra effort to port them.
Many of the issues they discuss are pretty serious: using backslashes as path separators and case-insensitive filenames are common practice, platform invokes too, and the only way to fix them without changing source code is to install the Windows version of Mono on wine and run the app on that, which is not fully supported yet.
And doesn’t Java work everywhere already?
“So apparently .NET does not create cross-platform applications by default and you have to invest extra effort to port them. ”
No, but good developers do. Any app which is going to be cross platform requires a substantially larger investment up front if it is to run correctly…which brings me to:
“Many of the issues they discuss are pretty serious: using backslashes as path separators and case-insensitive filenames are common practice, platform invokes too”
Seasoned .Net devs know about Path.DirectorySeparatorChar (which provides an abstraction for the path separator character), and regardless of programming languages, string comparison (i.e. file names in this case) should always be done in a case-insensitive manner unless there is a specific reason not to do so. String.Equals has an overload that accepts a StringComparison enum to allow for case insensitive comparison, and most .Net devs make it a habit to almost always call string.ToLower().Trim() if they can’t use the Equals method.
Platform invokes should be implemented as a separate library…there is no way of getting around them in some cases, but if they are pulled out of core code, then a suitable library can be written for other platforms utilizing their version of p/invoke (I don’t know what Mono’s is) and swapped out during deployment.
By no means are these serious issues as we’re taught all of this fairly early on.
“And doesn’t Java work everywhere already?”
There is a runtime available for almost all platforms, but a good bit of tweaking is usually needed for different platforms for non-trivial applications (meaning larger than java applets).
Edited 2007-06-04 06:44
“but a good bit of tweaking is usually needed for different platforms for non-trivial applications (meaning larger than java applets). ”
What a FUD. care to explain those good bit of tweakings?
Path separators, hard coded paths and others can also break portability for Java and for any other programming environment.
Consider for example a program that hard codes the file with hosts as being “C:hosts” regardless of the language/runtime that you are using, the above will fail in non-Windows systems (And Windows systems with a non C: root).
And doesn’t Java work everywhere already?
This statement/question simply invalidates your entire argument.
I have used PLENTY of java apps that only work properly on a single platform (usually Windows – surprise!).
Often this is either due to the use of JNI (Java Native Interface – read: platform-specific), or stupid code that only works on one platform (similar to assuming backslashes are OK in pathnames everywhere).
My impression is that Java “works everywhere” just as well as .NET code does at this point. Java has simply been in the game longer. This means there are many more platforms supported (officially even) and developers have been forced to learn the hard way how to write truly cross-platform Java code.
Winforms is essentially a platform-specific .NET API as it is – I mean even the name suggests this. I would not expect to write GTK+ software and have it work on a platform that has no GTK+ support – likewise with Winforms. It is amazing that Mono supports it as well as it does – and Microsoft never intended for Winforms to be cross-platform anyway I suspect.
I have used PLENTY of java apps that only work properly on a single platform (usually Windows – surprise!).
Often this is either due to the use of JNI (Java Native Interface – read: platform-specific), or stupid code that only works on one platform (similar to assuming backslashes are OK in pathnames everywhere).
Install wine and then install the Windows version of Java on wine. Run your application through that setup, and it works. It’s worked for many years.
Now try the same with Mono and an application using platform invokes and it won’t work. It won’t work for many years.
Windows.Forms. Yay! Which has now been deprecated by Microsoft in favour of Avalon, and where no one is quite sure what the future of Windows.Forms is. Nice way to waste a lot of developer time and effort at Microsoft’s behest ;-). I digress though.
Often this is either due to the use of JNI (Java Native Interface – read: platform-specific), or stupid code that only works on one platform (similar to assuming backslashes are OK in pathnames everywhere).
JNI can certainly be used in Java, but even worse is the effect of .Net’s P/Invoke. You see, all .Net is is a great big object oriented wrapper around Win32 and existing COM components, and where there are things that aren’t or can’t be wrapped, or where performance is an issue, P/Invoke inevitably becomes an issue.
This is the sole reason why JNI gets used on Windows usually – because of hooks into pre-existing COM servers that will be around for some time. It’s not Java that’s the issue there.
You even have the option of running the JRE under Wine if this is an issue for you, whereas Mono just cannot do that and can give you no option at all for portability there. Don’t expect Microsoft to help out with running under Wine any time soon on that front.
Windows.Forms. Yay! Which has now been deprecated by Microsoft in favour of Avalon, and where no one is quite sure what the future of Windows.Forms is. Nice way to waste a lot of developer time and effort at Microsoft’s behest ;-). I digress though.
And also Win32-based and MFC development is on the same bucket, but the are still hundreds of thousands of applications using those APIs.
The same happens with Windows.Forms, what we offer is the chance for those applications to run on Linux because people do not switch to the latest toolkit as soon as it comes out.
Some people are able to switch API as soon as they are released, the “early adopters”, and smaller projects can afford to do rewrite their code bases, but the majority of people do not rewrite their code overnight without a good reason, it is after all a waste of money.
You should know better, in fact, you probably do. But it would not serve your purpose of bashing Mono yet again and would defeat your point.
You even have the option of running the JRE under Wine if this is an issue for you, whereas Mono just cannot do that and can give you no option at all for portability there. Don’t expect Microsoft to help out with running under Wine any time soon on that front.
Ah, making things up to prove a point.
What a sad thing.
Miguel
And also Win32-based and MFC development is on the same bucket, but the are still hundreds of thousands of applications using those APIs.
Yes, people have a ton of stuff written for Win32, and with COM that won’t be rewritten? What does Mono actually offer them there over any other cross-platform technology?
The same happens with Windows.Forms, what we offer is the chance for those applications to run on Linux because people do not switch to the latest toolkit as soon as it comes out.
WinForms has been around for about ten seconds, with very, very little written in it. It does absolutely nothing for the people who have pre-existing stuff written for Windows with COM, and those who are looking at porting to Linux are looking into relevant technology to do so anyway.
I suggest you wander into an average development environment some time and see what people are developing with, and also look at customers for Java, Qt and have a chat with Mainsoft as to what their customers use and require, otherwise anything else is just technology wanking masquerading as something that people who don’t know any better think will somehow magically make people port applications.
…but the majority of people do not rewrite their code overnight without a good reason, it is after all a waste of money.
That’s the only bit you got right. So what about all those people with COM based applications again, that sit behind any .Net code, who will not rewrite them?
You should know better, in fact, you probably do. But it would not serve your purpose of bashing Mono yet again and would defeat your point.
Sorry Miguel, I realise it’s your baby and all and you can’t really admit any kind of failure now.
Ah, making things up to prove a point.
What a sad thing.
Why do I have visions of pots, kettles and black things :-)?
I suggest you try running the .Net runtime and a JRE in Wine with some applications you’d like to run some time sweetheart. That’s the only way it’s going to happen for the vast majority of people who have stuff written for Windows and the only option they have. As soon as that compatibility tool tells them they have COM components attached to their .Net application it’s all over.
For those with existing COM server applications Wine is the only way of going outside of Windows with what they have. Porting applications from .Net to Mono simply isn’t enough, because that’s what the vast majority of people who’ve developed for Windows have their code written in. Without something like this:
http://wiki.winehq.org/Mono-Wine_bridge
and quality integration with existing development tools and IDEs on a Linux platform that makes Visual Studio users sit up and take notice, you don’t have a snowball in hell’s chance in getting any kind of message through to the vast majority of Windows developers who are specifically using Microsoft development tools.
I mean hell, look at that article. You’ve got screenshots of Visual Studio, and then Linux porting stuck on as an afterthought. What kind of advert is that for Linux development, moving to desktop Linux and the usefulness of Mono when people can’t port their applications and COM components, and also open their Visual Studio projects in an equivalent and well featured IDE? Unless you can offer that to a Windows developer he or she just isn’t going to be very interested, otherwise they will specifically look at cross platform tools as and when they need them.
You’re promising them .Net compatibility in an attempt to get them to desktop Linux presumably, so how are they going to do development when they get there? Porting applications is about more than just taking a bunch of executables and getting them to sort-of run…………with some caveats.
I suggest you wander into an average development environment some time and see what people are developing with, and also look at customers for Java, Qt and have a chat with Mainsoft as to what their customers use and require, otherwise anything else is just technology wanking masquerading as something that people who don’t know any better think will somehow magically make people port applications.
Except we happen to have data for thousands of applications and COM usage with .NET is less than 5% of the applications in the wild.
We estimate from the Moma reports that we have received that 50% of the .NET applications can be ported with no effort (a day or two); Something like 20% requires moderate changes, another 20% requires serious changes and the rest is unportable.
You can wave your hands all you want, but COM is just not that common in .NET applications (109 out of 2086 reports we have received use COM, so about 5%).
P/Invoke is where the real problem is, you would know that if you spend more time understanding Mono than attacking everything that might compete with KDE and Qt which you seem to defend religiously.
Our estimates for the difficultly of a port that I outlined before come from the study of COM and P/Invoke. You can see the results in my FOSDEM talk.
You’re promising them .Net compatibility in an attempt to get them to desktop Linux presumably, so how are they going to do development when they get there? Porting applications is about more than just taking a bunch of executables and getting them to sort-of run…………with some caveats.
Well, there are a number of options today: people can use the commercial X-Develop IDE which is fantastic, or they can use our beta MonoDevelop.
Nothing is a match for VisualStudio comprehensiveness, but then again nothing is in the Linux world.
In my view, we can invest in making the tools, create communities around them and developing.
You seem to be upset that am not investing in whatever technology you think must “win” you almost seem like you are annoyed that you can not control the direction that other people choose.
Feel free to go and implement your own strategy and keep us posted.
Miguel.
You seem to be upset that am not investing in whatever technology you think must “win” you almost seem like you are annoyed that you can not control the direction that other people choose.
I’m not upset by any stretch of the imagination. I strongly and sincerely hope that Mono really will provide the means for Windows developers to simply hop over, and it may well become very important one in helping people over in the way that Wine is the only chance for people getting a vast multitude of applications over today. I don’t think many distributions invest enough in Wine in terms of developers on Linux, and not just users to be perfectly honest, but it’s their loss. The earlier that compatibility with Windows applications was nailed down the less of a need for compatibility with the next version of Microsoft’s development mystery tour there would have been.
However, when you look at the effort needed to be invested in being a credible equivalent to .Net in the extremely critical eyes of many Windows developers out there, and just keeping up on the technology front, at this point in time there’s better things that could be done.
In terms of providing compatibility with Windows, all you end up having if you keep doing that are two types of problem applications people have to port – COM and .Net – with double the problems and double the barriers to entry. Desktop Linux distros need to concentrate on building their own development platform that people can grab hold of, otherwise all that can possibly happen is that people develop for Windows first and if it runs on anything else then its a bonus.
.Net could actually be Microsoft’s great strategic blunder from a business point of view. They built an excellent API on a great platform and left the door open for everybody to clone it.
It reminds me of when IBM put together the PC and and was careless enough to leave the OS to somebody else.
Instead of patenting every other line of code, Microsoft submitted the CLI as a standard because at the time they were so worried about Java.
WinForms is the most convenient and well thought out API for GUI development, period.
And yes, it is deprecated in favour of Avalon. But looking closer at Avalon’s shortcomings it will take another version number or two before it will be useable for a heavy duty app. Currently WinForms is the way to go for development on Windows.
“WinForms is the most convenient and well thought out API for GUI development, period.
And yes, it is deprecated in favour of Avalon. But looking closer at Avalon’s shortcomings it will take another version number or two before it will be useable for a heavy duty app. Currently WinForms is the way to go for development on Windows.”
I largely agree with your post, but I wouldn’t necessarily agree that “it will take another version number or two before it [Avalon] will be useable for a heavy duty app.” The new Expression Suite is WPF (Avalon). I’ve played with the preview version of Expression Media Encoder, and it’s a pretty “heavy duty” app.
Edited 2007-06-05 15:22
I have to admit I did not delve deep into Avalon but based my opinion on the findings of C. Petzold:
http://www.charlespetzold.com/blog/2006/03/030335.html
Going by that, I would rather wait and see before I invested too much of an effort into WPF.
You see, all .Net is is a great big object oriented wrapper around Win32 and existing COM components, and where there are things that aren’t or can’t be wrapped, or where performance is an issue, P/Invoke inevitably becomes an issue.
You are mistaken. .NET is NOT simply a wrapper around Win32 and COM (I believe you are thinking of VB6 and older). If you are referring to the CLR, well then – DUH! just like Java’s VM has to use the native OS to facilitate it’s APIs, so does .NET.
I think everyone mistakenly refers to Winforms as .NET – this is a grave mistake. Winforms was never meant to be cross-platform. Microsoft at least broke it out into is own assembly and namespace so that developers didn’t HAVE to use it.
An intelligent developer (using any language) will separate the software into functional layers – one being the presentation layer. This allows modular pieces to be rewritten without having to start over. I continually see developers making this mistake. These are usually the same people who generally whine about nonsense like this.
Winforms is meant to provide a native Windows GUI interface for .NET software and no more. If some idiot developer goes and uses a Winforms combo box to sort their array of data because that’s all they know how to use, then they deserve what they get. Everyone is focusing on Winforms here – what about the use of GTK# or Cocoa#? Those are clearly platform-specific (GTK happens to be “cross-platform” as well – but what about platforms that don’t have an updated version of it?)
I think you miss the point of .Net. The point of .Net is not cross-platform interoperability, but rather it is yet another means of platform lock-in to Windows platform.
There is Windows Forms:
http://en.wikipedia.org/wiki/Winforms
… which is clearly designed to run on top of Windows only, and then there is Swing:
http://en.wikipedia.org/wiki/Swing_%28Java%29
… which has a primary design aim of platform independence:
http://en.wikipedia.org/wiki/Swing_%28Java%29#Architecture
If you wanted to write an application that works on more than one platform, you would not choose .Net to do it.
If you wanted to limit your market to strictly Windows platforms, and give yourself next-to-zero chance of ever making a working version on any other platform, then and only then might you consider .Net.
Man, this whole Mono thing must be a complete joke then eh? Perhaps you should email Miguel et al and let them know they are wasting their time.
It means that Mono will always be behind Windows, though, or at the least that Windows has the ability to gain advantages because Microsoft controls both. Which must mean that Linux will be second class, benefitting Microsoft Windows, just as Sun v Microsoft and the whole Microsoft Java debacle pointed out a decade ago.
I hear that argument all the time, but doesn’t it work in the other direction too? Why say that Mono will always be behind Windows? You could just as easily say that Windows will always be behind Mono, because it also has some libraries and abilities that the Windows .NET implementation doesn’t have.
“
”
I see your point, but I can’t see many people choosing (arguably) crossplatform tools only to then lock their application into the smallest install base. Sadly Windows will always be one step ahead of other platforms – not because of it’s innovation, but because of it’s monopoly.
sorry, wrong comment at the wrong place, just read over it.
Edited 2007-06-04 09:49
You could just as easily say that Windows will always be behind Mono, because it also has some libraries and abilities that the Windows .NET implementation doesn’t have.
Because the weight of development and installed applications behind .Net is with Microsoft and Windows. That’s why the Mono people feel the need to come up with a Windows.Forms implementation (and Windows.Forms is just one part of .Net on Windows and has been deprecated in favour of Avalon remember) and why Microsoft probably hasn’t even heard of GTKSharp.
Mono is continually limited in its usefulness as a cross platform environment in how much of the .Net and surrounding Windows component environment it can reproduce, in a way which will make it transparent to ported applications. That’s a big, big ask, and you need an awful lot of time, developers and resources to make it feasibly achievable. Remember that Windows.Forms is just one area within .Net and Windows to be implemented by Mono, and Microsoft now recommends everyone use Avalon instead.
Basically, you’re just going to be treading water at best with this approach. Trying to re-implement Microsoft’s technology with the huge numbers of developers, time, resources and money that is required is not exactly the smartest move one could be doing. It’s one the the weapons Microsoft uses to stop you from coming up with something that will work properly outside of Windows.
Who says Mono has release all the same functionality 2 days after MS launches it?
Yeah with .Net 1.1 that was very true since all the foundation was being laid there, but with 2.0 it wasn’t nearly as important. Many developers targeting windows used 1.1 a year or more after 2.0 came out.
I don’t understand this infatuation I see over and over again with posts on here about “OMG the sky is falling cause you can’t release the same features at the same time”. Microsoft is not going to, and can’t afford to, redesign all of .Net every two years just to mess up Mono. The base of code out there will stay largely the same with some additions here and there which are of smaller and smaller significance. Look at 3.0 it’s a smaller amount of new code then 1.1 -> 2.0 and already Mono is getting support for it.
Uhm, no?
I have successfully written a cross-platform application in C# that works on both Linux and Windows, with minimal porting effort. The application was developed on *Linux* and then ported to Windows, not vice versa. It uses GtkSharp as GUI toolkit. All in all, the development and porting of the application was much more pleasant than when I would have written the app in C++.
Swing is a joke. Its API absolutely sucks. To properly align a component I have to create hundreds of panels. Why can’t they just do like GTK does? GTK’s alignment features are awsome and easy to use.
Edited 2007-06-04 07:35
Of course you could also use QT.
Anyway it is good to see efforts for cross platform development going on. Even though i doubt that we will see a stream of application suddenly being ported to Linux / Unix because of mono. Heck there are hardly any “great” .NET apps out there on Windows. The adoption of .NET seems very slow, even on Windows. And in the Enterprise space most applications are written in Java.
Swing is a joke. Its API absolutely sucks. To properly align a component I have to create hundreds of panels. Why can’t they just do like GTK does? GTK’s alignment features are awsome and easy to use.
Having used C# 2.0 and WinForms, I can tell you it’s resizable form design is much worse than Swing.
I don’t doubt that that’s true – Windows toolkits usually use fixed layouts. And that’s why GTK is my preferred toolkit – it’s cross-platform and everything is easily resizable.
Just a minor correction – WinForms 2.0 actually supports all the features which GTK has, hence the reason why they broken compatibility with Winforms 1.x – to add features such as resizable/scalable forms. For Mono, the ‘best kit’ to use would be gtk#, but at the same time, however, Winforms is there for those from the Windows world who find themselves more confortable with it.
“Having used C# 2.0 and WinForms, I can tell you it’s resizable form design is much worse than Swing.”
Either you’re trolling, or haven’t heard of the new TableLayoutPanel and FlowLayoutPanel controls in WinForms 2.0.
Swing is a joke. Its API absolutely sucks. To properly align a component I have to create hundreds of panels.
Only because you don’t know what your doing? Ever heard of GridBagLayout.
“Only because you don’t know what your doing?”
People use that same excuse every time one criticizes Swing.
“Ever heard of GridBagLayout.”
Yes, and its API sucks. It’s horrendously complex compared to GTK’s simple HBox, VBox and Table.
Take a look at this simple dialog: http://izumi.plan99.net/kwarto/kwarto-nieuwspel.png
It took *over 400 lines of code* just to write that simple dialog! I needed *3* classes to write that – if I used less classes I would have needed even more code.
To make the spacings correct, I had to wrap components in panels. Tons of panels. And the layout is still not correct, notice how the inside the “Speler” panel has inconsistent spacing. Fixing that would require me to wrap things in *yet another* panel.
In GTK I can write that same dialog with 2 to 3 times less code.
I’m sure you’re going to tell me how much my code sucks, so I invite you to download it and judge it for yourself: http://izumi.plan99.net/kwarto/kwarto.tar.bz
Look in kwarto/ui/NieuwSpelDialog.java. I challenge you to write a better-looking GUI in less code.
Edited 2007-06-04 13:30
I challenge you to write a better-looking GUI in less code.
Yea… I’m going to rewrite YOUR code. I have lots of time for that. GridBagLayout is not that complex. Spend thirty minutes learning how it works and you should be able to figure it out.
You could also use Box and BoxLayout but if you are not going to spend the time to learn how to use them then you will still be frustrated. Swing is complex but also flexible and the reason most Swing GUI’s look like crap is because the developers not because of Swing itself. Most developers never use Insets or Borders in Swing and unfortunaly those two simple things can have a hugh impact on a Swing based GUI. It all boils down to how much time you spend learning what you have to work with.
“Spend thirty minutes learning how it works and you should be able to figure it out.”
No, really, why should I spend 30 minutes on it when I can learn the GTK box model in 1 minute? The GTK box model can do everything I want, with much simpler code. The fact that I have to spend 30 minutes on learning GridBagLayout already means that it’s too complex.
It’s basic usability. It applies to programming too. Just like I shouldn’t have to spend time on learning unnecessarily complex user interfaces, I shouldn’t have to spend time on learning unnecessarily complex APIs.
Edited 2007-06-04 22:43
One bit of good news: that the GUI designer in Netbeans creates that bloated code for you pretty easily
Well… I found a few minutes to rewrite your dialog using GridBagLayout. You can pick up the code here:
http://www.cubeyellow.com/DialogTest.zip
Note it is implemented in a JFrame but you can move the code to a JDialog just the same. Also, this was done with jdk 1.4.2 so should be fine with that and any jdk above.
The layout code is only one file, 267 lines.
Great, but your dialog doesn’t layout correctly. This is what it looks like on my system: http://izumi.plan99.net/kwarto/gridbaglayout.png
I don’t see the OK/Cancel buttons. The labels and text fields on the left panel are not aligned left. There’s too much space between the radio item and its associated label and textfield. Etcetera. If you can do all that in less code than me…
Edited 2007-06-04 22:49
The size of the JFrame needs to be adjusted big deal. Like your not going to have minor issues between platforms (I wrote the sample on Windows). As you might expect, I’m not going to spend a ton of time implementing YOUR dialog. I did a rough layout with GridBagLayout so you could see it could be done quite simply.
Here is what I see on Windows.
http://www.cubeyellow.com/dialog.png
The labels and text fields on the left panel are not aligned left
If you cannot adjust these by looking at the code I provided then there are bigger issues. As I said in a previous post. If you are not going to spend the time to learn then the problem is with you. If Swing is too difficult for you then don’t use it. I could care less.
“The size of the JFrame needs to be adjusted big deal.”
That’s because it is a big deal. End users want a good-looking, consistent, usable dialog. How can you expect any developer to show a badly aligned and crammed dialog to end users? That attitude is exactly what OSAlerters and Slashdotters have been complaining about for years (“developers don’t care about users and can’t design user interfaces”).
“Like your not going to have minor issues between platforms (I wrote the sample on Windows).”
Well I wrote mine on Linux and the dialog showed up correctly on Windows the first time I tried it.
“As you might expect, I’m not going to spend a ton of time implementing YOUR dialog…
If you cannot adjust these by looking at the code I provided then there are bigger issues.”
The fact that you *have* to spend a ton of time on it already proves my point. I shouldn’t have to spend “a ton of time” to create such a simple dialog, even with perfect layout.
I can adjust them just fine, but why should I have to bother? Why can’t they make it easy so I can adjust them in 2 seconds? Why do I need 10, or maybe more, seconds?
“If Swing is too difficult for you then don’t use it. I could care less.”
Pure elitism. That’s exactly what people have been complaining about for years. When I criticize your holy Swing toolkit for bad API usability, you immediately jump into defense mode and blame the developer.
If you couldn’t care less then why did you write all these? But you’re right on one thing – I won’t use Swing. GTK is just as powerful (if not more) and a lot easier to use. But that doesn’t waive my right to criticize Swing.
Edited 2007-06-05 00:09
I can adjust them just fine, but why should I?
Seeing a though it was just a challenge you shouldn’t. I’m simply stating it is possible and quite easy to do.
Pure elitism. That’s exactly what people have been complaining about for years.
This is not elitism. I have simply taken the time to learn Swing. You are unwilling to do that. I never said Swing was perfect, it has some issues but it works for me and works for our company. We deploy on Windows, Solaris, AIX and HP-UX (sorry no Linux) and have learned how to deal with the tweaks needed for those platforms.
By the way. I did not spend a “ton” of time on your dialog nor am I going to. Go back and look at the time on the posts, less then an hour to duplicate your layout in GridBagLayout. Even though I did not get your spacing exacly as you would like it I think I met your challenge.
“Seeing a though it was just a challenge you shouldn’t. I’m simply stating it is possible and quite easy to do.”
And yet, when I add all that “quite easy to do” code to adjust the alignment and spacing (by wrapping things in panels), I would end up with roughly 300-400 lines of code. I would be back at square one. And that was the challenge – to create a GUI that looks nicer (proper alignment and spacing) in less code. If anything, I think you’ve proven that that’s impossible in Swing, even with GridBagLayout.
“This is not elitism. I have simply taken the time to learn Swing. You are unwilling to do that.”
I was forced to learn Swing for this assignment, whether I wanted or not. But it was all but pleasant. I already knew GTK, VCL (Delphi), wxWidgets and to some extend AWT, and Swing was the worst experience, right next to AWT.
And yet, when I add all that “quite easy to do” code to adjust the alignment and spacing (by wrapping things in panels), I would end up with roughly 300-400 lines of code.
All you have to do is adjust the insets on the GridBagConstraints! This does not push the code to over 300-400 lines! Again, you just don’t know what your doing in Swing.
I already knew GTK, VCL (Delphi), wxWidgets and to some extend AWT, and Swing was the worst experience, right next to AWT.
You just admitted the problem. The failure to lean Swing because you knew the others.
Only because you don’t know what your doing? Ever heard of GridBagLayout.
Or, to make it even easier, have a look at Matisse
http://www.netbeans.org/files/documents/4/475/matisse.html
Nobody said that it was going to provide 100% compatibility with .NET – first and foremost, its a platform for future development which will allow easier development in GNOME; second priority is compatibility with Microsofts own .NET.
With that being said, good enough compatibility which allows easier porting of applications is better than no compatibility at all. With more applications beginning to be written using .NET, both internal and large applications – the opensource community need to keep up with the play.
The opensource world don’t necessarily have to have 100% compatibility; for example, look at wine and mainsoft, for example. Hopefully as more application vendors start to look at Linux as a viable target, more software will appear.
Side note; Mono 1.2.4 now officially supports Solaris x86/x64, which hopefully will mean that you can compile Banshee media player as well – which has become an awesome piece of software in such a short space of time.
Nobody said that it was going to provide 100% compatibility with .NET – first and foremost, its a platform for future development which will allow easier development in GNOME; second priority is compatibility with Microsofts own .NET.
Sorry, but the only real, sole reason why anyone outside of Gnome would find Mono remotely interesting is because of its .Net compatibility. If this wasn’t the case then Mono’s developers wouldn’t feel the need for a Windows.Forms implementation, and wouldn’t talk about the feasibility of getting Avalon working, looking at Microsoft’s Silverlight and talking about Indigo.
From what we’ve seen so far, many people are just not keen on it being a universal way to develop for Gnome either. I also don’t see any web developers doing things currently in Java, PHP, Ruby or Python getting excited about it any time soon either.
The reason is that the rest of the world has moved to managed languages. If you write an app on Windows, it will be done in C# under .net. If you write an app on OSX, it will be done in objective C. On linux? C++, or even worse, C. Sure, we have Python and Ruby and whatnot, but those are really geared towards smaller projects. Nowadays, most schools don’t even teach C++ (let alone C) due to the low marketability of the language. Not only are Java/C# more efficient in terms of maintainability and developement speed, but by providing these APIs to linux, we will attract more developers then would otherwise write for the platform.
ASP.net 2.0 is completely and totally different then the technologies you listed. From what I’ve read, JSF will come close to offering what ASP does, but it is a new technology, and there is still a lack of an environment for JSP that offers what VS.net does for ASP.
both KDE, and ESPECIALLY gnome need a more modern language for their respective APIs. Mono is one of the few projects working to offer one.
Please tell us what platforms other than Windows Microsoft supports.
.NET is a single platform proprietary development environment.. it’s only through non-sponsored rogue and legally-shaky methods its able to run anywhere except Windows.
Until I can download something from microsoft.com to run .NET apps on something other than Windows…..ITS NOT CROSSPLATFORM.
Forget your angry pills this morning?
> Until I can download something from microsoft.com to run .NET apps on something other than Windows…..ITS NOT CROSSPLATFORM.
Here you go:
http://msdn.microsoft.com/net/sscli/
I know I’m going to get flamed for this because it’s not a full .NET platform with all the libraries, but the previous poster made me angry by making false claims.
>for Windows XP only
Bzzzt..
Yeah try again..here is a clue, cross platform does not mean Windows XP and Windows CE.
Damn. You’re right and I’m wrong, sort of … the thing is that the first version of SSCLI (then called ROTOR) was officially supported on FreeBSD (see
http://msdn.microsoft.com/msdnmag/issues/02/07/sharedsourcecli/). When the second version was released they tried to get it out of the door as fast as they could and to make that happen the SSCLI 2 package builds _out of the box_ on XP only. The “Platform Adaptation Layer” bits are still there though.
Oh and to nitpick a bit, the Windows CE and Windows XP are rather different platforms that use totally different code base (although the API is similar).
Edited 2007-06-05 21:50
Fairly high level, but good advice given in the article.
I’m in the process of converting a medium sized project (~50,000 lines of code) over to Mono, and was pleasantly surprised at the amount of work I’m not going to have to do after running MoMa. All said and done, I’m estimating about 20 hours worth of actual work.
As far as the porting strategies listed in the article, I personally think that for existing projects, compiler directives are the best way to go. By maintaining separate assemblies for platforms, you get better code separation, less chance of code written for one platform introducing bugs in another, and relative ease of making changes, plus performance doesn’t suffer since extraneous code is stripped out during compilation.
Of course it would be nice to have one set of assemblies for all platforms (runtime conditionals), but in real world scenarios this leads to larger/slower modules, and spaghetti code (‘if isMono do this, else do this’ sprinkled all over the codebase). The top two goals of code are maintainability and performance, and this violates both of those.
The rewriting code option is nice for new projects (or for projects that have the resources to start a rewrite…but most projects don’t have that luxury), but the caveat is that both platforms could end up taking a hit on functionality for some features to “just work” with only a single execution path.
Of course good judgment is key, and a blend of the methods mentioned will usually be needed.
Interesting, this is cool, nearly made my day.
Software
http://www.popsoftware.net/
I have followed Mono from the beginning. At the start there were in every release notes some news about Gtk# but in the last release notes you only read about Windows.Forms. Are Novell or the Mono Team planing to switch from Gtk# to Window.Forms as their “default” Toolkit? Also if you look at gtk.org, gtk# supports only gtk 2.6. I consider this as really bad if i see that more and more Gtk# apps enter GNOME (tomboy, beagle,…). Also i can’t find a Gtk#-developer mailinglist where the development of gtk# is coordinated. I wouldn’t say that Gtk# is dead but it seems like the progress becomes really slow and from the press release it seems like Mono focused more on Windows.Forms.
What do you think?
I have followed Mono from the beginning. At the start there were in every release notes some news about Gtk# but in the last release notes you only read about Windows.Forms. Are Novell or the Mono Team planing to switch from Gtk# to Window.Forms as their “default” Toolkit?
The explanation is simple, Windows.Forms is part of the libraries that make up the core of Mono, while Gtk# is a separate package.
So when we make Mono releases, we list the major achievements in the Mono release. Gtk# has its own release schedule and is released as a separate package.
Gtk# is a binding around an existing API, while Windows.Forms is a complete stack reimplementation and there are considerable more people working on Windows.Forms than the Gtk# binding.
Also if you look at gtk.org, gtk# supports only gtk 2.6. I consider this as really bad if i see that more and more Gtk# apps enter GNOME (tomboy, beagle,…).
You are not looking in the right places, and I suspect you are not a Gtk# developer. Gtk.org seems out of date most modern distributions ship Gtk# 2.8 or 2.10.
Also i can’t find a Gtk#-developer mailinglist where the development of gtk# is coordinated. I wouldn’t say that Gtk# is dead but it seems like the progress becomes really slow and from the press release it seems like Mono focused more on Windows.Forms.
You did not look too hard, but its listed here (third google match, for gtksharp mailing list):
http://www.mono-project.com/Mailing_Lists
New features in Gtk# are documented here:
http://www.mono-project.com/GtkSharpNewInVersion2x
New ideas, and the roadmap for it is here:
http://www.mono-project.com/GtkSharpPlan
And finally, all of our desktop apps are built with GtkSharp including the upcoming MonoDevelop and the Stetic GUI designer for Gtk# (and like some other poster on the thread, we also like the fact that Gtk# apps automatically work with all kinds of font sizes, internationalized setups and l-to-r and r-to-l fonts)
But Gtk# is a mature binding nowadays, and it is being improved, while Windows.Forms 2.0 is still in its infancy (we have Winforms 1.1 done, but we are about half way to 2.0). And there are a few thousand applications that we can bring to Linux if we complete the 2.0 work, which is why we have more developers working on Windows.Forms than Gtk#.
Miguel.
I saw that in Fedora 7 they dropped Beagle from starting at login. It consumed a lot of memory and people were complaining about having to turn it off. I have heard other issues with Mono in terms of not releasing memory when applications quit. The GUI features are nice and everything but how does it perform compared to a GTK application written in C/C++ or Python?
I have heard other issues with Mono in terms of not releasing memory when applications quit. The GUI features are nice and everything but how does it perform compared to a GTK application written in C/C++ or Python?
If an application does not release memory when it quits, then you have a kernel bug in your hands.
You can look at performance on the Debian language shootout page, it will give you an idea of where things are.
Last time we checked Gtk+ based applications (Python vs C#) C# consumed considerably less memory, but we have not done the tests in a couple of years, so you might want to check them again
Miguel.
Only because you don’t know what your doing? Ever heard of GridBagLayout.
I took an advanced course in Java at Northeastern and we completed a project in Swing using GridBagLayout. I felt like I was on the verge of pulling out my remaining hair. Having used Python and GTK widgets in the past, Java’s GUI API’s were infuriating. I ended up using a GTK-Java library to code the UI and all my stress went away. I would never touch swing again. It is crazy Sun hasn’t replaced it with something like GTK-java. In some ways, having Windows.Forms around is good since it is competition for swing and pushes development forward.
Edited 2007-06-04 14:12
“I ended up using a GTK-Java library to code the UI and all my stress went away.”
You should give SWT and Eclipse RCP a try. SWT wraps (using JNI, of course) native widget toolkits – Win32, Mac Cocoa, and GTK).
This gives Java GUI apps native performance and native look and feel, at least more so than Swing (generally speaking).
And what I’ve seen (and used) of both Swing and SWT (along with Win32, GTK, and QT), I have found SWT a bit simpler to use and learn than Swing (which is, admittedly, pretty complex).
Then there is QT-Jambi (or existing Java bindings for QT). Again, that will give native performance and look and feel.
And both SWT and QT-Jambi give full cross platform capability. It’s not compile once run anywhere like Swing is, it’s Package for each targeted platform. But that packaging is extremely trivial.
As for Mono/GTK# apps, I have found porting them from Linux to Windows extremely difficult (in my attempts to do so). For instance, GTK# apps like F-Spot, Banshee, etc, which run great on Linux/Gnome, can’t be run on windows, even with the full GTK runtime and mono.
Then there is Microsoft. I’m not trying to spread FUD about a very good technology (which I actually consider Mono to be very good). But, even on the ECMA standardized parts of Mono (the CLR and C#), MS still owns patents. And, even though they’ve made a “public pledge” to not sue or try to collect royalties on those bits, there is absolutely nothing, legally speaking, stopping them from doing just that.
And is there anyone foolish enough to trust MS to “play nice”?
Then there are the non ECMA standard bits of Mono – WinForms, ASP.Net, ADO.Net. Microsoft has already publicly stated that such implementations constitutes stealing of their IP.
Finally, need I remind anyone of Microsoft’s latest patent threats against Linux?
Are there intentions not completely crystal clear?
No matter how nice Mono is, and no matter how good a job Miguel and crew have done – using and/or implementing Mono is like trying to pet your friendly neighborhood coiled, rattling, rattlesnake.
Why take the risk? And yes, no matter how much anyone rationalizes it, the risk is very very real. Again, just remember Microsoft’s latest patent threats against Linux.
The good news is Java, which is now being licensed under the GPL, has the JCP, has both open source and multi-vendor support and implementation, is fully cross platform, is very mature, has a huge eco-system, it’s primary vendor/implentator (Sun) is extremely open source friendly, and has multiple (very good) choices for cross platform GUI development (SWT, QT-Jambi, GTK-Java, and yes, Swing).
It seems like, to me, which to choose (Java/SWT/Swing/QT or Mono/WinForms/GTK#) is a complete no-brainer.
You can choose the one with no legal risk and complete ease of porting, or you can choose the one with extreme legal risk (or at least extreme FUD risk) and greater difficulty in porting.
I know which one I choose (hint: It also makes a nice beverage!).
I know which I’ll avoid (hint: it’s also an infectious disease)
Edited 2007-06-04 16:03
I think the chances of Microsoft suing Free Software Developers for using Mono to write apps with non-Microsoft toolkits like GTK# are extremely remote. C# is just another language and the CLR is just another virtual machine, and there are no patents that will stand up in court for that category of software. C and Algol-like languages, object orientation, and VM’s like the Smalltalk VM or the Pascal p-code system have been around for 30 years or more.
C# is not the same as Java, it is just in the same family as Java, and I think it has its own distinctive personality. From the point of view of implementing Qt bindings there are several things that C# has the Java doesn’t:
– Properties which can be mapped directly onto Qt’s Q_PROPERTIES
– Unsigned types
– Operator methods
– Implicit type conversions which allow you to convert from say a QBrush to a QVariant automagically
– Namespaces
– Generic types that work with reflection. QtJambi uses generic types to define signals, and this may cause problems for non-Java languages running on the JVM (or it may not, I not sure).
– Structs, which are useful for passing a stack of args to native methods
– Upper case method names as a convention. Hmm, not sure if that is a ‘feature’, but it certainly makes C# code look different for the equivalent Java.
We’re quite close to doing a first release of the C# Qyoto Qt bindings, and people will be able to try out Qt programming with mono and decide for themselves. I personally think it works well, and complements the other choices for Qt programming like PyQt, QtRuby, QtJambi and native C++.
Edited 2007-06-04 16:25
>We’re quite close to doing a first release of the C# Qyoto Qt bindings, and people will be able to try out Qt programming with mono and decide for themselves.
Sounds interesting, count me in (as soon as I learn Qt
>Windows toolkits usually use fixed layouts.
Complete an utter bo**ocks. Why do non-windows programmers continually promulgate these total falsehoods. I’ve been writing Windows apps for 10 years and I’ve never had fixed layout.
Please note this is not a flame attempt, but a genuine question.
Hey, snowflake. Can you show me an example code of non fixed layout for windows API’s ? I always avoided programming on windows platforms because I couldn’t stand those fixed positioning for everything.
Alexandre Moreira.
It’s been about 5 years since I programmed on Windows, but from what I remember, controls in resource files were indexed by fixed co-ordinates and I don’t remember ever seeing anything related to layout managers such as the grid layout. I did a google on MFC “layout manager” and only got this link which confirms that MFC didn’t have one, but it is possible to roll your own: http://www.codeproject.com/dialog/layoutmgr.asp
That means, either the apps you’ve written 10 years ago used your own custom layout manager (in which case, I complement you on your foresight, but it doesn’t help the average MFC programmer that’s stuck with what Microsoft provides them), or you programmed on some non-C/C++ language like Delphi (which I think had layout managers), or you think you know what “fixed layout” means but don’t, or you’re BSing.
Edited 2007-06-04 16:49
Delphi doesn’t have layout managers either, at least not out of the box. You can align components to left/right/top/bottom but that’s nowhere near as powerful as and easy as the capabilities I’m used to in GTK. As a result, my dialogs tend to display differently for different users, depending on whether they have XP skinning turned on.
I searched for layout managers for Delphi but I haven’t been able to find anything.
Why feed Microsoft’s cow? It’s their cow; it will always be their cow. Just because you can milk it doesn’t mean that you own it.
What a baffling waste of programming time. I guess I should be more diplomatic and sensitive to people’s feelings, but it’s really difficult on this topic. There are so many other projects and challenges worthy of programming time, so many drivers that are needed that it doesn’t seem to make sense to work on a project that, if successful, will make give Linux’s competitor a better foothold.
I think because everybody’s free to invest/waste their own money/time at their will
I do appreciate the effort of Mono team but why we need to choose .Net/Mono when there are others choices out there ?
1. Java
2. GTK
3. Qt
4. wxWidgets (on linux is wrapper on GTK)
5. FLTK
We won’t know when MS will be FUDing again . However, I believe after a lot of people have chosen .Net , thinking that the application will run cross-platform, then MS will start FUDing.
Developing an application is a long term investment, why choose a framework that hv a under-threat future ?
The purpose of MS to introduce IronPython.Net and IronRuby.Net is very obvious. They want to attract the open source developer to the new era of OS -> .Net platform, and continue their monopoly.
If they can ignore the request Foxpro fans who has been supporting them for the last few year , and rather develop IronPython and IronRuby , I see no point supporting MS. MS , after all , is not a non-profit organization, they may give you easier/good start you will not have control of where are they going to.
Where do you want to go today ? I really hate this.
[Flame On]
Because we like it! .NET is a very interesting, well-developed framework. The development model simplifies the creation of both Web (ASP.NET) and Desktop (WinForms) application using a very similar model. .NET makes it very easy to rapidly create applications (language RAD feature) so that I can create a complete app (main windows, controls, logic) with only a few lines of code, JUST like I can with RAD toolkits like GTK. I also like the way ASP.NET applications are created – total separation of HTML elements of a page and the code-behind logic. In the code-behind page, I can treat the cotrols on the page just like I do on a Winforms app (well, almost!).
The bottom line, the .NET framework is a very cool framework, and worthy of utilization. It isn’t the big messsy world of MFC and Win32 API. I think most non-biased programmers would be pleasantly pleased with it.
[Flame Off]
I consider the merits of the .NET framwork worthy of attention. However, I do have to agree that there is the _possibility_ of Microsoft intervention at some point. But realistically, I don’t see how they would have much to stand on – .NET is a much more open framework that the past Windows standards (MFC, Win32). C# is an ISO standard. I really think Microsoft may not be embracing Open Source, but they are embracing Open Standards. I look at .NET as an Open Standard, and Novell and Mr. de Icaza are implementing this standard. I really think Mono is on safe grounds.
I do agree that .Net is a very interesting framework.
I do not understand what you mean language RAD feature, is it a .Net feature or the Visual Studio.Net feature ? Mind to explain futher ?
Code-Behind concept is cool but not new. Unfortunately, most of them are “runat” server side. When dealing with javascript, the strength of code behind is not obvious.
I do agree with you that .Net is much more open than MFC, Win32. Even Mono is safe ground , however, does .Net/Mono is a better choice ?
My personal opinion, I won’t refuse to code program on .Net , and I am interest to learn. However, if I would develop a large application , I really won’t put .Net/Mono as first option.
I do appreciate the effort of Mono team but why we need to choose .Net/Mono when there are others choices out there ?
Because none of those choices are .NET … wow, such a self-centered point of view.
BTW the only one there that appears to be even comparable to .NET is Java – the others are just toolkits. GTK# is already a .NET wrapper for GTK…
We won’t know when MS will be FUDing again . However, I believe after a lot of people have chosen .Net , thinking that the application will run cross-platform, then MS will start FUDing.
Apparently their FUD worked on you – but for some of us, .NET is not going away. At least with Mono as an option, Microsoft can go away, Windows can go away, but .NET software won’t
The purpose of MS to introduce IronPython.Net and IronRuby.Net is very obvious. They want to attract the open source developer to the new era of OS -> .Net platform, and continue their monopoly.
Last I checked, Microsoft didn’t develop those. .NET is all about multiple languages with a single CLR!
That’s one of the strong points of .NET, and something that doesn’t really exist elsewhere. It allows developers of all languages to write code in their preferred language syntax, and compile it to work with other code written in different languages. It also allows an excellent platform for language prototyping and experimentation with new language concepts.
You are basically creating conspiracy theories – and you are spreading the FUD. Two rights don’t make a wrong.
If they can ignore the request Foxpro fans who has been supporting them for the last few year , and rather develop IronPython and IronRuby , I see no point supporting MS. MS , after all , is not a non-profit organization, they may give you easier/good start you will not have control of where are they going to.
You just provided the perfect example of why projects like Mono should exist.
Foxpro fans should have gotten the hint YEARS ago that their platform was dying. Why aren’t there any OSS choices that allow Foxpro developers to continue writing with their favorite platform? Was it not appealing enough? Are Foxpro developers simply helpless and they can’t re-create an OSS version of their favorite development platform?
Mono exists because the merits of .NET and C# are clear to those who wish to use them. However, they do not wish to be tied to Microsoft or Windows.
[quote]
BTW the only one there that appears to be even comparable to .NET is Java – the others are just toolkits. GTK# is already a .NET wrapper for GTK…
[/quote]
I do agree that Java is the only one comparable to .Net. However, with the toolkits (as you think), the objective to develop a cross-platform (more platform than .Net/Mono) application already archive. Therefore, why do we need to choose .Net if the toolkit work well?
[quote]
That’s one of the strong points of .NET, and something that doesn’t really exist elsewhere. It allows developers of all languages to write code in their preferred language syntax, and compile it to work with other code written in different languages.
[/quote]
Isn’t it already exists in the OS ? For example, on Linux/BSD , we can code in python , perl, C , C++ etc.
We can work with the python program from a C++ through the OS. What are the advantages in .Net in this case, mind to share ?
[quote]
It also allows an excellent platform for language prototyping and experimentation with new language concepts.
[/quote]
This I really do not know, thanks for your info.
[quote]
You just provided the perfect example of why projects like Mono should exist.
Foxpro fans should have gotten the hint YEARS ago that their platform was dying. Why aren’t there any OSS choices that allow Foxpro developers to continue writing with their favorite platform? Was it not appealing enough? Are Foxpro developers simply helpless and they can’t re-create an OSS version of their favorite development platform?
Mono exists because the merits of .NET and C# are clear to those who wish to use them. However, they do not wish to be tied to Microsoft or Windows.
[/quote]
I never say Mono should not exist, I only said why choose Mono/.Net when develop application. The existence of Mono is very normal , if there is a demand , there is a supply.
Foxpro users want a Foxpro , not .Net , not Java, not others, this is the reason they do not choose others.
This is not a reason of the existence of .Net.
Last I checked, Microsoft didn’t develop those. .NET is all about multiple languages with a single CLR!
Last I checked, Microsoft funded those language developments and the main IronPython developer is a Microsoft employee. Asking why Microsoft is doing that is a pretty reasonable question.
That’s one of the strong points of .NET, and something that doesn’t really exist elsewhere. It allows developers of all languages to write code in their preferred language syntax, and compile it to work with other code written in different languages.
The notion of language neutrality in .Net is absolutely bogus, and I just wish people wouldn’t keep regurgitating Microsoft’s marketing material and handing it around as fact after all these years. Even Microsoft has dropped that angle.
Think about the notion of language neutrality in .Net logically for a second. The whole point of having a Common Language Runtime and the Common Language Specification was so that you could plug apparently different languages into the CLR and get them all to run happily together and reuse each others’ functionality and code. The only way you can do this feasibly is if each .Net language compiles to the same underlying IL code, which it does.
Think about that for a second. You have several higher level languages that compile to exactly the same underlying low level language, in a compatible way. The net effect of that is that those higher level languages are all the same, and differ only in syntax.
One can reasonably ask, “What’s the point of that?”, and they do. VB developers have looked at VB.Net, have seen a language that is a long, long way away from the RAD environment that they once knew, with all the complexities and overhead of OO development, and are asking themselves “Why don’t we just learn C#?”; “What’s the point in VB?”. What .Net needed was a decent RAD environment implemented on it – for VB. If you want to provide something different with Mono that Microsoft isn’t, and attract a ton of Windows developers, do that.
This is why the notion of Python and PERL as .Net languages from ActiveState died a death, because in porting them as .Net languages you lose any of the reasons you’d use a different language like Python or PERL in the first place! People have realised how useless this is now as IronPython and IronRuby are re-implementations of those languages and their environments to run on .Net, without strictly using the CLS. However, you still have some trade-offs to make in what kind of .Net compatibility you can provide versus being compatible with each particular language, and you still can’t reuse modules built for use in Python or Ruby or vice versa. I mean, read this:
http://www.codeplex.com/IronPython/Wiki/View.aspx?title=Exception~*…
and the stuff around ‘When Worlds Collide’.
Mono exists because the merits of .NET and C# are clear to those who wish to use them. However, they do not wish to be tied to Microsoft or Windows.
It’s too late I’m afraid. The article actually talks about porting Windows applications with WinForms, which is a Windows technology you have to create an implementation of and port if people are to take their applications from one platform to another and if Mono is to be cross-platform. It’s very much an all or nothing thing, and if you think that you can get away with not implementing something like Indigo then eventually you get sucked into implementing it by people who are asking “Does Mono support Indigo? No use to me then”. That’s why WinForms has got so much attention from Mono, and why few see GTKSharp as an option. It’s simply where the weight is.
That’s what gets me about Mono. There’s an awful lot of hot air expended about getting WinForms ported, talking about running Silverlight under Mono and debating whether they should run around like headless chickens implementing things like Indigo (all Microsoft technology incidentally ;-)) presumably to get people to move to Linux………somehow. However, once people get there there’s no IDE or development tools available like Visual Studio, and for something that looks .Net compatible Mono provides no way of feasibly using their existing COM components.
The notion of language neutrality in .Net is absolutely bogus, and I just wish people wouldn’t keep regurgitating Microsoft’s marketing material and handing it around as fact after all these years. Even Microsoft has dropped that angle.
Think about the notion of language neutrality in .Net logically for a second. The whole point of having a Common Language Runtime and the Common Language Specification was so that you could plug apparently different languages into the CLR and get them all to run happily together and reuse each others’ functionality and code. The only way you can do this feasibly is if each .Net language compiles to the same underlying IL code, which it does.
Are you f–king kidding me? Well then I guess every language available for x86 is the same because it all compiles to machine code.
See this? This is me rolling my eyes at you.
Are you f–king kidding me? Well then I guess every language available for x86 is the same because it all compiles to machine code.
Oh right. So if I compile a class in Objective C, say, another one in Java through GCC and another in C++ to native code then all those classes will be equivalent and they will all be capable of being reused across all those languages will they?!
Oh, and these languages all have common datatypes do they, so an integer in C++ and Java is equivalent if I decide to do the above, is it? Either that’s the case, or you haven’t the faintest idea what I, or even you, have been talking about.
Compilation to IL in .Net, and making a .Net compatible language, is entirely different and it places onerous restrictions on each language that causes them to lose anything that made them different in the first place. Get it? Did you read that link I gave in that post as well, or did you just get all excited? :-
http://www.codeplex.com/IronPython/Wiki/View.aspx?title=Exception~*…
See this? This is me rolling my eyes at you.
Watch me not be surprised at how little a clue you, and the people who modded you up, actually have.
It’s customary to try and work out what someone is talking about before making a bit of an idiot of yourself.
Edited 2007-06-06 17:00
You tried to argue that there is no language neutrality because:
“Think about that for a second. You have several higher level languages that compile to exactly the same underlying low level language, in a compatible way. The net effect of that is that those higher level languages are all the same, and differ only in syntax.”
The same can be applied to all compiled languages compiling to machine code. It’s a ridiculous argument and most people can probably see that except apparently you.
A .NET language can implement more abstract data types. There is a PHP and Perl for .NET. Those are drastically different languages than say, C# or C++. The data types are not really the same.
I just don’t understand what actual point you are trying to make.
The same can be applied to all compiled languages compiling to machine code. It’s a ridiculous argument and most people can probably see that except apparently you.
Bollocks. You know very well what I was talking about and I explained it in detail. Creating a moderately .Net compatible language is an entirely different thing thatn compiling something to machine code.
A .NET language can implement more abstract data types. There is a PHP and Perl for .NET. Those are drastically different languages than say, C# or C++.
No. Perl and PHP have been retrofitted on to .Net. They’re not the same thing.
Again, I’ll ask you. Did you read that IronPython link I gave which talk about the pitfalls involved in creating such a language on .Net, otherwise you’re talking about nothing?
I just don’t understand what actual point you are trying to make.
Well quite. If you don’t understand it, don’t bother.
“If they can ignore the request Foxpro fans who has been supporting them for the last few year , and rather develop IronPython and IronRuby , I see no point supporting MS. “
Yeah, like Microsoft is going to throw guys like Jim Hugunin and Jon Lam (the lead devs of IronPython and IronRuby, repectively) on Foxpro. Both of those guys joined Microsoft explicitly to develop IronPython and IronRuby; they have no interest in Foxpro (and likely lack the knowledge to be able to work on it). Microsoft has multiple teams that work on their own stuff. The existence of IronPython has nothing to do with Foxpro.
>That means, either the apps you’ve written 10 years ago >used your own custom layout manager (in which case, I >complement you on your foresight, but it doesn’t help >the average MFC programmer that’s stuck with what >Microsoft provides them), or you programmed on some >non-C/C++ language like Delphi (which I think had layout >managers), or you think you know what “fixed layout” >means but don’t, or you’re BSing.
You guessed well, I used Delphi, which makes life so much easier compared to something like MFC (which I have tried, and quickly untried). Having both used Delphi and Winforms, Delphi still has the more mature GUI library. Eg Winforms has not dockable windows support, you have to either go to a third-party solution or use PInvoke.
It is not true when people say that Windows has to be programmed using fixed coordinates. I am sure I would have to use fixed coords on linux if I used the wrong development tool, but it doesn’t mean that linux (windows) uses fixed coords.
>Hey, snowflake. Can you show me an example code of non >fixed layout for windows API’s ? I always avoided >programming on windows platforms because I couldn’t >stand those fixed positioning for everything.
It always amazes me at how limited our knowledge is in the computer world. Geeks can be a very conservative lot and tend to have very limited exposure to the variety of tools and developments kits out there. I think that if you use MFC or raw Win API then you have a lot of work on your plate, however, just like linux, there are other solutions, such a Delphi. I presume you’re familar with Delphi.
Uhm, if by “no fixed layout” you meant Delphi, then I’m disappointed. Delphi’s support for dynamic layout is a joke for anything other than the main window. Out of the box, it only supports aligning left, right, top and bottom, and to fill up all available space. How do you build resizable *dialogs* in Delphi?
You’ll have to simulate that with aligned panels, but that’s a real pain. For instance, you’ll have to put 4 panels in a single panel just to simulate padding inside the panel. All this is trivially solved by the GTK box model.
>Uhm, if by “no fixed layout” you meant Delphi, then
>I’m disappointed. Delphi’s support for dynamic layout >is a joke for anything other than the main window. Out >of the box, it only supports aligning left, right, top
>and bottom, and to fill up all available space.
I thought someone might come back to me on this so I just quickly put something together and it works fine. Yes I admit to using panels, two of them in this case but I always use panels in a window anyway, and dropping one on a form with a mouse click is not difficult. The only thing I was really worried about (which was an issue some years ago) were OS enforced font changes, but I just tried that and it was ok. I tried it on jedit (java app) as well and that worked fine.
One of the nice things about Delphi is the IDE, true GTK has glade (I assume I am right?) but compared to the Delphi RAD its not as polished, admittedly I only tried it once. What I don’t like is when people spread falsehoods, I will take it on faith from you that GTK coupled to Glade is a very good match and makes programmers such as yourself very productive, but Delphi is pretty good as well and at least compared to Java, the level of productivity seems much higher, I suspect this because I’ve worked with java programmers and GUI development for them does seem slower, and more tedious as far as I can tell. Perhaps this explains why there are only a few java desktops apps.
Looking at jedit just now, which is probably one of the poster boys for a java app, it doesn’t look very professional. eg look at the global options dialog box, looks like an amateur laid it out, of course it was the layout manager that was responsible. If a human had laid it out it would look much better.