Re: cabinet: Revert cabinet: Fix for FDICopy with an empty cabinet file.
On Sat, Apr 26, 2008 at 1:03 AM, Reece Dunn [EMAIL PROTECTED] wrote: 2008/4/26 James Hawkins [EMAIL PROTECTED]: Hi, The test was incorrect and failed on all platforms. Vitaly, please ask someone to test your patches on a real windows system in the future if you don't have access to one. Wouldn't it be better to actually fix the test case than revert it all together? Just simply change line 630: -ok(ret, Expected FDICopy to succeed\n); +ok(!ret, Expected FDICopy to fail\n); and remove the todo_wine. Adding a GetLastError check would be good as well. Have you actually read the patch or the changelog for that matter? -- James Hawkins
Re: ddraw: Remove a test that fails in VMs
On Sat, Apr 26, 2008 at 1:11 AM, Reece Dunn [EMAIL PROTECTED] wrote: 2008/4/26 James Hawkins [EMAIL PROTECTED]: Hi, The tests aren't run anyway in this case. Changelog: * Remove a test that fails in VMs. ... hr = IDirect3D7_CreateDevice(Direct3D, IID_IDirect3DRefDevice, Surface, Direct3DDevice); } } -ok(hr == D3D_OK, IDirect3D7_CreateDevice failed with %08x\n, hr); Wouldn't it be better to move the ok line to directly after the IDirect3D7_CreateDevice call? That way, on VM machines the test will not get run and on non-VM machines it will, as it is a valid test in that case. No, the test will still be run in all cases, VM or not, and will fail in VMs. The function just sets up the direct3d device object for other tests; there's no point in an ok test in this function, especially when it doesn't pass for all systems. -- James Hawkins
Re: cabinet: Revert cabinet: Fix for FDICopy with an empty cabinet file.
2008/4/26 James Hawkins [EMAIL PROTECTED]: Hi, The test was incorrect and failed on all platforms. Vitaly, please ask someone to test your patches on a real windows system in the future if you don't have access to one. Wouldn't it be better to actually fix the test case than revert it all together? Just simply change line 630: -ok(ret, Expected FDICopy to succeed\n); +ok(!ret, Expected FDICopy to fail\n); and remove the todo_wine. Adding a GetLastError check would be good as well. - Reece
Re: ddraw: Remove a test that fails in VMs
2008/4/26 James Hawkins [EMAIL PROTECTED]: Hi, The tests aren't run anyway in this case. Changelog: * Remove a test that fails in VMs. ... hr = IDirect3D7_CreateDevice(Direct3D, IID_IDirect3DRefDevice, Surface, Direct3DDevice); } } -ok(hr == D3D_OK, IDirect3D7_CreateDevice failed with %08x\n, hr); Wouldn't it be better to move the ok line to directly after the IDirect3D7_CreateDevice call? That way, on VM machines the test will not get run and on non-VM machines it will, as it is a valid test in that case. - Reece
Re: cabinet: Revert cabinet: Fix for FDICopy with an empty cabinet file.
2008/4/26 James Hawkins [EMAIL PROTECTED]: On Sat, Apr 26, 2008 at 1:03 AM, Reece Dunn [EMAIL PROTECTED] wrote: 2008/4/26 James Hawkins [EMAIL PROTECTED]: Hi, The test was incorrect and failed on all platforms. Vitaly, please ask someone to test your patches on a real windows system in the future if you don't have access to one. Wouldn't it be better to actually fix the test case than revert it all together? Have you actually read the patch or the changelog for that matter? I misread the Revert ... part to mean a full revert of the original patch. Sorry for the noise. - Reece
Re: ddraw: Remove a test that fails in VMs
2008/4/26 James Hawkins [EMAIL PROTECTED]: On Sat, Apr 26, 2008 at 1:11 AM, Reece Dunn [EMAIL PROTECTED] wrote: Wouldn't it be better to move the ok line to directly after the IDirect3D7_CreateDevice call? That way, on VM machines the test will not get run and on non-VM machines it will, as it is a valid test in that case. No, the test will still be run in all cases, VM or not, and will fail in VMs. The function just sets up the direct3d device object for other tests; there's no point in an ok test in this function, especially when it doesn't pass for all systems. Ok. - Reece
Re: [GSoC][RFC] Case Insensitive Filesystem
Hi, Just wanted to let you know that i have finally found the time to set up a little page for ciopfs: http://www.brain-dump.org/projects/ciopfs/ There are certainly a few things which could be improved but it in my tests it worked quite well in it's current form. As it seems that the idea of a fuse mounted .wine directory isn't that popular i will probably leave the code as it is and move on to other things. Anyway it was fun to do some work with fuse and in case someone is interested in it you now know where you can find it. Regards, Marc -- Marc Andre Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [Try 3] [1/2] cabinet.dll - FDICopy: Test added
Hi, Hi, The test was incorrect and failed on all platforms. Vitaly, please ask someone to test your patches on a real windows system in the future if you don't have access to one. I have never received this message. I found it by chance in the comment of Reece Dunn. Does the problem still persist? -- Best wishes, Vitaly Perov Russia, Saint-Petersburg. www.etersoft.ru
Re: [dinput] move the common joystick_map_.* methods from joystick_linuxinput.c into device.c
Christoph Frick wrote: diff --git a/dlls/dinput/device.c b/dlls/dinput/device.c index 5f927d0..baca0b3 100644 --- a/dlls/dinput/device.c +++ b/dlls/dinput/device.c @@ -1400,3 +1400,54 @@ HRESULT WINAPI IDirectInputDevice8WImpl_GetImageInfo(LPDIRECTINPUTDEVICE8W iface Please don't. Device is common for everything (keyboard, mouse, joysticks). Joystick specific code should not be there. Vitaliy.
Re: [dinput] initial support for BSD's usbhid joysticks
Christoph Frick wrote:
From 7618ceb6941c0dffac9c48c1fa1aeb7e821673a2 Mon Sep 17 00:00:00 2001
From: Christoph Frick [EMAIL PROTECTED]
Date: Sat, 26 Apr 2008 02:50:01 +0200
Subject: [PATCH] Initial support for BSD's usbhid joysticks
Please consider this a tracer bullet. I had only time to test it with a
4-axis/4-button wheel in LFS in FreeBSD 7.0. I will take further tests using a
flight stick and other games soon. But for now i just want to see, what others
have to say about it.
---
Please use 4 spaces indentation, no tabs.
+ snprintf(buf, MAX_PATH, FMT_UHIDDEVS, i);
+ buf[MAX_PATH - 1] = 0;
snprintf always writes terminating '\0' character at the end of the string.
You don't need to explicitly do that yourself.
+ if ((fd = open(buf, O_RDWR | O_NDELAY, 0)) == -1) {
+ TRACE(Unable to open %s read/write: %s\n, buf,
strerror(errno));
+ continue;
+ }
Do you really have to open it read/write? Shouldn't read only be enough for
not FF joystick?
The only way I can think of to remove code duplication is to create base
joystick class. There were no reason for that with only 2 joystick drivers.
With third one should really do it.
Vitaliy.
Re: [dinput] initial support for BSD's usbhid joysticks
snprintf always writes terminating '\0' character at the end of the string. Only if the buffer contains enough space for the terminating null. You don't need to explicitly do that yourself. That's probably true in this case. --Juan
Re: [dinput] initial support for BSD's usbhid joysticks
Juan Lang wrote:
snprintf always writes terminating '\0' character at the end of the string.
Only if the buffer contains enough space for the terminating null.
No (in case buffer at least 1 byte long). From man page:
The functions snprintf() and vsnprintf() write at most size bytes (including
the trailing null byte ('\0')) to str.
This means that terminating zero is always written to the buffer (if it's at
least 1 char long). I agree that above part of the man page is not exactly
clear. But you can find a better explanation on the web, which spell out
what is actually written.
This is not the infamous strncpy that does what you said.
Vitaliy.
Re: [dinput] initial support for BSD's usbhid joysticks
No (in case buffer at least 1 byte long). Oh, right you are! Thanks, I did confuse that the strncpy. --Juan
Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.
On Wed, Apr 23, 2008 at 5:59 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: Module: wine Branch: master Commit: faaccca59be08be547ec4e1948b6306eff3808a2 URL: http://source.winehq.org/git/wine.git/?a=commit;h=faaccca59be08be547ec4e1948b6306eff3808a2 Author: Dan Kegel [EMAIL PROTECTED] Date: Tue Apr 22 17:56:36 2008 -0700 winecfg: Restrict dpi slider to sane values. --- programs/winecfg/x11drvdlg.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/programs/winecfg/x11drvdlg.c b/programs/winecfg/x11drvdlg.c index bfa6ec5..c0ec058 100644 --- a/programs/winecfg/x11drvdlg.c +++ b/programs/winecfg/x11drvdlg.c @@ -35,9 +35,9 @@ WINE_DEFAULT_DEBUG_CHANNEL(winecfg); -#define RES_MAXLEN 5 /* the maximum number of characters in a screen dimension. 5 digits should be plenty, what kind of crazy person runs their screen 10,000 pixels across? */ +#define RES_MAXLEN 5 /* max number of digits in a screen dimension. 5 digits should be plenty */ #define MINDPI 96 -#define MAXDPI 480 +#define MAXDPI 144 /* making this too high surprises and hurts users */ #define DEFDPI 96 #define IDT_DPIEDIT 0x1234 Dan, this basically reverted commit 0110512904d9c646abef416819a057c06d3f2c97, which bumped MAXDPI from 160 to 480 because some users specifically requested the ability for higher DPI settings. I think we need to decide what we want and stop the tug-o-war.
Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.
On Sat, Apr 26, 2008 at 10:37 AM, Lei Zhang [EMAIL PROTECTED] wrote: On Wed, Apr 23, 2008 at 5:59 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: Module: wine Branch: master Commit: faaccca59be08be547ec4e1948b6306eff3808a2 URL: http://source.winehq.org/git/wine.git/?a=commit;h=faaccca59be08be547ec4e1948b6306eff3808a2 Author: Dan Kegel [EMAIL PROTECTED] Date: Tue Apr 22 17:56:36 2008 -0700 winecfg: Restrict dpi slider to sane values. --- programs/winecfg/x11drvdlg.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/programs/winecfg/x11drvdlg.c b/programs/winecfg/x11drvdlg.c index bfa6ec5..c0ec058 100644 --- a/programs/winecfg/x11drvdlg.c +++ b/programs/winecfg/x11drvdlg.c @@ -35,9 +35,9 @@ WINE_DEFAULT_DEBUG_CHANNEL(winecfg); -#define RES_MAXLEN 5 /* the maximum number of characters in a screen dimension. 5 digits should be plenty, what kind of crazy person runs their screen 10,000 pixels across? */ +#define RES_MAXLEN 5 /* max number of digits in a screen dimension. 5 digits should be plenty */ #define MINDPI 96 -#define MAXDPI 480 +#define MAXDPI 144 /* making this too high surprises and hurts users */ #define DEFDPI 96 #define IDT_DPIEDIT 0x1234 Dan, this basically reverted commit 0110512904d9c646abef416819a057c06d3f2c97, which bumped MAXDPI from 160 to 480 because some users specifically requested the ability for higher DPI settings. I think we need to decide what we want and stop the tug-o-war. Please see bug 9715.
Re: 1.0 idea - ntdll - add a messagebox for missing dlls
On Fri, Apr 25, 2008 at 2:07 PM, Dan Kegel [EMAIL PROTECTED] wrote: * have start.exe examine the import table of the exe and do an explicit check (hard) Seems like too much to go in to start anyway. And I am lazy * have start.exe set an environment variable saying show graphical error box on dll load failure, and clear that before calling executed apps' WinMain() (easy) So something like start.exe.so in Unix mode would set a variable like VERSBOSE_USERDEBUG or which then we could query in the loader using RtlQueryEnvironmentVariable_U or something that would trigger the MessageBox from the example code I already wrote in ntdll? Thanks Steven -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: [PATCH 6/7] widl: Accept integer constant suffixes in the lexer.
On Sat, Apr 26, 2008 at 09:51:58AM +0100, Robert Shearman wrote: +u_suffix (l|L) +l_suffix (u|U) I'm guessing you meant for these to be the other way around.
Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.
On 4/26/08, Lei Zhang [EMAIL PROTECTED] wrote: On Sat, Apr 26, 2008 at 10:37 AM, Lei Zhang [EMAIL PROTECTED] wrote: On Wed, Apr 23, 2008 at 5:59 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: Module: wine Branch: master Commit: faaccca59be08be547ec4e1948b6306eff3808a2 URL: http://source.winehq.org/git/wine.git/?a=commit;h=faaccca59be08be547ec4e1948b6306eff3808a2 Author: Dan Kegel [EMAIL PROTECTED] Date: Tue Apr 22 17:56:36 2008 -0700 winecfg: Restrict dpi slider to sane values. --- programs/winecfg/x11drvdlg.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/programs/winecfg/x11drvdlg.c b/programs/winecfg/x11drvdlg.c index bfa6ec5..c0ec058 100644 --- a/programs/winecfg/x11drvdlg.c +++ b/programs/winecfg/x11drvdlg.c @@ -35,9 +35,9 @@ WINE_DEFAULT_DEBUG_CHANNEL(winecfg); -#define RES_MAXLEN 5 /* the maximum number of characters in a screen dimension. 5 digits should be plenty, what kind of crazy person runs their screen 10,000 pixels across? */ +#define RES_MAXLEN 5 /* max number of digits in a screen dimension. 5 digits should be plenty */ #define MINDPI 96 -#define MAXDPI 480 +#define MAXDPI 144 /* making this too high surprises and hurts users */ #define DEFDPI 96 #define IDT_DPIEDIT 0x1234 Dan, this basically reverted commit 0110512904d9c646abef416819a057c06d3f2c97, which bumped MAXDPI from 160 to 480 because some users specifically requested the ability for higher DPI settings. I think we need to decide what we want and stop the tug-o-war. Please see bug 9715. The change was specifically requested. A warning if someone sets it over 150, or a small explanation in winecfg would be better IMHO.
Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.
Austin English wrote: On 4/26/08, *Lei Zhang* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Sat, Apr 26, 2008 at 10:37 AM, Lei Zhang [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Wed, Apr 23, 2008 at 5:59 AM, Alexandre Julliard [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Module: wine Branch: master Commit: faaccca59be08be547ec4e1948b6306eff3808a2 URL: http://source.winehq.org/git/wine.git/?a=commit;h=faaccca59be08be547ec4e1948b6306eff3808a2 Author: Dan Kegel [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Date: Tue Apr 22 17:56:36 2008 -0700 winecfg: Restrict dpi slider to sane values. --- programs/winecfg/x11drvdlg.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/programs/winecfg/x11drvdlg.c b/programs/winecfg/x11drvdlg.c index bfa6ec5..c0ec058 100644 --- a/programs/winecfg/x11drvdlg.c +++ b/programs/winecfg/x11drvdlg.c @@ -35,9 +35,9 @@ WINE_DEFAULT_DEBUG_CHANNEL(winecfg); -#define RES_MAXLEN 5 /* the maximum number of characters in a screen dimension. 5 digits should be plenty, what kind of crazy person runs their screen 10,000 pixels across? */ +#define RES_MAXLEN 5 /* max number of digits in a screen dimension. 5 digits should be plenty */ #define MINDPI 96 -#define MAXDPI 480 +#define MAXDPI 144 /* making this too high surprises and hurts users */ #define DEFDPI 96 #define IDT_DPIEDIT 0x1234 Dan, this basically reverted commit 0110512904d9c646abef416819a057c06d3f2c97, which bumped MAXDPI from 160 to 480 because some users specifically requested the ability for higher DPI settings. I think we need to decide what we want and stop the tug-o-war. Please see bug 9715. The change was specifically requested. A warning if someone sets it over 150, or a small explanation in winecfg would be better IMHO. For anyone who wants more then 150 they can change that in the registry. Honestly I've yet to see a single device with such a high DPI! And since by definition users will do everything to screw themselves up we have to make it hard enough so majority will just give up. Vitaliy.
Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.
On Sat, Apr 26, 2008 at 1:54 PM, Vitaliy Margolen [EMAIL PROTECTED] wrote: Austin English wrote: On 4/26/08, *Lei Zhang* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Sat, Apr 26, 2008 at 10:37 AM, Lei Zhang [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Wed, Apr 23, 2008 at 5:59 AM, Alexandre Julliard [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Module: wine Branch: master Commit: faaccca59be08be547ec4e1948b6306eff3808a2 URL: http://source.winehq.org/git/wine.git/?a=commit;h=faaccca59be08be547ec4e1948b6306eff3808a2 Author: Dan Kegel [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Date: Tue Apr 22 17:56:36 2008 -0700 winecfg: Restrict dpi slider to sane values. --- programs/winecfg/x11drvdlg.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/programs/winecfg/x11drvdlg.c b/programs/winecfg/x11drvdlg.c index bfa6ec5..c0ec058 100644 --- a/programs/winecfg/x11drvdlg.c +++ b/programs/winecfg/x11drvdlg.c @@ -35,9 +35,9 @@ WINE_DEFAULT_DEBUG_CHANNEL(winecfg); -#define RES_MAXLEN 5 /* the maximum number of characters in a screen dimension. 5 digits should be plenty, what kind of crazy person runs their screen 10,000 pixels across? */ +#define RES_MAXLEN 5 /* max number of digits in a screen dimension. 5 digits should be plenty */ #define MINDPI 96 -#define MAXDPI 480 +#define MAXDPI 144 /* making this too high surprises and hurts users */ #define DEFDPI 96 #define IDT_DPIEDIT 0x1234 Dan, this basically reverted commit 0110512904d9c646abef416819a057c06d3f2c97, which bumped MAXDPI from 160 to 480 because some users specifically requested the ability for higher DPI settings. I think we need to decide what we want and stop the tug-o-war. Please see bug 9715. The change was specifically requested. A warning if someone sets it over 150, or a small explanation in winecfg would be better IMHO. For anyone who wants more then 150 they can change that in the registry. Honestly I've yet to see a single device with such a high DPI! And since by definition users will do everything to screw themselves up we have to make it hard enough so majority will just give up. Vitaliy. How about something like the following, along with restoring back to 480 max? diff --git a/programs/winecfg/En.rc b/programs/winecfg/En.rc index 65b6fd1..97550c0 100644 --- a/programs/winecfg/En.rc +++ b/programs/winecfg/En.rc @@ -87,7 +87,7 @@ BEGIN COMBOBOX IDC_D3D_VSHADER_MODE,100,201,145,70,CBS_DROPDOWNLIST | WS_VSCROLL | WS_TABSTOP CONTROL Allow Pixel Shader (if supported by hardware),IDC_D3D_PSHADER_MODE,Button,BS_AUTOCHECKBOX | WS_TABSTOP,15,219,230,10 -GROUPBOX Screen Resolution ,IDC_STATIC,8,242,244,25 +GROUPBOX Screen Resolution - Don't change this if you don't know what it is! ,IDC_STATIC,8,242,244,25 CONTROL , IDC_RES_TRACKBAR, msctls_trackbar32,WS_TABSTOP,12,250,187,15 EDITTEXTIDC_RES_DPIEDIT,204,250,23,13,ES_NUMBER|WS_TABSTOP LTEXT dpi,IDC_STATIC,235,252,10,8
Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vitaliy Margolen wrote: | For anyone who wants more then 150 they can change that in the registry. | Honestly I've yet to see a single device with such a high DPI! I have ported Wine to run on the OLPC XO, which has a 200 DPI screen. I am currently running Wine at 160 DPI, which makes the fonts somewhat small but improves the ability of Windows apps to fit on the 7.5 screen. Also, some Windows software runs badly at high DPI. Some of Wine's own utilities, such as wordpad.exe, seem to malfunction even at 160 dpi. - --Ben P.S. If you have an XO, you may try out Wine for XO from http://dev.laptop.org/~bemasc/DOSConsole-3.xo -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIE5W/UJT6e6HFtqQRAs1tAKChfwNIHwozyCd6UGAYFXRla0QIxQCgkUqk EvCic33qC8VRgzZjScvLSk4= =dn3X -END PGP SIGNATURE-
Re: [dinput] move the common joystick_map_.* methods from joystick_linuxinput.c into device.c
On Sat, Apr 26, 2008 at 08:39:19AM -0600, Vitaliy Margolen wrote: Christoph Frick wrote: diff --git a/dlls/dinput/device.c b/dlls/dinput/device.c index 5f927d0..baca0b3 100644 --- a/dlls/dinput/device.c +++ b/dlls/dinput/device.c @@ -1400,3 +1400,54 @@ HRESULT WINAPI IDirectInputDevice8WImpl_GetImageInfo(LPDIRECTINPUTDEVICE8W iface Please don't. Device is common for everything (keyboard, mouse, joysticks). Joystick specific code should not be there. i dont like it in joysticks_linuxinput. it stands there right before the bigbig ifdef and the only reason it is there, is because it was written for that file in the first place. any suggestions where to move it? on the other hand my other patch does not depend on the move - just on the functions - so we just keep in the linux file until we get the common joystick class. -- cu pgpIe0pxjbGtg.pgp Description: PGP signature
Re: [dinput] initial support for BSD's usbhid joysticks
On Sat, Apr 26, 2008 at 08:57:28AM -0600, Vitaliy Margolen wrote:
Please use 4 spaces indentation, no tabs.
what happened to original author decides? ;)
i will run the uncopied parts through indent once i find the -unreadable
flag for it...
+ snprintf(buf, MAX_PATH, FMT_UHIDDEVS, i);
+ buf[MAX_PATH - 1] = 0;
snprintf always writes terminating '\0' character at the end of the
string. You don't need to explicitly do that yourself.
ack
+ if ((fd = open(buf, O_RDWR | O_NDELAY, 0)) == -1) {
+ TRACE(Unable to open %s read/write: %s\n, buf,
strerror(errno));
+ continue;
+ }
Do you really have to open it read/write? Shouldn't read only be
enough for not FF joystick?
i tested beforehand with usbhidctl - and it needed r/w for just getting
the state there. so i assumed it is needed. i will just try it out.
The only way I can think of to remove code duplication is to create
base joystick class. There were no reason for that with only 2
joystick drivers. With third one should really do it.
Four with an potential xinput implementation.
Some of the functions had subtle changes; but i guess they could be
unified. if there where no FF the interface would be quite small:
- find them
- (un)acquire
- poll
I can not think of stuff, that get/setProperty would really need a
special implementation for. A common JoyDev struct could hold all vital
data; we could keep a private area for the driver around.
But i guess I can go with the release before this changes. We can cope
with the dups later on.
so my next steps are:
- fix above mentioned problems
- test with a TM cougar (6 axes, 28 buttons)
- test more games (GPL, NR2003 - especially ones, that needed patches in
the linux parts some time ago: IL2 and RBR)
i head for a release on monday - if there are no show stoppers ahead,
of course.
BTW: no complains about the autoconf additions?
--
cu
pgpToltWujSYd.pgp
Description: PGP signature
Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.
On Sat, Apr 26, 2008 at 12:54:14PM -0600, Vitaliy Margolen wrote: For anyone who wants more then 150 they can change that in the registry. Honestly I've yet to see a single device with such a high DPI! for the fun of it - i run wine at 144 it is one less than i need: 0:32 !1 [EMAIL PROTECTED]:~% grep DPI /var/log/Xorg.0.log (--) NVIDIA(0): DPI set to (147, 145); computed from UseEdidDpi X config (15 notebook with 1920x1200) -- cu pgp8VZ7auvFi8.pgp Description: PGP signature
Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.
On Sat, Apr 26, 2008 at 10:40 AM, Lei Zhang [EMAIL PROTECTED] wrote: URL: http://source.winehq.org/git/wine.git/?a=commit;h=faaccca59be08be547ec4e1948b6306eff3808a2 Author: Dan Kegel [EMAIL PROTECTED] Date: Tue Apr 22 17:56:36 2008 -0700 winecfg: Restrict dpi slider to sane values. Dan, this basically reverted commit 0110512904d9c646abef416819a057c06d3f2c97, which bumped MAXDPI from 160 to 480 because some users specifically requested the ability for higher DPI settings. I think we need to decide what we want and stop the tug-o-war. Please see bug 9715. 480 was completely unusable; average Joes were setting it at random and were unable to use winecfg to reset it to something sane. I found a few monitors out there at 200 dpi, so perhaps that would be a reasonable upper limit, but we'd have to check to make sure that the average person with a crap monitor could set that to 200dpi, realize it was wrong, and set it back without having to edit the registry by hand. - Dan
Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.
On Sat, Apr 26, 2008 at 6:22 PM, Dan Kegel [EMAIL PROTECTED] wrote: On Sat, Apr 26, 2008 at 10:40 AM, Lei Zhang [EMAIL PROTECTED] wrote: URL: http://source.winehq.org/git/wine.git/?a=commit;h=faaccca59be08be547ec4e1948b6306eff3808a2 Author: Dan Kegel [EMAIL PROTECTED] Date: Tue Apr 22 17:56:36 2008 -0700 winecfg: Restrict dpi slider to sane values. Dan, this basically reverted commit 0110512904d9c646abef416819a057c06d3f2c97, which bumped MAXDPI from 160 to 480 because some users specifically requested the ability for higher DPI settings. I think we need to decide what we want and stop the tug-o-war. Please see bug 9715. 480 was completely unusable; average Joes were setting it at random and were unable to use winecfg to reset it to something sane. I found a few monitors out there at 200 dpi, so perhaps that would be a reasonable upper limit, but we'd have to check to make sure that the average person with a crap monitor could set that to 200dpi, realize it was wrong, and set it back without having to edit the registry by hand. - Dan Why not wizardify it? Enter the physical size of your screen: x in/cm y in/cm Then use appropriate dpi based on current resolution? Does it not work like that? --John
Side affects from running wineprefixcreate
So for one notable problems is some file types being reset by Wine. Looks like it comes from dlls/mshtml/mshtml.inf. At a minimum all the created registry entries should not overwrite already existing ones. Vitaliy.
Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.
On Saturday 26 April 2008 04:58:53 pm John Klehm wrote: On Sat, Apr 26, 2008 at 6:22 PM, Dan Kegel [EMAIL PROTECTED] wrote: I found a few monitors out there at 200 dpi, so perhaps that would be a reasonable upper limit, but we'd have to check to make sure that the average person with a crap monitor could set that to 200dpi, realize it was wrong, and set it back without having to edit the registry by hand. - Dan Why not wizardify it? Enter the physical size of your screen: x in/cm y in/cm Then use appropriate dpi based on current resolution? Does it not work like that? What about getting the value from X? Since Windows only expects one DPI for both vertical and horizontal, while X provides two, Wine could just take the mean and autoset that on startup.
Re: Side affects from running wineprefixcreate
On Saturday 26 April 2008 05:48:35 pm Vitaliy Margolen wrote: At a minimum all the created registry entries should not overwrite already existing ones. Doesn't that kind of defeat the purpose of having wineprefixcreate executed, which is to update the registry? Not that I don't agree there could be a problem with just blindly overwriting. But blindly ignoring can be just as much of a problem.
Re: Side affects from running wineprefixcreate
Chris Robinson wrote: On Saturday 26 April 2008 05:48:35 pm Vitaliy Margolen wrote: At a minimum all the created registry entries should not overwrite already existing ones. Doesn't that kind of defeat the purpose of having wineprefixcreate executed, which is to update the registry? Not that I don't agree there could be a problem with just blindly overwriting. But blindly ignoring can be just as much of a problem. That's the problem of forcefully refreshing registry. If you don't do it - some old cruft will get in a way of new stiff. If you do - you removing perfectly good entries that user had there. However things like file associations should not be overwritten. Especially that they don't work after that: $ wine start image.jpg wine: configuration in '/home/vitaliy/.wine' has been updated. fixme:exec:SHELL_execute flags ignored: 0x0500 Application could not be started, or no application associated with the specified file. ShellExecuteEx failed: Success Vitaliy.
Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.
On Saturday April 26 2008 23:22:37 Dan Kegel wrote: On Sat, Apr 26, 2008 at 10:40 AM, Lei Zhang [EMAIL PROTECTED] wrote: URL: http://source.winehq.org/git/wine.git/?a=commit;h=faaccca59be08be54 7ec4e1948b6306eff3808a2 Author: Dan Kegel [EMAIL PROTECTED] Date: Tue Apr 22 17:56:36 2008 -0700 winecfg: Restrict dpi slider to sane values. Dan, this basically reverted commit 0110512904d9c646abef416819a057c06d3f2c97, which bumped MAXDPI from 160 to 480 because some users specifically requested the ability for higher DPI settings. I think we need to decide what we want and stop the tug-o-war. Please see bug 9715. 480 was completely unusable; average Joes were setting it at random and were unable to use winecfg to reset it to something sane. I found a few monitors out there at 200 dpi, so perhaps that would be a reasonable upper limit, but we'd have to check to make sure that the average person with a crap monitor could set that to 200dpi, realize it was wrong, - Dan 200 DPI limit is acceptable for most users. However, what this patch done by setting maximum to this small value (144) doesn't seems to be acceptable. There is enough users who want higher values and BTW I'm one of them (I need 150 and 160; I need two values because I have more than one monitor/computer). So if we want to set the maximum limit lower than on Windows we need to choose reasonable value for most of us. I propose that we agree on at least 200 DPI limit in winecfg otherwise this puts too much inconvenience (especially for everyone who create new WINE prefix for new set of Windows programs, and this is what I do regularly). and set it back without having to edit the registry by hand. Just a note: in all WMs I have tried winecfg remains usable even on 480 DPI because you can move the window as usually with Alt+Mouse_move or Meta+Mouse_move, and you need to move the window only once to reset the setting to any other value.
Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.
On Sat, Apr 26, 2008 at 7:54 PM, L. Rahyen [EMAIL PROTECTED] wrote: 200 DPI limit is acceptable for most users. However, what this patch done by setting maximum to this small value (144) doesn't seems to be acceptable. Users really are lost if they set a too-high value. They don't know how to do alt+mouse_move. Thus simply setting the limit higher again would be a support nightmare; we got a preview of that on wine-users recently, with user after user panicking. But as I wrote in http://bugs.winehq.org/show_bug.cgi?id=9715 we can probably do something that will make everybody happy: arrange for winecfg to never let the user set dpi so high that winecfg is bigger than the screen. That's probably pretty easy to do. And we can probably make high-res users happier still by defaulting to Xft.dpi (used by Gnome and maybe KDE; it's set by default to 96, but is increased by some users of high-res displays). Anyone willing to try implementing that? I'd do it, but I'm kind of limited by sore hands and time these days... - Dan
Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.
On Sunday April 27 2008 03:23:40 Dan Kegel wrote: But as I wrote in http://bugs.winehq.org/show_bug.cgi?id=9715 we can probably do something that will make everybody happy: arrange for winecfg to never let the user set dpi so high that winecfg is bigger than the screen. Yes, I think this would be better solution. This will probably will work well for everyone and will be much better than hard-coded limit.
