Robert Shearman schrieb:
Peter Beutner wrote:
IMHO all this stuff goes a bit too much into the wrong direction.
I really fear that this will end up with vendors loudly advertising linux support and proudly putting linux stickers on their products where everything you find inside are just the same windows .exe files and a readme stating that these will work fine with wine. Which at least is not what I would like to see.
Why? Wine is effectively just a different toolkit, like QT or GTK (albeit much larger) that give applications a Windows, KDE and Gnome look respectively. Take Notepad for example - with some slight modifications you could even modify the File Open dialog to only show the Unix namespace. Is there any reason that this application can't be a fully fledged part of the desktop?
Wine is _not_ just a different toolkit. Just look at all the "nasty" stuff wine has to do to emulate the windows process environment. This is not exactly what I would prefer as an ideal environment when I had to develop an application.
The main thing the _developers_ should be pointed to(if they care about their product on other platforms then windows) are some decent docs about platform-independent programming :p
Sure. While you're at it give them some docs about globalization practices and efficient CPU usage. These are all nice to have things, but you have to face it that if you're a developer at a software company with a deadline then these are the first things to be ignored. You also have to bear in mind that it is incredibly difficult to do platform idependent GUI programming, whilst still maintaining the Windows look.
Nobody said it's easy or that it will happen over night. But it can/should be the long term goal. Besides gtk+/qt are imho quite mature to use as cross-plattform gui toolkits.
Maybe it's just me but when reading all this I got the feeling that writing windows applications(which work with wine) is just *the* way to go.
It is the cheapest way for companies and it gives good results for the users. What's wrong with that?
See above. Wine does a lot of "tricks" to emulate windows behaviour. And the more you use some complex window api the more is the chance that wine just can't implement it the way it works in windows but has to use all sorts of workarounds to get it to work under linux. Sure all that probably won't interest any manager in a company and probably won't stand against the "money" argument. But as a developer I would always vote for doing a little bit of extra thinking by going the platform independent way.
Not that I generally disagree with what you wrote. Actually it's mostly totally fine.And it's definitly a good thing when vendors care about their product running with wine or companies migrating to linux trying to get their highly-specialized-app to work with wine. But imho it _shouldn't_ be the long term solution.
Wine is a very good way of testing the waters with a Linux market. If a significant part of the market share starts coming from Linux or other Unix operating systems then the company can start offering winelib extensions that integrate better with the environment in which they are running.
I doubt that this will happen. If the windows version works with wine the company will more likely continue to work on that. See your money argument.
However, you have to face facts that Linux is a hostile environment for commercial companies - constantly changing APIs, lack of regression testing by distributions, lots of variations meaning lots of testing needed and different standards on different distributions. Wine is a layer on top of that, which provides a degree of stability.
As long as wine doesn't break. And we all have seen how easy wine gets messed up when something in underlying linux software changes. May it be the kernel or X. Besides wine doesn't do all the testing for you. You still need to do a lot of testing on different configurations.