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

Re: winemac: Track drawn surface rect to reduce black flicker for new or resized windows.

by Ken Thomases

On Mar 27, 2013, at 3:31 PM, Ken Thomases wrote: > dlls/winemac.drv/macdrv.h | 12 +++++++++++- > dlls/winemac.drv/surface.c | 16 ++++++++++++++-- > dlls/winemac.drv/window.c | 17 ++--------------- > 3 files changed, 27 insertions(+), 18 deletions(-) > > <0001-winemac-Track-drawn-surface-rect-to-reduce-black-fli.patch> Please don't commit this. I've thought of a different approach. -Ken

March 28, 2013

Re: user32: ImmProcessKey is only called on WM_KEYDOWN and if the message is being removed

by André Hentschel

Am 28.03.2013 14:41, schrieb Aric Stewart: > On 3/28/13 8:10 AM, Dmitry Timoshkov wrote: >> Aric Stewart <aric(a)codeweavers.com> wrote: >> >>>>> Worked out with testing on Japanese windows XP. Resolves issues with >>>>> keystrokes and accelerators in menus when the IME is active. >>>> >>>> You should really start adding the tests and base your patches on test >>>> results instead of some sort of speculation. >>>> >>> I would love to add tests. But things like this require enough parts of >>> things working in such a way that it was very hard if not impossible for >>> me to think of a way to do it through an automated test for wine, let >>> alone one that would run for windows. >> >> So, you admit that your IME patches are just a guesswork, i.e. you have >> zero number of automated tests to check another guess? That's really >> confusing. >> > > No. They are not guesswork. > > I wrote _interactive_ tests that I used on my windows machine to prove the behavior and this patch. It am was unable to make _automated_ tests that will in any meaningful way test the behavior. I just want to mention at this point that there is a interactive mode for winetest: export WINETEST_INTERACTIVE=1 should do it...

March 28, 2013

Re: user32: ImmProcessKey is only called on WM_KEYDOWN and if the message is being removed

by Aric Stewart

On 3/28/13 8:10 AM, Dmitry Timoshkov wrote: > Aric Stewart <aric(a)codeweavers.com> wrote: > >>>> Worked out with testing on Japanese windows XP. Resolves issues with >>>> keystrokes and accelerators in menus when the IME is active. >>> >>> You should really start adding the tests and base your patches on test >>> results instead of some sort of speculation. >>> >> I would love to add tests. But things like this require enough parts of >> things working in such a way that it was very hard if not impossible for >> me to think of a way to do it through an automated test for wine, let >> alone one that would run for windows. > > So, you admit that your IME patches are just a guesswork, i.e. you have > zero number of automated tests to check another guess? That's really > confusing. > No. They are not guesswork. I wrote _interactive_ tests that I used on my windows machine to prove the behavior and this patch. It am was unable to make _automated_ tests that will in any meaningful way test the behavior. -aric

March 28, 2013

Re: user32: ImmProcessKey is only called on WM_KEYDOWN and if the message is being removed

by Dmitry Timoshkov

Aric Stewart <aric(a)codeweavers.com> wrote: > >> Worked out with testing on Japanese windows XP. Resolves issues with > >> keystrokes and accelerators in menus when the IME is active. > > > > You should really start adding the tests and base your patches on test > > results instead of some sort of speculation. > > > I would love to add tests. But things like this require enough parts of > things working in such a way that it was very hard if not impossible for > me to think of a way to do it through an automated test for wine, let > alone one that would run for windows. So, you admit that your IME patches are just a guesswork, i.e. you have zero number of automated tests to check another guess? That's really confusing. -- Dmitry.

March 28, 2013

Re: user32: ImmProcessKey is only called on WM_KEYDOWN and if the message is being removed

by Aric Stewart

On 3/27/13 9:25 PM, Dmitry Timoshkov wrote: > Aric Stewart <aric(a)codeweavers.com> wrote: > >> Worked out with testing on Japanese windows XP. Resolves issues with >> keystrokes and accelerators in menus when the IME is active. > > You should really start adding the tests and base your patches on test > results instead of some sort of speculation. > I would love to add tests. But things like this require enough parts of things working in such a way that it was very hard if not impossible for me to think of a way to do it through an automated test for wine, let alone one that would run for windows. -aric

March 28, 2013

Re: winemac: Null-terminate an snprintf-ed key name buffer in case of short buffer.

by Ken Thomases

On Mar 28, 2013, at 2:26 AM, Per Johansson wrote: > On Wed, Mar 27, 2013 at 7:22 PM, Ken Thomases <ken(a)codeweavers.com> wrote: >> --- > > This has probably been discussed before, but shouldn't snprintfW be > safe against this kind of thing, the way POSIX snprintf is? I actually checked the man page for snprintf() when I originally wrote that code, which is why I assumed snprintfW() would terminate it. So, my vote is for "yes". :) -Ken

March 28, 2013

Re: winemac: Null-terminate an snprintf-ed key name buffer in case of short buffer.

by Per Johansson

On Wed, Mar 27, 2013 at 7:22 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > --- This has probably been discussed before, but shouldn't snprintfW be safe against this kind of thing, the way POSIX snprintf is? Regards, -- Per Johansson

March 28, 2013

Re: user32: ImmProcessKey is only called on WM_KEYDOWN and if the message is being removed

by Dmitry Timoshkov

Aric Stewart <aric(a)codeweavers.com> wrote: > Worked out with testing on Japanese windows XP. Resolves issues with > keystrokes and accelerators in menus when the IME is active. You should really start adding the tests and base your patches on test results instead of some sort of speculation. -- Dmitry.

March 28, 2013

RE: Linker error when improving GetLargestConsoleWindowSize

by Hugh McMaster

-----Original Message----- From: Eric Pouech [mailto:eric.pouech(a)orange.fr] Sent: Wednesday, 27 March 2013 8:54 AM To: wine-devel(a)winehq.org Subject: Re: Linker error when improving GetLargestConsoleWindowSize Ken Thomases wrote: >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 Eric Pouech wrote: >> actually the correct fix would be to transfer this computation to wineconsole (which already imports user32), but thats' not a really trivial task So, if wineconsole imports user32 to run console programs, that explains why a generic program using SystemParametersInfo or GetSystemMetrics is able to compile and run correctly, yes? For example: --- #include <windows.h> #include <winuser.h> #include <stdio.h> main(void) { RECT workarea; SystemParametersInfo(SPI_GETWORKAREA, 0, &workarea, 0); int screen_x = workarea.right; int screen_y = workarea.bottom; printf("Your screen resolution is %d x %d pixels.\n", screen_x, screen_y); } --- Anyway, if I understand you correctly, the computations would need to be moved to programs/wineconsole (wineconsole.c). Hugh

March 28, 2013

Re: [1/3] kernel32: Set GetLargestConsoleWindowSize based on screen resolution

by Ken Thomases

On Mar 27, 2013, at 6:08 PM, Hugh McMaster wrote: > Ken Thomases wrote: > >>> This approach is untenable. Kernel32 can't be made to depend on X11. It has to still work when X11 isn't available. Also, X11 is just one possible graphics/windowing system that Wine can use, so it's not always the right authority to consult about screen size. > > A fair point. I hadn't considered that windowing systems such as XFree86 were still in use. I'm too used to using distributions running X11. More to the point, Wine doesn't necessarily use any variant of the X Window System. On Mac OS X, it can use the Mac driver. Other drivers are being investigated. >>> Finally, your patch series is broken in the sense that each patch in the series must still be able to compile. You introduce a dependency on screensize.c in the first patch but don't actually provide that source file until the third. > > So patches are applied one by one and then tested? Yes. > I thought patches in a series were applied at the same time. No. A series is used to indicate that later patches can't be applied before the earlier ones. That is, for example, patch 2 requires that patch 1 already was applied before it can be successfully applied. "Successfully applied" means all of: the patch applies, Wine builds, and tests succeed (at least as well as before). Regards, Ken

March 27, 2013