http://bugs.winehq.org/show_bug.cgi?id=19651
Summary: iTunes "Add folder"-window doesn't reappear after
switching to other programs
Product: Wine
Version: 1.1.27
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: pieter.ideler(a)gmail.com
This bug considers iTunes 8
When you choose File -> "Add folder to library..." a diractory-chooser opens.
When giving focus to an other program and afterwards switching back this window
doesn't reappears. This renders iTunes unusable and to continue using it you
have to restart it manually.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=50743
Bug ID: 50743
Summary: .NET Core WPF applications with layered windows do not
initially render
Product: Wine
Version: 6.3
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: winex11.drv
Assignee: wine-bugs(a)winehq.org
Reporter: madewokherd(a)gmail.com
Distribution: ---
Found while working on WPF in Wine Mono. I've committed a work-around to Wine
Mono (not yet in a release), but the bug is present in .NET Core as well.
For any application using a WPF window with AllowsTransparency set to true
(which makes it a layered window), the window's contents are initially an
opaque black fill. Fully transparent areas are still transparent. If part of
the window redraws (such as from a hover effect), the refreshed area draws
correctly.
I'm working on uploading a self-contained test case. Unfortunately, the archive
exceeds the file size limit.
The work-around in Wine Mono is to redraw the entire window in response to
WM_WINDOWPOSCHANGED messages.
The code that controls this can be found here:
https://github.com/dotnet/wpf/blob/release/3.1/src/Microsoft.DotNet.Wpf/src…
There are a lot of cases where they redraw, but the relevant ones here are
probably WM_SIZE and WM_SHOWWINDOW.
I tried the test program in CrossOver Mac 20, and it rendered correctly. This
makes me think it's an X11-specific issue, but it could also be related to
version difference.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=51551
Bug ID: 51551
Summary: Medibang Paint Pro: Pen pressure and opacity on Wine
6.14 not working
Product: Wine
Version: 6.14
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: wintab32
Assignee: wine-bugs(a)winehq.org
Reporter: crxtrtupgm(a)gmail.com
Distribution: ---
Created attachment 70394
--> https://bugs.winehq.org/attachment.cgi?id=70394
Log.txt - Log for wintab32.
OS: Pop!_OS 21.04 x86-64
App in question: Medibang Paint Pro 26.2
Wine ver: 6.14
Machine: Acer Nitro 5
Tablet used: XP-PEN Star 03 (Old version)
Driver for tablet: Pentablet 1.2.14.1 (Old driver provided by XP-PEN Support)
The application works just as well, can connect to the Medibang Cloud and all
that.
Drawing in the tablet does work, you can draw with it and it registers
properly. The right click of the tablet also works. Issue is the pen pressure
and opacity not working.
This is not the case in native applications such as Krita. Pressure and opacity
works on those applications.
Before you say it, I tried the newer driver from the XP-PEN website and I have
not made it to work on the OS. In fact the driver I used for windows is also in
the older side. Apparently the tablet is old enough that modern support for it
is now unavailable.
I have already replied in the issue Bug 40199 but reported this new bug ID
anyway for investigation for newer 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.
https://bugs.winehq.org/show_bug.cgi?id=49885
Bug ID: 49885
Summary: Missing platform in games category
Product: WineHQ Apps Database
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: appdb-unknown
Assignee: wine-bugs(a)winehq.org
Reporter: matteobin(a)protonmail.com
Distribution: ---
When submitting a new app, there is no platform category under the games one.
I think it should be added.
I submitted an app that is a platform game:
Yooka-Laylee and the Impossible Lair [1].
[1] https://appdb.winehq.org/objectManager.php?sClass=application&iId=20024
--
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.
https://bugs.winehq.org/show_bug.cgi?id=47600
Bug ID: 47600
Summary: DeaDBeeF doesn't show icons
Product: Wine
Version: 4.13
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: t6zm3v62fkp7fe5(a)yandex.ru
Distribution: ---
Created attachment 65017
--> https://bugs.winehq.org/attachment.cgi?id=65017
Screenshot
DeaDBeeF for Windows
(https://github.com/DeaDBeeF-for-Windows/deadbeef/releases/download/2019-06-…)
doesn't show icons and outputs these strings when opening the menu:
002b:err:module:import_dll Library librsvg-2-2.dll (which is needed by
L"C:\\Program
Files\\DeaDBeeF\\lib\\gdk-pixbuf-2.0\\2.10.0\\loaders\\libpixbufloader-svg.dll")
not found
002b:err:module:import_dll Library libxml2-2.dll (which is needed by
L"C:\\Program
Files\\DeaDBeeF\\lib\\gdk-pixbuf-2.0\\2.10.0\\loaders\\libpixbufloader-svg.dll")
not found
Lubuntu 18.04.2, Wine 4.13 from official PPA.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=45447
Bug ID: 45447
Summary: [World of Tanks] Borderless window broken since 1.0.2
Product: Wine
Version: 3.12
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: magist3r(a)gmail.com
Distribution: ---
Created attachment 61779
--> https://bugs.winehq.org/attachment.cgi?id=61779
Screenshot
After update to WoT 1.0.2 borderless window mode of World of Tanks is broken.
It shows header of window and panel instead of fullscreen (see screenshot).
--
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.
https://bugs.winehq.org/show_bug.cgi?id=48523
Bug ID: 48523
Summary: dlls/toolhelp16.dll16 LocalFirst and LocalNext only
return LMEM_FIXED handles
Product: Wine
Version: 5.0-rc6
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dirk.niggemann(a)gmail.com
Distribution: ---
I have a program (HP Chemstation G1701BA) which ha two 16-bit components
(MSTOP.EXE and MSCONFIG.EXE) which inspect their own allocated local heaps to
find their menus.
They use TOOLHELP.DLL to do this(LocalFirst() and LocalNext()) .
However, the Wine implementation of toolhelp.dll does not return any of the
moveable local heap handles, only the fixed ones. This causes both programs to
error during menu building with an internal 'CP Object not found' error.
I have an unfinished test implementation of toolhelp.dll that handles moveable
handles which seems to resolve this issue.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=51868
Bug ID: 51868
Summary: Wine Staging - RPG Maker Game Fails To Load Script(s)
in Wine
Product: Wine
Version: 6.14
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: nekoNexus(a)protonmail.ch
Distribution: ---
Created attachment 70783
--> https://bugs.winehq.org/attachment.cgi?id=70783
Terminal output log
Bug is about this game:
https://appdb.winehq.org/objectManager.php?sClass=version&iId=40186
(Also, the game does not run properly in testing with 6.16 Staging; it ran but
restarting the game afterwards landed me in a white screen [I had closed the
window manually])
With 6.14 Staging, the issue is that the game doesn't proceed to the main menu
due to failing to initialize because it can't run the game's ruby scripting
system.
In Wine forks, though unrelated to this bug but still important to keep in
mind, I had been able to reach the main menu and start the game but fonts,
arrows, and other graphics failed to render and I wouldn't be surprised if this
continues to take place once the current issue is resolved.
Until both are resolved, the game is essentially unplayable.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=51706
Bug ID: 51706
Summary: Msi HANDLE_CustomType1 fails to load dll [patch]
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: msi
Assignee: wine-bugs(a)winehq.org
Reporter: ake.rehnman(a)gmail.com
Distribution: ---
Created attachment 70581
--> https://bugs.winehq.org/attachment.cgi?id=70581
Patch for correctly determine the bitness for CustomAction dll
do_msidbCustomActionTypeDll incorrectly assume dlls have the same "bitness" as
the calling application. The Windows GetBinaryTypeW function used actually
always fails for dll-types. From the documentation:
"If the file is a DLL, the last error code is ERROR_BAD_EXE_FORMAT."
If GetBinaryTypeW fails the fall back is incorrectly using the same bitness as
the application it self.
As far as I know there is no windows api to determine the bitness of DLLs. In
my attached patch I have written a new function to determine the DLL type.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=45597
Bug ID: 45597
Summary: Flicker in GTAIV
Product: Wine
Version: 3.13
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: b7.10110111(a)gmail.com
Distribution: ---
Created attachment 62031
--> https://bugs.winehq.org/attachment.cgi?id=62031
APNG animation of the flicker
After a Wine upgrade, objects in GTAIV started flicker (see the animation in
attachment, namely its top-center part where a lamp is located). Bisection
gives the following result:
dd0ea0a61463db83c647a9367ca61e2b69a98eb3 is the first bad commit
commit dd0ea0a61463db83c647a9367ca61e2b69a98eb3
Author: Henri Verbeet <hverbeet(a)codeweavers.com>
Date: Fri Feb 16 09:39:08 2018 +0330
wined3d: Enable the multi-threaded command stream by default.
Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
:040000 040000 494432da56fa4c73f71f62151a3013fd4a6fb850
501f26cfd0dbf7d24224ad1f5fabfd9e8ce569c9 M dlls
Nothing unusual appears in the terminal, frame rate doesn't noticeably change,
only the visual artifacts appear. If you go outdoors (in game :) ), then
there'll be more objects which flicker, like here:
https://i.imgur.com/tvtU94I.png (ignore the motion of cars and humans, it's
normal).
--
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.