On 05/09/2013 12:36 PM, Alexandre Julliard wrote:
It's okay only because you are not actually calling it ;-)
Yeah, I don't call it until patch 2 in the series. This patch just
introduces it without calling it, which does cause a warning. (I hope
this doesn't violate the atomic patches rule.)
On 05/10/2013 09:11 AM, Alexandre Julliard wrote:
Sam Edwards cfswo...@gmail.com writes:
Yeah, I don't call it until patch 2 in the series. This patch just
introduces it without calling it, which does cause a warning. (I hope
this doesn't violate the atomic patches rule.)
It does, you can't
On 05/10/2013 10:51 AM, Ruslan Kabatsayev wrote:
Hi,
Won't such code fail if the mode is changed outside wine?
Regards,
Ruslan
Unfortunately it will, but the only way to fix that is to listen for an
XRandR event indicating that the mode has changed.
The screen_width/screen_height values
On 05/06/2013 03:05 PM, Max TenEyck Woodbury wrote:
Just to make this clear, the most recent version of this patch is such
a graceful handling, right?
I haven't worked on gdi32/freetype.c much, so I wouldn't be the one to
say for sure (you should probably talk to Alexandre Julliard, Dmitry
On 05/04/2013 10:38 PM, Max TenEyck Woodbury wrote:
$ grep ' has tmHeight=0, aveWidth=' 201305055-make-test-native.log
err:font:get_text_metrics Font named 'Emmentaler-Brace' has
tmHeight=0, aveWidth=3!
err:font:get_text_metrics Font named 'Emmentaler-Brace' has
tmHeight=0, aveWidth=3!
On 05/04/2013 12:59 PM, Max TenEyck Woodbury wrote:
You are trying to make this about me. It is not. Windows fairly
obviously does not do this 'sanity' test. Wine is supposed to imitate
windows. To do this absolutely correctly, the whole 'sanity' test
should go away.
This sounds like an
On 05/04/2013 05:13 PM, Max TenEyck Woodbury wrote:
Having wine throw an exception where it did not do so before is another
kind of problem indicator. One that hardly needs a special conformance
test.
Hmm. As I suspected, that is a single point pass only test. It does
not explore any of
unnecessary because tmHeight will always be
nonzero anyway.
From f5dc537a3799b9c4507cb0c8aefcc4ee73d2a0b5 Mon Sep 17 00:00:00 2001
From: Sam Edwards cfswo...@gmail.com
Date: Sat, 4 May 2013 21:58:19 -0600
Subject: gdi32: [HACK] Print which font is causing division-by-zero problems.
---
dlls/gdi32
On 04/30/2013 11:05 AM, Alexandre Julliard wrote:
It still crashes:
Hmm... Guess I didn't fully understand the underlying problem.
Fortunately, after enabling subpixel rendering on my system, the same
crash now happens for me, so I can figure out exactly what's breaking.
I'll try to get
On 05/01/2013 05:21 AM, Christopher Cope wrote:
I am unsure how the enum x11drv_atoms in the file
dlls/winex11.dev/x11drv.h works. My /usr/include/Xatom.h defines
XA_LAST_PREDEFINED as 68. Presumably, therefore XATOM_Rel_X and
XATOM_Rel_X should be 81 and 82 respectively. However, when I dump
On 05/01/2013 05:38 AM, Christopher Cope wrote:
On 05/01/2013 07:21 AM, Christopher Cope wrote:
I am unsure how the enum x11drv_atoms in the file
dlls/winex11.dev/x11drv.h works. My /usr/include/Xatom.h defines
XA_LAST_PREDEFINED as 68. Presumably, therefore XATOM_Rel_X and
XATOM_Rel_X
On 04/29/2013 08:20 AM, Alexandre Julliard wrote:
Well, there was no backtrace since winedbg crashes. Fortunately gdb
works:
Big thanks! I found the problem (it only happened with subpixel
rendering, which I don't have enabled) and am resending the patches now. :)
On 04/26/2013 08:17 AM, Michael Stefaniuc wrote:
Sam, look at the size of the address. It is the 64bit build that crashes.
bye
michael
Michael: Thanks for the advice; I noticed that too and have been running
both 64-bit and 32-bit tests. (Although, it's perplexing to me that a
change
On 04/25/2013 12:28 PM, Alexandre Julliard wrote:
It doesn't work here:
../../../../wine/tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p
comctl32_test.exe.so ../../../../wine/dlls/comctl32/tests/listview.c touch
listview.ok
wine: Unhandled page fault on write access to 0x400053b34
This series has been waiting in the queue for a few days now. Does this
need further discussion, or can it be committed?
Thanks,
Sam
On 04/20/2013 08:08 AM, Sam Edwards wrote:
On 04/22/2013 07:08 PM, Ken Thomases wrote:
I can't speak to how Windows would render it, but one such font is
Zapfino. It's an exuberant calligraphic font with lots of
flourishes, some of which have strokes extending into the line above
or below. http://en.wikipedia.org/wiki/Zapfino
On 04/23/2013 02:04 AM, Ken Thomases wrote:
Hmm. I assumed that ascent+descent+leading equals the distance between
baselines. In a Mac-native text editor, the strokes of one line of
Zapfino can extend into the lines above or below, which is why I
figured they exceeded the ascent and descent
On 04/19/2013 10:32 AM, Max TenEyck Woodbury wrote:
As I understand it, some fonts deliberately have glyphs larger than
their metrics bounding boxes. Clipping them is almost certainly not a
good idea.
Forgive my disbelief, but can you provide an example? It seems like
Windows has the same
On 04/01/2013 08:16 AM, Henri Verbeet wrote:
I think it's ok for the tests to be todo_wine, but we do want ddraw
coverage for this in the tests.
Fine by me. But that will take a few days since I'll have to familiarize
myself with ddraw first. :)
In the meantime, should I resend this patchset
On 03/29/2013 06:16 AM, Henri Verbeet wrote:
I think the idea is basically ok, but I do have some comments:
I think test_window_style() is a more appropriate place for the tests,
and you should add them to the variants in ddraw as well. Ddraw
applications in particular are very fragile in this
On Nov 6, 2012, at 3:45, Henri Verbeet hverb...@gmail.com wrote:
Yeah, we'll want a similar test for d3d8.
Okay, I'll write that as soon as the d3d9 test is accepted.
You're probably looking for AdjustWindowRect() and SetWindowPos().
Thank you, I didn't know about AdjustWindowRect(), but
21 matches
Mail list logo
