January 2019 - Wine-bugs - list.winehq.org

[Bug 46437] New: explorer: Add an option to keep the taskbar on top of other windows ( virtual desktop)
by wine-bugs＠winehq.org 07 Jan '19

07 Jan '19

https://bugs.winehq.org/show_bug.cgi?id=46437 Bug ID: 46437 Summary: explorer: Add an option to keep the taskbar on top of other windows (virtual desktop) Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: enhancement Priority: P2 Component: programs Assignee: wine-bugs(a)winehq.org Reporter: o.dierick(a)piezo-forte.be Distribution: --- This bug describes an user interface enhancement to the taskbar of the built-in explorer in virtual desktop mode. Current behavior: The taskbar is created without the 'topmost' style. Any window created/activated is brought to the foreground, on top of the taskbar. The taskbar is automatically hidden when the last icon is removed from the systray. The taskbar is made visible and is brought on top when: - The virtual desktop is created; - The virtual desktop size changes; - An icon is added to the previously empty hidden systray. When these events occur, fullscreen windows are treated like normal windows: The taskbar is drawn over them, and one has to activate the window to bring it above the taskbar. The issue with the taskbar appearing above fullscreen windows is reported as bug 40828. I already submitted a patch to address this by preventing any z order change to the taskbar. This leaves the taskbar below other windows at all time. Even without that patch, the taskbar doesn't stay on top of normal windows. Many people likes to have the taskbar always on top of normal windows. Proposed enhancement: Add an option to 'keep the taskbar on top of other windows'. User Interface: - A right-click pop-up menu will be added to the taskbar; - The pop-up menu will have an entry 'Taskbar settings'; - The menu entry will open a 'Taskbar settings' window; - The Taskbar settings window will contain a 'Keep taskbar on top of other window' checkbox; - The checkbox will be checked by default on prefix creation. - The settings will be saved in the registry; - The user shall click 'ok' to save and apply the changes and close the window; - The user shall click 'cancel' to discard the changes and close the window; Implementation details: When the option is enabled, the 'topmost' style will be applied to the taskbar. Fullscreen windows are not necessarily topmost and the taskbar will be above non-topmost fullscreen windows. To avoid that, the taskbar will have to detect when a fullscreen window is activated and hide itself (Maybe through SetWinEventHook() with EVENT_SYSTEM_FOREGROUND). It will be made visible again when the fullscreen window is no longer active. For now, the visibility toggling when icon are added/removed from the systray would be retained. Adding an actual 'Automatically hide the taskbar' option is another possible enhancement. Comments welcome. -- 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 3

[Bug 46257] New: PrintWindow returns black image
by wine-bugs＠winehq.org 07 Jan '19

07 Jan '19

https://bugs.winehq.org/show_bug.cgi?id=46257 Bug ID: 46257 Summary: PrintWindow returns black image Product: Wine Version: 3.17 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: stu.axon(a)gmail.com Distribution: --- On Windows I can get an image of a win32 window using PrintWindow, on Wine it just returns a black image of the size of the window. I ran this code https://stackoverflow.com/questions/19695214/python-screenshot-of-inactive-… And changed the app from Calculator (which is Universal in Windows now) to Notepad. -- 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 46434] New: GUI components not showing when usnig the GTK-3 theme.
by wine-bugs＠winehq.org 07 Jan '19

07 Jan '19

https://bugs.winehq.org/show_bug.cgi?id=46434 Bug ID: 46434 Summary: GUI components not showing when usnig the GTK-3 theme. Product: Wine Version: 4.0-rc5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: badouri.g(a)gmail.com Distribution: --- Created attachment 63208 --> https://bugs.winehq.org/attachment.cgi?id=63208 Only the top buttons are rendered because I clicked them. Hi there, This is my first bug-report so go easy on me. I'm running wine-staging rc5 on Fedora 29 x86-64. The build was installed from the official repository: https://dl.winehq.org/wine-builds/fedora/29 Now by default in winecfg -> staging tab there is a box that says: "Enable GTK3 Theming" It's checked by default. However this causes the gui elements (buttons, input fields etc) in BMC Remedy User to not being visible unless I highlight them. e.g. for buttons I need to click and keep it them pressed, then move the cursor away from them and release the button, so I don't click them right away. Then they show up. This is a bit of a pain, when there's forms with multiple buttons, textfields etc.. When I disable GTK3 theming they do show up properly. See the attachment, I highlighted the top three buttons for them to show up. The others are not rendered by default. -- 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 1

[Bug 46431] New: Quicktime VR 2.1 videos don't play properly
by wine-bugs＠winehq.org 06 Jan '19

06 Jan '19

https://bugs.winehq.org/show_bug.cgi?id=46431 Bug ID: 46431 Summary: Quicktime VR 2.1 videos don't play properly Product: Wine Version: 3.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: jorgesanini(a)gmail.com Distribution: --- I have tried to play a game based around QuickTime 2.1.2.59 (Safecracker from 1996) that uses QuickTime VR videos where you are able to use the mouse to look around the environment. However, when I try to look around with the mouse the video does not move at all (sometimes it does but it stops doing it at random). This is probably related to bug 18257 that reports that QuickTime 2 video player stops playing videos after 0.5 seconds since looking around the video could be the same action as playing the video, however this bug doesn't seem to be fixed in latest wine versions, which is probably a regression since it seems to have been fixed at some point in Wine 1.2 (as seen here: https://bugs.launchpad.net/ubuntu/+source/wine/+bug/355567) I tried with Wine staging 3.21 but this happens too in the stable branch (and probably in every recent version of Wine). -- 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 46427] New: Ubuntu Repository Broken
by wine-bugs＠winehq.org 06 Jan '19

06 Jan '19

https://bugs.winehq.org/show_bug.cgi?id=46427 Bug ID: 46427 Summary: Ubuntu Repository Broken Product: Packaging Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-packages Assignee: wine-bugs(a)winehq.org Reporter: pkutzner+winehq(a)gmail.com CC: michael(a)fds-team.de, sebastian(a)fds-team.de Distribution: --- The current Ubuntu Bionic repository's Packages.xz file is coming up with an incorrect size/hash error. I don't know if this problem affects other builds as well. E: Failed to fetch https://dl.winehq.org/wine-builds/ubuntu/dists/bionic/main/binary-amd64/Pac… File has unexpected size (71508 != 74696). Mirror sync in progress? [IP: 151.101.46.217 443] Hashes of expected file: - Filesize:74696 [weak] - SHA512:393e59be2c01ffd6191b7981bcb12f324f8a106158504082f1a529282903a19ae8478b366a432247d3670fde4d55be66ea052d3eb0ef568467b086587190877f - SHA256:4dfb4a00c3ec0ee5a96a0617040477fd6eb35bf02ec52f55e872e54519a5c881 - SHA1:60baf1398afd5beb492cc5bf9ccf679190e64c26 [weak] - MD5Sum:0023b0fa659c0bea9511f55e3dbe303e [weak] Release file created at: Sun, 06 Jan 2019 15:07:05 +0000 This is the case for both the amd64 and i386 builds. I initially saw this error for the i386 build, but added [arch=amd64] to my sources.list file to force the amd64 version and got the same error. -- 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 44128] New: HebRech Invoicing throws error message
by wine-bugs＠winehq.org 05 Jan '19

05 Jan '19

https://bugs.winehq.org/show_bug.cgi?id=44128 Bug ID: 44128 Summary: HebRech Invoicing throws error message Product: Wine Version: 2.22 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: maiktapwagner(a)aol.com Distribution: --- Created attachment 59867 --> https://bugs.winehq.org/attachment.cgi?id=59867 Console Output (wine 2.22) Hello everyone, after testing HebRech which got its own entry in the AppDB I noticed that the button "Rechnung" in the main programm throws an error message. Ein unerwarteter Fehler ist aufgetreten: LOMAIN ist kein Objekt. (1) Klasse Commain_optionsdialogsservice (Zeile: 0) Translation: An unexpected error has occured: LOMAIN is not an object. (1) Class Commain_optionsdialogsservice (Line: 0) Console output is attached. Please note that this program requires a "winetricks dotnet46" to install. -- 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 1

[Bug 33835] New: Touhou 13.5 black screen
by wine-bugs＠winehq.org 04 Jan '19

04 Jan '19

http://bugs.winehq.org/show_bug.cgi?id=33835 Bug #: 33835 Summary: Touhou 13.5 black screen Product: Wine Version: unspecified Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: directx-d3dx9 AssignedTo: wine-bugs(a)winehq.org ReportedBy: murela_alba(a)abv.bg CC: wine-bugs(a)winehq.org Classification: Unclassified Created attachment 44861 --> http://bugs.winehq.org/attachment.cgi?id=44861 Title screen When running Hopeless Masquerade after the loading screen the only thing rendered is the main menu and game logo, with no background and when trying to go into story mode, the entire screen turns black. Music and sound effects are running properly at the same time. Game version is 1.03b, but 1.0 does the same. Tested with wine 1.6-rc2 on Ubuntu 13.04 (64-bit). -- 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 15

[Bug 38721] New: Steam problem - Wine uncompability or something similar
by wine-bugs＠winehq.org 04 Jan '19

04 Jan '19

https://bugs.winehq.org/show_bug.cgi?id=38721 Bug ID: 38721 Summary: Steam problem - Wine uncompability or something similar Product: Wine Version: 1.7.44 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: adriansnetlis3(a)inbox.lv Distribution: --- Created attachment 51646 --> https://bugs.winehq.org/attachment.cgi?id=51646 The .log file with errors Hi! I want to report that Steam installation has a problem here. I am posting the log as attachment, but it is PlayOnlinux. Why PlayOnLinux - I am not gone do very the same in console now as the installation was long for running Resident Evil 5. But I am 100% sure this problem is releated to Wine and will be the same also in non-POL installation. Actually, I am not 100% sure what the problem is, but the log puts out one error that POL members which I reported a problem with Resident Evil 5(here you can see my problem: https://www.playonlinux.com/en/topic-13184-Resident_Evil_5_Gold_Edition_Ste… ). It may be reason why Resident Evil 5 not run, so I have to ask it here as POL can't help with Wine errors. The POL log is in attachment. Please, don't reject this - this may be important for multiple people! -- 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 17

[Bug 34334] New: MetaTester 5 never sends or receives data
by wine-bugs＠winehq.org 04 Jan '19

04 Jan '19

http://bugs.winehq.org/show_bug.cgi?id=34334 Bug #: 34334 Summary: MetaTester 5 never sends or receives data Product: Wine Version: 1.7.0 Platform: x86-64 URL: http://files.metaquotes.net/metaquotes.software.corp/m t5/mt5tester.setup.exe OS/Version: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: kennybobs(a)o2.co.uk Classification: Unclassified Created attachment 45702 --> http://bugs.winehq.org/attachment.cgi?id=45702 wine-1.7.0-199-g52fb1cc console output (1st run) The MetaTrader 5 Strategy Tester Agent (MetaTester 5) never sends or receives any data. It comes as part of MetaTrader 5 but is also available separately to create your own server farm. It installs itself as a system service on Windows (SYSTEM account) and runs in the background once it has been initially set up from the main application. Wine seems to have a problem running the services but that is a different problem (bug not yet logged). Wireshark confirms that no connection attempts are sent or received. Not externally anyway. The main application window shows statistics for data transfer and under Windows XP this can be a few kB each day when quiet (when stock markets are closed), but Wine never registers a single byte. Netstat shows that the agents themselves are listening: tcp 0 0 0.0.0.0:2001 0.0.0.0:* LISTEN 216313/wineserver I can telnet to this port and it remains open for a few seconds before timing out and closing. This does not register as data on the main application (same in XP). There are listeners on port 6010 and 6011 too but I think they're control ports. I am attaching the first run log as two agent services start successfully on first run. You can start as many as you like but it makes sense to have one agent per core. Ran all day on Windows XP and Linux to compare. In testing I enabled the agents to join the community (global) network. An account is not required for this. -- 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 45917] New: battle.net launcher and mouse position on high DPI monitor
by wine-bugs＠winehq.org 04 Jan '19

04 Jan '19

https://bugs.winehq.org/show_bug.cgi?id=45917 Bug ID: 45917 Summary: battle.net launcher and mouse position on high DPI monitor Product: Wine Version: 3.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: kdt3rd(a)gmail.com Distribution: --- In both wine 3.16 and 3.17, and both vanilla and wine-staging wine, the cursor / mouse position is scaled inside the Battle.net launcher application. I initially thought it was only temporary since it seemed there were a bunch of changes for correctly passing the DPI in the change sets for 3.16, but it has persisted, so thought to file a bug. Basically, when running on a (single) UHD monitor (nvidia graphics card, asus uhd monitor) where xdpyinfo returns 157 dpi (xdpyinfo|grep resolution gives 157x161 dots per inch), the Battle.net launcher application thinks the mouse is in the wrong position, meaning to click on a particular button, I need to move the window such that the button is in the upper left of the screen, or have the mouse be ~1.5x of the distance from the upper left from where the button actually is and have mouse still be inside the application (otherwise it switches focus to the application under the mouse). And even then, the "play" button is mouse-over highlighted wider than the actual button. When the button is just in from the top left of the display, it doesn't become active (mouse-over highlight or clickable) until the mouse is moved more than the distance from the top left. Which is flat strange, because I haven't resized the window, just moved, so the upper left of the toplevel app window is still offset by the same amount from the button. Of course, I don't know if it is computing position from the upper left of the top window or somehow querying the global cursor position and comparing that to the perceived global position of the widgets in the window. Basically, my attempt to naively find what is being scaled by dpi and what has been missed in that step have failed. Interestingly, if I do the above to move the window such that I can click the Play button and then launch a game, the mouse position seems fine when the game is running and in full screen - Of course, that's a different app, and as it is fullscreen, I presume because it forces itself to be at 0,0, and probably uses xrandr to reset the screen coordinates and figures itself out. If there is any other information that would be helpful, or if someone can point out code to look at / traces to turn on, I am happy to help. -- 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 9