wine-devel May 2013

wine-devel@winehq.org

77 participants
183 discussions

Re: [PATCH 2/2] user32/tests: Test that sending WM_CANCELMODE cancels tracking in window's menu bar.
by Dmitry Timoshkov 17 May '13

17 May '13

Ken Thomases <ken(a)codeweavers.com> wrote: > dlls/user32/tests/menu.c | 21 ++++++++++++++++++++- Please add a message test instead, it would much more clearer show what is going on. > + {MSG msg; while (PeekMessage(&msg, 0, 0, 0, PM_REMOVE)) DispatchMessage(&msg);} Please avoid creating such embedded blocks. -- Dmitry.

2 2

Re: winemac.drv: add fullscreen mode support for Mac OS X 10.7+
by Ken Thomases 16 May '13

16 May '13

Hi Kevin, I'm bringing this back to wine-devel. Please CC the list unless you intend to take things private, in which case please say so. On May 10, 2013, at 6:48 PM, Kevin Eaves wrote: > I should have made everything clear, sorry. It was for personal use, so it's pretty nasty, but works great. The only real problem is with user32. Everything else is easy to clean up and get working with Wine properly without any issues. Just wanted to show that. Sure, that's what I figured. > On May 9, 2013, at 9:56 PM, Ken Thomases wrote: > >>> The fullscreen button appears if a main window is resizable. >> >> We may want to narrow this down a bit. For example, the common file dialogs are resizable, but probably shouldn't be full-screen-enabled. Perhaps no owned window should be. > > Only windows in the windows cycle should be fullscreen enabled. If the window can be manually moved to its own space, then it should be able to go fullscreen. No dialogs are enabled. These follow the main window to spaces. If in Cocoa fullscreen, the new window automatically opens fullscreen in its own space. Everything works just like Mac applications with this setting. Ah, I failed to notice before that the use of NSWindowCollectionBehaviorFullScreenPrimary was only in the same code path as NSWindowCollectionBehaviorParticipatesInCycle. Yes, that makes sense. >> From cocoa_window.m.diff: >> >>> +#import <Cocoa/Cocoa.h> >> >> >> Was that actually needed? cocoa_window.h already imports <AppKit/AppKit.h>. >> >> ... >> >>> + if (style & NSResizableWindowMask) >>> + [[self standardWindowButton:NSWindowZoomButton] setEnabled:!self.disabled]; > > These should have not been included in the diff. It's unrelated to Cocoa fullscreen, however, the zoom button is currently bugged. It is not disabled when the window is disabled. To reproduce the problem: launch regedit, open the import window, and click the zoom button on the main window. I sent a patch for it. I'm not seeing that problem happen here. Mind you, I'm currently testing on 10.6. I'll have to run some tests on 10.7+ tomorrow. I find it improbable that removing NSResizableWindowMask from the style doesn't disable the zoom button. That style is the only thing which enables the zoom button to begin with. In other words, in a normal Mac app, one would not need to disable the zoom button separately. >>> - if (captured || fullscreen) >>> + if (captured || (fullscreen && !(normalStyleMask & NSResizableWindowMask))) >> >> You're trying to distinguish between a window that was full-screened at the instigation of the Windows program versus one which has been full-screened by Cocoa, right? Hmm. I think we need a better technique to determine that. I agree that it's not likely the Windows program would make its window full-screen while still allowing it to be resized but it feels wrong to assume that. >> >> Also, I think we can entirely avoid setting the window level for windows that have been Cocoa full-screened. Setting the window level is mostly about relationship to other windows, but a Cocoa full-screen window should be on a space by itself, shouldn't it? >> >>> + else if ([self styleMask] & NSFullScreenWindowMask) >>> + level = NSMainMenuWindowLevel + 2; >> >> I'm not following why Cocoa full-screened windows should be at +2 vs. +1. > > The window levels are automatically adjusted and the menu is in a hover state. We need to prevent the menu from being hidden, and hide the menu if the Windows program goes fullscreen while in Cocoa fullscreen (+1 doesn't cut it). I'm going to have to do some testing to understand this, too. NSMainMenuWindowLevel should be in the same level as the menu (meaning could be above or below due to normal window ordering operations). NSMainMenuWindowLevel + 1 should always be above the menu, regardless. NSMainMenuWindowLevel + 2 should not be necessary. But maybe something weird is going on. Also, if the Windows program changes a window from resizable to non-resizable, then we should probably pull the window out of Cocoa fullscreen. The Windows program _may_ have intended to make the window full-screen but we can't know that. It may simply be changing the window style for some other purpose, and that may make it no longer a candidate for Cocoa full-screen mode. >>> + - (NSSize)window:(NSWindow *)window willUseFullScreenContentSize:(NSSize)proposedSize >>> + { >>> + return NSMakeSize(proposedSize.width, proposedSize.height); >>> + } >> >> Is this actually needed? I assume that's the default behavior when the delegate method is absent. (Also, if it is necessary, it can just return proposedSize without making a new size struct.) > > This little gem will resize ANY window — non-resizable, disabled, a dialog box... Add this and poof!! There is no reason to ever disable Cocoa fullscreen. Mac applications don't so neither should Wine. I disagree. Windows programs that are not expecting their window to resize (because they haven't made them resizable) can misbehave badly if the window does resize. Just because that didn't happen in your testing doesn't mean it won't. As you mentioned in your original email, Cocoa full-screen is roughly akin to window resizing. So, it should be disabled if/when the window is made non-resizable. > I haven't tested this enough with non-resizable windows, but it is possible to resize any window. I don't follow this. It is possible to resize any window even non-resizable ones? To what are you referring? Possible how? Do you mean specifically just with this full-screen patch? > I use this feature to resize a few non-resizable game windows. Maybe add a registry key to allow non-resizable windows to go fullscreen. Perhaps. Cheers, Ken

2 2

Re: [PATCH 1/6] fonts: Add default glyph to Tahoma.
by Alexandre Julliard 16 May '13

16 May '13

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > --- > fonts/tahoma.sfd | 94 +++++++++++++++++++++++++++++------------------------- > fonts/tahoma.ttf | Bin 100420 -> 97836 bytes > 2 files changed, 50 insertions(+), 44 deletions(-) We already have .notdef, we shouldn't need a second one. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: configure: try to use -Werror=unknown-warning-option if available (2/2)
by Alexandre Julliard 16 May '13

16 May '13

Austin English <austinenglish(a)gmail.com> writes: > @@ -1773,6 +1773,7 @@ then > fi > > dnl Check for some compiler flags > + WINE_TRY_CFLAGS([-Werror=unknown-warning-option]) > WINE_TRY_CFLAGS([-fno-builtin],[AC_SUBST(BUILTINFLAG,"-fno-builtin")]) > WINE_TRY_CFLAGS([-fno-strict-aliasing]) > WINE_TRY_CFLAGS([-Wdeclaration-after-statement]) I don't think we want to build with that, it should be used only for the configure checks. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: vbscript: Round half to even in to_int.
by Marvin 16 May '13

16 May '13

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=25581 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP2 (32 bit) === No test summary line found === WXPX64 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAX64 (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === WXPX64 (64 bit) === No test summary line found === WVISTAX64 (64 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Participate in GSoC
by Adam Chyła 16 May '13

16 May '13

Hi all, I'm a student who would like to participate in GSoC with task "Tools - Winetest Graphical User Interface". What should I do? Adam Ch.

2 1

Re: WM_IME_REQUEST gets passed into ImmIsUIMessage
by Alexandre Julliard 15 May '13

15 May '13

Aric Stewart <aric(a)codeweavers.com> writes: > --- > dlls/imm32/imm.c | 2 ++ > dlls/user32/defwnd.c | 19 +++++++++++++++++++ > dlls/winemac.drv/ime.c | 34 ++++++++++++++++++++++++++++++++++ > dlls/winex11.drv/ime.c | 34 ++++++++++++++++++++++++++++++++++ > 4 files changed, 89 insertions(+) It breaks the tests: ../../../tools/runtest -q -P wine -M imm32.dll -T ../../.. -p imm32_test.exe.so imm32.c && touch imm32.ok imm32.c:580: Test failed: ImmIsUIMessageA returned 1 for 288 imm32.c:584: Test failed: ImmIsUIMessageA returned 1 for 288 make: *** [imm32.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 4/6] wined3d: Use d3d_level_from_gl_info in match_dx10_capable
by Henri Verbeet 15 May '13

15 May '13

On 14 May 2013 23:46, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -613,14 +635,7 @@ static BOOL match_apple_nonr500ati(const struct wined3d_gl_info *gl_info, const > static BOOL match_dx10_capable(const struct wined3d_gl_info *gl_info, const char *gl_renderer, > enum wined3d_gl_vendor gl_vendor, enum wined3d_pci_vendor card_vendor, enum wined3d_pci_device device) > { > - /* DX9 cards support 40 single float varyings in hardware, most drivers report 32. ATI misreports > - * 44 varyings. So assume that if we have more than 44 varyings we have a dx10 card. > - * This detection is for the gl_ClipPos varying quirk. If a d3d9 card really supports more than 44 > - * varyings and we subtract one in dx9 shaders its not going to hurt us because the dx9 limit is > - * hardcoded > - * > - * dx10 cards usually have 64 varyings */ > - return gl_info->limits.glsl_varyings > 44; > + return d3d_level_from_gl_info(gl_info) >= 10; > } > I'm not sure d3d_level_from_gl_info() is quite reliable enough for this. For example, Mesa doesn't implement EXT_gpu_shader4, and possibly never will. Using an actual hardware limit seems more reliable.

1 0

Re: [PATCH 5/6] d3d: d3d9ex does not do video memory accounting for D3DPOOL_DEFAULT resources
by Henri Verbeet 15 May '13

15 May '13

On 14 May 2013 23:46, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -922,6 +922,8 @@ enum wined3d_display_rotation > #define WINED3DCREATE_DISABLE_DRIVER_MANAGEMENT 0x00000100 > #define WINED3DCREATE_ADAPTERGROUP_DEVICE 0x00000200 > > +#define WINED3DCREATE_NO_VIDMEM_ACCOUNTING 0x10000000 > + I think it makes more sense to make this a wined3d_create() flag, and in invert it, since we also want this for d3d10+. E.g. something along the lines of WINED3D_NO_GPU_VMM.

1 0

Wacom Graphire3 tablet not detected as tablet (MacOSX 10.8)
by Andrey Upadyshev 14 May '13

14 May '13

Hi, I have Wacom Graphire3 tablet and it's working well under Windows, MacOS or MacOS + X (Inkscape). But Wine can't detect it as tablet and disables the wintab support. The actual stylus device is Device 6 [id 8|name pen|type |num_classes 2|use 4], but log says it is not apparently a tablet cursor type device. There is a wintab log: > trace:wintab32:DllMain 0x43d60000, 1, 0x0 > trace:wintab32:DllMain Initialization > trace:wintab32:TABLET_WindowProc Incoming Message 0x81 (0x00000000, > 0x0032f6b0) > trace:wintab32:TABLET_WindowProc Incoming Message 0x83 (0x00000000, > 0x0032f400) > trace:wintab32:TABLET_WindowProc Incoming Message 0x1 (0x00000000, > 0x0032f6b0) > trace:wintab32:TABLET_WindowProc Incoming Message 0x5 (0x00000000, > 0x00000000) > trace:wintab32:TABLET_WindowProc Incoming Message 0x3 (0x00000000, > 0x00000000) > trace:wintab32:LoadTablet Initializing the tablet to hwnd 0x10126 > trace:wintab32:X11DRV_LoadTabletInfo XListInputDevices reports 9 devices > trace:wintab32:X11DRV_LoadTabletInfo Device 0: [id 2|name Virtual core > pointer|type |num_classes 2|use 0] > trace:wintab32:X11DRV_LoadTabletInfo Device 1: [id 3|name Virtual core > keyboard|type |num_classes 1|use 1] > trace:wintab32:X11DRV_LoadTabletInfo Device 2: [id 4|name Virtual core > XTEST pointer|type |num_classes 2|use 4] > trace:wintab32:X11DRV_LoadTabletInfo Is XExtension: Device, Keyboard, or > Pointer > warn:wintab32:X11DRV_LoadTabletInfo Skipping device 2 [name Virtual core > XTEST pointer|type ]; not apparently a tablet cursor type device. If this > is wrong, please report it to wine-devel(a)winehq.org > trace:wintab32:X11DRV_LoadTabletInfo Device 3: [id 5|name Virtual core > XTEST keyboard|type |num_classes 1|use 3] > trace:wintab32:X11DRV_LoadTabletInfo Is XExtension: Device, Keyboard, or > Pointer > trace:wintab32:X11DRV_LoadTabletInfo No buttons, Non Tablet Device > trace:wintab32:X11DRV_LoadTabletInfo Device 4: [id 6|name xquartz virtual > pointer|type |num_classes 2|use 4] > trace:wintab32:X11DRV_LoadTabletInfo Is XExtension: Device, Keyboard, or > Pointer > warn:wintab32:X11DRV_LoadTabletInfo Skipping device 4 [name xquartz > virtual pointer|type ]; not apparently a tablet cursor type device. If > this is wrong, please report it to wine-devel(a)winehq.org > trace:wintab32:X11DRV_LoadTabletInfo Device 5: [id 7|name xquartz virtual > keyboard|type |num_classes 1|use 3] > trace:wintab32:X11DRV_LoadTabletInfo Is XExtension: Device, Keyboard, or > Pointer > trace:wintab32:X11DRV_LoadTabletInfo No buttons, Non Tablet Device > trace:wintab32:X11DRV_LoadTabletInfo Device 6: [id 8|name pen|type > |num_classes 2|use 4] > trace:wintab32:X11DRV_LoadTabletInfo Is XExtension: Device, Keyboard, or > Pointer > warn:wintab32:X11DRV_LoadTabletInfo Skipping device 6 [name pen|type ]; > not apparently a tablet cursor type device. If this is wrong, please > report it to wine-devel(a)winehq.org > trace:wintab32:X11DRV_LoadTabletInfo Device 7: [id 9|name cursor|type > |num_classes 2|use 4] > trace:wintab32:X11DRV_LoadTabletInfo Is XExtension: Device, Keyboard, or > Pointer > trace:wintab32:X11DRV_LoadTabletInfo ButtonInput 0: [class 1|length > 12|num_buttons 3] > trace:wintab32:X11DRV_LoadTabletInfo ValidatorInput 1: [class 2|length > 80|num_axes 5|mode 1|motion_buffer 256] > trace:wintab32:trace_axes Axis 0: [resolution 1|min_value > 0|max_value 65536] > trace:wintab32:trace_axes Axis 1: [resolution 1|min_value > 0|max_value 65536] > trace:wintab32:trace_axes Axis 2: [resolution 1|min_value > 0|max_value 65536] > trace:wintab32:trace_axes Axis 3: [resolution 1|min_value > -65536|max_value 65536] > trace:wintab32:trace_axes Axis 4: [resolution 1|min_value > -65536|max_value 65536] > trace:wintab32:X11DRV_LoadTabletInfo Device 8: [id 10|name eraser|type > |num_classes 2|use 4] > trace:wintab32:X11DRV_LoadTabletInfo Is XExtension: Device, Keyboard, or > Pointer > trace:wintab32:X11DRV_LoadTabletInfo ButtonInput 0: [class 1|length > 12|num_buttons 3] > trace:wintab32:X11DRV_LoadTabletInfo ValidatorInput 1: [class 2|length > 80|num_axes 5|mode 1|motion_buffer 256] > trace:wintab32:trace_axes Axis 0: [resolution 1|min_value > 0|max_value 65536] > trace:wintab32:trace_axes Axis 1: [resolution 1|min_value > 0|max_value 65536] > trace:wintab32:trace_axes Axis 2: [resolution 1|min_value > 0|max_value 65536] > trace:wintab32:trace_axes Axis 3: [resolution 1|min_value > -65536|max_value 65536] > trace:wintab32:trace_axes Axis 4: [resolution 1|min_value > -65536|max_value 65536] > warn:wintab32:X11DRV_LoadTabletInfo Did not find a valid stylus, unable to > determine system context parameters. Wintab is disabled. > It would be great if someone can fix this problem. Thank you, Andrey Upadyshev

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
19
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 May 2013