Re: [PATCH] This patch fixes context menu crashes for edit controlsas apparent in vb apps.
"Michael Martin" wrote: The following patch fixes 18130. In my tests, context menu for the Edit window control does not send the WM_COMMAND message. Please comment. And what is the reason of the crash? Please add a test case replicating the problem first, only then start fixing it. -- Dmitry.
Re: d3d9: Add DF16 support
2009/6/7 Frank Richter : > On 07.06.2009 22:22, Henri Verbeet wrote: >> Even if the format isn't lockable, you can still use the data with a >> shader. > > If it's a typical depth format the shader will see normalized values. > Yes, but floating point formats aren't "typical". > Information on DF16 seems to be sparse, one thing I found was: > http://discussms.hosting.lsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0611A&L=DIRECTXDEV&P=R2492&I=-3&d=No+Match%3BMatch%3BMatches > It says that DF16 returns "real" depth values - which would indeed be > normalized. > Ok, I guess the format could just be named badly, although Chris makes a good point about precision, even if the values are normalized. > Some ATI graphics demos (e.g. Toy Shop). > If those demos have source, it might be useful to look at that for hints. At the very least this needs tests to determine if the values are normalized or not.
Re: d3d9: Add DF16 support
Am 07.06.2009 um 10:35 schrieb Henri Verbeet: 2009/6/7 Frank Richter : As far as I could gather DF16 is the "ATI way" of getting a renderable 16 bit depth texture. Without knowing much about the actual format, DF16 implies this should be a floating point format, similar to the ones provided by ARB_depth_buffer_float. Also, could you please add this at the same location as the other depth formats? I don't think it is a float format, in spite of the name. I don't understand what it exactly is, but it seems that ATI Windows drivers cannot use regular D3DFMT_D16 or D24S8 as texture. That means that if an app wants a depth texture it has to StretchRect from the depth stencil to a D3DFMT_Lx texture. I think when D16 is used in a shader it is supposed to behave like GL_ARB_shadow. Sometimes this is not flexible enough, and hearsay says it does not work on ATI cards. My understanding is that the different formats work somewhat like this: D3DFMT_D16 / D24X8, D24S8(all? nv only?): GL_ARB_shadow / shadow2D() in GLSL DF16, DF24(ati): Like sampling DEPTH_COMPONENT24 formats with regular texture2D INTZ(nv): denormalized texture2D() RAWZ(nv): Comparable to INTZ, but needs some extra calculations. I guess we'll not implement this, only INTZ. If this is correct, Franks patch is content wise correct. I think we'll need tests to see if my understanding of the formats is correct.
Re: d3d9: ATI1N support
Nice that you found a way to support this format :-)
Can you separate the compressed data loading changes from the ATI1N
specific changes? I will make regression testing easier if anything
should break.
Do you have an app that needs this format? I think a test would be a
good idea.
Am 07.06.2009 um 09:48 schrieb Frank Richter:
---
dlls/wined3d/device.c |5 +-
dlls/wined3d/directx.c |8 +++
dlls/wined3d/surface.c | 110
---
dlls/wined3d/surface_base.c |6 +-
dlls/wined3d/utils.c|6 ++
include/wine/wined3d.idl|1 +
6 files changed, 82 insertions(+), 54 deletions(-)
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
index f1dd938..a08f713 100644
--- a/dlls/wined3d/device.c
+++ b/dlls/wined3d/device.c
@@ -920,10 +920,9 @@ static HRESULT WINAPI
IWineD3DDeviceImpl_CreateSurface(IWineD3DDevice *iface,
mul_4h = (Height + 3) & ~3;
if (WINED3DFMT_UNKNOWN == Format) {
Size = 0;
-} else if (Format == WINED3DFMT_DXT1) {
-/* DXT1 is half byte per pixel */
+} else if (Format == WINED3DFMT_DXT1 || Format ==
WINED3DFMT_ATI1N) {
+/* DXT1, ATI1N are half byte per pixel */
Size = (mul_4w * glDesc->byte_count * mul_4h) >> 1;
-
} else if (Format == WINED3DFMT_DXT2 || Format ==
WINED3DFMT_DXT3 ||
Format == WINED3DFMT_DXT4 || Format ==
WINED3DFMT_DXT5 ||
Format == WINED3DFMT_ATI2N) {
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index 4a2a270..60045aa 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -2467,6 +2467,14 @@ static BOOL CheckTextureCapability(struct
WineD3DAdapter *adapter,
return FALSE;
/* Vendor specific formats */
+case WINED3DFMT_ATI1N:
+if(GL_SUPPORT(EXT_TEXTURE_COMPRESSION_RGTC)) {
+TRACE_(d3d_caps)("[OK]\n");
+return TRUE;
+}
+TRACE_(d3d_caps)("[FAILED]\n");
+return FALSE;
+
case WINED3DFMT_ATI2N:
if(GL_SUPPORT(ATI_TEXTURE_COMPRESSION_3DC) ||
GL_SUPPORT(EXT_TEXTURE_COMPRESSION_RGTC)) {
shader_backend = select_shader_backend(adapter,
DeviceType);
diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
index 2f5554f..6469fa4 100644
--- a/dlls/wined3d/surface.c
+++ b/dlls/wined3d/surface.c
@@ -132,6 +132,25 @@ static BOOL
primary_render_target_is_p8(IWineD3DDeviceImpl *device)
return FALSE;
}
+/* Download data for a compressed surface */
+static void surface_download_data_compressed(IWineD3DSurfaceImpl
*This, const struct GlPixelFormatDesc *format_desc) {
+TRACE("(%p) : Calling glGetCompressedTexImageARB level %d,
format %#x, type %#x, data %p\n",
+ This, This->glDescription.level, format_desc->glFormat,
format_desc->glType,
+ This->resource.allocatedMemory);
+
+if(This->Flags & SFLAG_PBO) {
+ GL_EXTCALL(glBindBufferARB(GL_PIXEL_PACK_BUFFER_ARB, This->pbo));
+ checkGLcall("glBindBufferARB");
+ GL_EXTCALL(glGetCompressedTexImageARB(This->glDescription.target,
This->glDescription.level, NULL));
+ checkGLcall("glGetCompressedTexImageARB()");
+ GL_EXTCALL(glBindBufferARB(GL_PIXEL_PACK_BUFFER_ARB, 0));
+ checkGLcall("glBindBufferARB");
+} else {
+ GL_EXTCALL(glGetCompressedTexImageARB(This->glDescription.target,
This->glDescription.level, This->resource.allocatedMemory));
+ checkGLcall("glGetCompressedTexImageARB()");
+}
+}
+
/* This call just downloads data, the caller is responsible for
activating the
* right context and binding the correct texture. */
static void surface_download_data(IWineD3DSurfaceImpl *This) {
@@ -145,31 +164,19 @@ static void
surface_download_data(IWineD3DSurfaceImpl *This) {
}
ENTER_GL();
-
-if (format_desc->format == WINED3DFMT_DXT1 || format_desc-
>format == WINED3DFMT_DXT2
-|| format_desc->format == WINED3DFMT_DXT3 ||
format_desc->format == WINED3DFMT_DXT4
-|| format_desc->format == WINED3DFMT_DXT5 ||
format_desc->format == WINED3DFMT_ATI2N)
-{
+
+if (format_desc->format == WINED3DFMT_DXT1 || format_desc-
>format == WINED3DFMT_DXT2
+ || format_desc->format == WINED3DFMT_DXT3 || format_desc-
>format == WINED3DFMT_DXT4
+ || format_desc->format == WINED3DFMT_DXT5) {
if (!GL_SUPPORT(EXT_TEXTURE_COMPRESSION_S3TC)) { /* We can
assume this as the texture would not have been created otherwise */
FIXME("(%p) : Attempting to lock a compressed texture
when texture compression isn't supported by opengl\n", This);
} else {
-TRACE("(%p) : Calling glGetCompressedTexImageARB level
%d, format %#x, type %#x, data %p\n",
-This, This->glDescription.level, format_desc-
>glFormat, format_desc->glType,
-This->resource.allocatedMemory);
-
-if(This->Flags & SFLAG_PBO) {
-
Re: gdiplus: Add support for horizontal string alignment to GdipDrawString
On Sun, Jun 7, 2009 at 8:27 PM, Stephan Rose wrote: > Well it'd have to be top left and top right. Given those two, top center > will be determined by DrawText on it's own when given DT_CENTER > alignment. > > Ok I think that I'm really going to have to do is make a rotated test > app to see what happens. Only 'issue' here is that I am not even > remotely setup here at home for writing / compiling any kind of native > windows software. While I have a windows installation, use it like maybe > once every couple weeks for some occasional gaming. > > Is there any easy way for me to do this under linux? MingW I suppose? Mingw should work. I've found sometimes that the mingw headers and libraries have been inadequate, and I've had to compile with the switches used by "make crosstest". I think they'll be good enough in this case. Technically, you could also run the test case using native gdiplus in Wine. In that case you could use winegcc. But I think you'll want to set up mingw anyway so you can compile Wine tests for Windows. Vincent Povirk
Re: gdiplus: Add support for horizontal string alignment to GdipDrawString
On Sun, 2009-06-07 at 19:53 -0500, Vincent Povirk wrote: > This looks wrong to me. You're only adjusting the left coordinate, but > in case of a rotation in the world transform, you'll need to adjust > the top as well. > > Also, I think you may still be able to use DT_CENTER and DT_RIGHT > rather than measuring the string beforehand. Creating a rectangle > something like the original is difficult, but DrawText probably only > needs to know the top-center or top-right point to do these other > alignments. So it should be able to align things properly if you give > it a rectangle where all corners are the point where it anchors the > text. Well it'd have to be top left and top right. Given those two, top center will be determined by DrawText on it's own when given DT_CENTER alignment. Ok I think that I'm really going to have to do is make a rotated test app to see what happens. Only 'issue' here is that I am not even remotely setup here at home for writing / compiling any kind of native windows software. While I have a windows installation, use it like maybe once every couple weeks for some occasional gaming. Is there any easy way for me to do this under linux? MingW I suppose? Thanks, Stephan
Re: gdiplus: Add support for horizontal string alignment to GdipDrawString
This looks wrong to me. You're only adjusting the left coordinate, but in case of a rotation in the world transform, you'll need to adjust the top as well. Also, I think you may still be able to use DT_CENTER and DT_RIGHT rather than measuring the string beforehand. Creating a rectangle something like the original is difficult, but DrawText probably only needs to know the top-center or top-right point to do these other alignments. So it should be able to align things properly if you give it a rectangle where all corners are the point where it anchors the text. DrawText doesn't need the original rectangle because gdiplus does the clipping and wrapping (and it already doesn't get the original rectangle anyway). Vincent Povirk On Sat, Jun 6, 2009 at 2:19 PM, Stephan Rose wrote: > Adds support for horizontal string alignment to GdipDrawString without > using DT_CENTER or DT_RIGHT. > > > >
New winetricks 20090607: new verbs d3dx9, fontsmooth-foo, vb2run, vcrun2008sp1, wme9, xact
Another, er, quarter, another winetricks. Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com Thanks to Austin English for taking on most of the work keeping winetricks up to date! (And apologies for my own slowness in doing another release.) Changes since 20090116: r491 | daniel.r.kegel | 2009-06-07 17:36:52 -0700 (Sun, 07 Jun 2009) | 2 lines Bump version, mention that Dan still maintains too. r489 | daniel.r.kegel | 2009-06-07 17:14:08 -0700 (Sun, 07 Jun 2009) | 4 lines Avoid using gnu tar extensions in liberation verb. Simplifies opensolaris support. r479 | austinenglish | 2009-05-31 20:11:06 -0700 (Sun, 31 May 2009) | 2 lines winetricks: Dan doesn't like subshells. I agree, they're messy. Get rid of one for liberation. r478 | austinenglish | 2009-05-31 20:08:27 -0700 (Sun, 31 May 2009) | 2 lines winetricks: clarify volnum workaround for vcrun2008 r477 | austinenglish | 2009-05-31 19:52:50 -0700 (Sun, 31 May 2009) | 2 lines winetricks: make sure we 'try' for all cp's, fix case-sensitive ones with wildcards r476 | austinenglish | 2009-05-31 19:08:30 -0700 (Sun, 31 May 2009) | 2 lines winetricks: only output Opensolaris info if running on OpenSolaris r475 | austinenglish | 2009-05-31 18:56:46 -0700 (Sun, 31 May 2009) | 2 lines winetricks: fix version function to only print the version r474 | daniel.r.kegel | 2009-05-31 17:38:50 -0700 (Sun, 31 May 2009) | 2 lines Be slightly more descriptive in fontsmooth verbs. r473 | austinenglish | 2009-05-31 12:55:44 -0700 (Sun, 31 May 2009) | 2 lines winetricks: work around kde bug r472 | austinenglish | 2009-05-30 19:03:23 -0700 (Sat, 30 May 2009) | 2 lines winetricks: minor ie6 fixes r471 | austinenglish | 2009-05-30 12:07:52 -0700 (Sat, 30 May 2009) | 2 lines winetricks: fix vcrun2008sp1 for old wine versions (1.0.1) r470 | austinenglish | 2009-05-30 08:48:48 -0700 (Sat, 30 May 2009) | 2 lines winetricks: make sure to run gunzip in a separate shell r467 | austinenglish | 2009-05-28 17:01:27 -0700 (Thu, 28 May 2009) | 2 lines winetricks: add a note about fixing local keystores for OpenSolaris r466 | austinenglish | 2009-05-28 16:50:17 -0700 (Thu, 28 May 2009) | 2 lines winetricks: fix busted urls and make a new release r465 | austinenglish | 2009-05-28 16:49:11 -0700 (Thu, 28 May 2009) | 2 lines winetricks: fix typo in last patch (liberation opensolaris fix) r464 | austinenglish | 2009-05-28 16:35:22 -0700 (Thu, 28 May 2009) | 2 lines winetricks: fix liberation verb for systems without tar (Patch by Matt Lewandowsky) r462 | austinenglish | 2009-05-27 21:29:30 -0700 (Wed, 27 May 2009) | 2 lines winetricks: disable services for wmp9/wmp10 r461 | austinenglish | 2009-05-27 21:09:51 -0700 (Wed, 27 May 2009) | 2 lines winetricks: fix ie6 install r460 | austinenglish | 2009-05-27 00:38:10 -0700 (Wed, 27 May 2009) | 2 lines winetricks: fix ie6 verb for non-english locales r439 | austinenglish | 2009-04-20 20:26:21 -0700 (Mon, 20 Apr 2009) | 2 lines winetricks: add gecko-dbg verb r438 | austinenglish | 2009-04-19 18:49:30 -0700 (Sun, 19 Apr 2009) | 2 lines winetricks: add version function r430 | austinenglish | 2009-04-06 23:40:27 -0700 (Mon, 06 Apr 2009) | 2 lines winetricks: fix download for fontfix verb r422 | austinenglish | 2009-03-30 17:
Re: d3d9: Add DF16 support
2009. 06. 7, vasárnap keltezéssel 23.05-kor Frank Richter ezt írta: > On 07.06.2009 22:22, Henri Verbeet wrote: > > Even if the format isn't lockable, you can still use the data with a > > shader. > > If it's a typical depth format the shader will see normalized values. > > Information on DF16 seems to be sparse, one thing I found was: > http://discussms.hosting.lsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0611A&L=DIRECTXDEV&P=R2492&I=-3&d=No+Match%3BMatch%3BMatches > It says that DF16 returns "real" depth values - which would indeed be > normalized. > > > Typically float formats aren't normalized, so you can have > > values outside the traditional [0.0,1.0] range. > > If there's no specific > > extension for this format you could use GL_DEPTH_COMPONENT32F as > > internal format and GL_HALF_FLOAT_ARB as type, although that would > > waste some memory, of course. > > On what graphics cards is that extension supported? > DF16 is supported since the R300. It appears that float depth formats > are much younger, so it seems unlikely DF16 is actually a float format > internally. > Does D3D(9) allow a depth range outside [0.0,1.0] anyway? > > > Is there any specific application that > > needs this format? > GTA4 for example. (it checks only DF16, DF24, INTZ, RAWZ formats, and because there is no support, it exits with an error message.) > Some ATI graphics demos (e.g. Toy Shop). > Probably at least some games that use shadow mapping. > > -f.r. >
Re: wined3d:
Pavel Prochazka wrote: There is an open bug for this problem, 14746. Can you clean up and attach your fix to this bug so that others can try it? I did apply it cleanly, through three steps to version 1.1.22 of Wine. James McKenzie
Re: [Bugzilla]: Refuse to accept comments with big number of logs / back traces
Austin English wrote: > On Sun, Jun 7, 2009 at 12:25 PM, Vitaliy > Margolen wrote: >> The limits are: >> 20 lines for logs (fixme, trace, err, warn) >> 10 lines for back traces >> --- >> Bugzilla/Bug.pm |7 +++ >> template/en/default/global/user-error.html.tmpl |4 >> 2 files changed, 11 insertions(+), 0 deletions(-) > > While I'm hugely in favor of this, AFAICT, this blocks everyone from > doing so, correct? > > What about developers that know what they're doing, or Anastasius? > Developers are not any different then everyone else. Big long posts make any bug hard to read, regardless who made this post. If developers need to paste huge amounts of logs, they should think twice if they really need it or not. 20 lines ought to be enough to get the point across. If that's not enough, one could make two posts. Or add +tid to the mix (as Anastasius does all the time) Vitaliy.
Re: d3d9: Add DF16 support
On Sunday 07 June 2009 2:05:41 pm Frank Richter wrote: > On what graphics cards is that extension supported? > DF16 is supported since the R300. It appears that float depth formats > are much younger, so it seems unlikely DF16 is actually a float format > internally. Just to note, there is a much earlier depth-float format in GL, before the ARB or NV versions came out: http://www.opengl.org/registry/specs/EXT/wgl_depth_float.txt It seems its main purpose is increased precision over the non-linear range of the buffer values. Unfortunately, Wine doesn't implement this extension, as there is no GLX equivalent.
Re: d3d9: Add DF16 support
On 07.06.2009 22:22, Henri Verbeet wrote: > Even if the format isn't lockable, you can still use the data with a > shader. If it's a typical depth format the shader will see normalized values. Information on DF16 seems to be sparse, one thing I found was: http://discussms.hosting.lsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0611A&L=DIRECTXDEV&P=R2492&I=-3&d=No+Match%3BMatch%3BMatches It says that DF16 returns "real" depth values - which would indeed be normalized. > Typically float formats aren't normalized, so you can have > values outside the traditional [0.0,1.0] range. > If there's no specific > extension for this format you could use GL_DEPTH_COMPONENT32F as > internal format and GL_HALF_FLOAT_ARB as type, although that would > waste some memory, of course. On what graphics cards is that extension supported? DF16 is supported since the R300. It appears that float depth formats are much younger, so it seems unlikely DF16 is actually a float format internally. Does D3D(9) allow a depth range outside [0.0,1.0] anyway? > Is there any specific application that > needs this format? Some ATI graphics demos (e.g. Toy Shop). Probably at least some games that use shadow mapping. -f.r. signature.asc Description: OpenPGP digital signature
Re: d3d9: Add DF16 support
2009/6/7 Frank Richter : > On 07.06.2009 19:35, Henri Verbeet wrote: >> 2009/6/7 Frank Richter : >>> As far as I could gather DF16 is the "ATI way" of getting a renderable >>> 16 bit depth texture. >> Without knowing much about the actual format, DF16 implies this should >> be a floating point format, similar to the ones provided by >> ARB_depth_buffer_float. > > Maybe... but it seems that format is solely intended for use on render > target textures, not any download or upload... so not sure if the data > type would matter in practice. Also, I didn't find a 16-bit float depth > texture format for OpenGL so far. > Even if the format isn't lockable, you can still use the data with a shader. Typically float formats aren't normalized, so you can have values outside the traditional [0.0,1.0] range. If there's no specific extension for this format you could use GL_DEPTH_COMPONENT32F as internal format and GL_HALF_FLOAT_ARB as type, although that would waste some memory, of course. Is there any specific application that needs this format?
Re: d3d9: Add DF16 support
On 07.06.2009 19:35, Henri Verbeet wrote: > 2009/6/7 Frank Richter : >> As far as I could gather DF16 is the "ATI way" of getting a renderable >> 16 bit depth texture. > Without knowing much about the actual format, DF16 implies this should > be a floating point format, similar to the ones provided by > ARB_depth_buffer_float. Maybe... but it seems that format is solely intended for use on render target textures, not any download or upload... so not sure if the data type would matter in practice. Also, I didn't find a 16-bit float depth texture format for OpenGL so far. > Also, could you please add this at the same > location as the other depth formats? Well I added it to the vendor-specific formats because it _is_ ATI-specific... -f.r.
Re: [Bugzilla]: Refuse to accept comments with big number of logs / back traces
On Sun, Jun 7, 2009 at 12:25 PM, Vitaliy Margolen wrote: > > The limits are: > 20 lines for logs (fixme, trace, err, warn) > 10 lines for back traces > --- > Bugzilla/Bug.pm | 7 +++ > template/en/default/global/user-error.html.tmpl | 4 > 2 files changed, 11 insertions(+), 0 deletions(-) While I'm hugely in favor of this, AFAICT, this blocks everyone from doing so, correct? What about developers that know what they're doing, or Anastasius? -- -Austin
Re: d3d9: Add DF16 support
2009/6/7 Frank Richter : > As far as I could gather DF16 is the "ATI way" of getting a renderable > 16 bit depth texture. Without knowing much about the actual format, DF16 implies this should be a floating point format, similar to the ones provided by ARB_depth_buffer_float. Also, could you please add this at the same location as the other depth formats?
Re: d3d9: ATI1N support
2009/6/7 Frank Richter :
> +/* Download data for a compressed surface */
> +static void surface_download_data_compressed(IWineD3DSurfaceImpl *This,
> const struct GlPixelFormatDesc *format_desc) {
> +TRACE("(%p) : Calling glGetCompressedTexImageARB level %d, format %#x,
> type %#x, data %p\n",
> + This, This->glDescription.level, format_desc->glFormat,
> format_desc->glType,
> + This->resource.allocatedMemory);
> +
> +if(This->Flags & SFLAG_PBO) {
> + GL_EXTCALL(glBindBufferARB(GL_PIXEL_PACK_BUFFER_ARB, This->pbo));
> + checkGLcall("glBindBufferARB");
> + GL_EXTCALL(glGetCompressedTexImageARB(This->glDescription.target,
> This->glDescription.level, NULL));
> + checkGLcall("glGetCompressedTexImageARB()");
> + GL_EXTCALL(glBindBufferARB(GL_PIXEL_PACK_BUFFER_ARB, 0));
> + checkGLcall("glBindBufferARB");
> +} else {
> + GL_EXTCALL(glGetCompressedTexImageARB(This->glDescription.target,
> This->glDescription.level, This->resource.allocatedMemory));
> + checkGLcall("glGetCompressedTexImageARB()");
> +}
> +}
Please don't add tabs. I also think wined3d would be more appropriate
as module name for these patches.
Re: Test box tagged [dr-asus]
> 2009/6/7 Francois Gouget : > >> Winetest should have an email field (optional) to make contacting the >> tester easier. That and also a description field (bug 13027) so one can >> give a proper description of the setup the tests are running on (e.g. >> locale, running in vmware or not, etc). > I'd agree but only to the extent of things which can't be reliably automatically detected. A google search listed a way to detect virtual pc and vmware [1]. Another search gave the impression that locale could be determined from using GetUserDefaultLangID or GetUserDefaultUILanguage. Best, --John [1] http://www.codegurus.be/codegurus/Programming/virtualpc&vmware_en.htm
Re: cd-roms that need unhide
On Sat, Jun 6, 2009 at 10:10 PM, Jeremy White wrote: >> What say? Would this help users more than it would hurt? > > Dan, can you just quick check the file system type? If it's > UDF, then it's a known issue. I think it's iso9660, but you can check yourself, I uploaded it to http://kegel.com/wine/dknydelicious.iso It's 281MB. (And I think it's two years old, not fresh, but it's one of those free discs they insert in magazines.) - Dan
Re: Test box tagged [dr-asus]
2009/6/7 Francois Gouget : > Winetest should have an email field (optional) to make contacting the > tester easier. That and also a description field (bug 13027) so one can > give a proper description of the setup the tests are running on (e.g. > locale, running in vmware or not, etc). +1 I'd expect most people running the tests would be happy to give more detail as needed, as that would help Wine run better on their stuff! - d.
Re: Test box tagged [dr-asus]
On Sat, 6 Jun 2009, Nikolay Sivov wrote: > Hi. > > Does anyone no whose box is it (dr-asus)? It has some (actually always 10) > test failures for ListView and > I think it's possible to find a cause. Same failures on 2k and XP actually. > > I'd like to contact owner for testing some patches. Winetest should have an email field (optional) to make contacting the tester easier. That and also a description field (bug 13027) so one can give a proper description of the setup the tests are running on (e.g. locale, running in vmware or not, etc). -- Francois Gouget http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.
Re: [PATCH] This patch fixes context menu crashes for edit controls as apparent in vb apps.
2009/6/7 Michael Martin :
You'll need to include the patch as an attachment (renamed as a text
file if your mail client messes up the encoding), instead of including
it in the body text (the indentation in the patch you included has
been removed by your mail client).
> + BOOL selectedMenuItem;
> ...
> + selectedMenuItem = TrackPopupMenu(popup, TPM_LEFTALIGN | TPM_RIGHTBUTTON |
> TMPRETURNCMD, x, y, 0, es->hwndSelf, NULL);
> + switch (selectedMenuItem) {
Despite TrackPopupMenu having a BOOL return type, using an int would
make it more readable (selectedMenuItem is not being used as a boolean
value, but as a command index). Alternatively, just use:
switch (TrackPopupMenu(...)) {
TMPRETURNCMD -- This should be TMP_RETURNCMD. Is this an error when
adding the patch to the email?
Thanks for contributing to Wine,
- Reece
Re: Wine translation statistics sources
If you send me the necessary information I can probably take care of it. I've uploaded the lastest version to http://www.mikolaj.zalewski.pl/dl/wine-transl.tgz . There is a README there, but basically one needs to start with copying scripts/config-example to scripts/config and setting the paths. There should be a path to a Wine tree, a path to a temporary work directory and a path to the directory with the final data (all of these must be writeable by the scripts). With this set, one should do 'cd scripts && ./Master.sh'. This should create langs/ and dumps/ directories, first in the work directory and then move them to the final data directory (it's good for the temporary and final directory to be on the same filesystem for the move to appear to be atomic). It will also synchronize the conf directory in scripts/ with the one in the permanent data directory. With these files persent, the php/config.php should be edited to point to the final data directory. With this set, the PHP should show the translation state. I'm showing separate statistics for 1.1.x and 1.0.x by having the same code in two different places. The config.php contains some options that allow to use the same codebase for this (with changes only in config). Mikołaj
Re: Wine translation statistics sources
Mikołaj Zalewski writes: > It's online again. Having it on WineHQ would probably give a better > uptime (and a much better latency, but this should also improve on my > side, when I won't need a temporary SSH tunnel anymore and will move > the HTTP server from my good old Pentium 100MHz to a new Atom > machine). I've been in contact with Jeremy Newman about it some time > ago, but, after a few exchanges, my e-mails got unanswered, so I > assumed he is too busy to help with it (and, alone, I don't know how > to do it). If you send me the necessary information I can probably take care of it. -- Alexandre Julliard julli...@winehq.org
