wine-devel October 2010

wine-devel@winehq.org

94 participants
301 discussions

Re: ddraw [patch 2/2 | RESEND]: SETFOCUSWINDOW lives independently of other flags
by testbot＠testbot.winehq.org 22 Oct '10

22 Oct '10

1 0

Re: ddraw [patch 2/2]: SETFOCUSWINDOW lives independently of other flags
by testbot＠testbot.winehq.org 21 Oct '10

21 Oct '10

1 0

Re: (resend) [PATCH] mscms: Handle bitmap formats BM_xRGBQUADS in from_bmformat( BMFORMAT format ) which is used by Translat
by testbot＠testbot.winehq.org 21 Oct '10

21 Oct '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6423 Your paranoid android. === W98SE (32 bit transform) === transform.c:127: Test failed: RGB: TranslateBitmapBits() succeeded (87) transform.c:137: Test failed: BGR: TranslateBitmapBits() succeeded (87) transform.c:142: Test failed: GRAY: TranslateBitmapBits() succeeded (87) transform.c:155: Test failed: xRGB/1: TranslateBitmapBits() succeeded (87) transform.c:167: Test failed: xRGB/2: TranslateBitmapBits() succeeded (87) === W2KPROSP4 (32 bit transform) === transform.c:127: Test failed: RGB: TranslateBitmapBits() succeeded (87) transform.c:137: Test failed: BGR: TranslateBitmapBits() succeeded (87) transform.c:142: Test failed: GRAY: TranslateBitmapBits() succeeded (87) transform.c:155: Test failed: xRGB/1: TranslateBitmapBits() succeeded (87) transform.c:167: Test failed: xRGB/2: TranslateBitmapBits() succeeded (87) === WXPPROSP3 (32 bit transform) === transform.c:127: Test failed: RGB: TranslateBitmapBits() succeeded (87) transform.c:137: Test failed: BGR: TranslateBitmapBits() succeeded (87) transform.c:142: Test failed: GRAY: TranslateBitmapBits() succeeded (87) transform.c:155: Test failed: xRGB/1: TranslateBitmapBits() succeeded (87) transform.c:167: Test failed: xRGB/2: TranslateBitmapBits() succeeded (87) === W2K3R2SESP2 (32 bit transform) === transform.c:127: Test failed: RGB: TranslateBitmapBits() succeeded (87) transform.c:137: Test failed: BGR: TranslateBitmapBits() succeeded (87) transform.c:142: Test failed: GRAY: TranslateBitmapBits() succeeded (87) transform.c:155: Test failed: xRGB/1: TranslateBitmapBits() succeeded (87) transform.c:167: Test failed: xRGB/2: TranslateBitmapBits() succeeded (87) === WVISTAADM (32 bit transform) === transform.c:127: Test failed: RGB: TranslateBitmapBits() succeeded (87) transform.c:137: Test failed: BGR: TranslateBitmapBits() succeeded (87) transform.c:142: Test failed: GRAY: TranslateBitmapBits() succeeded (87) transform.c:155: Test failed: xRGB/1: TranslateBitmapBits() succeeded (87) transform.c:167: Test failed: xRGB/2: TranslateBitmapBits() succeeded (87) === W2K8SE (32 bit transform) === transform.c:127: Test failed: RGB: TranslateBitmapBits() succeeded (87) transform.c:137: Test failed: BGR: TranslateBitmapBits() succeeded (87) transform.c:142: Test failed: GRAY: TranslateBitmapBits() succeeded (87) transform.c:155: Test failed: xRGB/1: TranslateBitmapBits() succeeded (87) transform.c:167: Test failed: xRGB/2: TranslateBitmapBits() succeeded (87) === W7PRO (32 bit transform) === transform.c:127: Test failed: RGB: TranslateBitmapBits() succeeded (87) transform.c:137: Test failed: BGR: TranslateBitmapBits() succeeded (87) transform.c:142: Test failed: GRAY: TranslateBitmapBits() succeeded (87) transform.c:155: Test failed: xRGB/1: TranslateBitmapBits() succeeded (87) transform.c:167: Test failed: xRGB/2: TranslateBitmapBits() succeeded (87) === W7PROX64 (32 bit transform) === transform.c:127: Test failed: RGB: TranslateBitmapBits() succeeded (87) transform.c:137: Test failed: BGR: TranslateBitmapBits() succeeded (87) transform.c:142: Test failed: GRAY: TranslateBitmapBits() succeeded (87) transform.c:155: Test failed: xRGB/1: TranslateBitmapBits() succeeded (87) transform.c:167: Test failed: xRGB/2: TranslateBitmapBits() succeeded (87) === W7PROX64 (64 bit transform) === transform.c:127: Test failed: RGB: TranslateBitmapBits() succeeded (87) transform.c:137: Test failed: BGR: TranslateBitmapBits() succeeded (87) transform.c:142: Test failed: GRAY: TranslateBitmapBits() succeeded (87) transform.c:155: Test failed: xRGB/1: TranslateBitmapBits() succeeded (87) transform.c:167: Test failed: xRGB/2: TranslateBitmapBits() succeeded (87)

1 0

Re: ddraw [patch 1/2]: Remove a useless else
by Henri Verbeet 21 Oct '10

21 Oct '10

On 21 October 2010 22:28, David Adam <david.adam.cnrs(a)gmail.com> wrote: > Trailing spaces.

1 0

Reflection interfaces
by Rico Schüller 21 Oct '10

21 Oct '10

Hi, I've a question concerning d3dcompiler, d3d10 and d3dx10 dlls in combination with the shader reflection interfaces. It seems there are 4 different known interfaces: IID_ID3D10ShaderReflection -> d3d10.dll (D3D10ReflectShader()) IID_ID3D10ShaderReflection1 -> d3dx10_xx.dll (D3DX10ReflectShader()) IID_ID3D11ShaderReflection_42 -> d3dcompiler_(40-42).dll (D3DReflect()) IID_ID3D11ShaderReflection -> d3dcompiler_(43).dll (D3DReflect()) The IID_ID3D11ShaderReflection_42 is just a new name for a IID_ID3D11ShaderReflection interface for version 40-42. In d3dcompiler 43 the interface changed and now has a new IID. What's the preferred way to implement the different interfaces? 1. Implement a parser which parses the shader (RDEF, STAT), and implement 4 independent interfaces (each in its own dll). Only reuse the parser. 2. Like 1, but all 4 implementations have there own parser, which leads to a lot of duplicated code. But it is the most flexible way. It could easily parse all possible shader blobs (theoretically they could differ from version to version, I have no test for that, yet). 3. Forward all interfaces to d3dcompiler_43.dll and this will contain all interfaces and the parser. This way the codebase is the smallest possible one, but it will offer all interfaces, which isn't what native does. Also all further interfaces would go to d3dcompiler_43.dll. This could get tricky. Attached is a test program and the output. The programm is compiled with "i686-pc-mingw32-gcc -I./wine/build/include -I./wine/git/include compilertest.c". The test for D3DReflectCode() doesn't work, so please ignore that part. Cheers Rico

2 2

Re: [PATCH] mscms: Handle bitmap formats BM_xRGBQUADS in from_bmformat( BMFORMAT format ) which is used by TranslateBitmapBits
by Hans Leidekker 21 Oct '10

21 Oct '10

On Wed, 2010-10-20 at 12:45 +0200, Tomasz Michno wrote: > C_SRCS = \ > - profile.c > + profile.c \ > + transform.c You are copying quite a bit a infrastructure from profile.c, so it would be better to add the tests to that file. We can always split them up later. > +#include "mscms_priv.h" This is not needed. > +void test_TranslateBitmapBits(void){ > + BOOL ret=TRUE; > + COLOR bitmapBits[bitmapSize]; > + COLOR bitmapBitsResult[bitmapSize]; > + #ifdef HAVE_LCMS You can't use that define in tests. > + HPROFILE hProfile; > ... > + transform = pCreateMultiProfileTransform(&hProfile, 2, &intent, 1, > + // test already handled BMFORMATs: This won't work, you say you have 2 profiles but pass only one. Don't use // for comments.

2 1

Re: ws2_32: Add support and tests for WSARecvMsg and IP_PKTINFO.
by Rolf Kalbermatter 21 Oct '10

21 Oct '10

On Tue, Oct 13, 2010 at 16:30 PM, Erich Hoover <ehoover(a)mines.edu> wrote: >> ... >> + int newsize = (int)*maxsize; >> + >> + /* Make sure there is at least enough room for this entry */ >> + newsize -= sizeof(WSACMSGHDR) + CMSG_ALIGN(len); >> + if (newsize < 0) >> + return 0; >> + *maxsize = (ULONG)newsize; >> Just declare it as a ULONG/size_t so you don't have to cast. > >I can obviously change this around a little bit, but the reason for this conversion is that as a >ULONG the "if (newsize < 0)" comparison is not going to work. Then following code would work better: ULONG newsize = sizeof(WSACMSGHDR) + CMSG_ALIGN(len); /* Make sure there is at least enough room for this entry */ if (newsize > *maxsize) return 0; /* else */ *maxsize -= newsize; Rolf Kalbermatter

3 5

current state of full screen on MacOS?
by Joerg-Cyril.Hoehle＠t-systems.com 21 Oct '10

21 Oct '10

Hi, I'd like to know whether a MacOSX user can expect full screen modes to work, as I've heard only rumors and too little facts. My experience is this: + winecfg's window opens fine even with desktop set uo full screen, no window. E.g. as in the initial setting after rm -rf ~/.wine; wine winecfg. + Likewise, other programs opening windows work fine (regedit, notepad etc.). - Programs that offer a "select screen resolution" requester present a list whose largest vertical/Y resolution is 22 pixel less than what the monitor offers. I believe OSX reserves some place for its menu bar. Lower resolution entries, e.g. 1024x768 and 800x600, are listed normally. They work in desktop window mode. - Programs that want to make use of full screen fail or hang somehow. The issue may be two-fold: a) full screen does not work at all, or b) switching to full screen resolutions less than my LCD's native resolution does not work, and applications do not cope with that. E.g. many want to display a low-resolution intro video. - Approx. two monthes ago, a hybrid desktop mode was implemented in Wine: eliminate the desktop window when it matches the full screen size; recreate it when switching back to lower resolutions. I've not observed that effect either, but the idea is brilliant. I've heard that OSX would not switch to lower resolutions like Linux machines do with e.g. xrandr -s 1 or -s 2 etc. My LCD monitor can stretch low resolution VGA signals, e.g. when plugged to a Linux netbook. However the "early 2009" nVidia Macs do not produce analog video signals anymore, and I'm using the DVI-D output. What's the current state of Wine (and Darwine) w.r.t. full screen mode? Is it just my digital DVI + LCD setting or is there an issue with Wine? I've built Wine-1.1.24 with OSX 10.5.7 and XQuartz 2.3.3.2. Thank you, Jörg Höhle.

3 2

Re: About: d3dx9: Store transform matrix per-sprite.
by Joris Huizer 20 Oct '10

20 Oct '10

--- On Tue, 10/19/10, Austin English <austinenglish(a)gmail.com> wrote: > While these emails are very helpful, can you please do a > reply to the > original thread? It makes it easier for those of us using > clients with > threaded mode to follow. > > Thanks! > > -- > -Austin > I can understand that's easier, less messy - I didn't do so up until now as it is quite a number of emails per day (especially if tracking both wine-devel and wine-patch) -- and my contributions/'contributions' are rare; Is there a way to do this other than registering to get the emails daily sent to me? I usually browse through the updates via the web (the mail archive and the patch watcher at http://source.winehq.org/patches/), and as far as I know there is no way of replying on either ? I think I will register to receive emails from the wine-devel and wine-patch mailing lists unless there's an other way to reply to thread. Best regards, Joris

2 1

Re: Translation of the AppDB
by James Mckenzie 20 Oct '10

20 Oct '10

Yaron Shahrabani <sh.yaron(a)gmail.com> wrote: > >On Wed, Oct 20, 2010 at 6:48 AM, James McKenzie ><jjmckenzie51(a)earthlink.net>wrote: > [snip] >So you mean you have got to get some input and there's no other way of >getting input from the users without typing... >Do you feel like you get enough feedback or that automating parts of the >reporting system would make it more widely used. >I'm maintaining lots of translations in the open source world, I never feel >like I get enough feedback and I truly think that if the input was at the >user's fingertips it would help a lot, just my way of looking at it... > Correct. There is quite a wide variation of what can and cannot work that having a bunch of selections would be tedious at best, confusing at worst. >> >> There are many 'drop down' menus that it would be nice to input Hebrew and >> have English populate them. Would this be a good idea? >> >The drop down boxes would be great, the simplest way of interaction is what >needed, no ways of typing Hebrew... > Again, the existing drop downs could be translated into Hebrew and then used to select the English equivilent. However, the text boxes will have to remain due to wide variations in 'What works' and 'What does not work'. Too many selections can be confusing and makes the web site appear to be slow (I work with a web application that has 35,000+ selections, it takes about two minutes for the menu to load on a high speed connection and not all Wine users have that luxury.) >(I was thinking of a small Javascript code that will check for foreign >scripts and if the script is different than the Latin script, a Red message >will appear on top of the box and after clicking the button a message will >pop up saying that this message contains non-universal characters and ask >the user if he is sure about sending this report). > I would just block it. Again, English, for now, is the world's universal language. If someone does not know English, there are sites like Babblefish that cover just about all languages, including (but not limited to) Hebrew, Farsi, Persian, Arabic, Simplified and Traditional Chinese. Users can avail themselves of them and copy/paste into the boxes. I can understand quite a bit of 'translated' English. James McKenzie

2 1

← Newer
1
...
8
9
10
11
12
13
14
...
31
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel October 2010