March 2013 - Wine-Devel - list.winehq.org

Re: gdi32: Printer drivers don't use the character extra spacing if lpdx is supplied.

by Huw Davies

On Tue, Mar 26, 2013 at 04:50:03PM +0100, Alexandre Julliard wrote: > Ah OK, I guess that makes it a PITA to test... Some kind of print-scan magic comes to mind ;-)

March 26, 2013

Re: gdi32: Printer drivers don't use the character extra spacing if lpdx is supplied.

by Alexandre Julliard

Huw Davies <huw(a)codeweavers.com> writes: > On Tue, Mar 26, 2013 at 04:30:14PM +0100, Alexandre Julliard wrote: >> Huw Davies <huw(a)codeweavers.com> writes: >> >> > Ideally this would be done in wineps.drv, but by that point the conversion to device units would cause rounding errors. >> >> What about GetTextExtent functions? Do they need this too? Some test >> cases would be nice. > > Note this only applies when lpDx != NULL, when it's NULL then > char_extra is still applied. So, yes the current GetTextExtent > behaviour is correct. Ah OK, I guess that makes it a PITA to test... -- Alexandre Julliard julliard(a)winehq.org

March 26, 2013

Re: gdi32: Printer drivers don't use the character extra spacing if lpdx is supplied.

by Huw Davies

On Tue, Mar 26, 2013 at 04:30:14PM +0100, Alexandre Julliard wrote: > Huw Davies <huw(a)codeweavers.com> writes: > > > Ideally this would be done in wineps.drv, but by that point the conversion to device units would cause rounding errors. > > What about GetTextExtent functions? Do they need this too? Some test > cases would be nice. Note this only applies when lpDx != NULL, when it's NULL then char_extra is still applied. So, yes the current GetTextExtent behaviour is correct. Huw.

March 26, 2013

Re: gdi32: Printer drivers don't use the character extra spacing if lpdx is supplied.

by Alexandre Julliard

Huw Davies <huw(a)codeweavers.com> writes: > Ideally this would be done in wineps.drv, but by that point the conversion to device units would cause rounding errors. What about GetTextExtent functions? Do they need this too? Some test cases would be nice. -- Alexandre Julliard julliard(a)winehq.org

March 26, 2013

Re: comctl32: Make an attempt to update notification handle

by Nikolay Sivov

On 3/25/2013 07:48, Dmitry Timoshkov wrote: >>>>> Why not just call GetParent() every time when a >>>>> notification is being sent? >>>> Because it won't work if you create a control without WS_CHILD. >>> How is that different from the WM_WINDOWPOSCHANGING handler? >> How what is different? There's a check for null parent as you can see. > Why the same can't be done at the time a notification needs to be sent? > There are many places (starting from user32/WM_PARENTNOTIFY) which send > notifications that way, what's so special about tab control? Unfortunately it's more complicated than that. For example notifications sent after TCM_SETCURFOCUS are delivered to original window, but if you do any mouse interaction it appears to notify new parent. So SetParent() leaves it in a kind of broken state. So we can't always use parent window, but for some notification cases valid GetParent() value should be used as in examples you mentioned. Is there any reliable way to test send mouse messages? Cause it looks like if I send WM_LBUTTONDOWN directly it doesn't trigger tab selection code on windows, but works in wine. Thanks for review.

March 26, 2013

Re: explorer: Create desktop window hidden and only show it if it wins the race.

by Ken Thomases

On Mar 26, 2013, at 3:20 AM, Dmitry Timoshkov wrote: > Ken Thomases <ken(a)codeweavers.com> wrote: > >> + ShowWindow( hwnd, SW_SHOW ); >> SetWindowLongPtrW( hwnd, GWLP_WNDPROC, (LONG_PTR)desktop_wnd_proc ); >> SendMessageW( hwnd, WM_SETICON, ICON_BIG, (LPARAM)LoadIconW( 0, MAKEINTRESOURCEW(OIC_WINLOGO))); >> if (name) set_desktop_window_title( hwnd, name ); > > You can postpone calling ShowWindow() after setting window text and icon, > since they are drawn as part of a non-client area, and changing them > forces another set of redraws. Good idea. Thanks. -Ken

March 26, 2013

Re: explorer: Create desktop window hidden and only show it if it wins the race.

by Dmitry Timoshkov

Ken Thomases <ken(a)codeweavers.com> wrote: > + ShowWindow( hwnd, SW_SHOW ); > SetWindowLongPtrW( hwnd, GWLP_WNDPROC, (LONG_PTR)desktop_wnd_proc ); > SendMessageW( hwnd, WM_SETICON, ICON_BIG, (LPARAM)LoadIconW( 0, MAKEINTRESOURCEW(OIC_WINLOGO))); > if (name) set_desktop_window_title( hwnd, name ); You can postpone calling ShowWindow() after setting window text and icon, since they are drawn as part of a non-client area, and changing them forces another set of redraws. -- Dmitry.

March 26, 2013

Mac driver screen flicker on launch (Was: Re: [1/3] Make mac driver the default on OS X)

by Ken Thomases

On Mar 8, 2013, at 6:20 AM, <Joerg-Cyril.Hoehle(a)t-systems.com> <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > I had a very annoying experience: when I started winemac the first > time, the whole screen turned black for a fraction of a second. That > was very unwelcome and reminded me of the infamous Intel-XOrg screen > flickering issue that plagued many Linux distros a few years ago :-( I have tracked this down. Unless explorer.exe is launched explicitly, it is launched on demand. Inside user32.GetDesktopWindow() there's a check if the desktop window exists. If it doesn't, then explorer.exe is launched. There is a race, of course, if multiple processes or threads call GetDesktopWindow() at roughly the same time before the desktop window has been created. All of them start explorer.exe. Explorer.exe creates a window that it intends to act as the desktop window. It then checks if that window actually became the desktop window. If it doesn't, it figures some other instance of explorer.exe won the race, destroys the window, and exits. Only one of the explorer.exe instances survives and it owns the real desktop window. The flicker is the prospective desktop window of the losers. The windows are created visible, so they are briefly shown before being destroyed. (The real desktop window is also created visible but it doesn't usually show unless virtual desktop is enabled under X11. That's because both the Mac and X11 drivers have checks for the desktop window and treat it specially. But only the real desktop window, from the winning explorer.exe, qualifies for that special treatment. The windows from the losers are just normal windows.) I think the solution is to have explorer.exe create its prospective desktop window hidden and only show it if it wins the race. I'll submit a patch shortly. -Ken

March 26, 2013

Re: Wiki is down

by Dimi Paun

Should be up now, the RAID controller on the box died. We'll be moving it to a better box soon, stay tuned. Dimi. On Mon, Mar 25, 2013 at 10:06 AM, Dimi Paun <dimi(a)lattica.com> wrote: > Working on it guys, I'll keep you posted. > > Dimi. > > On Mon, Mar 25, 2013 at 7:18 AM, Francois Gouget <fgouget(a)free.fr> wrote: > >> On Sun, 24 Mar 2013, Rosanne DiMesio wrote: >> >> > I'm getting an "Internal Server Error" message when I try to access the >> wiki. >> >> Cc-ing in case you missed this email (the Wiki is still down :-( ). >> >> >> -- >> Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ >> Dieu dit: "M-x Lumière". Et la lumière fut. > > > > > -- > Dimi Paun <dimi(a)lattica.com> > Lattica, Inc. > > -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 26, 2013

Re: Linker error when improving GetLargestConsoleWindowSize

by Ken Thomases

On Mar 25, 2013, at 8:51 PM, Hugh McMaster wrote: > I've written a function to determine the largest possible screen buffer that wineconsole is able to display. This function replaces the hard-coded constants listed in both instances of GetLargestConsoleWindowSize in dlls/kernel32/console.c. > > [snip] > #include <windows.h> > #include <winuser.h> > > [snip] > > COORD GetLargestConsoleWindowSize_helper(HANDLE hConsoleOutput) > { > RECT workarea; > COORD console_fontsize; > COORD max_console; > > SystemParametersInfoA(SPI_GETWORKAREA, 0, &workarea, 0); > console_fontsize = GetConsoleFontSize(hConsoleOutput, 0); > > max_console.X = (workarea.right / console_fontsize.X) - 6; > max_console.Y = (workarea.bottom / console_fontsize.Y) - 6; > > return max_console; > } > > While dlls/kernel32/console.c compiles, I'm having trouble with the final compile-time linking. It seems that SystemParametersInfoA is an undefined reference, but windows.h and winuser.h are included in console.c. This won't be able to work. The linker error is telling you, effectively, that you're not importing user32. However, kernel32 can't import user32. Kernel32 is at a lower level than user32. And a console program especially can't rely on user32 being loaded and initialized to satisfy the request you're making. Regards, Ken

March 26, 2013