August 2012 - Wine-Devel - list.winehq.org

Re: [3/3] gdiplus: GdipMeasureCharacterRanges should respect device units and transformations.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > >> Shouldn't you be scaling range_size.cx as well? > > > > No, range_size is already in pixels. > > So is bounds. I think you need to scale both of them to world units. You are right, somehow I missed that, thanks. -- Dmitry.

Aug. 22, 2012

Re: [3/3] gdiplus: GdipMeasureCharacterRanges should respect device units and transformations.

by Vincent Povirk

>> Shouldn't you be scaling range_size.cx as well? > > No, range_size is already in pixels. So is bounds. I think you need to scale both of them to world units.

Aug. 22, 2012

Re: [3/3] gdiplus: GdipMeasureCharacterRanges should respect device units and transformations.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > GetTextExtentExPointW(hdc, string + index, range_start - index, > > INT_MAX, NULL, NULL, &range_size); > > - range_rect.X = bounds->X + range_size.cx; > > + range_rect.X = bounds->X / args->rel_width + range_size.cx; > > > > GetTextExtentExPointW(hdc, string + index, range_end - index, > > INT_MAX, NULL, NULL, &range_size); > > - range_rect.Width = (bounds->X + range_size.cx) - range_rect.X; > > + range_rect.Width = (bounds->X / args->rel_width + range_size.cx) - range_rect.X; > > Shouldn't you be scaling range_size.cx as well? No, range_size is already in pixels. -- Dmitry.

Aug. 22, 2012

Re: [3/3] gdiplus: GdipMeasureCharacterRanges should respect device units and transformations.

by Vincent Povirk

> GetTextExtentExPointW(hdc, string + index, range_start - index, > INT_MAX, NULL, NULL, &range_size); > - range_rect.X = bounds->X + range_size.cx; > + range_rect.X = bounds->X / args->rel_width + range_size.cx; > > GetTextExtentExPointW(hdc, string + index, range_end - index, > INT_MAX, NULL, NULL, &range_size); > - range_rect.Width = (bounds->X + range_size.cx) - range_rect.X; > + range_rect.Width = (bounds->X / args->rel_width + range_size.cx) - range_rect.X; Shouldn't you be scaling range_size.cx as well?

Aug. 22, 2012

Re: Have there been any problems with Wine on GCC 4.7?

by Austin English

On Mon, Aug 20, 2012 at 11:55 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote: > >> >> >> http://source.winehq.org/git/wine.git/commitdiff/3f1dbaf3df0ae8ec2f0e86191e… >> >> -- >> -Austin > > > the trouble with this patch is that it enables debug info whatever the > default configuration is... > A+ > > -- > Eric Pouech -g was already the default. Most packagers (to my knowledge) provide a separate debug package, which isn't installed by default. -- -Austin

Aug. 21, 2012

Re: user32: Don't limit time needed for WM_DDE_INITIATE processing.

by Piotr Caban

On 08/21/12 17:40, Alexandre Julliard wrote: > Piotr Caban<piotr(a)codeweavers.com> writes: > >> Current timeout is too small for Microsoft Office 2010 in some cases. >> I've checked that DdeConnect succeeds on windows when it needs to wait >> for 10 minutes. > > Are you sure that you want to remove the SMTO_ABORTIFHUNG flag? Does a > hung process really prevent all DDE connections? My bad, it was not my intention. I will send another patch. I was only trying to allow the application to spend more time while processing WM_DDE_INITIATE message.

Aug. 21, 2012

Re: user32: Don't limit time needed for WM_DDE_INITIATE processing.

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > Current timeout is too small for Microsoft Office 2010 in some cases. > I've checked that DdeConnect succeeds on windows when it needs to wait > for 10 minutes. Are you sure that you want to remove the SMTO_ABORTIFHUNG flag? Does a hung process really prevent all DDE connections? -- Alexandre Julliard julliard(a)winehq.org

Aug. 21, 2012

Re: [1/3] dinput: Disable linuxinput or linux joysticks based on registry key

by Alexandre Julliard

Lucas Zawacki <lfzawacki(a)gmail.com> writes: > From: Lucas Fialho Zawacki <lfzawacki(a)gmail.com> > > In the form of "Disable Controllername"="driver" > > Examples: > Disable "Usb Controller"="js" disable linux js driver > Disable "OtherController"="event,js" disable linux js and event drivers That's a fairly complicated way to disable a given joystick. What you probably want is to give them a unique name and have a enable/disable value for each name. -- Alexandre Julliard julliard(a)winehq.org

Aug. 21, 2012

Re: mountmgr.sys: For loop-mounted devices, use the backing file

by Damjan Jovanovic

On Tue, Aug 21, 2012 at 4:25 PM, GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > I thought mounting the ISO should be the same thing than inserting the disc > in the drive. > But you seem to think that the current behaviour is the right one so in this > case, simply ignore my patch. > > Try using cdemu to load that ISO into a virtual CDROM drive. There's an Ubuntu PPA for it at https://launchpad.net/~cdemu/+archive/ppa Damjan

Aug. 21, 2012

Re: mountmgr.sys: For loop-mounted devices, use the backing file

by GOUJON Alexandre

On 08/21/2012 11:49 AM, Alexandre Julliard wrote: > Alexandre Goujon <ale.goujon(a)gmail.com> writes: > >> As part of their copy protection, some games use some ioctl's to check some physical attributes. >> Unfortunately, when using the loop device, some ioctl fail (like IOCTL_SCSI_GET_ADDRESS). >> A simple fix is to use /path/to/the/file.ISO instead of /dev/loopX. > Several places depend on this being a device. Besides, failing to get > the SCSI address of a loop mount seems like correct behavior to me. > I originally wanted this patch in because my game was failing when I mounted the ISO of the disc via the loop device. The game was calling GetVolumeInformation to check its serial and to do so, GetVolumeInformation has to look at some blocks at specific offsets. But seeking (SetFilePointer) and reading (ReadFile) is not the same with the handle of the loop device and the ISO file. So I had to manually change the dosdesices/X:: link to make it point from /dev/loop/X to /path/to/file.iso Moreover, even if it is understandable that IOCTL_SCSI_GET_ADDRESS fails, others like IOCTL_DVD_READ_STRUCTURE, should return valid values, not ERROR_NOT_SUPPORTED. I thought mounting the ISO should be the same thing than inserting the disc in the drive. But you seem to think that the current behaviour is the right one so in this case, simply ignore my patch.

Aug. 21, 2012