Le lun 22/08/2005 à 07:58, John Smith a écrit :
[snip]
2. (not really relevant to this discussion, but relevant to the whole issue
of supporting end-users): binary RPMs for RedHat/Fedora on winehq.org are
still 20050524, and winecfg is pretty much useless there. If WINE team does
care about
This will just allow developers to hide bugs in wine and slow development
even further, I thing it's a bad idea.
Ahem. To say it politely - I didn't get an impression that WINE developers
are desperately looking for unknown bugs to fix.
Situation is pretty simple. We have an application, which
John Smith wrote:
Situation is pretty simple. We have an application, which works Ok under
WINE, provided that Managed=N specified
Then just tell your users to set that in winecfg, AFAIK winecfg allows app
specific settings.
I'm sure your great guys but any such mechanism could be easily
Ivan Leo Puoti wrote:
John Smith wrote:
Situation is pretty simple. We have an application, which works Ok
under WINE, provided that Managed=N specified
Then just tell your users to set that in winecfg, AFAIK winecfg allows
app specific settings.
You can also set it yourselves in in
Then just tell your users to set that in winecfg, AFAIK winecfg allows app
specific settings. I'm sure your great guys but any such mechanism could be
easily abuse by lazy programmers, also once it wasn't needed some sort of
backwards compatibility may even be needed, I don't think it's a
Then just tell your users to set that in winecfg, AFAIK winecfg allows app
specific settings.
1. It is still not 'out-of-the-box' - and from this point of view it doesn't
matter much whether it is hacking config file or using GUI; 80% of end-users
will try it and throw it away if it doesn't
John Smith wrote:
This will just allow developers to hide bugs in wine and slow
development even further, I thing it's a bad idea.
Ahem. To say it politely - I didn't get an impression that WINE
developers are desperately looking for unknown bugs to fix.
Because it's a tedious and boring task
Because it's a tedious and boring task to narrow down those unknown bugs in
closed-source apps. And that's exactly why we ask you (since you got access
to the sources) to tell us what the application is trying to do which
doesn't work in Wine...
Ahem. And how long it usually takes to fix the
John Smith wrote:
Ahem. And how long it usually takes to fix the bug for not-top-10
application? And please, don't suggest to fix it ourselves - it is not
going to happen in corporate environment.
Not that long if you provide a small testcase with source that triggers the bug
As it would fix
John Smith wrote:
1. It is still not 'out-of-the-box' - and from this point of view it
doesn't matter much whether it is hacking config file or using GUI; 80%
of end-users will try it and throw it away if it doesn't work without
hacking settings; 20% of others will ask questions, and will hack
John Smith wrote:
Because it's a tedious and boring task to narrow down those unknown
bugs in closed-source apps. And that's exactly why we ask you (since
you got access to the sources) to tell us what the application is
trying to do which doesn't work in Wine...
Ahem. And how long it
On Mon, 22 Aug 2005 22:46, John Smith wrote:
Ahem. And how long it usually takes to fix the bug for not-top-10
application? And please, don't suggest to fix it ourselves - it is not
going to happen in corporate environment.
Sure it is. There are several corporates around here where fixing
As a Win developer, I want to make a suggestion (sorry if it was already
discussed - or if similar mechanism already exists):
What if some simple way will be provided for Win developers to say which
options they prefer for WINE to use for their application? While it may seem
to somewhat
John Smith wrote:
As a Win developer, I want to make a suggestion (sorry if it was already
discussed - or if similar mechanism already exists):
What if some simple way will be provided for Win developers to say which
options they prefer for WINE to use for their application? While it may
seem
14 matches
Mail list logo