Re: Throwing in an idea (probably it was discussed before though)

2005-08-24 Thread Vincent Béron
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 end-users, it would be nice to have binary RPMs for the most 
 popular distribution not that much out-of-date.

Yes, that's my fault. After moving in June, I haven't found the time yet
to reinstall all my computer stuff (I'm typing this sitting on the floor
with my keybord on my knees), so I don't know when I'll get back to it.
I already missed two releases, and haven't produced any rpm for FC4 (for
which I get a couple emails per week).

If somebody wants to step up to the task (at least temporarily), I'd be
glad to share my experience with them.

Vincent





Re: Throwing in an idea (probably it was discussed before though)

2005-08-22 Thread John Smith
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 works Ok under 
WINE, provided that Managed=N specified (with CrossOver it works Ok 
out-of-the-box). We won't change our code to go around WINE shortcomings (we 
checked relevant portions of our code though for potential bugs and found 
nothing), but we would add some kind of hint to make life of our customers a 
little bit easier. On the other hand, if WINE team doesn't care about 
current WINE end-users (and there are lots of them, despite the fact that 
WINE is still Alpha; they just download binary RPM provided and expect their 
favorite applications to work out-of-the-box) and thinks that they should 
wait until bug-free WINE released - we don't care much either.




From: Ivan Leo Puoti [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: wine-devel@winehq.com
Subject: Re: Throwing in an idea (probably it was discussed before though)
Date: Mon, 22 Aug 2005 00:31:07 +0100

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 to somewhat contradict to the 'big bright future' of the WINE (with 
all the apps running flawlessly under WINE), it would hopefully allow for 
immediate increase of out-of-the-box supported applications.


For example, it could be a resource string of special format (for example, 
__WINE_CONFIG_HINT: Managed = N), and multiple hints should be 
allowed. This hint should override system-wide settings but in turn should 
be overridden by per-app settings in wine config file/registry.


This will just allow developers to hide bugs in wine and slow development 
even further, I thing it's a bad idea.


Ivan.




_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/





Re: Throwing in an idea (probably it was discussed before though)

2005-08-22 Thread Ivan Leo Puoti

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 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 great 
idea. One simple solution would be to provide default settings for apps that have known problems, 
Alexandre hasn't ruled that out if it helps some apps to work out of the box.


Ivan.




Re: Throwing in an idea (probably it was discussed before though)

2005-08-22 Thread Jacek Caban

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 your app. As configuration
is in registry, every app can modify it.

Jacek



Re: Throwing in an idea (probably it was discussed before though)

2005-08-22 Thread Stefan Dösinger
 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 great
 idea. One simple solution would be to provide default settings for apps
 that have known problems, Alexandre hasn't ruled that out if it helps some
 apps to work out of the box.
Isn't it possible that the App just writes some registry entries to 
HKCU/Software/Wine/AppDefaults/Filename.exe/   ???

Stefan



Re: Throwing in an idea (probably it was discussed before though)

2005-08-22 Thread John Smith
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 work without hacking settings; 
20% of others will ask questions, and will hack config or run winecfg, but 
those 80% will be lost.
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 end-users, it would be nice to have binary RPMs for the most 
popular distribution not that much out-of-date.


I'm sure your great guys but any such mechanism could be easily abuse by 
lazy programmers,
Don't see much ways to abuse in general - eventually WINE is supposed to run 
_any_ Win application, right? Also I've suggested that config/winecfg 
per-application settings should override those 'hints', so user is still in 
control of it.


also once it wasn't needed some sort of backwards compatibility may even be 
needed,
If all it is about is overriding currently existing settings, no backward 
compatibility is required.


One simple solution would be to provide default settings for apps that have 
known problems, Alexandre hasn't ruled that out if it helps some apps to 
work out of the box.
Ok, this probably is even better; what about integrating such a thing with 
AppDB and automatically include some special field from AppDB data into 
winehq distribuitions?


_
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/





Re: Throwing in an idea (probably it was discussed before though)

2005-08-22 Thread Felix Nawothnig

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 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...


Actually fixing bugs is usually easy, tracking them down OTOH...

(we checked relevant portions of our code though for potential bugs and 
found nothing)


Even if your application relies on undocumented behaviour (potential 
bugs heh) it should work - if it doesn't that's a bug in Wine which 
should be fixed.


And by the way:

Managed=N breaks focusing for everything on my box (bug #2149)... :-)

Felix





Re: Throwing in an idea (probably it was discussed before though)

2005-08-22 Thread John Smith
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 bug for not-top-10 
application? And please, don't suggest to fix it ourselves - it is not going 
to happen in corporate environment.


As for 'tell us what the application is trying to do' - you've got all APIs 
in your hands, so what's the problem to track down system calls? The issue 
our app is experiencing is quite a subtle one - it works Ok with Managed=N 
or with Desktop=YYYxZZZ (or from CrossOver BTW), but with default WineHQ 
distribution when it tries to minimize one of it's top-level windows with an 
explicit call to ShowWindow, the window is not only minimized, but also 
reduced to 1x1 pixel; when restoring it, sometimes it is restored normally, 
sometimes not. This behaviour was reported for Gnome/KDE/Xfce and can be 
fixed with 'Managed' or 'Desktop' settings I've mentioned above.


(we checked relevant portions of our code though for potential bugs and 
found nothing)
Even if your application relies on undocumented behaviour (potential bugs 
heh) it should work - if it doesn't that's a bug in Wine which should be 
fixed.
Well, in fact WINE compatibility wasn't our goal in such a check (WINE 
installation base is still negligible, and probably will remain negligible 
until some attention will be paid to out-of-the-box compatibility - at least 
like in CrossOver); it was just a good reason to check for potential 
incompatibilities under 'native' Win platforms. Also note that having WINE 
work perfectly is not our goal (personally I would like it, but the company 
coudln't care less).



Managed=N breaks focusing for everything on my box (bug #2149)...
As it would fix the problem for 99% of our users, and won't affect those who 
doesn't run our app, IMO it is still good enough.


Also I remember you've just told that fixing bugs is easy - why does it 
still exist then?


_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/





Re: Throwing in an idea (probably it was discussed before though)

2005-08-22 Thread Ivan Leo Puoti

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 the problem for 99% of our users, and won't affect those 
who doesn't run our app, IMO it is still good enough.


Then write the setting to the reg yourself, and hope the wine config key never 
moves.

Ivan.




Re: Throwing in an idea (probably it was discussed before though)

2005-08-22 Thread Ivan Leo Puoti

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 config 
or run winecfg, but those 80% will be lost.


As some have suggested you can write the settings to the registry yourself

Ivan.




Re: Throwing in an idea (probably it was discussed before though)

2005-08-22 Thread Shachar Shemesh
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 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.

If you give a scenario that is easilly reproduceable, it is rare that
problems go more than a couple of days unfixed. Sometimes you hit
something that requires a rewirte of half the relevant subsystem, but
usually it's just a small ommision, and is easilly fixed.

The thing that takes so much time is tracking the exact behavior that
goes wrong.

 Also I remember you've just told that fixing bugs is easy - why does
 it still exist then?

Fixing bugs is easy. Finding them is not. It's exactly the same with
proprietary software too, btw. If a user reports this doesn't work, my
experience is that you spend two weeks in QA trying to reproduce the
problem, half a day fixing it, and a couple more weeks testing the
solution. It's fairly rare that the relations are much different, but do
let us in on your experience.

All we are saying is pin-point the problem for us.

 Shachar



Re: Throwing in an idea (probably it was discussed before though)

2005-08-22 Thread Troy Rollo
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 bugs in Wine 
is corporate policy.



Throwing in an idea (probably it was discussed before though)

2005-08-21 Thread John Smith
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 contradict to the 'big bright future' of the WINE (with all the 
apps running flawlessly under WINE), it would hopefully allow for immediate 
increase of out-of-the-box supported applications.


For example, it could be a resource string of special format (for example, 
__WINE_CONFIG_HINT: Managed = N), and multiple hints should be 
allowed. This hint should override system-wide settings but in turn should 
be overridden by per-app settings in wine config file/registry.


_
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/





Re: Throwing in an idea (probably it was discussed before though)

2005-08-21 Thread Ivan Leo Puoti

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 to somewhat contradict to the 'big bright future' of the WINE (with 
all the apps running flawlessly under WINE), it would hopefully allow 
for immediate increase of out-of-the-box supported applications.


For example, it could be a resource string of special format (for 
example, __WINE_CONFIG_HINT: Managed = N), and multiple hints 
should be allowed. This hint should override system-wide settings but in 
turn should be overridden by per-app settings in wine config file/registry.


This will just allow developers to hide bugs in wine and slow development even further, I thing it's 
a bad idea.


Ivan.