wine-bugs November 2015

wine-bugs@winehq.org

1 participants
7944 discussions

[Bug 17483] New: EngInSite CSS Editor font distance rendering problem
by wine-bugs＠winehq.org 01 Mar '16

01 Mar '16

http://bugs.winehq.org/show_bug.cgi?id=17483 Summary: EngInSite CSS Editor font distance rendering problem Product: Wine Version: 1.1.14 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: shdocvw AssignedTo: wine-bugs(a)winehq.org ReportedBy: ar(a)esoma.org Created an attachment (id=19577) --> (http://bugs.winehq.org/attachment.cgi?id=19577) Screenshot In the editor window all fonts are monospaced but the display font does not adapt to that and inserts spaces. You can see the problem in the attached screenshot: I don't know if that is related to fixme:system:SetProcessDPIAware stub! -- 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 7

[Bug 21581] New: GTA4 crashes during "Lure" mission
by wine-bugs＠winehq.org 01 Mar '16

01 Mar '16

http://bugs.winehq.org/show_bug.cgi?id=21581 Summary: GTA4 crashes during "Lure" mission Product: Wine Version: 1.1.37 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll AssignedTo: wine-bugs(a)winehq.org ReportedBy: knaprigt(a)gmail.com Created an attachment (id=26030) --> (http://bugs.winehq.org/attachment.cgi?id=26030) Output after crash during the Lure mission in GTA4 GTA4 crashes during the mission "Lure" when the player is supposed to kill a drug dealer. Everything seems fine until the player reaches the roof where he should take the shot. First a cutscene is shown and when the player's returned to the controls the game crashes. Tested with versions 1.0.0.4 and 1.0.4.0 of the game with the same results. See attachment for terminal output displayed after the crash. ... also I don't know if this bugs component really is ntdll (maybe wined3d?), so someone may want to change that one. -- 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 24

[Bug 35450] New: Clean up 'Version' in bugzilla
by wine-bugs＠winehq.org 28 Feb '16

28 Feb '16

http://bugs.winehq.org/show_bug.cgi?id=35450 Bug ID: 35450 Summary: Clean up 'Version' in bugzilla Product: WineHQ Bugzilla Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: bugzilla-unknown Assignee: wine-bugs(a)winehq.org Reporter: litimetal(a)gmail.com Classification: Unclassified There are too many old versions to choose, which may waste time Would Wine Bugzilla hide the *very old* versions, or re-arrange them? -- 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 10

[Bug 37862] New: Wrong instruction on Bugzilla and Bugs page.
by wine-bugs＠winehq.org 28 Feb '16

28 Feb '16

https://bugs.winehq.org/show_bug.cgi?id=37862 Bug ID: 37862 Summary: Wrong instruction on Bugzilla and Bugs page. Product: WineHQ Bugzilla Version: unspecified Hardware: x86 URL: http://wiki.winehq.org/Bugs OS: Linux Status: UNCONFIRMED Severity: trivial Priority: P2 Component: bugzilla-unknown Assignee: wine-bugs(a)winehq.org Reporter: iritrozen(a)gmail.com Distribution: --- Page http://wiki.winehq.org/Bugs, in chapter "How to report" says * Attach complete terminal output ... You have to _Submit_ the bug first before you're given the option to attach files. It is not true. User can attach files when creating a new bug. -- 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 2

[Bug 16301] New: wine user guide asks the user to run programs without explaining how
by wine-bugs＠winehq.org 28 Feb '16

28 Feb '16

http://bugs.winehq.org/show_bug.cgi?id=16301 Summary: wine user guide asks the user to run programs without explaining how Product: WineHQ.org Version: unspecified Platform: Other URL: http://www.winehq.org/site/docs/wineusr-guide/running OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: www-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: madewokherd(a)gmail.com The introductory page under "Running Wine" (http://www.winehq.org/site/docs/wineusr-guide/running) says this: "Assuming you are using a fake Windows installation, you install applications into Wine in the same way you would in Windows: by running the installer." and gives several examples of wine command lines, including an example for starting a program after it has been installed to C:. Yet there is no explanation of how to run a program or use the wine command. -- 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 39450] New: The polish FAQ is absolutely terrible
by wine-bugs＠winehq.org 27 Feb '16

27 Feb '16

https://bugs.winehq.org/show_bug.cgi?id=39450 Bug ID: 39450 Summary: The polish FAQ is absolutely terrible Product: WineHQ.org Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: www-unknown Assignee: wine-bugs(a)winehq.org Reporter: d33tah(a)gmail.com Distribution: --- I just stumbled upon this wiki article: http://wiki.winehq.org/FAQ_pl Somewhere in the middle of the article there are so many spelling mistakes and the style is so bad it's barely comprehensible. There might be some useful information there, but the article needs a lot of work from someone who knows how to write proper Polish. Could you let the Polish translation team know? Also, I replaced a word starting with "drug" (drugi? drugą? either of those) meaning "second" to "kolejny" ("next") because the word "drug" is not allowed. The spam filter is actually making it much more difficult to write articles. -- 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 6

[Bug 29590] New: Search results do not update on webpage (IE8)
by wine-bugs＠winehq.org 24 Feb '16

24 Feb '16

http://bugs.winehq.org/show_bug.cgi?id=29590 Bug #: 29590 Summary: Search results do not update on webpage (IE8) Product: Wine Version: 1.3.36 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: msxml3 AssignedTo: wine-bugs(a)winehq.org ReportedBy: ocean04(a)suomi24.fi Classification: Unclassified winetricks ie8 Open http://asunnot.oikotie.fi Search should update automatically every time you make changes to form fields, but does nothing. Workaround winetricks msxml3 I'll attach msxml log. Most interesting parts are: 003d:fixme:msxml:httprequest_get_statusText stub 0x3c82428 0x2b53cd8 and many lines like: 003d:trace:msxml:domdoc_loadXML (0x36ce620)->(L"{\"responseHeader\":{\"status\":0,\"QTime\":11},\"response\":{\"numFound\":22852,\"start\":0,\"docs\":[]}}" 0x268c612) 003d:err:msxml:doparse Start tag expected, '<' not found 003d:trace:msxml:domdoc_loadXML (0x3cef120)->(L"{\"time\":1326303123.1712}" 0x268bfb2) 003d:err:msxml:doparse Start tag expected, '<' not found -- 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 16

[Bug 33100] New: ALSA Audio playback in WINE locks up ALSA capture by other applications
by wine-bugs＠winehq.org 22 Feb '16

22 Feb '16

http://bugs.winehq.org/show_bug.cgi?id=33100 Bug #: 33100 Summary: ALSA Audio playback in WINE locks up ALSA capture by other applications Product: Wine Version: 1.5.25 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winealsa.drv AssignedTo: wine-bugs(a)winehq.org ReportedBy: torsten.crass(a)eBiology.de Classification: Unclassified Hi there, when trying to record sound (e.g. using arecord) played by some application running on WINE (e.g. vlc.exe) via ALSA, and if the recording application is launched *before* the playback application, recording stops immediately when playback starts, and after a while ALSA reports an "Input/output error". This does not happen with native playback applications, e.g. the Linux version of vlc. Funny enough, if recordings starts *after* playback has begun, everything works fine. How to reproduce: 1. In a terminal, issue sudo alsactl restore; arecord -D default -f dat -v -V stereo test.wav 2. In another terminal, launch vlc.exe by issuing something like WINEPREFIX=/path/to/prefix wine /path/to/vlc.exe /path/to/some/audiofile 3. Wait for a few seconds... and see arecord complaining: arecord: pcm_read:1801: read error: Input/output error 4. Re-launch arecrod: sudo alsactl restore; arecord -D default -f dat -v -V stereo test.wav 5. Watch arecord recording happily ever after. I initially suspected WINE to somehow force access to my soundcard's capture device (A SB Live, which seems not to be dsnoop'd by default), but after creating a dsnoop'd device (which did allow for multiple simultaneous recordings with arecord when playing back audio with Linux's vlc) and teaching WINE to actually use it, the problem unfortunately remained. Best regards -- Torsten P.S. If filed this bug with Debian's wine-unstable-alsa package some two months ago already, but since there hasn't been a single reply up to now and since the problem still remains with 1.5.25 (Debian is still at 1.5.6), I found it appropriate to directly re-file this report at WINE's bug tracking system. -- 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 6

[Bug 35260] New: Sound weirdness with XCOM: Enemy Within
by wine-bugs＠winehq.org 22 Feb '16

22 Feb '16

http://bugs.winehq.org/show_bug.cgi?id=35260 Bug ID: 35260 Summary: Sound weirdness with XCOM: Enemy Within Product: Wine Version: 1.7.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winealsa.drv Assignee: wine-bugs(a)winehq.org Reporter: lama(a)lamamail.de Classification: Unclassified This is a strange one... I'll just describe what happened: - I'm using the digital out on my sound card. This works fine with everything but this game in WINE - Got the game working after registering XAudio2_7.dll - There is no sound whatsoever ingame (also no sound options beyond a mixer) - After running the game I have no sound anywhere anymore, even after closing all WINE processes. No errors while playing though (so it's not blocked), just quiet - Mixer settings are fine - Turns out the default ALSA device has been changed to the analog output, even after explicitly selecting the digital output (instead of default) in WINE. Only a reboot fixes this. ALSA documentation doesn't even mention this as a possibility. Oh, and game audio still isn't played through that either. I've tested this with WINE 1.7.9 and built from GIT. -- 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 10

[Bug 36694] New: Using PBM_SETPOS to change the position of a progress bar to what it was before after a style change (for instance, leaving marquee mode) does not redraw the progress bar
by wine-bugs＠winehq.org 22 Feb '16

22 Feb '16

http://bugs.winehq.org/show_bug.cgi?id=36694 Bug ID: 36694 Summary: Using PBM_SETPOS to change the position of a progress bar to what it was before after a style change (for instance, leaving marquee mode) does not redraw the progress bar Product: Wine Version: 1.7.19 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comctl32 Assignee: wine-bugs(a)winehq.org Reporter: pietro10(a)mac.com Created attachment 48733 --> http://bugs.winehq.org/attachment.cgi?id=48733 The test program that can be used to duplicate this behavior. If you do this when you switch out of marquee mode on a progress bar: SendMessage(pbar, PBM_SETMARQUEE, FALSE, 0); SetWindowLongPtr(pbar, GWL_STYLE, GetWindowLongPtr(hwnd, GWL_STYLE) & ~PBS_MARQUEE); SendMessage(pbar, PBM_SETPOS, currentPos, 0); the progress bar will not redraw, and thus will continue to show the marquee animation frozen at the place it was at the time of the above call. Attached is a sample program that will demonstrate this behavior. Set one value, then click Marquee and Set again. On Windows XP (at least), the progress bar will redraw properly with the second click of Set. The attached file is also available at https://github.com/andlabs/misctestprogs/blob/master/winprogresstest.c. (As marquees are a comctl32 version 6 feature, you may need a manifest file.) Looking at the soruce, I see here - http://source.winehq.org/source/dlls/comctl32/progress.c#L639 - that the implementation's handling of PBM_SETPOS only draws the progressbar if the new position is different. Thus, I could come up with a variety of ways to fix it, such as adding a style change check there, or always redrawing the progress bar, or redrawing on a style change... but I don't know which is the most correct, so I'll leave it to the experts. Thanks. -- 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 6

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 November 2015