wine-bugs March 2011

wine-bugs@winehq.org

1 participants
8631 discussions

[Bug 6971] Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE
by wine-bugs＠winehq.org 09 Mar '11

09 Mar '11

http://bugs.winehq.org/show_bug.cgi?id=6971 --- Comment #442 from Michael Abbott <michael(a)araneidae.co.uk> 2011-03-09 08:54:42 CST --- (In reply to comment #441) > (In reply to comment #440) > > Is it possible for this patch to be modified so that the mouse is warped back > > into the application window, at least when the application thinks it's running > > full screen? > I guess that mouse warping is not failproof and moreover it's breaking apps > that do not need it at all. Vitaliy commented before that "any real solution > should not warp mouse". I've no good idea how to solve this problem. The mouse goes wandering all over the screen, and it's very easy to end up giving the focus away. The problem only arises, I guess, when the application thinks it's full screen but is being run in a virtual desktop. Is there some way for the application to gain exclusive capture of mouse events so that mouse clicks don't get sent to other applications? Of course, this would mean that it's *impossible* to click away from the application, you'd have to use a desktop manager key binding (eg Alt-Tab). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 6971] Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE
by wine-bugs＠winehq.org 09 Mar '11

09 Mar '11

http://bugs.winehq.org/show_bug.cgi?id=6971 --- Comment #441 from Valeriy Malov <jazzvoid(a)gmail.com> 2011-03-09 06:45:26 CST --- (In reply to comment #440) > Is it possible for this patch to be modified so that the mouse is warped back > into the application window, at least when the application thinks it's running > full screen? I guess that mouse warping is not failproof and moreover it's breaking apps that do not need it at all. Vitaliy commented before that "any real solution should not warp mouse". -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 6971] Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE
by wine-bugs＠winehq.org 09 Mar '11

09 Mar '11

http://bugs.winehq.org/show_bug.cgi?id=6971 --- Comment #440 from Michael Abbott <michael(a)araneidae.co.uk> 2011-03-09 06:13:43 CST --- Is it possible for this patch to be modified so that the mouse is warped back into the application window, at least when the application thinks it's running full screen? If you run a program with this patch which relies on the current behaviour in a virtual desktop which doesn't cover the entire Linux desktop then while the cursor is outside the application window mouse key presses are being sent to outside windows or the desktop. This can end up triggering all sorts of accidents if you're not paying attention! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org 09 Mar '11

09 Mar '11

http://bugs.winehq.org/show_bug.cgi?id=2082 --- Comment #78 from Saulius K. <saulius2(a)gmail.com> 2011-03-09 00:24:22 CST --- Hello folks. Lets transfer talks on the hacky patch to the AppDB. This is bugreport and only technical details _related to the bug directly_ are interesting here. So please stop talking about workarounds. There are only 20 usefull comments (at most) in this report. Please keep the noise lower :) Thank you :) Now the tech-details. Vincent Povirk and Jesse Allen have investigated on the bug. Jesse has made a standalone and interactive test-case: http://bugs.winehq.org/show_bug.cgi?id=4009#c27 It would be nice to transform it into autonomous WRT block. Though I am not sure about the way to read and interpret the resulting image (to make difference between bug and normal case). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 26227] New: GetClipboardFormatName() / RegisterWindowsMessage(): thoroughly incompatible implementation
by wine-bugs＠winehq.org 09 Mar '11

09 Mar '11

http://bugs.winehq.org/show_bug.cgi?id=26227 Summary: GetClipboardFormatName() / RegisterWindowsMessage(): thoroughly incompatible implementation Product: Wine Version: 1.3.14 Platform: x86 OS/Version: All Status: NEW Severity: normal Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: andi(a)rhlx01.fht-esslingen.de GetClipboardFormatName() / RegisterWindowsMessage() and related APIs are said to map to identical functions (RVAs) in Windows. In Wine, we have individual USER drivers (winex11.drv etc), and they do their _own_ (even non-ATOM) clipboard format handling. And RegisterWindowsMessage() uses GlobalAddAtom() which is said to be WRONG, too. "Registered Window Message String", http://www.eggheadcafe.com/software/aspnet/30695961/registered-window-messa… clarifies it: both APIs are _identical_, and they make use of _another_ _internal_ ATOM table. I.e., there's the application-global (NULL HINSTANCE?) atom table, application-local (per-HINSTANCE?), and this _system-internal_ table _common_ to both clipboard/messages. Conclusion: incompatibilities abound (and that in a situation where Google "RegisterWindowMessage GetClipboardFormatName" shows 1850 results, IOW a very widely known undocumented Windows behaviour). If correcting the implementation is deemed less urgent, then perhaps it's useful to add a corresponding comment at a prominent place, hinting at these implementation specifics (should probably reference this bug#). HTH, Andreas -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 4

[Bug 6971] Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE
by wine-bugs＠winehq.org 08 Mar '11

08 Mar '11

http://bugs.winehq.org/show_bug.cgi?id=6971 --- Comment #439 from Dan Kegel <dank(a)kegel.com> 2011-03-08 15:41:24 CST --- Created an attachment (id=33574) --> (http://bugs.winehq.org/attachment.cgi?id=33574) Rediffed to apply to today's git -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org 08 Mar '11

08 Mar '11

http://bugs.winehq.org/show_bug.cgi?id=2082 Manuel Soukup <linuxuser-sky(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |linuxuser-sky(a)gmx.de --- Comment #77 from Manuel Soukup <linuxuser-sky(a)gmx.de> 2011-03-08 15:18:14 CST --- This is still an issue with Diablo 1 and wine 1.3.15 Using the Worms World Party fix for wine 1.2 (2.90 KB, patch) and the wine source od 1.2.2 does fix it but you have to change the stuff manualy cause because of version mismatch patch does not work. The patch does not work on recent wine source (1.3.15) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 421] Implement a DIB engine
by wine-bugs＠winehq.org 08 Mar '11

08 Mar '11

http://bugs.winehq.org/show_bug.cgi?id=421 --- Comment #414 from max(a)veneto.com 2011-03-08 04:05:59 CST --- Hi all :-) About Chen Minqiang comments : 1) the DIB engine won't be accepted, in particular if embedded in winex11.drv. This has already been discussed thousands of times. 2) Embedding it in winex11.drv would mean to rebase it on EVERY wine change; summed with point 1 would mean an huge work for the maintainer, and I don't have time anymore for it. 3) About the bugs : last time I tested it, winedib.drv passed MORE tests than original winex11 alone. That said, the code is fully and extensively commented (even too much, on some people's opinion...), so if you want to fix some bugs, you're wellcome. As I said some time ago, I don't have much time anymore to fix them and, as it would be never included in official wine, it's almost an useless task. 4) winedib code is NOT based on old source code; it's a "bridge" between gdi and winex11 and, besides some very late changes, is up to date with wine codebase; by design it will be so for long time, besides the need to rebase configure.ac file from time to time. That said, if somebody wants to take the task of rewriting it from scratch he's *very* wellcome :-) Ciao Max -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 421] Implement a DIB engine
by wine-bugs＠winehq.org 08 Mar '11

08 Mar '11

http://bugs.winehq.org/show_bug.cgi?id=421 Michel Nolard <michel.nolard(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michel.nolard(a)gmail.com --- Comment #413 from Michel Nolard <michel.nolard(a)gmail.com> 2011-03-08 04:01:25 CST --- Hi Chen, Not criticisms, just questions to be sure we don't miss the target : - what about the MacOS X guys who do not have X11 installed ? - what performances will it provide under Wayland (nearly compatible X11 replacement in future distros) By the way, I am using neither of those yet. Michel Nolard -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 26351] New: Mouse wheel no longer works in City of Heroes
by wine-bugs＠winehq.org 08 Mar '11

08 Mar '11

http://bugs.winehq.org/show_bug.cgi?id=26351 Summary: Mouse wheel no longer works in City of Heroes Product: Wine Version: 1.3.15 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: mark+winebugs(a)carnildo.com City of Heroes no longer responds to mouse wheel input. Steps to reproduce: 1) Log in to CoH. 2) Scroll the mousewheel up and down. Expected result: Camera zooms in and out. Actual result: Nothing happens. This isn't restricted to camera zoom, it's just the easiest way to test it. Other uses of the mousewheel (eg. scrolling through lists) are also broken. This is a regression from WINE 1.3.14. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 4

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-bugs March 2011