Announcing wineui

[Scott Ritchie]

On Thu, 2007-06-07 at 09:37 +0200, Stephan Hermann wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Matt,
> 
> sorry to come back to you a bit late, but work and family needs more
> time right now :)
> 
> 
> Am Tue, 5 Jun 2007 11:27:31 +0100
> schrieb Matt Zimmerman <mdz at ubuntu.com>:
> 
> > On Tue, Jun 05, 2007 at 11:32:18AM +0200, Stephan Hermann wrote:
> > > Am Dienstag, den 05.06.2007, 09:57 +0100 schrieb Matt Zimmerman:
> > > > We are not talking about building wine into gnome-app-install,
> > > > only about enabling it to manage installation/uninstallation of
> > > > wine applications.  Do you feel that this would compromise it
> > > > somehow?
> > > 
> > > That I didn't say. An Installation/Removal tool outside wine would
> > > be nice (for both of the main desktops) but right now, it wouldn't
> > > be that great, just because wine is far away from being stable.
> > > Chats with wine core devs gave me the opportunity to see what those
> > > devs need: more experienced "hackers" to use a debugger and winedbg
> > > to find out what's wrong and file bugreports towards them. With an
> > > installation tool inside our infrastructure, it will give us more
> > > hassels, because more people are not using free software, but
> > > windows software, and more bugreports are flooding our malone with
> > > not usable apport bug reports. this is something which we shouldn't
> > > want to have.  What the winehq devs need is written on
> > > http://www.winehq.org/?issue=330, topic Debugging, and this is
> > > something we don't have right now. 
> > 
> > Let's be clear on a few things:
> > 
> > - No one is suggesting that we ship Windows applications to Ubuntu
> > users
> 
> No, but having "wine" more integrated then it should, gives the User
> the opportunity to not use unix natives. They will always use what
> they know, even under Linux...but this is another thing.

So?  If a user wants to use eMule or Filezilla, why shouldn't we make it
easier to do that?

With the right interface, we could make the use of some Windows
applications easier on Ubuntu than Windows itself.  Many of these
already work, despite Wine's beta nature. That right there is a powerful
use case for potential switchers.

>  
> > 
> > - According to this thread, there is already sufficient developer
> > interest to write an installation/removal tool.  I am simply
> > suggesting that it makes more sense to do that work inside an
> > existing installation/removal tool rather than creating a new one.
> > If someone wants to work on this, there is no reason do discourage
> > them
> 
> Yes, do they know what happens to wine when they need to update some
> stuff? Changes in the wine registry needs sometimes the complete
> removal auf the local .wine directory. For what do I need an
> application removal tool, when a rm -Rvf .wine helps here?
> 

One thing that should be added is a "wipe and reinitialize" feature to
whatever Wine configuration tool gets made.

> Many people are using or trying to use their native windows ntfs
> partition and run their apps with wine from there. An application
> removal tool here would be somewhat fatal.

This should be discouraged anyway: it doesn't work, and Wine might break
the Windows installation.  Windows applications (except "portable" ones)
need to be installed in Wine's virtual drive.

> 
> This is the most difficult problem with something like that. 
> I'm not against such a tool, start to code it, but push it away from
> the main install/removal tool. Let it be a plugin for g-a-i or
> whatever, but not an essential tool for it. 
> 
> > 
> > - This is something of a pedantic point, but not all Windows software
> > is non-free
> 
> Yes, but for that, no one is using wine. You are using wine, because
> your tax software is not running natively on linux...and most of the
> time even with wine it's not running. Anyways a absolute useless
> discussion.

I don't buy it.  eMule is a great example - there simply is no better ed2k client, since porting it without Wine turned out to be a lot more work than people expected - the lmule and amule projects have never achieved the features of eMule.  It's also Windows only, and open source.


Thanks,
Scott Ritchie