Bug 389448 - Width and height of the window doesn't set correctly on HiDPI screen when using Plasma Qt scaling on X11
Summary: Width and height of the window doesn't set correctly on HiDPI screen when usi...
Status: RESOLVED FIXED
Alias: None
Product: yakuake
Classification: Applications
Component: general (show other bugs)
Version: 3.0.4
Platform: OpenSUSE Linux
: HI normal with 65 votes (vote)
Target Milestone: ---
Assignee: Eike Hein
URL:
Keywords:
: 369178 377063 388217 392960 412308 415022 415184 416901 417959 (view as bug list)
Depends on:
Blocks: 356446
  Show dependency treegraph
 
Reported: 2018-01-26 08:49 UTC by Marcel
Modified: 2020-12-01 18:19 UTC (History)
21 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
The width and height are set to be 100% (2.83 MB, image/png)
2018-01-26 08:49 UTC, Marcel
Details
attachment-31031-0.html (1.40 KB, text/html)
2020-03-01 03:19 UTC, Gregory Ernest
Details
attachment-8639-0.html (827 bytes, text/html)
2020-03-01 13:36 UTC, Gregory Ernest
Details
attachment-10060-0.html (1.05 KB, text/html)
2020-03-01 14:42 UTC, Gregory Ernest
Details
Behaviour on HiDPI screen with 20.08.2 and Plasma 5.20 (2.73 MB, video/x-matroska)
2020-10-22 10:49 UTC, phrxmd
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcel 2018-01-26 08:49:33 UTC
Created attachment 110127 [details]
The width and height are set to be 100%

I'm using a 4k monitor. After upgrading to KDE Plasma 12.0 (11.95), the width and height of the Yakuake terminal cannot be correctly set. I set the both of them to be 100%, while it actually only 50%.
Comment 1 Peifeng Yu 2018-02-09 16:24:55 UTC
I'm facing the same bug after my upgrade today. I'm using ArchLinux.

Versions:
yakuake: 3.0.4
plasma: 5.12.0
qt: 5.10.0

I have a 4k monitor running at native resolution 3840x2160. I also set scale display factor to 2, which KDE translates to QT_SCREEN_SCREAN_SCALE_FACTORS.

I tried quitting and removing ~/.cache/yakuake and restarting but with no success.
Comment 2 Peifeng Yu 2018-02-09 16:27:20 UTC
Another report of the same bug: https://bugs.kde.org/show_bug.cgi?id=388217
Comment 3 Peifeng Yu 2018-02-09 20:33:17 UTC
Some investigation:

Given my resolution 3840x2160, It appears that Qt returns screen geometry as 1920x1080, which has been scaled down by QT_SCREEN_SCALE_FACTORS=2. Then in KWindowSystem::workArea, which calls QScreen::geometry internally in X11 plugin[1], the returned value is scaled down the second time[2], and returns 960x540. Therefore yakuake calculates using wrong max height and width of the screen.

[1] https://cgit.kde.org/kwindowsystem.git/tree/src/platforms/xcb/kwindowsystem.cpp#n73
[2] https://cgit.kde.org/kwindowsystem.git/tree/src/kwindowsystem.cpp#n599
Comment 4 Marcel 2018-02-26 12:21:09 UTC
Solved in a recently openSUSE Tumbleweed upgrade for reasons unknown.
Comment 5 Marcel 2018-02-26 20:10:09 UTC
(In reply to Marcel from comment #4)
> Solved in a recently openSUSE Tumbleweed upgrade for reasons unknown.

It happened again after I changed the theme.
Comment 6 Marcel 2018-02-27 21:34:36 UTC
I finally figure out why the size is wrong. If the top panel is center aligned, then the size will be wrong! After changing the alignment to "left", the size becomes normal.
Comment 7 Marcel 2018-02-28 08:04:13 UTC
(In reply to Marcel from comment #6)
> I finally figure out why the size is wrong. If the top panel is center
> aligned, then the size will be wrong! After changing the alignment to
> "left", the size becomes normal.

Well, it seems that auto hide is the reason why the size is abnormal.
Comment 8 Adi Stadi 2018-03-28 08:35:46 UTC
workaround:
QT_AUTO_SCREEN_SCALE_FACTOR=1;yakuake

Happens only when screen scaling is active (scaling 1.5 for my hdpi screen)
Comment 9 Adi Stadi 2018-03-28 08:38:27 UTC
sorry, wrong workaround, i use 
export QT_SCREEN_SCALE_FACTORS=1
Comment 10 Patrick Silva 2018-04-22 23:04:31 UTC
*** Bug 392960 has been marked as a duplicate of this bug. ***
Comment 11 Ace 2019-01-29 16:09:23 UTC
This is still an issue for me with Yakuake 3.0.5, Plasma 5.14.5, and QT 5.12, and Frameworks version 5.54.0. 

The only workaround for my use case is to use Yakuake 'Fullscreen' (ctrl+shift+F11) but this has the undesirable side effect of forcing Yakuake to be on top of any windows on the same virtual desktop, i.e. 'keep above' no longer works the way it should. 

Kernel 4.20 but that doesn't really matter.
Comment 12 Peifeng Yu 2019-01-29 16:15:58 UTC
I've found a workaround. Adding/removing virtual desktops seems to force Qt to recalculate the desktop size and makes Yakuake's sizing correct.
Comment 13 Patrick Silva 2019-02-28 13:59:31 UTC
both bug 388217 and bug 401982 seem related/duplicate.
Comment 14 Patrick Silva 2019-02-28 14:40:27 UTC
bug 377063 seems related
Comment 15 George Moutsopoulos 2019-05-28 11:41:34 UTC
comment https://bugs.kde.org/show_bug.cgi?id=389448#c9
works for me
Comment 16 FeepingCreature 2019-06-12 14:28:00 UTC
https://bugs.kde.org/show_bug.cgi?id=389448#c9 works for me as well.
Comment 17 Andrew Hou 2020-02-29 23:05:50 UTC
*** Bug 369178 has been marked as a duplicate of this bug. ***
Comment 18 Andrew Hou 2020-02-29 23:20:58 UTC
bug 396814 and bug 415184 seem to be related.
Comment 19 Andrew Hou 2020-03-01 00:53:28 UTC
Spent some time digging into it, and this is what I came up with regarding this bug:

The issue appears to happen whenever windows scaling of Plasma is set to
something greater than 1 on a high dpi monitor. Yakuake will generate its
initial dimensions based off of the original, unscaled dpi. This is accurate to observations of various testing on a high dpi system

This is why Yakuake isn't centered on the screen:
Yakuake specifies its own width via percentage of the max width of the screen,
but it does so before the dpi is scaled.

The issue seems to be reliably solved when a new virtual desktop is generated
and Yakuake is reopened in it. Somehow, this generation forces Yakuake to
recalculate the screen width in accordance to the scaled values.

getDesktopGeometry() at yakuake/app/mainwindow.cpp:1435 seems to be where
Yakuake is getting the information used to determine its dimensions.

For non-Wayland and non-fullscreen, KWindowSystem::workArea() in
kwindowsystem.cpp:601 is being called, which appears to then call
devicePixelRatio()

I believe this is the reason why the bug occurs: devicePixelRatio(), from the
QGuiApplication class simply gets the HIGHEST screen device pixel ratio found
on the system.

We need to somehow programmatically determine the user's specified
display/monitor scaling, and apply this in KwindowSystem::workArea()

This can potentially done by using QWindow::devicePixelRatio() instead of
QGuiApplication::devicePixelRatio(), as the QWindow variant specifically gets
the pixel ratio for the specified window, which should respect the system's
dpi scaling.

I suspect that the creation of a virtual desktop on Plasma forces
a re-calculation of devicePixelRatio(), potentially being called from QWindow,
which is why the Yakuake window is 'fixed' when generating a new Plasma
desktop. This is all speculation, however.
Comment 20 Andrew Hou 2020-03-01 03:07:50 UTC
*** Bug 415184 has been marked as a duplicate of this bug. ***
Comment 21 Gregory Ernest 2020-03-01 03:19:35 UTC
Created attachment 126511 [details]
attachment-31031-0.html

Right I put too many reports in, my mistake! Sorry!
I think a total of 4 0ver the last yr. Did not know better.

regards;
GE

On Sat, Feb 29, 2020 at 10:07 PM Andrew Hou <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=389448
>
> Andrew Hou <andrewfhou@gmail.com> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |gregorye541@gmail.com
>
> --- Comment #20 from Andrew Hou <andrewfhou@gmail.com> ---
> *** Bug 415184 has been marked as a duplicate of this bug. ***
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 22 Andrew Hou 2020-03-01 03:59:08 UTC
*** Bug 388217 has been marked as a duplicate of this bug. ***
Comment 23 Andrew Hou 2020-03-01 04:02:19 UTC
*** Bug 377063 has been marked as a duplicate of this bug. ***
Comment 24 Andrew Hou 2020-03-01 07:06:49 UTC
*** Bug 416901 has been marked as a duplicate of this bug. ***
Comment 25 Andrew Hou 2020-03-01 07:17:42 UTC
*** Bug 415022 has been marked as a duplicate of this bug. ***
Comment 26 Gregory Ernest 2020-03-01 13:36:08 UTC
Created attachment 126520 [details]
attachment-8639-0.html

Yes it probably is, thanks

On Sun, Mar 1, 2020 at 2:17 AM Andrew Hou <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=389448
>
> --- Comment #25 from Andrew Hou <andrewfhou@gmail.com> ---
> *** Bug 415022 has been marked as a duplicate of this bug. ***
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 27 Gregory Ernest 2020-03-01 14:42:49 UTC
Created attachment 126523 [details]
attachment-10060-0.html

This has been fixed. Thank you guy's so much for doing this for me!
Have a blessed life!
GE

On Sun, Mar 1, 2020 at 9:18 AM Nate Graham <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=389448
>
> Nate Graham <nate@kde.org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>            Priority|NOR                         |HI
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 28 phrxmd 2020-06-14 08:41:39 UTC
(In reply to Gregory Ernest from comment #27)
> This has been fixed. Thank you guy's so much for doing this for me!
> Have a blessed life!
> GE

Has this been fixed? the problem persists for me in recent OpenSUSE Tumbleweed (Plasma 5.19, KDE Frameworks 5.70, Qt 5.15, Yakuake 20.04.1 which reports itself as 3.0.5+)
Comment 29 phrxmd 2020-06-27 16:02:26 UTC
I've been seeing this bug after moving my configuration from Kubuntu to OpenSUSE Tumbleweed. To get back proper scaling in Plasma, I had to set global scaling to 200% and PLASMA_USE_QT_SCALING=1 (in Kubuntu I had been using global scaling 100% and had set the scale using screen DPI). Since then Yakuake has been showing this behaviour. 

This seems to be consistent with Andrew Hou's observation that the initial geometry is based on a mix-up between logical and physical dimensions.

In the meantime, I am resorting to an ugly workaround with a startup script that adds and then removes a virtual desktop using wmctrl.
Comment 30 Nate Graham 2020-06-27 16:36:11 UTC
Yes, it makes sense. When using PLASMA_USE_QT_SCALING=1, there's a mismatch in resolutions because Plasma uses the logical (scaled) resolution while KWin and KWindowSystem still speak in physical (unscaled) resolutions. This doesn't happen on Wayland because both of them use the logical resolution there.

As far as I can tell, it's not super feasible to teach KWin to speak logical resolutions, so we need to convert between the two, probbly by having Yaukaue multiply the resolution it gets back from KWindowSystem by the device pixel ratio.
Comment 31 Gregory Ernest 2020-06-27 19:05:07 UTC
Thank you

On Sat, Jun 27, 2020 at 12:02 PM Philipp Reichmuth
<bugzilla_noreply@kde.org> wrote:
>
> https://bugs.kde.org/show_bug.cgi?id=389448
>
> --- Comment #29 from Philipp Reichmuth <philipp.reichmuth@gmail.com> ---
> I've been seeing this bug after moving my configuration from Kubuntu to
> OpenSUSE Tumbleweed. To get back proper scaling in Plasma, I had to set global
> scaling to 200% and PLASMA_USE_QT_SCALING=1 (in Kubuntu I had been using global
> scaling 100% and had set the scale using screen DPI). Since then Yakuake has
> been showing this behaviour.
>
> This seems to be consistent with Andrew Hou's observation that the initial
> geometry is based on a mix-up between logical and physical dimensions.
>
> In the meantime, I am resorting to an ugly workaround with a startup script
> that adds and then removes a virtual desktop using wmctrl.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 32 Gregory Ernest 2020-06-27 19:05:47 UTC
Thanks again

On Sat, Jun 27, 2020 at 12:36 PM Nate Graham <bugzilla_noreply@kde.org> wrote:
>
> https://bugs.kde.org/show_bug.cgi?id=389448
>
> Nate Graham <nate@kde.org> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Summary|Width and height of the     |Width and height of the
>                    |window doesn't set          |window doesn't set
>                    |correctly on HiDPI screen   |correctly on HiDPI screen
>                    |after upgrade to plasma     |when using Plasma Qt
>                    |5.12                        |scaling on X11
>              Blocks|                            |356446
>
> --- Comment #30 from Nate Graham <nate@kde.org> ---
> Yes, it makes sense. When using PLASMA_USE_QT_SCALING=1, there's a mismatch in
> resolutions because Plasma uses the logical (scaled) resolution while KWin and
> KWindowSystem still speak in physical (unscaled) resolutions. This doesn't
> happen on Wayland because both of them use the logical resolution there.
>
> As far as I can tell, it's not super feasible to teach KWin to speak logical
> resolutions, so we need to convert between the two, probbly by having Yaukaue
> multiply the resolution it gets back from KWindowSystem by the device pixel
> ratio.
>
>
> Referenced Bugs:
>
> https://bugs.kde.org/show_bug.cgi?id=356446
> [Bug 356446] plasmashell does not respect QT_DEVICE_PIXEL_RATIO on X
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 33 Nate Graham 2020-06-28 15:26:24 UTC
Should be fixed by https://invent.kde.org/utilities/yakuake/-/merge_requests/22
Comment 34 Gregory Ernest 2020-06-28 15:36:19 UTC
thanks so much for the direct attention to this.


On Sun, Jun 28, 2020 at 11:26 AM Nate Graham <bugzilla_noreply@kde.org> wrote:
>
> https://bugs.kde.org/show_bug.cgi?id=389448
>
> Nate Graham <nate@kde.org> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|CONFIRMED                   |ASSIGNED
>
> --- Comment #33 from Nate Graham <nate@kde.org> ---
> Should be fixed by https://invent.kde.org/utilities/yakuake/-/merge_requests/22
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 35 Nate Graham 2020-07-02 16:27:05 UTC
This is working properly for me when using PLASMA_USE_QT_SCALING=1 on X11 with everything from git master on a high DPI screen.

Can anyone with a similar setup confirm or deny?
Comment 36 Andrew Hou 2020-07-04 00:51:50 UTC
This works for me as well on my machine (X11, non-HiDPI screen, simulated with display scaled to 125%), both without the PLASMA_USE_QT_SCALING environment variable set, and with it set to 1
Comment 37 Gregory Ernest 2020-07-04 01:21:14 UTC
Andrew I hope you are well, Thank you and the other's that have worked
on this for me! I really do appreciate that and so far things seem
fine. I see Yakuake change from the small to the default size. That is
great! You have a nice holiday weekend and of course Stay safe. Hope
your University is accommodating you and others during this difficult
time. Again thank you so much!

Greg

On Fri, Jul 3, 2020 at 8:51 PM Andrew Hou <bugzilla_noreply@kde.org> wrote:
>
> https://bugs.kde.org/show_bug.cgi?id=389448
>
> --- Comment #36 from Andrew Hou <andrewfhou@gmail.com> ---
> This works for me as well on my machine (X11, non-HiDPI screen, simulated with
> display scaled to 125%), both without the PLASMA_USE_QT_SCALING environment
> variable set, and with it set to 1
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 38 Nate Graham 2020-07-04 02:05:08 UTC
Awesome, looks like this got accidentally fixed somewhere else! :)
Comment 39 Lastique 2020-07-04 08:50:37 UTC
Is the fix only enabled by PLASMA_USE_QT_SCALING=1? If so, why is it not the default?

I would prefer that the bug stays open until it works as intended out of the box.
Comment 40 Gregory Ernest 2020-07-04 19:41:49 UTC
Thank you Nate, Happy holiday!

On Sat, Jul 4, 2020 at 4:50 AM Lastique <bugzilla_noreply@kde.org> wrote:
>
> https://bugs.kde.org/show_bug.cgi?id=389448
>
> --- Comment #39 from Lastique <andysem@mail.ru> ---
> Is the fix only enabled by PLASMA_USE_QT_SCALING=1? If so, why is it not the
> default?
>
> I would prefer that the bug stays open until it works as intended out of the
> box.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 41 Nate Graham 2020-07-06 14:16:28 UTC
Looks like it works both with and without it now, and I've proposed making it the default in https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/139/diffs
Comment 42 Gregory Ernest 2020-07-06 15:23:00 UTC
Thanks Nate for the info, things seem much better on my end. What you
guy's do is very special. Please stay safe and tell your team I
appreciate everything!

Best regards;

Greg

On Mon, Jul 6, 2020 at 10:16 AM Nate Graham <bugzilla_noreply@kde.org> wrote:
>
> https://bugs.kde.org/show_bug.cgi?id=389448
>
> --- Comment #41 from Nate Graham <nate@kde.org> ---
> Looks like it works both with and without it now, and I've proposed making it
> the default in
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/139/diffs
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 43 Nate Graham 2020-07-16 19:28:23 UTC
*** Bug 412308 has been marked as a duplicate of this bug. ***
Comment 44 Lê Hoàng Phương 2020-08-28 00:11:45 UTC
*** Bug 417959 has been marked as a duplicate of this bug. ***
Comment 45 phrxmd 2020-08-28 14:38:05 UTC
which version is this fixed in? I'm still seeing the same behaviour with Yakuake 20.08.0, Plasma 5.19.4, Frameworks 5.73.0, Qt 5.15.0. 

With screen scaling set to 200% and PLASMA_USE_QT_SCALING=1, Yakuake opens at 50% screen with. If I add and remove a virtual desktop, it rescales to 100% screen with. Before the 20.08 update, it would resize instantly; since the 20.08 update I have to close and reopen the Yakuake terminal window.
Comment 46 phrxmd 2020-10-16 22:47:28 UTC
I still get this problem with Yakuake 20.08.2, Plasma 5.20.0, Frameworks 5.75.

At 200% display scaling on X11, the Yakuake window opens across 50% of the screen. As soon as I add and remove a virtual desktop, the window opens across the full width of the screen.

This happens only on X11, in the Wayland session it works fine out of the box.
Comment 47 Gregory Ernest 2020-10-17 13:50:59 UTC
Thank you for the info, Have a nice weekend.

On Fri, Oct 16, 2020 at 6:47 PM Philipp Reichmuth
<bugzilla_noreply@kde.org> wrote:
>
> https://bugs.kde.org/show_bug.cgi?id=389448
>
> --- Comment #46 from Philipp Reichmuth <philipp.reichmuth@gmail.com> ---
> I still get this problem with Yakuake 20.08.2, Plasma 5.20.0, Frameworks 5.75.
>
> At 200% display scaling on X11, the Yakuake window opens across 50% of the
> screen. As soon as I add and remove a virtual desktop, the window opens across
> the full width of the screen.
>
> This happens only on X11, in the Wayland session it works fine out of the box.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 48 stedlev 2020-10-17 16:30:38 UTC
I was able to resolve this by deleting ~/.config/yakuakerc and resetting the settings. It fixed the half open problem for me. It was still doing it even when I had two 1440p screens, one in landscape and one in portrait.
Comment 49 phrxmd 2020-10-22 10:49:21 UTC
Created attachment 132632 [details]
Behaviour on HiDPI screen with 20.08.2 and Plasma 5.20

So I deleted .yakuakerc, and when it didn't work I cleaned out my .config directory and started from scratch. Yakuake 20.08.2, Plasma 5.20.0, Frameworks 5.75.0, Qt 5.15.1 on OpenSUSE TW, screen scaling set to 200%. 

The screencast shows the behaviour I'm still seeing: Yakuake opens at 50% screen width until I add and remove a virtual desktop, the next time I open it it opens at 100%.
Comment 50 Gregory Ernest 2020-10-22 12:00:06 UTC
You seem to be making some headway, Good job! thank you again for the
information,

Greg

On Thu, Oct 22, 2020 at 6:49 AM Philipp Reichmuth
<bugzilla_noreply@kde.org> wrote:
>
> https://bugs.kde.org/show_bug.cgi?id=389448
>
> --- Comment #49 from Philipp Reichmuth <philipp.reichmuth@gmail.com> ---
> Created attachment 132632 [details]
>   --> https://bugs.kde.org/attachment.cgi?id=132632&action=edit
> Behaviour on HiDPI screen with 20.08.2 and Plasma 5.20
>
> So I deleted .yakuakerc, and when it didn't work I cleaned out my .config
> directory and started from scratch. Yakuake 20.08.2, Plasma 5.20.0, Frameworks
> 5.75.0, Qt 5.15.1 on OpenSUSE TW, screen scaling set to 200%.
>
> The screencast shows the behaviour I'm still seeing: Yakuake opens at 50%
> screen width until I add and remove a virtual desktop, the next time I open it
> it opens at 100%.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 51 phrxmd 2020-10-22 13:39:25 UTC
I'm reopening this, the behaviour persists for me on Yakuake 20.08.2 with Plasma 5.20.0 on OpenSUSE TW 20201021. I've removed ~/.config/yakuakerc and cleared out ~/.cache and I'm still seeing the same thing (see screencast).
Comment 52 phrxmd 2020-11-12 14:42:55 UTC
If it helps - interestingly if I kill the Yakuake process and restart it, it opens correctly from the start, so there is some change here that persists.

Steps to reproduce on my system (recent OpenSUSE TW, X11, KDE 5.20.2, scale factor 200%, 9 virtual desktops, Yakuake bound to F12 key):

1. Initial launch of Yakuake (e.g. through autostart)
2. Press F12, Yakuake window opens at 50% width
3. Type `wmctrl -n 10 && wmctrl -n 9` (i.e. add and remove a virtual desktop)
4. Press Esc to close the Yakuake window, which is still at 50% width
5. Press F12 again, Yakuake window now opens at 100% width
6. Type `killall -9 yakuake` 
7. Open Konsole, in Konsole type `ps -ax | grep yakuake` --> not running
8. Launch Yakuake again
9. Press F12, Yakuake window still opens at 100% width
Comment 53 Gregory Ernest 2020-11-12 17:59:15 UTC
Thank you Philipp Reichmuth for this valuable update. Please stay safe
and thank you all for working on this bug.
Gregory Ernest

On Thu, Nov 12, 2020 at 9:42 AM Philipp Reichmuth
<bugzilla_noreply@kde.org> wrote:
>
> https://bugs.kde.org/show_bug.cgi?id=389448
>
> --- Comment #52 from Philipp Reichmuth <philipp.reichmuth@gmail.com> ---
> If it helps - interestingly if I kill the Yakuake process and restart it, it
> opens correctly from the start, so there is some change here that persists.
>
> Steps to reproduce on my system (recent OpenSUSE TW, X11, KDE 5.20.2, scale
> factor 200%, 9 virtual desktops, Yakuake bound to F12 key):
>
> 1. Initial launch of Yakuake (e.g. through autostart)
> 2. Press F12, Yakuake window opens at 50% width
> 3. Type `wmctrl -n 10 && wmctrl -n 9` (i.e. add and remove a virtual desktop)
> 4. Press Esc to close the Yakuake window, which is still at 50% width
> 5. Press F12 again, Yakuake window now opens at 100% width
> 6. Type `killall -9 yakuake`
> 7. Open Konsole, in Konsole type `ps -ax | grep yakuake` --> not running
> 8. Launch Yakuake again
> 9. Press F12, Yakuake window still opens at 100% width
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 54 phrxmd 2020-11-30 12:50:08 UTC
With a more recent update (TW 20201127, Plasma 5.20.3, Frameworks 5.76, Qt 5.15.2, Yakuake 20.08.3) the problem has disappeared for me.
Comment 55 Gregory Ernest 2020-11-30 14:48:15 UTC
My problem seems to be resolved also. thank you guys so much for
dealing with this problem. Happy Holidays and be safe!

On Mon, Nov 30, 2020 at 7:50 AM Philipp Reichmuth
<bugzilla_noreply@kde.org> wrote:
>
> https://bugs.kde.org/show_bug.cgi?id=389448
>
> --- Comment #54 from Philipp Reichmuth <philipp.reichmuth@gmail.com> ---
> With a more recent update (TW 20201127, Plasma 5.20.3, Frameworks 5.76, Qt
> 5.15.2, Yakuake 20.08.3) the problem has disappeared for me.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 56 Nate Graham 2020-11-30 14:50:05 UTC
Phew!
Comment 57 Gregory Ernest 2020-12-01 18:19:04 UTC
If I didn't thank you all for your talented efforts, I am grateful.
Happy holidays and stay safe guy',s.

On Mon, Nov 30, 2020 at 9:50 AM Nate Graham <bugzilla_noreply@kde.org> wrote:
>
> https://bugs.kde.org/show_bug.cgi?id=389448
>
> Nate Graham <nate@kde.org> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>          Resolution|---                         |FIXED
>              Status|REOPENED                    |RESOLVED
>
> --- Comment #56 from Nate Graham <nate@kde.org> ---
> Phew!
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.