http://bugs.winehq.org/show_bug.cgi?id=34282
Bug #: 34282
Summary: AppDB App for Wine
Product: WineHQ Apps Database
Version: unspecified
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: appdb-unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: shatteredlites(a)gmail.com
Classification: Unclassified
Ok It just came to mind that there should be a app for wine that keeps track of
the AppDB and its games and this is my Idea and what it could do...
When wine is running you will be asked whether or not to send info as in- game
logs and debug info and system info without compromising privacy that is. and
while this app runs it would do a search in AppDB on what game you're using and
what settings are recommended for it as well as patches for it and so on. The
info that is being sent while ingame can be monitored by the game maintainer in
Appdb to check for bugs or regressions.
what do yall think and how would I go about asking for an enhancement like
this?
EXTRA INFO
Requirements To Work
-AppDB Game Needs A Maintainer
-AppDB Games Need Constant Watch To Keep Track Of Regressions & Bugs
Pros & Cons
Pro- Games Will Automatically Apply Fixes When Needed
Pro- Bugs Could Automatically Be Sent To Bugzilla With Info Already In Report
Pro- Less Hassle For Devs & Users
Con- More Dedicated Devs Needed To Keep DB In Order
Con- A New Project That Will Take Time
Con- WineHQ Will Go Through Changes In Order To Work With Program
--
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.
http://bugs.winehq.org/show_bug.cgi?id=6941
--- Comment #14 from Bruno Jesus <00cpxxx(a)gmail.com> ---
Still in wine 1.7.9. It blocks in a recv call in an IPX socket, I'll try to
find out what is happening when I have time.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=23940
Summary: SetWindowPos does not work for other wine processes
Product: Wine
Version: unspecified
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: user32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: jUrner(a)arcor.de
resizing windows belonging to other (wine) processes does not work. user32.dll
SetWindowPos() always returns 0.
somewhere down in winpos.c set_window_pos() returns FALSE
wine 1.2
--
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.
http://bugs.winehq.org/show_bug.cgi?id=5402
Anastasius Focht <focht(a)gmx.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|patch |
URL|http://www.wolflair.com/rig |http://www.minisiteg.narod.
|htframe.php?context=army_bu |ru/Canon/PhotoStitch311332.
|ilder&page=downloads |rar
Summary|Multiple apps crash (e.g. |Canon PhotoStitch 3.1.13
|PhotoStitch 3.1, Army |crashes on startup
|Builder, Web Builder....) |
--- Comment #37 from Anastasius Focht <focht(a)gmx.net> ---
Hello folks,
still present.
--- snip ---
...
0009:Ret user32.CreateWindowExA() retval=00010076 ret=5f40c211
0009:Call user32.GetActiveWindow() ret=5f4013c8
0009:Ret user32.GetActiveWindow() retval=00000000 ret=5f4013c8
0009:trace:seh:raise_exception code=c0000005 flags=0 addr=0x42e81e ip=0042e81e
tid=0009
0009:trace:seh:raise_exception info[0]=00000000
0009:trace:seh:raise_exception info[1]=00000138
0009:trace:seh:raise_exception eax=00000000 ebx=0033e24c ecx=0033e20c
edx=00000386 esi=0019e6d0 edi=0019e3f8
0009:trace:seh:raise_exception ebp=00000000 esp=0033e1f4 cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00010246
--- snip ---
ArmyBuilder 3.1 (http://www.wolflair.com/download/ab/ab31c_install.exe) also
referenced in this bug works fine which indicates it suffered from bug 19052
'WYSIWYG Web Builder 5.5.x' (http://3dwebdesign.org/download/webbuilder5.zip)
also works fine indicating it suffered from bug 19052
Refining summary and replacing download with old version of PhotoStitch 3.1.13
$ sha1sum PhotoStitch311332.rar
02856a422d6d57eb2c6694463f422852a7c653e5 PhotoStitch311332.rar
$ du -sh PhotoStitch311332.rar
4.0M PhotoStitch311332.rar
$ wine --version
wine-1.7.9-158-g33fa552
Regards
--
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.
http://bugs.winehq.org/show_bug.cgi?id=2082
--- Comment #128 from Vincent Povirk <madewokherd(a)gmail.com> ---
> The ultimate result is that dialog D obscures window A. I haven't
> investigated why dialog D is all black as opposed to looking like a typical
> user32 dialog window with controls.
This is because (on Windows, at least before compositing was introduced and
before Windows 8), although ddraw will ignore clipping and draw over other
windows, it does not prevent those other windows from also drawing. To prevent
ddraw from fighting user32 and causing flicker, WA intentionally prevents the
dialog from drawing (on older versions that prevention was flawed and you'd
sometimes get flicker anyway, but they may have fixed that). It happens that WA
does not need to do any gdi drawing at all, but other programs use clipping to
mix ddraw with gdi, and there may be a few that do not use clipping but instead
manually synchronize ddraw and gdi drawing (diablo maybe?).
--
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.
http://bugs.winehq.org/show_bug.cgi?id=2082
Stefan Dösinger <stefan(a)codeweavers.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |stefan(a)codeweavers.com
--- Comment #127 from Stefan Dösinger <stefan(a)codeweavers.com> ---
d3d8/9 drawing to the desktop window is not valid, unless D3DDEVTYPE_NULLREF is
used. Which is what some applications do, and we don't implement NULLREF and
just treat it as HAL.
I believe we have tests that demonstrate that opengl rendering on the desktop
window is not valid on Windows. I might be mistaken though, I haven't checked
the code.
I'm not entirely sure about the ddraw behavior. This needs some additional
tests for clippers. Specifically we'll have to check what clippers do in
fullscreen mode, and if clippers affect primary surface locks (and not just
blits). The current behavior is to render to the clipper window if a clipper is
assigned to the primary, and it has a clip window and not a clip list.
What may be the correct behavior:
*) Always render to the device window, which is NULL by default unless the
application explicitly sets it with SetCoopLevel(DDSCL_SETDEVICEWINDOW) or asks
ddraw to create one with SetCoopLevel(DDSCL_CREATEDEVICEWINDOW). I think
SetCoopLevel(window, FULLSCREEN | EXCLUSIVE) just sets the focus window, not
the device window.
*) Never render to the clipper window.
*) Use the clipper window only in surface::blt to limit the written area.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=2082
--- Comment #126 from Ken Thomases <ken(a)codeweavers.com> ---
Created attachment 46977
--> http://bugs.winehq.org/attachment.cgi?id=46977
Use desktop window for fullscreen ddraw, with support in Mac driver
This is a hack that a) makes ddraw target the desktop window when
DDSCL_FULLSCREEN is specified and doesn't treat it differently from other
windows; and b) adds support in the Mac driver for doing OpenGL on the desktop
window.
This allows Worms Armageddon to work with the Mac driver without its
Wine-specific tweaks. It's sort of a proof of concept of the plan I mentioned
in my last reply.
NOTE: This will not work with the X11 driver because it doesn't have support
for doing OpenGL on the desktop window. (The X11 driver actually has code
specifically to reject attempts to do so, as did the Mac driver before this
hack.) The ddraw hacks will actually break the ability of the X11 driver to
run WA when its tweaks are active.
I also don't expect this to work with DirectDrawRenderer=gdi.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=2082
Ken Thomases <ken(a)codeweavers.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ken(a)codeweavers.com
--- Comment #125 from Ken Thomases <ken(a)codeweavers.com> ---
I've been looking into this bug as it affects Worms Armageddon. That game has
built-in Wine-specific tweaks to work around the problem, but they don't work
with the Mac driver because the Mac driver doesn't support a virtual desktop
window. For testing purposes, I'm using the X11 driver with WA's tweaks
disabled.
I'm going to summarize what I have found (which has also been demonstrated by
some of the test cases):
* WA creates window A.
* WA creates a dialog window D, which is owned by window A. This has sometimes
been described as a child window but it's not. It's a top-level window. Being
owned by window A means that it is kept in front of window A.
* The dialog D has various controls, including buttons, etc.
* WA calls IDirectDraw::SetCooperativeLevel(window A, DDSCL_EXCLUSIVE |
DDSCL_FULLSCREEN). The presence of DDSCL_FULLSCREEN should mean that it draws
directly to the screen, bypassing all normal (GDI) drawing of other windows.
So, even though dialog D is in front of window A, the drawing to window A
should appear on screen.
* Wine's ddraw calls wined3d_device_setup_fullscreen_window() to set window A
up as a full-screen window. This attempts to order window A to the front of
all windows by calling SetWindowPos(window A, HWND_TOPMOST, ...). However,
because dialog D is owned by window A, user32 keeps D in front.
The ultimate result is that dialog D obscures window A. I haven't investigated
why dialog D is all black as opposed to looking like a typical user32 dialog
window with controls.
I have confirmed this with a gross hack. In
dlls/user32/dialog.c:DIALOG_CreateIndirect(), I have modified the two calls to
CreateWindowEx[AW]() to pass NULL for the owner. This means that dialog D is
not owned by window A and window A can be moved in front of it. The result is
that you can see the rendering. However, clicks on the window are ignored.
That's because window A isn't prepared to respond to the clicks. The dialog D
is supposed to receive those clicks.
I think that Stefan was on the right path. I think that, when ddraw/wined3d
goes to set up window A for full-screen, it should not attempt to change the
Win32 window. I think it needs to work with the user driver to set up a
full-screen OpenGL surface that's outside of the Win32 window hierarchy. This
surface would have to avoid interfering with mouse events. Those should still
be delivered to whatever Win32 window is under the cursor.
It may be that targeting the desktop window is the most appropriate way for
ddraw/wined3d to communicate the need to draw to the full screen to the user
driver, although Stefan mentioned that that has its own problems. Given that
ddraw (and d3d?) has a need to bypass the normal windowing and graphics, I
think it makes sense for it to communicate directly with the user driver.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=31160
Bug #: 31160
Summary: Driver problem for Epson stylus sx235w
printer/scanner.
Product: Wine
Version: unspecified
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: setupapi
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: l.jackal99(a)gmail.com
Classification: Unclassified
Unable to setup drivers from authentic cd, for Epson Stylus sx235w
printer/scanner. Wine crushes during the setup, and printer doesn' t operate
properly.
--
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.