?

Log in

No account? Create an account

Previous 10 | Next 10

Sep. 18th, 2008

ubuntu, wine

"Native Ports" are not better

One of the stranger yet persistant criticisms of Wine I hear is the fear that compatibility is somehow bad for Linux. When users can run an application with Wine, it is argued, then developers won't bother to make a proper native port.

Well, yeah.  That's exactly the point - developers shouldn't have to. Properly porting an application is a huge deal.  You have to rewrite Direct3D using OpenGL, rewrite DirectSound with OpenAL or SDL, remake the installer, and then worry about things breaking between different distributions or even different releases of the same distribution.  Even with simple apps, that's a lot of work - not surprisingly, most developers don't bother at all, especially when they don't have any Linux people.

Now, suppose you're lucky enough to have an application already works fantastically well in Wine.  What advantage does any of that extra "native porting" offer?  In that case, you're looking at different installation locations, a launcher in Applications->Games rather than Applications->Wine->Programs->Company->Game, and a bunch of complex behind the scenes changes that the user will never see.  That's a very small benefit for so much extra work, and even that benefit might disappear if we extended the MSI installer and let Wine make the application look native.

Now, the comparison isn't completely fair, as Wine rarely works perfectly.  There are thousands of bugs in Wine, and a substantial number of interface issues that can make usability downright suck

But Wine's issues are all fixable and, frankly, easier to do than rewriting even one massive application like Photoshop or World of Warcraft, much less rewriting all of them.  If we do the work in Wine once, then we never have to do it again.  The value of native ports is to work around Wine's deficiencies; if we fix Wine, then we don't have to waste effort demanding companies rewrite software that already works on Windows.

Winelib, Microsoft.build

Wine should be no different from any other system library we depend on and link programs against, like GTK or Mono.  Porting (and compiling) an application should be as simple as selecting a "build for Linux/Wine" from within the IDE and then answering a few Linux-specific questions like where in the Applications menu to put the old start menu entries.  Assuming the code isn't architecture specific, this same method could be used to port an application to any cpu arch that Linux and Winelib run on (say, Sparc).

This may eventually be possible with Mono's Microsoft.build, which can already handle Visual Studio project files.  Or it might be done through a magic python script that turns a visual studio project into an scons-powered build system.  Either way, improving Wine and the ease of porting seems like a much more realistic option than rewriting major parts of dozens of applications.

Wine and .msi might be the first working "cross-distro installation framework"

An interesting side effect of all this is that Wine has a very stable API to target.  Aside from performance and the user interface, acheiving compatibility with that API is literally the only kind of improvement Wine can make.  Microsoft was very intentional about this: you write one application, and it works on all recent enough versions of Windows on all systems.  Wine has to be the same way, as one of those systems.

This is the same goal of some of the more aggressive Linux standardization efforts; write an application once, and have it be binary-compatible across multiple distros.  It's become pretty apparent that won't happen - except with Wine, which has inherited that necessity from Windows.


So, will there come a day when an intentionally Linux application is written largely in Winelib because it'll be binary-compatible across multiple distros?  Quite possibly.  And it'll be easy to port to Windows as well ;)
Tags: ,

Aug. 18th, 2008

ubuntu, wine

A brief impression of Linux Hater

I'd be bit of the past, Flash just a pirate for compression but it's obvious that is have samba code; and software on our time, in just keep things I also all the ever cared about your own blog post: and you'll be magnified; look bad it let's them to make FOSS users that, you and their profits, actually better than Windows Flash for Linux which is out all, got it yourself?  People and that's you file a choice is the audio systems that.  So far as if I couldn't possibly want; to integrate with difficult.

  Well, it difficult for Kde people others it's called documentation and or pa alsa would be pure!

  I saw had a FOSS users, already called Silverlight and call it is the only to release and another one of making things listed on the Debian over which glibc and thus the software?  Ubuntu?

  Refine that there's not is supposed to get fixed?  Toponce I don't talk of right click the code that the fuck, if you are hurting it spec and it: again, on your rules; respect their customers former freetards sit around a lot of it.  What it well as An OpenMoko Freerunner the market, share: is the case for the software.

  Angry?  Or Ubuntu; is plugin that it's written, a default, for saving children?  Redhat will be inferior, magnified.

  Look at least minutes: after some really, comes down.  One channel click (the Slashdot continues: to bust out of the Michael Phelps of the one more than Windows I had a good place at me the choices they you care about a few guidelines for instant messaging: giving a whole dozen women in window such A non trivial).  Your goals, you don't had a month update my wife but that's not open up on the fuck do.  O try to suck even if that's a spaghetti of the is that figured out that others Ubuntu Masturbating Monkey.

  And Ubuntu Linux that have even try going to FreeBSD or pa Ubuntu are getting closer and the closed IE works, for two.  So much as I also go back to have Notepad and FOSS users.  Hopefully it could not play the comments, but best of configurations that none of you see a few Reasons to understand and testers who knew just have anything on Linux: moves farther and don't like NVIDIA are a stable kernel And what, the winning Flash in a tad busy these guys lets blame Firefox.  Sure the one.

The above was created using dadadodo and recent linuxhater posts.
Tags:

Aug. 16th, 2008

ubuntu, wine

Using the right metaphor

Not long ago, I was actively involved in a local movement to use single transferable voting in the city of Davis' city council elections.  STV is really a simple system at heart - casting a ranked ballot is in many ways easier for a user than properly choosing a single candidate in a plurality election.

Intuitively, when you give voters a single choice, they want to pick their favorite. In a plurality election with vote-splitting and spoiler candidates, however, this is a terrible strategy for actually getting representation.  By contrast, ranking some of the candidates according to your preferences is a simple process, and under STV this is actually a good strategy.

There were other reasons to support STV than usability, of course - proportional representation in general is better than the plurality voting system that most American cities like Davis currently use.  Opponents of STV, however, inevitably brought up the same complaint about STV: that it was too hard to understand for the average voter.

I, of course, disagreed.  I don't understand how my car works, yet I depend on driving. All I really need to know is how to use it. We say the same thing about software, even going so far as to say the user shouldn't have to understand how it works. I felt the same way about voting: as long as the average person knows how to cast a ballot, and as long as the counting system actually rewards such voters with representation, then it doesn't really matter if most people don't understand the intricate details of the counting process.

This wasn't good enough. People were, justifiably, afraid to support changing the voting system to something they didn't understand, especially when they felt that the current system worked well enough.  It didn't help that most of the people in our movement were math majors from the local university who knew about the theoretical intricacies of voting systems and would use words like "droop quota" when giving a 10 minute explanation of the STV counting process.

Essentially, the current system was Windows, and we were the nerds telling people Linux was great because of the terminal.

I had two tasks, both of which seemed herculean at the time: convince people that the system we had been using for hundreds of years was an affront to democracy, and then teach them how STV worked without making it seem complicated. Our only advantage was branding: virtually no one in America had heard of STV, so we called the process "choice voting."

I resolved to do both in 60 seconds. The inspiration came to me when I was tabling at the local farmers market.  I asked one of the merchants if I could have his box of multicolored toothpicks if I bought some of his fruit.  He agreed, and I brought the box back to the table and told my peers, "guys, I want to show you something."

I reached into my bag and took out two groups of fruit - a white peach, a yellow peach, and three different kinds of apples.  I then got 20 toothpicks from the box, grouped them by color, and laid them out in front.  "I'm going to teach you about choice voting, and I'm going to do it in under a minute."

I announced we were having a food election, and that we needed to decide on three fruits to represent the community.  I laid out the toothpicks - 6 were in front of the two peaches, and 14 in front of the apples.  If these were the favorites of the voters under the current system, what would the count say was our favorite fruit?  He named the top three fruits - one apple had 12 toothpicks in front of it; the others had only one, losing to the two peaches.  "That's absurd, isn't it, picking two peaches when they're only about 1/3 of the vote?"  He nodded in agreement.

I moved the apple toothpicks into different piles, "If these apple voters had been a little smarter and spread their votes out more, they would have won all three spots."  Again, he nodded.  "But it'd be equally silly to pick all three apples too, wouldn't it?" He agreed - if peaches were a third of the voters, then intuitively they should be one of the three chosen.

I moved the toothpicks back to their original layout. "OK, now we're going to do this with choice voting." I explained the droop quota in two sentences - "There are 20 toothpicks, so the minimum you need is six.  If it were only five, then four of them might win." I then asked an obvious question to elicit an obvious response, "Now, does anyone have six?" He pointed to the green apple, with its 12 toothpicks.  The green apple was the first winner.

Vote transferring was next. "Green had twice as many votes as he needed, so to avoid wasting that excess we're going to transfer half of them to their second choice." Eight of the toothpicks were red, and four were yellow.  I took half of each pile and moved them right where he expected - four in front of the red apple, and two in front of the yellow apple.

We exchanged smiles, both seeing the simplicity of what was happening.  "Now, does anyone else have 6 votes?"  He shook his head.  Ok, then, who has the least?  He pointed to one of the peaches, which had only two toothpicks in front of it.  "All right, then, this peach loses.  So now we transfer his votes to their second choice, the other peach."  The other peach now had six votes, becoming the second winner.  From there it was obvious what happened next - the yellow apple was elimated, and the red one took the final seat.

I gave some commentary, which would later become talking points.  Everything about the three fruits we chose made sense.  The overwhelming favorite green apple was there, the diversity of taste was represented by the better of two peaches, and the red apple beat out the less preferred yellow apple.  In a short demonstration, I had made a concept as complicated as STV feel simple and intuitve, even moreso than plurality voting. I practiced it one more time, and then began showing it to the general public.

A pair of women who had never heard of choice voting were my first victims.  They'd seen our table before, but had never really had it explained to them.  I gave them my food demo, and at the end their faces lit up and they gasped as though I had just done a magic trick. In the span of a couple of minutes, they had gone from general apathy to serious choice voting supporters.  They even began to show understanding by empathizing with the peaches; both women were black, and were excited by the idea of proportional representation helping minorities.

I continued the demos throughout the day. "Excuse me, have you heard about choice voting?" we'd ask.  Many said they had, but didn't quite understand it or, at least, were worried that other people wouldn't. In the past, we'd tell them that the Irish use the system and they're no smarter than us. Now, we'd say "Well, do you have sixty seconds?"

Proportional representation became intuitive too.  When ordering pizza for a large party, for instance, only a sociopathic host would insist that none of them be vegetarian because only 1/4 of his guests were. It didn't matter if they were black, a conservative, a Green Party member, or just someone who hated pepperoni.  Food made sense, and in that frame anything other than proportional representation felt downright unfair.

All we needed to do was choose the right metaphor, and give a simple example.  The rest of the complexity was there only if they wanted it; we were more than willing to talk about Arrow's theorem or the mechanics of calculating fractional quotas when someone asked, but for most people they were content with the brief overview the demo gave them.


When you have a good idea, getting support really is as simple as making education simple.  When I got home I began working on the Wikipedia article.  I made a neat table out of my example and began simplifying the text, especially in the introduction.  The article would later become a featured article and appear on the front page, shortly before Davis held a referendum on choice voting.  It passed.


We in the free software community have a good idea. To us, it is obvious. To most people, however, things are just fine as they are, and they are justifiably afraid of making a big change they don't fully understand.

Teaching users how the system works shouldn't be necessary.  Complexity like the mechanics of counting votes or the enabling of a video driver can be hidden unless someone wants to know.  When we can't hide it, we can at least make it feel simple by using the right metaphor.  A good interface does all of this, like the demonstration with fruit.

But so does a good Linux advocate.  He doesn't talk about license agreements or open source code development or security vulnerabilities.  Instead, he gives a story, one that shows the idea on its own merits.  I don't talk about code anymore with strangers, just like I don't talk about Droop quotas.  Instead, I tell them how I once received a letter from the administrator of a school computer lab, personally thanking me for my work on the Wine package - with it, he had been able to convert the school's computers to Ubuntu, saving them tens of thousands of dollars in Windows licenses and hardware upgrades.  It was as though I had personally donated that money to the school, all for nothign in return - that the system was usable, functional, and practical enough was obvious, and if they wanted to ask, I'd gladly tell them more.

Aug. 11th, 2008

ubuntu, wine

Why Wine sucks in Ubuntu Hardy and how I plan on fixing it for Intrepid

A few days ago, I outlined a few reasons why Wine sucks. I love Wine, but if we want to be honest with ourselves we need to acknowledge our deficiencies so we can talk about how to fight them. It's the same reason we have open bug trackers, open mailing lists, and open code.

Memory issues:

Running 16-bit applications that require the first 64k of memory doesn't work
. You run an old DOS game, any .com program, or even a Windows 98 era program that used an older version of Install Shield, and it flat-out refuses to work while giving a cryptic error in the terminal about the preloader being unable to access DOS memory. To avoid this error you have to manually edit /etc/sysctl.conf in a way sure to frighten everyone.

How I am fixing this. I already have, at least in the Wine package. Wine now installs an override setting to allow the early memory to be accessed in the (new) /etc/sysctl.d/ folder. However, this bug also needs to be closed, which I suspect is a relatively simple fix that I can do myself. This change unfortunately cannot be backported to Hardy because it lacks the newer procps.

Sound issues:

Sound and Wine don't work well
. You run a Wine application and then other programs can't use audio. Flash movies won't go past 2 seconds. You stop hearing IM beeps. You fire your gun in Half Life and don't hear the shot until over half a second later.

How I am fixing this. All of the above problems came with Hardy's change to PulseAudio. Wine doesn't have a pulseaudio driver, and pulseaudio 9.10 itself doesn't handle Wine's requirements very well, even through the pulseaudio-alsa translation layer. I've already filed an upgrade request bug for the newer PulseAudio, which can likely be included before freeze. The automatic use of Wine's alsa library and PulseAudio's alsa-compatibility module would then be sufficient. If this still doesn't work due to latency issues even in the new PulseAudio (which was supposed to fix things), we can look into including the experimental pulseaudio driver for Wine. If THAT doesn't work, another alternative is to have Wine suspend pulseaudio at launch, or use padsp and the oss sound module by default. At worst, things will be just as bad as Hardy.

Application issues:

You run a Windows application, and it doesn't work.
These are all problems with Wine itself. At this point, other than the above I'm not aware of anything that doesn't work in Wine because of something Ubuntu-specific.

How I am fixing this. My main responsibilty as a packager is to select the best version of Wine available for the distribution. For Hardy that meant using a recent version of Wine and backporting fixes for whatever regressions I could find before release, and then backporting 1.0 when it was released. For Intrepid, this means either sticking with 1.0.1 and backporting various fixes that have since come out, or personally stabilizing a Wine release around beta-time.

Usability issues:

Double clicking .msi files doesn't work. You go download steam, and then you double click on the installer, and Gnome freaks the hell out and doesn't know what to do with it. You then have to manually tell it to open with Wine, or, worse, run wine msiexec /i in a terminal window.

How I am fixing this. After having my bug report fixed in shared-mime-info with my patch for recognizing .msi files included, all Ubuntu needs is to use that newer version (or just that patch). The preferred way to do this is to fix the package in Debian and then ask for a sync of the package, however the Ubuntu package is already many versions ahead of the Debian one. The best way forward is to simply update the package myself and then let the Utnubu team try and shove the update back to Debian.

Installing Gecko is annoying, and sometimes fails so fake Internet Explorer doesn't work.

How I am fixing this. Creating a new wine-gecko package and bundling a local copy of Gecko alongside Wine. Wine can be configured to search the local filesystem for Gecko before downloading it off the internet, and this is the surest way to ensure a working copy everywhere. Unfortunately, the Wine still requires the Windows version of Gecko that in turn requires Visual Studio to build; since it can't compile on Linux with free software, the wine-gecko package will have to go in Multiverse.

Things in the Wine menu aren't integrated into the desktop. Winecfg is too complicated and is a big mess. Wine uninstaller is ugly and not in the normal place for uninstalling applications. The browse C:\ drive link isn't in the Places menu.

How I am fixing this.  When I got lucky enough to be sponsored to attend FOSSCamp and the subsequent Ubuntu Developer Summit in Boston for the Hardy release, I came up with some good ideas for further integration.  One of them was to have Wine configurable from the command line so that we could write our own custom UI on top, and make it work perfectly elsewhere within the desktop.  It's taken a while, but another developer has made serious progress with this (via the Wine reg.exe module). We made an informal agreement: I'd design the interfaces and make all the GUI widgets, and he'd make the backend work. Things are looking promising so far, and with some serious work these next two months we may be able to hide Winecfg and the Wine Uninstaller completely by Intrepid.  Configuration would instead be done through a simplified System->Preferences->Windows Applications or by right click->Properties for individual apps.  Uninstallation, similarly, would be done by adding a Windows Applications section to Gnome-App-Install.




I appear to be making negative progress with Wine. Wine is getting better, and I'm accomplishing some things, but my todo list is growing even faster. I've been considering asking the community for donations so I can afford to work on Wine full time.  If I had enough cash to cover food and rent, I'd be willing to work on Wine nonstop right up through Wineconf at the end of September.  Right now, however, it's almost 6am, three people have already asked me where this blog entry is, and I need to go to sleep so I don't miss the tutoring job I have tomorrow.

Note: The above was supposed to be posted days ago, however I am stuck with Comcast as an Internet Service Provider.  On the third day of the outage, they were kind enough to call me reminding me to pay my bill online.
Tags: ,

Aug. 6th, 2008

ubuntu, wine

Wine sucks and I'm not going to pretend otherwise

Wine is a lot like my cell phone.  It sucks, but it would be really awesome if it didn't.  As much as we'd like to, we can't give up on it entirely.  So the only reasonable thing to do is try and make it suck less.

Part of that, of course, is understanding why Wine sucks.  As the Wine maintainer for Ubuntu, I deal with this every day.

Wine's Application Compatibility Sucks.  There are a bunch of applications that simply don't work right.  Wine keeps getting better, so this list keeps shrinking, but many of the most important applications still don't work.

Wine's User Interface Sucks.  Double clicking msi installers still doesn't work. No one can figure out how to associate a file type with a Wine applicaiton.  Winecfg is an ugly, scary monstrosity that violates basic usability norms like not having one tab refer to another.  There's no easy way to edit per-application settings.  Wine's uninstaller is separate from Gnome's, and the system can't even clean up the old start menu entries after completely removing Wine.  Worse, we don't even have gui options for a lot of important registry settings (which, additionally, shouldn't need to be changed by the user in the first place.)

Wine doesn't work with the security model. You try to run a 16 bit application, and it doesn't work.  At all.  Wine needs the first 640k of memory, and our new secure kernel blocks it.  You have to run a cryptic terminal command to fix this temporarily, or edit something in /etc.  This is awful.

Wine doesn't work with PulseAudio.  Wine doesn't have a pulseaudio sound driver.  This really really sucks, since Wine runs incredibly demanding sound applications.  So you run Wine in alsa mode, and hope for the best.  Then you play Half LIfe and note it takes about a half a second after you pull the trigger for your gun to make a noise.


Tomorrow, I'll give my plan for fixing these issues.  All of them.
Tags: ,

Aug. 3rd, 2008

ubuntu, wine

Bundling Windows Mono 2.0 with Wine

Mono 2.0 is set for a stable release in September.  This puts it right on target to be shipped with Intrepid.

Wine needs an implementation of the .NET library in order to run a good chunk of Windows software.  Some programs won't even install without .NET, even if they don't use it at runtime (programs obtained through the Gamers Gate downloader, for instance, behave this way).

Bundling Mono with Wine has so far been largely pointless - Mono simply didn't support enough of the API to attempt to run these programs.  That's changing a bit with Mono 2.0, and hopefully not having Microsoft's .NET runtime won't result in a completely useless setup.

The goal is to be able to run programs with "mixed mode assemblies" - that is, programs that use both .NET stuff and also call the stock Windows APIs.  These impure programs can't possibly run on Linux without being rewritten, no matter how good Linux Mono gets.  This is where the Wine and Mono projects overlap.

So, here's the idea: I create a wine-mono package which has the Windows version of Mono 2.0 included.  We then jerry-rig wineprefixcreate (the program that runs the first time you use Wine if you have no ~/.wine directory) to also install Mono 2.0 and set it as the .NET handler in the same manner as winetricks.

Ideally, this means most .NET apps the user wants to run will work out of the box (provided they have a clean Wine directory).  If the user wants, they can also install Microsoft .NET on top of what we provide (using actual winetricks this time), and that should still work.


Of course, actually making these modifications and properly packaging up Windows Mono will be quite a bit of work, and I have a huge Wine todo list already...
Tags: ,

Jul. 28th, 2008

ubuntu, wine

Wine should "embrace and extend" the Microsoft Installer format

I had a thought late at night, and decided to post my idea to the Wine mailing list.

What if we created a standard for passing some sort of wine-specific
metadata in an MSI file? Windows would ignore it, but application
developers could use it to include some helpful Linux-specific Wine
instructions like what windows version to use, a custom .desktop file,
or even instructions to install into a completely independent Wine prefix.

This way, a single .msi file could be a true universal installer for
both Windows machines and Linux machines. Moreover, there'd be less of
a need to create custom Wine packages for applications like Picassa
since a lot of that functionality would be abstracted into Wine itself.
Surprisingly, the idea wasn't that preposterous.  It'd take a bit of work to implement in Wine, and likely most Windows developers wouldn't use it at all for quite some time, but it still has promise as a way to make it much easier to port applications to Linux and give them a truly native feel.

There's an interesting difference between an approach like this and just creating a Linux package that either depends on or bundles Wine (like Picassa currently does): here, the Windows developer only needs to do it once (rather than per distribution).  Moreover, since Wine is a user-level application the program can easily be installed into a single user's home folder; this is something we still can't do with standard packages in Ubuntu.  Plausibly, the extension could also include hooks for installing the application system-wide if desired, however this would require some substantial work both upstream in Wine and within the Wine package itself.


Still, there could be a day where some Windows-installer building tool like InstallShield prompts the application developer "In order to make your program integrate better with Linux, please answer these 5 simple questions about how you'd like it to be used."  They'd then receive some basic questions about their preferred Windows version, Applications menu program group, and so on.  If porting were that easy, you can count on seeing far more software bridging the divide.

Now, we just need to make sure Wine can actually run the programs once they're installed...
Tags: ,

Jul. 26th, 2008

ubuntu, wine

Moderating the Wine forum

I recently volunteered to be moderator of the Wine forum. The main reason is that, for many users, the first place they go to seek help is the sticky threads at the top of the relevant forum. Improving these sticky threads is in many cases more important than developing the wiki or even making good documentation.

Today, for instance, I cleared out an old sticky thread about "how to get the latest Wine" and replaced it with a similar set of instructions, except these made clear that the "latest" version of Wine is an alpha. http://ubuntuforums.org/showthread.php?t=871535

There are still some things I'd like to clear up and condense (4 sticky threads is a bit too much, and much of the stuff in Codagh's "stuff I've learned about Wine" thread is now obsolete). In general, a lot of forum information should move to the wiki, and forum sticky threads should point to wiki pages (which tend to be far more updated and current).


When you provide good information to the forums, you have another positive effect: you educate those forum-users who post in other people's threads sounding knowledgeable. In other words, you minimize the possibility of someone coming to the community for help and getting bad advice.

While not every area of Ubuntu has its own dedicated forum like Wine, the lessons still apply elsewhere in the community. Developers tend to prefer mailing lists, but I'd encourage any developer with some time and knowledge to get a forums account, poke one of the admins to give you a developer custom title (so people listen to you), and then correct any bad information where you see it and refer users to a good wiki page.
Tags: ,

Jul. 25th, 2008

ubuntu, wine

Installing a dark theme

I've been developing on Intrepid in a vm lately, and one thing I've noticed is that my eyes are much happier using the dark theme than the normal one in Hardy. The dark colors contrast less with the room and make the monitor output less light, reducing strain on my eyes and making it easier to go to bed after working at 3am. The dark interface elements draw more attention to my actual work - I'm not focusing on the Applications menu or the taskbar or the Firefox titlebar, but instead the actual web page I'm browsing.

This isn't about looks - it's about usability.

I wanted a similar dark theme in Hardy, so I tried fooling around with the highest rated dark themes on gnome-looks.org. Big mistake. I tried at least 6, and every single one of them did annoying things like change Google's search bar to white text on a black background.

It took me a while to find out, but the best dark theme for Hardy is already in the apt repositories - the ubuntustudio-theme package. Unlike the others, it keeps Firefox and Pidgin behaving as you'd expect. It's also got customizable interface colors.


There was a good side to my computer helping turn me into a night owl though - energy is cheaper during off peak hours, and traffic is lighter when I end up driving. I've only just started using the dark theme full time, but it may very well cause me to stay up even later as I won't mind the late-night monitor light as much.
Tags:

Jun. 21st, 2008

ubuntu, wine

Wine is not an emulator in the .desktop file

While getting Wine to open .msi files properly, I realized I had to add an entry to Wine's .desktop file.  This inspired me to finally fix bug 235593, since it also required a patch to the exact same file.

So, from now on, instead of "Open with Wine Windows Emulator" you will now see "Open with Wine Windows Program Loader".  In order to do this right, however, I decided that every translation of that in the .desktop file should be updated at the same time.  This lead to me joining about 8 different loco team rooms (eg #ubuntu-de) to ask for a quick translation of "Wine Windows Program Loader."  Most rooms had someone who spoke enough english to understand the question and answer right away.

When I brought my translation question to the French room, however, I encountered resistance to the fact that I wasn't speaking French.  I'm going to ask my roommate (who happens to be a native speaker) for a good translation when she gets home.

Here's the current wine.desktop file, including the old french text:
Name=Wine Windows Program Loader
Name[de]=Wine Windows Programm Starter
Name[es]=Wine Cargador de programas de Windows
Name[nl]=Wine Windows programmalader
Name[sv]=Wine Windows Programstartare
Name[ru]=Wine, Эмулятор Windows
Name[fr]=Émulateur Windows Wine
Name[ca]=Wine - Carregador d'aplicacions del Windows

edit: french is now Name[fr]=Wine lanceur de programme Windows

Helping translate the .desktop file
If you know a translation for your language, now would be a great time to slip it in (the Catalan translation is new, for instance, simply because a speaker happened to be listening in while I talked about it in #ubuntu-motu).  This text is seen when you right click an exe file (and, soon, a .msi file) and nautilus tells you "Open with Wine Windows Program Loader".

The russian text is still old (though it now includes a comma), however this is intentional as the people in #ubuntu-ru couldn't come up with a good translation for Program Loader (all the russian documentation refers to Wine as an emulator anyway, so it's just as well.)

Post translated text here, or send a message to YokoZar on IRC and I'll include it.

Backporting Wine 1.0
Meanwhile, Wine 1.0 (sans the new .desktop file) has made it's way into hardy-backports.  Users won't have to mess around with the budgetdedicated repository or the Wine team PPA in order to use 1.0 - instead they can just enable backports.  I'll push to have the version with the newer .desktop file ported as well.

If there are no regression reports after about a week, 1.0 will be released into hardy-proposed and then hardy-updates as a stable release update, much like FireFox 3 final was.
Tags: , ,

Previous 10 | Next 10