wine-bugs November 2019

wine-bugs@winehq.org

1 participants
7561 discussions

[Bug 2155] Failure of SetFocus, SetActiveWindow and SetForegroundWindow
by WineHQ Bugzilla 05 Nov '19

05 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=2155 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #23 from joaopa <jeremielapuree(a)yahoo.fr> --- bug still occurs with wine-4.19. -- 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 21661] New: RichEdit: Wrong behaviour when formating an empty selection
by wine-bugs＠winehq.org 05 Nov '19

05 Nov '19

http://bugs.winehq.org/show_bug.cgi?id=21661 Summary: RichEdit: Wrong behaviour when formating an empty selection Product: Wine Version: 1.1.37 Platform: x86 URL: http://www.teamviewer.com OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: richedit AssignedTo: wine-bugs(a)winehq.org ReportedBy: caliga(a)arcor.de In our Software TeamViewer, a Richedit control is used to display chat messages. The nick names are colored green or blue, the text should remain black. This works in general... But if one side sends several chat messages in row, the nick name is omitted (by TeamViewer). And then, an empty selection (where the nickname would be) is formated green or blue. It seems, that if this happens the second time, something is screwed up and the color becomes the default color... Of course TeamViewer could just NOT format the empty selection with EM_SETCHARFORMAT, (and this will be done in an upcoming release), but still this is a wine bug, I think. To reproduce, start a remote support session in TeamViewer from your Linux-box to a different TeamViewer, then click on Audio/Video/Chat and type three or more messages. -- 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.

2 11

[Bug 35896] New: Switching to Chinese input method after typing some English will fail.
by wine-bugs＠winehq.org 05 Nov '19

05 Nov '19

http://bugs.winehq.org/show_bug.cgi?id=35896 Bug ID: 35896 Summary: Switching to Chinese input method after typing some English will fail. Product: Wine Version: 1.7.15 Hardware: x86 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: hwei.sy(a)gmail.com == Steps to reproduce == 1. Open notepad in wine. 2. Make sure input method is English. 3. Type something (e.g. H, A, SPACE), then the notepad will display it (e.g. "ha "). 4. Switch to Chinese input method. 5. Type something (e.g. H, A, SPACE), then the notepad dose not receive anything (e.g. should display "哈"). This bug will only appear when input something in English before Chinese. But if you input Chinese before any English character (i.e. remove step 2, 3), every thing is going well. == How to fix it == In the source file "dlls/imm32/imm.c", function "ImmProcessKey", after "if (imc) data = imc; else return FALSE;", insert one line "data->immKbd = IMM_GetImmHkl(hKl);". Then it seems fixed. But I don't know will this cause other problems. ---- I am not sure this bug is same to Bug 34056. -- 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.

2 8

[Bug 31434] New: Menu is activated by alt key while mouse button is down
by wine-bugs＠winehq.org 05 Nov '19

05 Nov '19

http://bugs.winehq.org/show_bug.cgi?id=31434 Bug #: 31434 Summary: Menu is activated by alt key while mouse button is down Product: Wine Version: 1.5.10 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: kaetemi(a)gmail.com Classification: Unclassified Created attachment 41320 --> http://bugs.winehq.org/attachment.cgi?id=41320 user32: Menu should not be activated by menu key while mouse buttons are down. When using and Alt+MouseButton combination, the application menu becomes selected after releasing Alt. More specifically, in 3ds Max 9, when using the Alt+MiddleMouse in a viewport to rotate, after releasing Alt the File menu will be selected, and the viewport will appear as if frozen to the user, not accepting any input until Alt is pressed again to release the menu. Patch with fix attached. -- 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.

2 7

[Bug 7198] user32: first window on the virtual desktop is not marked as active
by WineHQ Bugzilla 05 Nov '19

05 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=7198 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #11 from joaopa <jeremielapuree(a)yahoo.fr> --- Still a bug with wine-4.19? -- 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 10358] New: wine 0.9.48 takes 5 minutes to start an application
by wine-bugs＠winehq.org 05 Nov '19

05 Nov '19

http://bugs.winehq.org/show_bug.cgi?id=10358 Summary: wine 0.9.48 takes 5 minutes to start an application Product: Wine Version: 0.9.48. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-winelib AssignedTo: wine-bugs(a)winehq.org ReportedBy: jean-jaques(a)women-at-work.org Created an attachment (id=9029) --> (http://bugs.winehq.org/attachment.cgi?id=9029) wine debug output where wine freezes for a while I've wiped my .wine directory and had winecfg rebuild it. Then I installed iTunes 7.3 and now it takes more than 5 minutes until wine launches _any_ windows application. When I enter "wine app.exe" nothing happens for a really long time. After waiting for 5 or sometimes up to 10 minutes (no CPU load) the application launches. This even applies to winecfg! When I run wine in debug mode (WINEDEBUG=+relay winecfg) it stops producing output at a certain point and then continues (again after a few minutes). I have attached some debug output (the place where wine seems to freeze and stops producing output). I can't attach the entire file, because it is 40MB :( wine 0.9.48, compiled from sources, Gentoo 2007.0 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 31

[Bug 3507] Starting Wine / certain programs under Wine run extremely slowly (enumerating printers on large networks is slow under cups)
by WineHQ Bugzilla 05 Nov '19

05 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=3507 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #21 from joaopa <jeremielapuree(a)yahoo.fr> --- Still a bug with wine-4.19? -- 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 48039] New: Pop up menus disappear behind main window when clicking in the main window
by WineHQ Bugzilla 04 Nov '19

04 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=48039 Bug ID: 48039 Summary: Pop up menus disappear behind main window when clicking in the main window Product: Wine Version: 4.19 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ph.brueckmann(a)bluewin.ch Distribution: --- In all abacom-programs (splan, layout, front designer) there is still a bug with pop up windwos. When a pop up window is open (i.e to add some text) and you click in the main window, the pop up window disappears behind the main window and everything is blocked. If that happens you have to move the main window aside until the pop up menu appears on the display. In windows the pop up menu stays in front even when clicking in the main window. This bug is not new, it was present in all older wine versions. -- 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 18790] New: Default search does not include resolved bugs
by wine-bugs＠winehq.org 04 Nov '19

04 Nov '19

http://bugs.winehq.org/show_bug.cgi?id=18790 Summary: Default search does not include resolved bugs Product: WineHQ Bugzilla Version: unspecified Platform: PC OS/Version: Linux Status: NEW Keywords: download, source Severity: enhancement Priority: P3 Component: bugzilla-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: kennybobs(a)o2.co.uk The default search (the search box at the top of this page) does not include closed bugs (rightly so), but it also does not include resolved bugs. This leads to duplicates that could be avoided. See Bug 18601 - a recent regression that is fixed by the next release, but anyone searching for an open bug for Google Sketchup will not see it unless they choose to run an advanced search, which some users clearly don't. I'm sure this is a simple change to the code. -- 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.

2 8

[Bug 48034] New: Better detect which Wine-related project a patch applies to
by WineHQ Bugzilla 04 Nov '19

04 Nov '19

https://bugs.winehq.org/show_bug.cgi?id=48034 Bug ID: 48034 Summary: Better detect which Wine-related project a patch applies to Product: Wine-Testbot Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- Currently the TestBot uses two pieces of information to detect whether a patch sent to the mailing list is a Wine patch or not: * The list of Wine source files (see bug 48033). * A pair of blacklists for source filenames that are too generic to be proof a patch is a Wine patch (see $AmbiguousPathsRe and $IgnoredPathsRe in testbot/lib/WineTestBot/PatchUtils.pm). A better method would be for the TestBot server to have access to all the Wine-related repositories. A patch would initially be considered as a match for all of them and the list of files it patches would then be analyzed. Every time it patches a (not-new) file not present in one of the repositories, that repository would be eliminated from the list of matches for that patch. At the end the remaining repositories are the ones the patch could apply to. Most of the time there should only be one and the TestBot would only create jobs if Wine is one of them. This would mostly eliminate the need for the hard-coded blacklists and may open the door to expanding support for other Wine-related projects since the TestBot would be able to identify patches for these projects too. -- 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:

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 2019