ubuntu-wine team mailing list archive

[Scott Ritchie <scott@xxxxxxxxxxxxx>]

Sorry Steve, I had to move out quickly in the past two days so things 
have been a bit hectic for responding to email.  I did get your original 
message.

Steve Dodier wrote:
> Hello folks,
>
> This email was meant to be sent to Scott Ritchie, but as he doesn't 
> answer, i fear it went to junk, so i'm re-sending through the mailing 
> list. Also, I thought someone would like to append comments / idea on it.
>
> Something else, who will for sure be at the next UDS ?

I will ;)

> Cordially, SD.
>
> ---------- Forwarded message ----------
> From: *Steve Dodier* <sidnioulz@xxxxxxxxx <mailto:sidnioulz@xxxxxxxxx>>
> Date: 2009/4/4
> Subject: Ubuntu in Wine
> To: scottritchie@xxxxxxxxxx <mailto:scottritchie@xxxxxxxxxx>
>
>
> Hello Scott,
>
> I read BetterWineIntegration (for the second time, since i read it 
> before joining the Ubuntu Wine Team a while ago ;) ), and i've had a few 
> things coming to my mind. As i don't know wether or not i'll be at the 
> UDS, and as i very dislike editing wiki pages (meh :p), i thought i'd 
> mail you my thoughts about the specs you wrote, so here be it :
>
>
>
> ________________________________________
> Packaging Windows apps in .deb :
>
> How to install ? i don't think we want to rewrite installers that will 
> fill registry and copy files, so do we run the windows installer upon 
> app install ? What if the installer fails, should we find a way to tell 
> apt/dpkg that installing the package failed ?

We don't have to rewrite an installer, all we really have to do is 
create a separate wine prefix, install the app into that, configure it, 
and then tar that up and turn it into a package.  One clever way to make 
this system wide without duplication is to have each user run a small 
script upon first run of the program that creates a wine prefix for that 
particular app, however this prefix is configured to have the C:\ drive 
in the system folder where the app is installed.

> ________________________________________
> Integration into GNOME
>
> - Clicking .exe : Isn't this doable via adding a single mimetype in 
> GNOME ? What happens in GNOME if you open a .7z file without p7zip 
> installed, for instance ? (i'm asking because i don't run GNOME :p). At 
> least we must remove the mimetype that associates Win32 binaries to 
> file-roller.

This is doable this way, however we gain something in usability by 
writing a special dialog explaining that this is a windows application, 
what Wine is, and why things will end up in a special Applications->Wine 
menu.  Most importantly, we can use this opportunity to lower 
expectations and tell them that Wine might not work with all apps.

> - Applications menu's name : i'm against naming it Windows instead of 
> Wine. Nothing would bug me more, as a linux user, than having "Windows" 
> written anywhere on my PC :)

I think there's a nice consistency when we call it the Wine menu and 
then also provide a (small) wine icon on the individual programs.  That 
way I can see it's a Wine installer when I get it, and when I double 
click it and it actually works perfectly I'm not surprised to see it end 
up in the Wine menu.

> - Wine apps menu items : placing them in a submenu related to what they 
> do would be great, but its only possible for apps that we ship within 
> .deb packages, by manually making the menu items, because there 
> obviously is no way to guess what category an app should go in, neither 
> is a way to keep an exhaustive list of apps with their associated 
> category. I'm more for leaving it as it is, and finding a way to help 
> users to move their shortcuts (apart from the .deb case).

Technically it's possible to try and make an exhaustive list of Apps - 
Microsoft actually attempts this with Windows Vista's "Games" section in 
the start menu.  But I'm not sure it adds any usability, especially when 
it's still important to let the user know it's a Wine app (and thus 
lower their expectations).  It's ok for them to have high expectations 
for the applications we package though, and thus we can put them in the 
normal menu.

> - Another suggestion : we should be able to find out what are 
> uninstall/doc/editor's website menu items and remove them upon install, 
> to keep it approximately readable for the user (because windows apps 
> love to create 10 useless/spam shortcuts for 1 useful one). We could 
> then move the remaining items to Wine/ or Wine/Programs/ directly, to 
> make them faster to access.

Cleaning up this kind of cruft properly is even more difficult than 
making the exhaustive list of every application, and it's not even clear 
that the user benefits from this since they are likely expecting the 
same thing as Windows.

> ________________________________________
> winecfg additional options
>
> - I suppose we'll have to rewrite winecfg as a GTK app, but i don't know 
> if it's technically possible. Either, we gotta ask wine devs how to send 
> dbus signals / call commands via a wine app to the linux box, so we can 
> directly use their winecfg.

We don't need to rewrite winecfg, since most of the stuff it does should 
be handled automatically (eg support for pixel shaders and the sound 
driver chooser).  We only need a GTK app that controls the 3 or 4 
options we could expect a human being to understand and set (eg windows 
version), and even then most of the time they shouldn't want to.

> - Here i'm quoting you :
>
>     * (unchecked by default) Automatically launch applications upon 
> inserting a disc            +1, this is an important feature to add
>    
>     * (radio button default): Allow full screen applications to change 
> the resolution          
>     * (radio button alternate): Contain full screen applications in a 
> window when smaller...    I propose we keep winecfg's current form, and 
> then we add per-app options (i'll explain that below).
>    
> - What we can do is merge the winecfg and wine app installer/uninstaller 
> (yeh, they have one, now :p). My idea is that we change the "apps" tab 
> in winecfg, and here put a list of currently installed apps (with their 
> version / wineprefix written), and we add the buttons "Uninstall", 
> "Advanced settings" for each app (see below). We also add a "Install 
> apps" button, and why not a "Install an app in a particular prefix" 
> button (or any other GUI feature for installing an app explicitely in 
> its own prefix).

What benefit do we have by making the user go through a separate work 
flow to uninstall Wine applications?  Why not just put them right into 
Applications->Add/Remove?  Similarly, having a central "Wine application 
settings editor" is just repeating the same mistake as winecfg - such 
things should be editable by right clicking the application (or its 
shortcut in the applications menu), like most users would expect.

And, realistically, I don't think we can expect to make a workable 
implementation of separate prefixes any time soon.  They really, really 
complicate things, especially when we have to worry about navigating 
around them in the Places menu.

> -- Standalone apps : we can add, in the "Applications" tab, a button to 
> "register" a standalone app (it always happens to have some of these in 
> windows), and then the registered app would appear in the list of 
> installed apps, and thus the user could modify its per-app settings with 
> the same interface.

This just adds work flow that's unnecessary - if the user can edit the 
settings for the app by finding it and right clicking->properties 
directly, then there's no need for a separate registration since we can 
do it there for them.

> -- For the apps that dont wanna uninstall (or that were manually 
> removed), we could just add a link that would clean the regedit entry 
> and remove the app from the list.

Yes, this is something we should worry about - there are quite a few 
third party utilities for Windows that clean up registry settings after 
users have manually deleted programs.

> - For the per-app settings, it's almost a fork of winecfg, since now 
> winecfg allows per-app settings for almost everything (apart from sound 
> settings / desktop integration).

Well yeah, the whole idea is to not have to use winecfg for anything. 
We'll be writing the same data files though (the registry for the 
~/.wine prefix)

> - We could add a wineprefixes tab that would allow modifying the 
> wineprefixes / installing dotnet/vcrun/dx9 via winetricks easily (if we 
> can legally do it, ofc).

It's still very very dicey, and it's not even clear that having separate 
prefixes has a sufficient use case to work into the design.  We'll 
always need a default prefix which more than one app installs into 
anyway, so we don't exactly shoot ourselves in the foot by not worrying 
about a Wine prefix manager until users actually demand it.

> ________________________________________
> winecfg additional options
>
> - Wine fonts : we can add a "recommands msttcorefonts" to wine, it'd 
> help for a lot of font troubles. Also, shipping "Sans" (or the future 
> default font in karmic) to wine will be helpful, for Wine's desktop 
> integration.

Wine upstream is already pretty good about providing aliases for the 
fonts now (as well as making their own eg Tahoma).  With every system 
shipping the liberation fonts and so on, we probably won't have to worry 
much about it.

> - Theme : nothing to add to what you said. i'm a total noob with 
> msstyles thing so i cant help here, but it would be awesome to manage to 
> get a theme for all the community themes, and package them in a 
> wine-themes .deb.

The problem with msstyles is there really is no free software for making 
one from scratch.  Every theme comes from editing an existing theme, so 
there's no such thing as a copyright-free Windows theme.

However, upcoming versions of system theming are going to be based on 
CSS, and as I understand it this is much easier to work into a usable 
Wine theme that doesn't look ugly.  So maybe it'll be possible to guess 
colors from the system theme after all.  It's all a little beyond me at 
this point.

> ________________________________________
> Documentation
>
> - I don't know the status of the documentation, but if you wanna ship it 
> in a more proper way, and possibly add a "wine doc" menu item, i'll be 
> able to help you write/review the doc, and to make the whole french 
> translation.

Wine's documentation should be with the rest of the system 
documentation, indexed by scrollkeeper, and available from the normal 
help menus.

Rewriting the docs was actually the very first thing I did for the Wine 
project.  Nowadays, however, I'm convinced that it'll be ok if users 
don't read it since we can make the interface much much more intuitive. 
 We'll still need docs, of course, especially for the more esoteric 
aspects of Wine and the new users who are completely unaware of what it 
is, and I'll be happy to give it a new write once the interface is working.


> ________________________________________
> On First Run
>
> - First run is actually wineprefix creation. A less intrusive solution 
> to a popup window would be a notification (and we have a nice notify 
> server now, don't we ? :D) saying Wine is creating a fake windows 
> install (or w/e for the formulation), this takes only 15 secs and is a 
> one-time thing.

Yes, an ephemeral notification is a much better thing to use now that we 
have them.  I wrote this spec long ago ;)

It would still be nice to provide some information that "Places->Wine 
C:\ Drive" and "Applications->Wine" now exist, though I'm not sure how 
to do it.  Perhaps we can just add it to the text.

> - Browse C:\ Drives : i'm for turning this into a Browse wineprefixes 
> thing, and we could create a folder such as ".config/wine/prefixes" 
> containing symlinks to the wine prefixes (or to their c:\ drives).

Possibly, if multiple prefixes is something we end up doing.  We'll have 
a straightforward migration path then.  90+% of the time the user will 
want the default though.

> ________________________________________
> Gecko / Mono integration
>
> - I don't know anything about Gecko, but making a wine-mono package 
> would be awesome, esp. since it removes most of the needs for dotnet2 
> and dotnet3, that are very big dependencies on windows. I think this is 
> a major issue.

Yes.  We'll see how mono and winetricks progress.

> I think i said most of what i had in mind. I'm going to have free time 
> in the summer and am willing to help you. The first thing we need to go 
> is to begin working, and i think it'll go on quite well from there. I'm 
> very unexperienced with Linux programming / app packaging, but willing 
> to learn (and, at least i think, capable of learning).
>
> Cordially, SD.

Thanks, it is awesome to have you here.  We'll chat more online :)

Thanks,
Scott Ritchie