March 2009 - Wine-devel - list.winehq.org

Re: comctl32: correct handling of toolbar separators' size
by Rob Shearman 18 Mar '09

18 Mar '09

2009/3/17 Igor Tarasov <tarasov.igor(a)gmail.com>: > Currently, wine uses iBitmap property for determining toolbar > separators width all the time, stating it's an undocumented feature. > This is not correct. > > According to MSDN, iBitmap is used only on inserting separator (since > there is no cx field in TBBUTTON structure). > http://msdn.microsoft.com/en-us/library/bb760476(VS.85).aspx > > In other cases, cx property that can be updated via get/set buttoninfo > is used, as tests show. Also, tests show that this property differs > from zero only if application specifically sets. Setting it to 0 makes > separator display in default width. All this is implemented in this > patch. More tests results in bugtracker (link below). Please ensure that there are no regressions in the display of IE6's toolbars after this patch. This is the main user of undocumented toolbar features. > @@ -4428,7 +4431,7 @@ TOOLBAR_SetButtonInfoA (HWND hwnd, WPARAM wParam, LPARAM lParam) > if (lptbbi->dwMask & TBIF_LPARAM) > btnPtr->dwData = lptbbi->lParam; > if (lptbbi->dwMask & TBIF_SIZE) > - btnPtr->cx = lptbbi->cx; > + btnPtr->cx = lptbbi->cx; > if (lptbbi->dwMask & TBIF_STATE) > btnPtr->fsState = lptbbi->fsState; > if (lptbbi->dwMask & TBIF_STYLE) Whitespace only changes shouldn't be included in patches with other changes. -- Rob Shearman

2 4

Re: shell32/tests: Fix a test on Win2k platform and above.
by Nicolas Le Cam 18 Mar '09

18 Mar '09

2009/3/18 Vincent Povirk <madewokherd+8cd9(a)gmail.com>: > On Wed, Mar 18, 2009 at 11:46 AM, Nicolas Le Cam <niko.lecam(a)gmail.com> wrote: >> Message notification comes from appbar3, I've checked hwnd handles. >> When calling last ABM_REMOVE there's no more appbars so Wine shouldn't >> send any notifications, if it does the broken macro (that will come >> with try2) will catch that. > > The window notified with ABN_POSCHANGED is never the window that > caused the notification. When a window is removed, every other window > gets a notification so it knows to update its position. > > The test is just getting that notification late. This is not broken. > > Vincent Povirk > Ok, did more testing ... It seems you're right, adding a do_events() call after each DestroyWindow() one seems to fix the test on Win2k. Do you think this is a better fix ? -- Nicolas Le Cam

2 2

Re: [urlmon/tests] Skip some tests on Vista and higher
by Jacek Caban 18 Mar '09

18 Mar '09

Hi Paul, Paul Vriens wrote: > Hi, > > The Gopher protocol has been removed from Vista (and later versions). hres = CoGetClassObject(&CLSID_GopherProtocol, CLSCTX_INPROC_SERVER, NULL, &IID_IUnknown, (void**)&unk); + if (hres == REGDB_E_CLASSNOTREG) { + win_skip("Gopher protocol has been removed as of Vista\n"); + return; + } As it was removed in newer Windows, I don't think it qualifies as missing functionality and we may consider removing it from Wine as well. I'd suggest to change existing ok() to accept REGDB_E_CLASSNOTREG and not call win_skip (perhaps trace or nothing). Thanks, Jacek

2 1

GSoC Idea: D3DXMesh
by Andrew Fenn 18 Mar '09

18 Mar '09

Just an idea I came up with for Google's summer of code is perhaps implementing some of the D3DXMesh header files and functions so that we can get on with implementing functions such as D3DXCleanMesh which I believe Assassin's Creed needs. I have no intention of applying for GSoC however it's an idea I'd like to put into the pot.

3 4

Re: shell32/tests: Fix a test on Win2k platform and above.
by Nicolas Le Cam 18 Mar '09

18 Mar '09

2009/3/18 Vincent Povirk <madewokherd+8cd9(a)gmail.com>: > On Wed, Mar 18, 2009 at 9:39 AM, Nicolas Le Cam <niko.lecam(a)gmail.com> wrote: >> I don't think calling SHAppBarMessage with ABM_REMOVE destroy the >> window and the ABN_POSCHANGED notification is catched between this >> call and the DestroyWindow one. But this particular behaviour only >> happens on Win2k and perhaps previous windows versions (should be >> tested) not on XP and later ones, that's why I wanted to keep your >> approach and mark this particular behaviour as broken (even if I >> didn't use the right approach as noticed by Paul) to force wine to >> behave like recent windows versions > > Wine DOES send a notification to all other appbars when one appbar is > removed. However, Wine's SHAppBarMessage will never processes messages > in the queue, nor will DestroyWindow. > > I really think you're getting the notification from destroying > appbar2, and you just happen to be getting it late. Windows' > implementation does have a tendency to send us late messages. > > The failure does not indicate that Wine is behaving more like winxp > than win2k. It doesn't tell us anything helpful at all, as the details > are something no real app should ever rely on. Nor is it a broken way > to implement this API. > > I think this case should pass even on Wine. > > Vincent Povirk > Message notification comes from appbar3, I've checked hwnd handles. When calling last ABM_REMOVE there's no more appbars so Wine shouldn't send any notifications, if it does the broken macro (that will come with try2) will catch that. -- Nicolas Le Cam

1 0

Re: shell32/tests: Fix a test on Win2k platform and above.
by Vincent Povirk 18 Mar '09

18 Mar '09

On Tue, Mar 17, 2009 at 4:50 PM, Nicolas Le Cam <niko.lecam(a)gmail.com> wrote: > Tell me if you have a better solution. You should add some traces first to find out what window is getting this notification and when. The test data currently doesn't have enough information to decide on a correct fix. Vincent Povirk

2 3

Re: shell32/tests: Fix a test on Win2k platform and above.
by Paul Vriens 18 Mar '09

18 Mar '09

Nicolas Le Cam wrote: > On Win2k (and according to test.winehq.org on above platforms) an > ABN_POSCHANGED message is sent to the last window that is removed. > > This patch change the ok to a win_skip in this case. > > Tell me if you have a better solution. > > Nicolas Le Cam > > > ------------------------------------------------------------------------ > > I can see several extra notifications on W2K and below. You are now doing things different. Previously the test was to check if info is not NULL. Now you are only doing the test if info is NULL. I think a broken() would be more appropriate here. So something like: ok(info != NULL || broken(!info && !registered_count), /* W2K */ "got unexpected ABN_POSCHANGED notification\n"); Could you check the behavior on Win9x/NT4? I guess Vincent Povirk can comment better on the patch as he wrote the initial tests. -- Cheers, Paul.

3 2

Re: Registry: Set FontSmoothing as default enabled (AA)
by André Hentschel 17 Mar '09

17 Mar '09

Havin AA enabled in Gnome/KDE dont means you want it in wine and it works fine with your configuration or windows software. Mostly it will work, so it should be default. And like Dmitry said it is not a good idea: http://bugs.winehq.org/show_bug.cgi?id=16745

1 0

SoC: DirectShow/Gstreamer
by Trevor Davenport 17 Mar '09

17 Mar '09

Hi, I'm interested in applying for a GSoC project related to wine. I am looking at doing the DirectShow/Gstreamer idea that is listed in the wiki (http://wiki.winehq.org/SummerOfCode) From the idea description there are a number of factors that would make this an ideal solution. The description mentions the availability of legal codecs (from fluendo) plus the ability to use the codecs already exposed to gstreamer (ie. install a codec and native/wine applications instantly get support). Recently GStreamer has added some pipeline elements targeted at integrating with other frameworks (appsrc/appsink) which allow sending data down a gstreamer pipeline and/or recieving it. Prior to these you had to write your own element (this wasn't too much work either depending on your needs and may still be preferred for more compatibility). I am quite familiar with both C and GStreamer. I have never looked at DirectShow though from what i know they are similar in concept. GStreamer does have some DirectShow filters that allow it to use directshow elements inside GStreamer (on windows anyway). My experience with wine has been limited to my own experiments. I've played around with audio drivers for wine. I wrote one that used GStreamer and later adjusted this to use pulseaudio instead. I never got time to clean them up to the point of submitting them. I have a few questions in regard to this idea. Do you think this project would provide adequate work to occupy the SoC timeframe? I would have to learn DirectShow which I don't believe would be too difficult. I've worked with DirectSound/DirectX and would expect it to require a similiar amount of work. I've also spent a fair amount of time inside wine's source code looking into various bugs. I welcome any comments, suggestions or idea related to this. I'd love any feedback so I know this is an idea that is wanted (i would like it...i use wine quite often) and so my application is as good as it can be. Cheers, Trevor Davenport

3 3

Re: [riched20/tests] Changed tests for EM_FORMATRANGE
by James Mckenzie 17 Mar '09

17 Mar '09

Paul Vriens <paul.vriens.wine(a)gmail.com> wrote on March 16th: > >Hi, > >I've been playing with this and just wanted to see if anybody has comments on >these changed tests. > >Tests succeed on Win95/Win98 and W2K3 with every possible resolution (as we are >not relying on the resolution anymore) and 96/120 dpi. > Paul: Looks good to me. I still need someone to pick up the actual implementation code and work with it. I have other priorities right now and think that Tony Rollo's code will not work and will require major rework to function properly with RichOLE. James McKenzie

1 0