January 2007 - Wine-Devel - list.winehq.org

[PATCH] fix tools/c2man.pl perl syntax
by Alexey Tourbin Jan. 12, 2007

Jan. 12, 2007

Fellas, tools/c2man.pl have buggy pieca code which work only for accident reasons. The patch fixes perl syntax for upcoming perl-5.8.9 who ain't not gonna tolerate the buggy pieca coda. http://www.nntp.perl.org/group/perl.perl5.porters/119879 http://www.nntp.perl.org/group/perl.perl5.porters/119881 http://www.nntp.perl.org/group/perl.perl5.porters/119882 http://www.nntp.perl.org/group/perl.perl5.porters/119883 --- tools/c2man.pl- 2006-12-24 00:17:04 +0000 +++ tools/c2man.pl 2007-01-12 07:13:05 +0000 @@ -627,7 +627,7 @@ sub process_comment($) # When the function is exported twice we have the second name below the first # (you see this a lot in ntdll, but also in some other places). - my $first_line = ${@{$comment->{TEXT}}}[1]; + my $first_line = $comment->{TEXT}[1]; if ( $first_line =~ /^(@|[A-Za-z0-9_]+) +($|\[)([A-Za-z0-9_]+)\.(([0-9]+)|@)($|\])$/ ) { @@ -642,14 +642,14 @@ sub process_comment($) my $alt_export = @{$spec_details->{EXPORTS}}[$alt_index]; @$alt_export[4] |= $FLAG_DOCUMENTED; $spec_details->{NUM_DOCS}++; - ${@{$comment->{TEXT}}}[1] = ""; + $comment->{TEXT}[1] = ""; } } if (@{$spec_details->{CURRENT_EXTRA}}) { # We have an extra comment that might be related to this one - my $current_comment = ${@{$spec_details->{CURRENT_EXTRA}}}[0]; + my $current_comment = $spec_details->{CURRENT_EXTRA}[0]; my $current_name = $current_comment->{COMMENT_NAME}; if ($comment->{COMMENT_NAME} =~ /^$current_name/ && $comment->{COMMENT_NAME} ne $current_name) { @@ -986,7 +986,7 @@ sub process_extra_comment($) if (@{$spec_details->{CURRENT_EXTRA}}) { - my $current_comment = ${@{$spec_details->{CURRENT_EXTRA}}}[0]; + my $current_comment = $spec_details->{CURRENT_EXTRA}[0]; if ($opt_verbose > 0) { @@ -1072,7 +1072,7 @@ sub process_index_files() if (@{$spec_details->{CURRENT_EXTRA}}) { # We have an unwritten extra comment, write it - my $current_comment = ${@{$spec_details->{CURRENT_EXTRA}}}[0]; + my $current_comment = $spec_details->{CURRENT_EXTRA}[0]; process_extra_comment($current_comment); @{$spec_details->{CURRENT_EXTRA}} = (); } @@ -1468,7 +1468,7 @@ sub output_api_synopsis($) my $biggest_length = 0; for(my $i=0; $i < @{$comment->{PROTOTYPE}}; $i++) { - my $line = ${@{$comment->{PROTOTYPE}}}[$i]; + my $line = $comment->{PROTOTYPE}[$i]; if ($line =~ /(.+?)([A-Za-z_][A-Za-z_0-9]*)$/) { my $length = length $1; @@ -1482,19 +1482,19 @@ sub output_api_synopsis($) # Now pad the string with blanks for(my $i=0; $i < @{$comment->{PROTOTYPE}}; $i++) { - my $line = ${@{$comment->{PROTOTYPE}}}[$i]; + my $line = $comment->{PROTOTYPE}[$i]; if ($line =~ /(.+?)([A-Za-z_][A-Za-z_0-9]*)$/) { my $pad_len = $biggest_length - length $1; my $padding = " " x ($pad_len); - ${@{$comment->{PROTOTYPE}}}[$i] = $1.$padding.$2; + $comment->{PROTOTYPE}[$i] = $1.$padding.$2; } } for(my $i=0; $i < @{$comment->{PROTOTYPE}}; $i++) { # Format the parameter name - my $line = ${@{$comment->{PROTOTYPE}}}[$i]; + my $line = $comment->{PROTOTYPE}[$i]; my $comma = ($i == @{$comment->{PROTOTYPE}}-1) ? "" : ","; $line =~ s/(.+?)([A-Za-z_][A-Za-z_0-9]*)$/ $fmt[0]$1$fmt[2]$2$fmt[3]$comma$fmt[1]/; print OUTPUT $line;

1 0

OpenGL in child windows
by Chris Robinson Jan. 12, 2007

Jan. 12, 2007

Here's something I've been working on for about the past week. It's my attempt to get OpenGL to render into an X11 child window that overlays the Win32 window. These patches are more proof-of-concept than anything I'd attempt to get into Wine.. just to show that it seems to work. If the method is good enough, these would need to be rewritten. The biggest problem facing these patches that I ran into are threading issues. Since each window is basically tied to the thread that it was created in but can be used out of it, and each thread uses its own X11 display connection, there's quite a few hoops to jump through. The problem is that the OpenGL X11 window can be created at basically any time after the window was created, in any thread (it's currently done in the call to SetPixelFormat, the earliest it'll know which visual/pixel format is wanted, and can create a colormap to be able to use it in a child window, regardless of the visual of its parent). If that call is not done in the thread the win32 window was created in, it would have trouble getting some of the data structures it needs. Add on top of that, that the X11 window can be parented to yet another win32 window (the one that has the "whole" X11 window), which can be in yet another thread, it leaves a lot of problem trying to keep syncronization. Most of the placement syncronization is done by adding a couple fields to x11drv_win_data to hold info for the X11 child window's parent, that can be used to properly offset the X11 child in relation to the X11 parent, according to the Win32 window's placement. It also needed a couple driver-specific WM_ messages to be able to get the data it needs in case the creation is done in a seperate thread. Because the X11 window uses a thread-specific display connection, and the child window needs to share the display connection, I needed to add a Display* to the X11DRV_PDEVICE struct, which is used wherever a GLX call needs an explicit display connection. This works well most of the time, but has a problem when a GL context (tied to an HDC in Windows) is in use when the thread that created the Win32 window that the HDC came from is killed. When the thread is killed, it closes the connection which leaves GLX using an invalid Display. I have to ask, is there a reason each thread uses its own display connection (which are all different from gdi_display), and leaves the window data to only be available from the thread the window was created in? Besides the aforementioned problem with the GL context, I'd imagine it would be problematic even in current Wine.. for example, if something creates a window in one thread, passes it to another, then kills the thread it was originally created in while still using the window. I currently made it so each thread shares the same Display connection (which is different from gdi_display). This seems to cause no noticeable problems, and it fixes the GL context display issue. Beyond that, the only problem I can recall off-hand is that the OpenGL window will draw overtop of all Win32 windows that are sharing the same X11 parent window. However, considering that the current method with the scissors hack causes the whole X11 window to clear on a buffer flip, and also draws on top of anything in its window space anyway, this is still a nice step forward. And there are also a couple syslevel potential-deadlock warnings generated from the calls to create the window, however I have yet to see a problem arise from all the programs I've tested (the warnings can't stay obviously, but they can be figured out later). What these patches end up accomplishing is that it allows for the possibility to use alternate visuals, so the X11 driver would not need to force a specific double-buffered visual on initialization, and it allows programs to use program-specified color, stencil, depth, aux, multisampling, and single/double-buffer configurations without relying on the main window to have it too (this isn't done in these patches, but it does allow for it to work). Also, the scissors hack is no longer needed. All calls to the Wine-specific extension for it can be removed (they aren't removed here, instead just piped directly to the appropriate gl* function with no alteration, since that would require changes to opengl32). OpenGL in Win32 child windows is improved by being restrained to the Win32 windows' extents, as seen in the screen-grab here in VLC using the OpenGL output renderer: http://kcat.strangesoft.net/deskshot.jpg It uses proper color ordering (unlike the GDI renderer), is properly centered, can be scaled with no performance impact, and doesn't clear the whole window. Performance is good, and it is actually quite useable. Terragen (which has a real-time 3D window), Terragen 2 (which has two or three OpenGL child windows), Milkshape 3D, and GoogleEarth all work. Terragen 2 has some issues with its right-click menu that comes up from the OpenGL child window (the mouse doesn't interact with it), however I'm not sure if this is an issue with my patches since Milkshape3D also has a right-click menu from an OpenGL child and it works fine. In any case, there's no other input-related issues to speak of. Clicking and dragging the globe in GoogleEarth works, as does the keyboard controls in Terragen, and the other Win32 windows are properly receptive to all input as well. It also behaves properly with composite effects (such as the transparency, stretching, and warping effects from Beryl). All testing and comments on the patches are welcome. If the code is doing something it shouldn't be, I'm more than willing to figure out alternative methods if needed (hopefully with help). With luck, they can be gotten to a point soon where they can be rewritten properly to get into Wine.

4 4

Re: dsound/tests: The tests link with dsound.dll so use GetModuleHandle() instead of LoadLibrary().
by Felix Nawothnig Jan. 11, 2007

Jan. 11, 2007

Francois Gouget wrote: > This is a NOP, it just seems a bit cleaner to me. > > - hDsound = LoadLibraryA("dsound.dll"); > - if (!hDsound) { > - trace("dsound.dll not found\n"); > - return; > - } > - > + hDsound = GetModuleHandleA("dsound.dll"); > + ok(hDsound != NULL, "dsound.dll not loaded!\n"); No it's not, that causes test failure on native when DirectX is not installed (NT4 out-of-the-box I believe?).

2 1

Looking for sound testers
by Maarten Lankhorst Jan. 11, 2007

Jan. 11, 2007

Hi all, I've forward ported the old patches of Davin McCall (dsound.patch). With them I have no more sound underruns etc, I'm therefore looking for other people to test them as well. I'm welcoming comments on how it works and possible issues with it. I also attached my patch to alsa, I'm aware of the things I need to fix for that, but I thought it might be good to test dsound with winealsa, to see if other things still need to be fixed. Cheers, Maarten

6 5

Re: Stub fro GetRawInputDeviceList
by Marcelo Duarte Jan. 11, 2007

Jan. 11, 2007

Michał Majchrowicz escreveu: > Hi. > I hope this time it is correct patch and will be accepted. > Regards Michael. I think the spec file is incorrect. > diff --git a/dlls/user32/user32.spec b/dlls/user32/user32.spec > index f857105..0517ebc 100644 > --- a/dlls/user32/user32.spec > +++ b/dlls/user32/user32.spec > @@ -345,7 +345,7 @@ > # @ stub GetRawInputData > # @ stub GetRawInputDeviceInfoA > # @ stub GetRawInputDeviceInfoW > -# @ stub GetRawInputDeviceList > +@ stub GetRawInputDeviceList > maybe: @ stdcall GetRawInputDeviceList(ptr ptr long) > # @ stub GetReasonTitleFromReasonCode > # @ stub GetRegisteredRawInputDevices > @ stdcall GetScrollBarInfo(long long ptr) > diff --git a/include/winuser.h b/include/winuser.

1 0

WinZip regression
by martin pilka Jan. 11, 2007

Jan. 11, 2007

Hello, automated CxTest testing shows WinZip regression: Jan 8 - WinZip ran 9 times (5 Francois + 4 Jozef), all succeeded Jan 9 - WinZip ran 1 time (Francois), failed with http://www.cxtest.org/triage/failures?dl=364121 (Out of resources error, unable to continue) Jan 10 - WinZip ran 2 times (1 Francois + 1 Jozef), both failed with same screenshot So there is a regression between Jan 8 and Jan 9 - unfortunately, I do not know GIT_ID. Should I create bug for this? If you want to join Wine automated testing process, go to http://www.cxtest.org/download and install CxTest. Martin

1 0

Re: WineD3D: Fix my name
by Alexandre Julliard Jan. 11, 2007

Jan. 11, 2007

Stefan Dösinger <stefan(a)codeweavers.com> writes: > Correct the umlauts for utf8, this seems to be the encoding everyone uses Actually the encoding for source files is Latin-1 at the moment. This should probably be changed once we convert resources to utf-8, to make all files use the same encoding. -- Alexandre Julliard julliard(a)winehq.org

4 5

Re: Electron Microscope III (EMIII)
by Dmitry Timoshkov Jan. 11, 2007

Jan. 11, 2007

"Seth Shelnutt" <shelnutt2(a)msn.com> wrote: > I am trying to get EMIII to run via wine. I'm perfectly willing to debug > this. I just don't know how. I think my issue is with MSVBVM60.DLL > (MSVBVM60.dbg)? I just sent a patch that should fix the crash. P.S. wineconf mailing list is not an appropriate place for a bug report. -- Dmitry.

1 0

dual displays
by James Hawkins Jan. 11, 2007

Jan. 11, 2007

Hi, dlls/winex11.drv/opengl.c:820 if(!display || !display) { ERR("Invalid display or visual\n"); } My guess is that second 'display' is supposed to be 'visual'. -- James Hawkins

1 0

Re: D3D9: Implement IDirect3DDevice9::StretchRect
by Ivan Gyurdiev Jan. 11, 2007

Jan. 11, 2007

Stefan Dösinger wrote: > This call can be handled fully by IWineD3DSurface::Blt. So where did the filter argument go.. there's 3 different filter types to support.

1 0

[ANN] Wine wiki
by Dimi Paun Jan. 11, 2007

Jan. 11, 2007

Folks, As promised, the server that the wiki is on has been upgraded to a much better and faster box. Everything should work just fine, only faster :) Please let me know if you notice any problems or glitches. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Re: WineD3D: Fix my name
by Stefan Dösinger Jan. 11, 2007

Jan. 11, 2007

Am Donnerstag 11 Januar 2007 02:07 schrieb Stefan Dösinger: > Correct the umlauts for utf8, this seems to be the encoding everyone uses Ignore this patch, a code change slipped in accidentally. One that depends on my yesterday's [9] - ignore patch

1 0

Experienced Wine Developers Wanted for Commercial Open Source project - Wine on Cygwin and Windows
by Chetan Venkatesh Jan. 10, 2007

Jan. 10, 2007

My company is looking for experienced Wine Developers to work on a commercial Open Source Project involving getting wine working under cygwin and Windows. Can anyone point me to the right mailing list / forum to make a posting at or can interested developers contact me please - chetan.venkatesh(a)gmail.com Regards Chetan

4 4

Re: [PATCH 2/10] dinput: [joystick_linux] Copy and modify default data format.
by Alexandre Julliard Jan. 10, 2007

Jan. 10, 2007

Vitaliy Margolen <wine-patches(a)kievinfo.com> writes: > @@ -610,6 +632,8 @@ static ULONG WINAPI JoystickAImpl_Releas > HeapFree(GetProcessHeap(), 0, This->props); > > /* release the data transform filter */ > + HeapFree(GetProcessHeap(), 0, (LPVOID)This->base.data_format.wine_df->rgodf); > + HeapFree(GetProcessHeap(), 0, (LPVOID)This->base.data_format.wine_df); Please don't add more cast-qual warnings, we are trying to get rid of them. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: rpcrt4: Give a proper name to some formerly reserved MIDL_STUB_MESSAGE fields.
by Francois Gouget Jan. 10, 2007

Jan. 10, 2007

On Wed, 10 Jan 2007, Francois Gouget wrote: > Define NTDDI_WIN2K so we get definitions for the Reserved51_X fields with the PSDK. > This fixes compilation of the ndr_marshall.c with the PSDK. Ignore this one for now, it does not really solve the compilation problems with the PSDK so I will rework it a bit. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner

1 0

Details: Wine Developers Wanted for Commercial Open Source project - Wine on Cygwin and Windows
by Chetan Venkatesh Jan. 10, 2007

Jan. 10, 2007

I got a lot of people asking me to post details about our intended project. Basically, what we are trying to do is run native Windows applications on a remote X desktop; we feel that the best way to do this would be to use wine as a base to develop a Windows to X translator/mapping, and then export the X calls over the network. It looks like wine should already implement much of the needed functionality in order to run Windows applications on Linux, so a windows port of the display code tied into an Xserver seems to make the most sense as a way forward. We're looking at contracting a development team to work on this with an estimated time to completion of 3 months, and are comfortable with an open source development model. The finished product will of course be released under the GPL. Feedback on this idea is welcome. Interested developers/organizations can contact me at chetan.venkatesh(a)gmail.com Chetan

1 0

Re: dinput, wheel/joystick and richard burns rally
by Vitaliy Margolen Jan. 9, 2007

Jan. 9, 2007

Christoph Frick wrote: > On Mon, Jan 08, 2007 at 11:31:58AM -0700, Vitaliy Margolen wrote: > >> Well I've been looking at what will it take to fix it. Also made few >> patches for EnumObjects and GetObjectInfo. But I can't send those, >> because other parts using wrong indexes. And it will really brake >> things (but should fix the problem Tuomo was talking about). >> If you want to pick it up, I can move on to something else. > > well i had a look at it yesterday. what i have seen then next things > are to build the wine_df within the alloc_device. this can either be > done by copiing the const format or by really create what we have. this > would mean then to move the code from EnumObjects over and adapt it and > get rid of EnumObjects at all. > > is this right? > Correct. Sorry I got this already done and patches sent. After looking at it myself I realized that it would be easier to send everything as one set. The hard part was figuring out which index used where and why. I think that should do it for now. The only other big refactoring that I can think of would be using user provided data format as internal format. And of course merging two joystick files. There are much closer to each-other now. Vitaliy.

1 0

Re: Alexandre Julliard : Release 0.9.29.
by Lei Zhang Jan. 9, 2007

Jan. 9, 2007

Bugzilla needs to be updated with the new version number. On 1/9/07, Alexandre Julliard <julliard(a)wine.codeweavers.com> wrote: > Module: wine > Branch: master > Commit: d8c3e7de692c785e1c7679d0521cf8b12469b0b8 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=d8c3e7de692c785e1c7679d05… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Tue Jan 9 16:42:47 2007 +0100 > > Release 0.9.29. > > --- > > ANNOUNCE | 923 +++++++++++++++++------------ > ChangeLog | 1936 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > VERSION | 2 +- > configure | 18 +- > 4 files changed, 2484 insertions(+), 395 deletions(-) > > Diff: http://source.winehq.org/git/wine.git/?a=commitdiff;h=d8c3e7de692c785e1c767… > > >

1 0

Re: uninstaller: Add a Portuguese translation (contributed by Americo Jose Melo).
by Frank Richter Jan. 9, 2007

Jan. 9, 2007

On 08.01.2007 11:49, Francois Gouget wrote: > +CAPTION "Desinstalador de AplicaÃ§Ãµes Wine" That's UTF-8... Is that correct? I though Portugese resources should be in cp1252. -f.r.

3 2

Re: uninstaller: Add a Portuguese translation (contributed by Americo Jose Melo).
by Michael Stefaniuc Jan. 9, 2007

Jan. 9, 2007

Francois Gouget wrote: > --- > Resubmitting with the proper encoding this time, with thanks to Frank > Richter. I also switched SUBLANG_PORTUGUESE_PORTUGAL to the more > standard SUBLANG_PORTUGUESE to match all the other resource files. Actualy http://wiki.winehq.org/Developers-Hints#head-ef42a958e4f633dbd4a0ae42649fa0… says quite the opposite. Target is to change the SUBLANG_$whatever to SUBLANG_NEUTRAL if all the sublanguages use the same translation. And default in Windows for portugese is SUBLANG_PORTUGUESE_BRAZILIAN and not SUBLANG_PORTUGUESE_PORTUGAL. bye michael > > programs/uninstaller/Pt.rc | 21 +++++++++++++++++++-- > 1 files changed, 19 insertions(+), 2 deletions(-) > > diff --git a/programs/uninstaller/Pt.rc b/programs/uninstaller/Pt.rc > index 5797fb1..0f8ea11 100644 > --- a/programs/uninstaller/Pt.rc > +++ b/programs/uninstaller/Pt.rc > @@ -18,9 +18,26 @@ > * > */ > > -LANGUAGE LANG_PORTUGUESE, SUBLANG_NEUTRAL > +LANGUAGE LANG_PORTUGUESE, SUBLANG_PORTUGUESE > > +IDD_UNINSTALLER DIALOG DISCARDABLE 0, 0, 330, 160 > +STYLE DS_MODALFRAME | WS_CAPTION | WS_SYSMENU > +CAPTION "Desinstalador de Aplicações Wine" > +FONT 10, "MS Sans Serif" > +BEGIN > + LTEXT "Por favor seleccione a aplicação que deseja desinstalar:",IDC_PLEASESELECT,10,10,250,14 > + EDITTEXT IDC_FILTER,10,25,250,14,ES_AUTOHSCROLL > + LISTBOX IDC_LIST,10,43,250,106,LBS_NOINTEGRALHEIGHT | > + LBS_EXTENDEDSEL | WS_VSCROLL | WS_TABSTOP > + PUSHBUTTON "&Desinstalar",IDC_UNINSTALL,270,48,50,14 > + PUSHBUTTON "&Acerca",IDC_ABOUT,270,65,50,14 > + PUSHBUTTON "&Sair",IDC_EXIT,270,81,50,14 > +END > > STRINGTABLE DISCARDABLE { > - IDS_APPNAME, "Desinstalador" > + IDS_APPNAME, "Desinstalador de Aplicações Wine" > + IDS_ABOUT, "Desinstalador de Aplicações Wine (C) 2005 por Andreas Mohr, Hannu Valtonen e Jonathan Ernst." > + IDS_ABOUTTITLE, "Acerca do Desinstalador" > + IDS_REGISTRYKEYNOTAVAILABLE, "Chave de registo de desinstalação não disponível (ainda), nada a fazer !" > + IDS_UNINSTALLFAILED, "Execução do comando de desinstalação '%s' falhado, talvez devido a faltar o executável.\r\nDeseja remover a entrada de desinstalação do registo ?" > } > > > ------------------------------------------------------------------------ > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

Re: [try 3] systray patches
by Kirill K. Smirnov Jan. 9, 2007

Jan. 9, 2007

> > Or I miss something really important? If so, just provide a use-case, > > please!! > > Well, for instance if the parent is a Wine window, which would be the > case when someone implements systray handling in desktop mode, it > would break since Wine windows are not painted with the background > pixmap. This case assumes absolutely other mechanism of embedding, not XEMBED. _Wine_ cannot be XEMBED-master for _wine_ application. (May it? Reasons?) My patches are to fix annoying background situation caused by _XEMBED_ usage. Only for xembed. Other way (as you supposed, native wine's tray in desktop mode) may be implemented (interesting idea, I though about it, but is there anybody who needs this?). Then XEMBED and the new mechanism MUST be mutually excluse. So, my patch does not hurt anything. > Anyway, I'm not necessarily opposed to doing pseudo-transparency, if > you can find a way to do it cleanly, i.e. without adding special cases > for systray windows all over the place. Heh, I intend to add cases as less as possible! BUT! For any "output-only-transparency, not input" mechanism for XEMBED I choose, I have to play around with background pixmap. When application changes icon, the window background must be repainted to remove previous junk. As you say, Wine windows are not painted with the background pixmap (I do not know details), so we must do it explicitly by calling XClearWindow. This is reason for at least one special case handling. And I add one special case in SetWindowIcon(a)winex11.drv/window.c!!! Other case I added in user32/defwnd.c looks like hack. You were right - I should investigate SetWindowPos problem. -- Kirill

1 0

Re: [try 3] systray patches
by Kirill K. Smirnov Jan. 9, 2007

Jan. 9, 2007

> It's not transparent, Hm... Yes, it is not transparent. It is pseudo-transparent. Just for us. > it's painted with what you hope is the same > background as the parent, but there's no guarantee of that. Xlib thinks opposite. The window will be painted with the same background as the parent (not a copy of parent pixmap, but the same pixmap). It will be even correctly tiled to provide 'pseudo-transparency'! Xlib programming manual guarentee that: http://www.cptec.inpe.br/sx4/sx4man2/g1ae02e/chap3.html chapter 3.2.1. The main ideas I based upon: 1) the parent window does not paint anything under our window. If there will be smth, then pseudo-transparency will be broken. 2) Any sane systray implementation satisfies 1). 3) KDE/fluxbox/other systrays are sane. The link: http://www.nabble.com/-Gaim-gtk-bugs----gaim-gtk-bugs-1370422---Tray-icon-n… provides some information (KDE): [quote] "The code of those applications needs to be changed to perform XSetWindowBackgroundPixmap( dpy, window, ParentRelative ) on the X window that is used as the systray icon. There's nothing KDE can do about this, you need to ask the app developers to support this fake transparency." [/quote] Or I miss something really important? If so, just provide a use-case, please!! -- Kirill

2 1

Re: [try 3] systray patches + SetWindowPos in WM_SETICON
by Kirill K. Smirnov Jan. 9, 2007

Jan. 9, 2007

> "Kirill K. Smirnov" <lich(a)math.spbu.ru> writes: > > Please, explain me, what is wrong with this serie of patches? > > What to do to improve them? > > As I said, making the background pixmap ParentRelative is just a hack, > it's not real transparency. Why is it not a real transparency? This is the easiest way to provide only output transparency, not input. Exactly what we need. > You don't know how the parent will paint > itself, so you can't rely on that. wine doesn't know that, but does not need to know too. That's why I use ParentRelative, because when I change KDE (e.g.) panel background it is handled correct. > Also, your patch adds special > handling for the tray window in user32, that's a violation of the > driver abstraction. Hm... The core problem here is to notify WM systray to be repainted when wine changes icon. To achieve this, I call XClearWindow in setwindowicon(a)winex11.drv/window.c. This is ideological correct (IMO) - perform X operation in setwindowicon function when application changes icon. But!!! defwndproc(a)user32.defwnd calls SetWindowPos. This breaks everything concerning wine tray. Tray window should not be reposed. It is done once (while docking) and forever. So, my patch for user32 is a 'bugfix' for a 'bug' caused by wine systray embedding idea. Maybe, there is other way to achieve this, but I cannot imagine. Any ideas? -- Kirill

2 1

Re: add tests to odbccp32
by Alexandre Julliard Jan. 9, 2007

Jan. 9, 2007

Bill Medland <billmedland(a)shaw.ca> writes: > + /* MSDN states that the error number should be between 1 and 8. Passing 0 is an error */ > + sql_ret = SQLInstallerError(0, NULL, NULL, 0, NULL); > + todo_wine(sql_ret == SQL_ERROR, "SQLInstallerError(0...) failed with %d instead of SQL_ERROR\n", sql_ret); That's not how todo_wine is used, this won't do anything useful. -- Alexandre Julliard julliard(a)winehq.org

1 0

Humus Water demo vs FBOs
by Ivan Gyurdiev Jan. 9, 2007

Jan. 9, 2007

Here's a demo that breaks FBOs: http://www.humus.ca/3D/Water.zip Also download: http://www.humus.ca/3D/Framework2.zip You'll notice all the glClear calls fail [ or at least a lot of them ]. That's because the framebuffer is incomplete at that point - checkFBOstatus() should be called before glClear, as well as drawprim to see that this is FRAMEBUFFER_INCOMPLETE_DIMENSIONS_EXT (0x8cd9). I think the call that fails is the clear call in the drawFrame() function of the app - the others set a 0 depth stencil buffer immediately prior, while this one is probably using wined3d's initial depth fbo. I think the Framework sets EnableAutoDepthStencil, so that an fbo is created. It probably ends up being a different size from the color fbo, which breaks a framebuffer completeness requirement.

2 1