Announcing wineui
Stephan Hermann
sh at sourcecode.de
Sun Jun 10 14:40:52 BST 2007
Moins,
On Fri, 08 Jun 2007 16:39:49 -0700
Scott Ritchie <scott at open-vote.org> wrote:
> 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?
To be honest, we mever received any bugreport about emule or whatever
geekish tool a windows user needs to get to their software, but more
bugreports were filed against games.
Some of them were already installed on (and even when winee core devs
are not encouraging it) on a native windows partition.
> 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.
I'm not against it, but right now in wines alpha state (not beta ;) I
can send you some chatlogs with this statement) it's more a nightmare.
>
> >
> > >
> > > - 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.
The typical wine user doesn't think about that. they want it just
running, it doesn't matter if it's newly installed or from their native
partition. It is a problem, that's it's possible.
>
> >
> > 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.
Well, if they wouldn't use windows in the first place, they shouldn't
need a tool like eMule. Just use Bittorrent as a replacement.
Anyways, the problems are deeper. Try e.g. the VMWare Infrastructure
client for the VMWare ESX Server. The installation failes when you
don't have an IE >=5.5 installed in the correct places. When the
installation failes, you have some crap installed, but no uninstaller
is being installed. So, how do we want to get rid of broken
installations?
Regards,
\sh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20070610/20d1c71a/attachment.pgp
More information about the ubuntu-devel
mailing list