ScottRitchie

Revision 145 as of 2009-04-16 18:23:49

Clear message

I'm Scott Ritchie. You can usually find me on Freenode IRC or the Ubuntu Wine forum as YokoZar. I keep keep a blog that you should read, which is syndicated on Planet Ubuntu. I also have pages on Launchpad, Wine's Wiki, and Wikipedia. I am a MOTU, and while my chief interest is maintaining the Wine package and everything that is related to it, these days I find myself doing a lot more. View recent uploads in Launchpad.

I want good, usable software everywhere in Ubuntu, especially Wine -- users shouldn't even need to know they're running it. My goal is to help make Wine easy and effective enough to be an official supported package in Ubuntu. Like most developers, however, I make myself useful throughout the entire Ubuntu project, doing everything from filing bugs in other packages to drafting entire blueprints to working on the Sponsorship Queue.

Becoming a Gnome developer

I want to make Wine the best it can be, and that means integrating it seamlessly into the Ubuntu desktop. This means a lot of work in both Wine and Gnome. After attending the Wine developer conference in 2008, I was able to convince the developers to make Wine present an interface to the system for good integration and configuration. However, someone else would have to write the changes to the desktop manager to actually make use of that - I volunteered for the job.

  • Get Gnome to display icons embedded into executable files. You put in a CD, and even if you have Wine installed the program has an unhelpful default icon instead of the one it normally does in Windows.

  • Allow uninstallation of Windows applications through Gnome-App-Install. This way we can put all software removal in one nice, convenient place. This also allows us to eliminate the rather out of place uninstaller in the Applications->Wine menu.

  • Create a good System->Preferences->Windows Applications menu to replace the relevant parts of Winecfg.

  • Create a good right click->properties menu for individual executables. Here the user would be able to modify what windows version they run in, and whether that application should be able to make itself full screen or be forced into a particular window. Currently in order to run Diablo 2 in a window a user has to mess with winecfg or run a cryptic terminal command.

  • Create a (self-killing) "please wait" message for that 12-second or so downtime when Wine is running for the first time. The new notifications feature coming to Jaunty is ideal for this.

  • Bug 111061 - Changing the Gnome theme needs to set the Wine theme properly. Until Wine's theming engine can be perfected, we will likely need to include a Windows version of the various system themes with Ubuntu (likely as just a .theme file within the theme archive). When the system theme is set, the system then needs to tell Wine to use the new theme. Someone (likely me) will also need to make the .theme files for the default system themes in the new release as well, and I will certainly need to make sure they work within Wine.

  • Make it easy to associate a Wine application as a handler for a file type. Currently, this task is so difficult it is nearly impossible. If I want to open .torrent files with Wine-powered uTorrent, for instance, I have to make a special script using winepath just to get things working right on double click.

  • Make autorun work properly for Windows applications. Gnome gives a nice dialog when the user inserts an autorun-equipped CD, but if it points to a windows exe it doesn't always launch it properly with Wine. We also might need some way of having a CD mark itself as "don't run autorun in Linux", perhaps if that CD also carries a Linux port. When I insert an Ubuntu disc, for example, I really don't want to see the prompts to install Windows free versions of software Wink ;)

  • Have a point and click system for mounting virtual CD Images right within the desktop. Essentially, we need to make Right Click->Open with "Archive Mounter" a very easy process that also works with other CD formats, like mdf. If Wine is installed, it should automatically present a standard drive letter (X:\), though this could be changed when multiple CDs are mounted simultaneously.

  • I discussed this a bit at UDS, and will draft a plan soon. "Daemon-tools for Linux" is one way of describing it, except we're doing even better.
  • Have an easy, centralized mechanism for displaying transparent messages. This feature is useful for far more than just Wine, and would be a substantial usability improvement for Gnome -- of course, since it would be done with D-Bus, KDE could handle it too. I'll outline it in a blog post in a bit. UPDATE: This feature was announced as a major coming feature in Jaunty at UDS. Seems someone else had the same idea.

  • Fix up the System->Preferences->Keyboard dialog. It was very difficult for my girlfriend to discover how to add accent marks into English - it's buried in the "other options"->"compose key" setting, and even there we don't tell anyone what the compose key is. Compose key might warrant an entire tab, with illustrations showing how to press/use it. This may merit being a main tab depending on how common this use case is.

WineTeam

Currently, I'm the only active member of the Ubuntu Wine Team. There are about 50 people who have joined the Wine Team by clicking on launchpad, however they haven't provided any actual package improvements. At this point the team is largely unused.

Other non-Wine tasks

Post UDS-Jaunty items

It seems like I come away from every UDS volunteering to do more and more work. UDS-Jaunty was no different. I need to:

  • Spec out the discussed changes to the Participate Pages on ubuntu.com

  • Help design questions for figuring out how a potential new contributor wants to help (eg artwork vs documentation)
  • Ensure that Ubuntu-mobile developers get in touch with the Pandora people to receive developer kits or early model devices to work on
  • Help create a usability testing wiki page to guide community volunteers testing out the next Ubuntu on their less computer savvy friends/family
  • Make (and popularize) a top 10 pet bugs list on wiki page; the goal is for many developers to do this
  • Get the mediainfo package through the sponsorship queue properly
  • Make some Gobby feature requests and post them as LP bugs
  • Request Wine invoke the "suppress screensaver" functionality when in a full screen game to prevent the new notifications system from interfering. We should consider a similar feature when using the "make full screen" command in a window manager (Dell laptops even have a key for this. Some window managers use alt+f11, which we should also consider making a default in Gnome)

Other items

  • Ubuntu could really use a good streaming media server fully integrated into the desktop. I should be able to right click my music folder, select "Sharing Options", and then select an option for streaming the files to my playstation. There are many steps to this project, however most of the work that needs to be done is just in the user interface at this point. As far as I'm aware, no one is really working on this.
    • I, however, am working to get mediainfo (a console program used by many of these servers) properly packaged and integrated into Jaunty.
  • Improving 32-bit compatibility on amd64 by slowly replacing the tremendous hack that ia32-libs is with individual lib32-foo packages. Wine is the chief user of ia32-libs at this point, so if we want Wine to be well supported this is infrastructural work we'll have to do first. There are a few specific bugs in launchpad which may be worked on by others, but most of the packages in ia32-libs have no one interested in migrating them.
  • Building packages for games for the Spring engine. Spring is now available through a launchpad PPA I created. Once I make a package for a freely distributable game for the engine so users will have something to actually play upon installation, I'll upload the packages to Universe.

Current Wine Goal

Most of the needed upstream work for BetterIntegratedWineSpec is being tackled, most notably the ability to configure Wine and remove software from the command line. What we need now is for someone to design and make the Gnome applets (as well as modify gnome-app-install). At the Wine developer conference, I was the only one willing to do it.

Neat ideas to think about doing at some point

  • If any of these tasks is interesting to you, please feel free to start on them. I'd like to help you, or at least provide moral support on IRC. If I somehow get enough time to work on Ubuntu, these are all tasks I might take on myself after finishing the major tasks above.
  • Using lzma compression for things apt-get fetches (eg Packages.gz))
    • Doing apt-get update for the main and universe repository now requires downloading over 5 megabytes. We could probably cut that down to 4 with lzma, saving our mirrors a ton of bandwidth. This isn't so much an issue with smaller repositories like wine.budgetdedicated.com or launchpad PPAs, which typically only have a handful of packages and thus a few k for Packages.gz.
  • Proper apt-p2p integration. If I had my way, it would be a checkbox in the installer.
    • Even our massive servers can't handle the bandwidth on beta release days, much less the full release. Mirrors in less internet-enabled countries are even worse off.
    • However, to do this right, we'd need to make sure it almost never interfered with "normal use", including making it very easy to disable (or cap upload)
  • Daemonizing transmission and being able to eg cap bandwidth usage using D-bus calls would be an awesome feature, since then other applications could slow it down if they needed to claim bandwidth. More generally, Ubuntu could use an entire "bandwidth manager" for doing this to all sorts of bandwidth using applications (torrent, apt-p2p, streaming media server, etc).
  • Modifying migration-assistant and Wubi to migrate installed Windows applications into Wine
  • Cleaning up packages-arch-specific. Selecting what arch to build for should be done through proper control files, not a workaround elsewhere. One way is to just fix whatever control files we need to in Ubuntu and stop using P-A-S.
    • Packages-arch-specific was made in Debian because a lot of Debian packagers didn't actually know what arches their packages worked on. This is much less of a problem for Ubuntu, since we only support a handful of arches that are reasonably easy to test on, especially for supported packages. In Ubuntu, we also don't shy away from patching a package "belonging" to someone else. The end result is that we could simply start ignoring packages-arch-specific, and then patch the control files if there's any resulting build failures.
    • As for the advantage this gives us: sometimes the only reason a package doesn't build on a specific architecture (for instance, zsnes) is because of an entry in this file. zsnes was recently patched to allow it to build on amd64, however the process for removing it from P-A-S required a substantial extra work.
    • There may also be a benefit to simply allowing the build daemon to attempt to build something and have it fail; alternatively, launchpad could output "package x not built for arch y due to listing in P-A-S file" - however, some packages do build successfully for the wrong arch but instantly segfault.
    • It seems like Ubuntu is ignoring P-A-S for Wine, as launchpad now reports build failures on sparc and ppc. This is the right way, but I'm not certain if it's due to Wine being removed from PAS or PAS being ignored in general.
  • Have a coherent "preferred email client" setting somewhere. Similar to a default web browser, we should have a default email client that (for instance) Firefox launches when you click an email link. Thunderbird should offer to do that for you after you install and run it as well.
    • It would be nice if this could also be set to a webmail; it would be rather slick if clicking a mailto link could pop up a gmail tab.
  • EmuleViaWine - A spec to integrate eMule as a regular application in Ubuntu, powered by Wine

    • Building eMule from source is difficult, since it uses visual studio.
    • We could just make it a multiverse package much like wine-gecko (which only builds on windows) and then package it accordingly.

How I got to Ubuntu

After some bad experiences attempting to contribute to Debian, I was pleasantly surprised when Jeff Waugh came directly to me and asked me to sign up for Ubuntu. That was back in the Hoary days, and I've been directly helping ever since. In the past, my contributions had mostly been making the Wine packages at winehq.org, however now I do far more. Making Wine work just right for the user involves improving many different parts of the system, and now that I am a MOTU I can work on most of them directly.

Detailed explanations of major tasks

One Click Install from SuSE

  • Not so much "one click" as it is "one file" - an ISV would provide one XML file that will give instructions that work on SuSE, Ubuntu, etc.
  • This is actually the continuation of the ThirdPartyApt spec that I resurrected from Dapper. It is still unimplemented.

    • As it stands, the installation instructions on this page are too complicated - a user must first identify his Ubuntu version, then run two terminal commands, and then make sure he runs them again when he upgrades distro versions six months later. A user should be able to simply click a link in FireFox, enter his password, and have it all be set up for him. It also took me as a repository maintainer quite a bit of time to figure out how to set that up - as we encourage more and more ISVs to create their own repositories, setup should be made more standardized and clear.

    • I would need to implement this myself. Jerome can't do the code anymore, and the spec has been differed since 2 years ago. Fortunately, I know python and can build on the work he did with GApti.
    • It would be neat to have repository "dependencies" - eg the WineHQ APT repository could depend on the universe repository (so the user would be prompted to enable universe), or it could depend on backports, etc. We should note in the spec the various "reserved" names that a repo could depend on that we'll automatically recognize (namely, Ubuntu ones, or if we build a list of recognized "official" third parties).
      • This could also be related to the key-signing idea discussed at the spec.
    • Google has graphical versions of the instructions here: http://www.google.com/linuxrepositories/ubuntu704.html

    • They also have text similar to what I have: http://www.google.com/linuxrepositories/apt.html

    • It should be as simple as downloading a single file and double-clicking it. That will then prompt for the password and tell the user it is adding a key and downloading particular repositories (also warning that this could be a security issue if they're untrusted), as well as installing a particular application (eg Wine or Google Desktop)
  • Instead of creating an entirely new filetype ala ThirdPartyApt, we can simply use the existing SuSE XML-based file. They've expressed willingness to extend the spec if we need to, however right now the only lingering difference between what we called for and their specification seems to be whether we force signing of the entire file using the same key as the repository. Not doing this allows someone other than the repository owner to create an installer file, which may actually be a good thing.

  • An Ubuntu proof of concept implementation already exists
  • With Ubuntu support, an ISV could provide 1 file that would install the appropriate repository/packages for both SuSE, Ubuntu, and whomever else supported the standard.

KillingIa32Libs

  • ia32-libs was created as a temporary workaround for apps like Open Office before there were working 64 bit versions, however it hasn't gone away and, because of Wine, won't ever go away until no one wants to run 32 bit Windows applications.
  • Currently, libraries in ia32-libs must be updated by hand, and the whole bundle must be downloaded whenever there's any change. Worse, there's no automatic process to force updates to the 32 bit version when a security bug is found. When the openssl vulnerabilities occured, for instance, ia32-libs wasn't updated until over a week later after I discovered it was still vulnerable. More annoyingly, every user had to download a 100+ megabyte update just to fix the one package.
  • When I contacted them privately during the Prague developer summit, Colin Watson and Pitti both agreed that while toolchain changes may be best in the long run, they're not going to happen as no one's been working on them for years. The best solution is to make separate 32 bit packages a la lib32asound2.

Todo list:

Wine todo list:

  • Usability:

    • Build the Autorun support into the Wine package

    • File association with Wine applications can be made much easier: https://bugs.edge.launchpad.net/ubuntu/+source/wine/+bug/243390

    • Warn the user if DirectRendering isn't true (ie, 3d things will run very very slow)

    • Consider moving the "Browse C:\ Drive" from Applications->Wine to places. Ask desktop team for feedback, and also figure out how this is done (places isn't a "normal" menu)

    • Multiple CD installations still don't work too well - we should use the full path (without switching the directory) when running off a CD, so it can be ejected if needed (and disc 2 then inserted)
    • Wine needs to have a command-line option to test if it's configured yet (IE, there exists ~/.wine), and if not then run Wine's first-time configuration. This way scripts can test if Wine's been setup.
      • This script, then, needs to be included in the "Browse virtual Windows drive" option created on the menu when installing Wine so that it'll be there. Ideally, it should also tell the user what it's doing and why it's taking so long (eg: "winecfg is creating your virtual windows drive, please wait")
    • Get usability reports from people on the forums to provide a developer guide for improving Wine usability
    • Browsing the forums, it seems that a very large number of new users expect to be able to "run wine" after installing it. They look for the Wine icon, and expect it to open some program that they can then open executables from. There are several solutions to this that should be done:
      • The Wine package description should make it clear that the user will now be able to open Windows executables by double clicking
      • Winecfg, or its replacement, should have a nice front page explaining this, as well as a brief overview of winecfg's purpose.
    • Wine uninstaller (and perhaps winecfg) should have an option to completely nuke ~/.wine
      • Wine uninstaller needs to properly clean the .desktop files for removed Windows apps (this is an upstream bug)
    • Take the initiative and get an official review at openusability.org for the layout of whatever replaces the current winecfg
    • The to be written Wine control panel applet being made could have a checkbox for "Launch Windows Applications configured to run at startup when you log in." This way someone could have eg Steam launch as soon as he logs in like it does in Windows. This in turn would run wineboot on login as one of the gnome init scripts. It would be nice if it were clear to the user that safe mode was a way of disabling this if things got really bad.
    • Would be nice to have the same right click -> properties for Windows applications to get individual configuration (eg app-specific Windows version) available by right clicking their shortcuts in the Wine start menu.

  • Documentation

    • Most of the documentation projects are going to be obsoleted by usability improvements to Wine itself. Wine will still need a good overview contextual, however.
    • Updating the content of the Wine User Guide itself is largely done, however live contextual help needs to be provided elsewhere (such as Winecfg)
    • The Wine documentation also needs to be moved into the right places. Currently it's in a separate package upstream and isn't even included in the Wine packages in Ubuntu. This is ok, since most people just read the manual from winehq.org, but we'll need to actually integrate the docs properly if we want to support Wine.
    • Need to convert Wine docs to XML (they're sgml at the moment), which is a blocker for using the scrollkeeper OMF standard and porting to the standard freedesktop help format.
    • Create a graphical means of running winetricks, a small script of temporary hacks that can help make Wine more functional until things are fixed upstream. Probably the simplest thing to do is just include the script and wrap it with a quick python gui, and make that launchable from winecfg (or its replacement).

  • Winecfg:

    • Should have checkboxes for enabling .desktop files for more obscure Wine functions (say, regedit or control panel)
    • Warn the user if they try to use an existing Windows drive/registry that it will probably not work and also break.
    • Winecfg needs a pretty through redesign, as it has some annoying usability issues such as tabs referring to other tabs. Ideally, users wouldn't really need to access winecfg at all (see Gnome modifications, up top).
    • Need to separate logic of winecfg (eg command to change audio drivers) from the program itself. These can all be converted into terminal commands since all they do is modify the registry in some predictable way. Then any application can properly reconfigure Wine, such as winecfg, a custom install script, a new user interface, or a system control applet.
    • Then, we can make a new config program in a toolkit native to the desktop environment, like in GTK. The configuration applet could then even be launched from System->Preferences->Windows Applications

    • The drives tab needs to make clear to the user that it's dangerous to simply treat a windows installation as a drive in Wine, both because applications might not work (due to missing registry entries) and because Wine might mess with it. Installing applications "fresh" is better.
    • I should be able to right click an executable file and adjust its settings directly in winecfg. Right now, to do this, I have to open winecfg and find the executable by hand, the long way.
  • Other:

    • Check whether it's a good idea to include the Wine Gecko stuff in the package somewhere rather than have Wine get it off the internet (we could put it in, say, /usr/share)
    • The integrated eject function when you push the CD eject button needs to call the wine eject program if Wine is locking the disk (so the wineserver can release it, otherwise Linux's eject won't work)
    • Get community help in making a full-fledged Ubuntu Windows theme, to use in Wine (when Wine's theming support starts working fully). In the interrim changing the default colors to match the Ubuntu default theme is a partial step, although things will get ugly when a user changes his Ubuntu theme.
    • A very useful (for Ubuntu) app would be eMule, however compiling it in Winelib so it builds on Ubuntu will be a bit hard as it's built in MSVC normally and there currently is no "simple" MinGW build. eMule would be a great candidate for inclusion with Feisty + 1, both for its utility and as a demonstration of how other windows programs can be seemlessly moved into Ubuntu - see EmuleViaWineSpec.

    • The pptview package needs to be available on amd64 arch now that Wine is
    • Consider what would happen if we integrated Winelib with Mono's [http://www.mono-project.com/Microsoft.Build Microsoft.Build].

Miscellaneous tasks for myself:

  • Write up a howto on setting up a third party repository, since I run the most popular one. ISVs will want to know how simple this is, and what kind of work they can expect maintaining it. I envision a day where I can download the latest Doom 3 from an APT repository, and have it work perfectly after entering in my CD Key.
  • Write up a post on the eMule forums detailing the argument for weighted random queue answering and an increased preference for peers who have uploaded more. I'm convinced that the overall speed and health of the network can improve significantly by two relatively simple changes, however it may require a well written argument and a mathematical model to convince the developers.
    • Also explain how I'd be the eMule maintainer and the ideas (and obstacles) behind an eMule for Ubuntu. Also needs to be configured to not check for updates and to use its own special wineprefix.
  • Pidgin-OTR needs to have an "automatically end private conversation when the person you're talking to ends it" feature, and it needs to be on by default. There's no point saving the session key once you know your partner has gotten rid of it, and this will reduce some of the "sending encrypted data when it's unexpected" problems. Also think about automatically forgetting it if the person has logged off and stayed off for an hour or so.
  • Evolution really, really needs to disable ctrl+enter as a shortcut for send email. ctrl+enter is the hotkey for "new line, same paragraph" in Pidgin and OpenOffice, and this "shortcut" can have nearly catastrophic consequences. Clicking send is not that difficult and, more importantly, the user will need to use the mouse after finishing an email anyway. Thunderbird will ask you if you really want to send an email when you hit ctrl+enter, which is a clear indication that this hotkey is too easy to press.

  • It would be really neat if Pidgin had a feature where if you didn't read a message it would store it for when you log back in and show it to you. On many occasions I've heard an IM beep but didn't read it because I was in a full screen game, only to have something crash or my computer get turned off without ever reading the message. After that point the only way I can tell what it was is to search through EVERY log of someone who might have contacted me.
  • GnuNET is a completely unusable mess at the moment, but is extremely promising software technologically. It's been that way for years - academics write papers about how great the protocol is theoretically, but no one can actually use it because the software sucks.

Other interests

  • I've been teaching myself Python for the purpose of conducting my own research into mathematical analysis of different voting systems. I plan to develop this research further as I head into grad school, and publish results as they come. I even see myself writing a book at some point, albeit that's around 4 years into the future.

  • I've recently graduated college, and am actively searching for work. There's nothing I'd love to do more than work full time on Ubuntu, Wine, and supporting users at this point. I'm completely willing to work pursuing bounties for the specs I've created.
  • I enjoy reading and writing short essays. Powerful writing is like a clear interface. You stop noticing the words, and instead just get the ideas.

Unusual Ubuntu tasks I've done that I want to remember

If it's something Wine related in Ubuntu, odds are I'm responsible for getting it done. But, like all Ubuntu developers, I occasionally dabble in other areas that I often forget about. This is a partial list of those things.

  • (./) Discuss the merit of having a "mute shutdown sound" checkbox when shutting down (if there is one)...or at least having no shutdown sound by default.

  • (./) Get community help making a free replacement to the tahoma.ttf font, like what Red Hat did with some other Microsoft fonts here: http://www.alldaycoffee.net/story.php/125

  • (./) Amd64BitWinePackage - my attempts at making a 64 bit Wine package that can run 32 bit apps.

  • (./) Nano, not vi, needs to be the default text editor for console programs throughout universe. A good example is mutt - a fairly intuitive program, until the user attempts to send an email with it and then gets dumped into a command line vi editor, where I myself couldn't even figure out how to save and quit after about 20 minutes of work. If this isn't the case with some application it is a bug Smile :)

  • (./) Integrate the fancy icons posted to the mailing list by another user earlier (also need to upload a zip file somewhere since the archive is dead). Already using one of them for the Launchpad branding Smile :)

  • (./) Fix shared-mime-info upstream and in Ubuntu so Wine can open .msi files: https://bugs.launchpad.net/bugs/229062

  • (./) Upload libtorrent-rasterbar (it's still waiting for debian sponsors, and debian import freeze is soon)

See ScottRitchie/Work for more wikipage


CategoryHomepage