Bug 395390 - After making the default panel vertically-oriented, Kickoff's layout is messed up until plasmashell is restarted
Summary: After making the default panel vertically-oriented, Kickoff's layout is messe...
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Application Launcher (Kickoff) widget (show other bugs)
Version: 5.16.2
Platform: Neon Linux
: HI normal
Target Milestone: 1.0
Assignee: David Edmundson
URL:
Keywords: usability
: 393697 394626 396583 398423 399493 400063 400885 408648 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-06-14 19:08 UTC by MitraX
Modified: 2019-08-09 02:33 UTC (History)
16 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.62
Sentry Crash Report:


Attachments
KDE Application Launcher Favorite Panel (174.22 KB, image/png)
2018-06-14 19:08 UTC, MitraX
Details
Changed colors of KickOff after applying Dmiry fix (184.58 KB, image/png)
2019-02-20 22:00 UTC, Piotr Mierzwinski
Details
my original look of KickOff (169.01 KB, image/png)
2019-02-21 20:04 UTC, Piotr Mierzwinski
Details
Attempt to patch (6.08 KB, patch)
2019-08-06 03:05 UTC, Konstantin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description MitraX 2018-06-14 19:08:17 UTC
Created attachment 113325 [details]
KDE Application Launcher Favorite Panel

DESCRIPTION:

If you run the Application Launcher for the first time after log in, the Favorites item missing from KDE Application Launcher in vertically oriented panel.

REPRODUCIBILITY: Always

STEPS TO REPRODUCE:

1) Turn on the computer (or log out / log in to new session)

2) Click the "Application Launcher"

EXPTECTED BEHAVIOR:

All panels are visible (Favorites, Application, Computer, History...)

ACTUAL BEHAVIOR:

Favorites panel missing (picture 1) and it appears only if a user hovers any of displayed panels (picture 2). From this point on, the Favorites panel is visible every time when the Application Launcher is open without any issue.

ENVIRONMENT:

Platform: KDE Neon 5.13
KDE Plasma Version: 5.13.0
KDE Framework Version: 5.47.0
Qt Version: 5.11.0
Kernel Version: 4.13.0-45-generic

NOTE: The issue is note tested in horizontally oriented panel.
Comment 1 Patrick Silva 2018-06-15 21:54:28 UTC
Same bug on Arch Linux, plasma 5.13.
Comment 2 darktori 2018-07-25 18:19:10 UTC
I would like to confirm this bug and provide a video: https://imgur.com/a/z2R6pXo
Comment 3 darktori 2018-07-25 19:57:08 UTC
*** Bug 396583 has been marked as a duplicate of this bug. ***
Comment 4 Patrick Silva 2018-07-26 01:43:50 UTC
*** Bug 394626 has been marked as a duplicate of this bug. ***
Comment 5 Patrick Silva 2018-10-08 01:18:01 UTC
*** Bug 399493 has been marked as a duplicate of this bug. ***
Comment 6 Nate Graham 2018-10-20 14:18:06 UTC
*** Bug 400063 has been marked as a duplicate of this bug. ***
Comment 7 Nate Graham 2018-10-20 15:46:41 UTC
*** Bug 398423 has been marked as a duplicate of this bug. ***
Comment 8 Nate Graham 2018-10-20 15:46:49 UTC
*** Bug 393697 has been marked as a duplicate of this bug. ***
Comment 9 Nate Graham 2018-10-20 21:26:48 UTC
This may be caused by https://phabricator.kde.org/D11098
Comment 10 Patrick Silva 2018-11-09 22:43:47 UTC
*** Bug 400885 has been marked as a duplicate of this bug. ***
Comment 11 Thomas Florenson 2018-12-05 20:11:48 UTC
Hi!

For me this bug reeks of an init problem when the display is vertical. I couldn't find where the horizontal/vertical properties are set in the kickoff code but it's probably done in a more generic piece of code.

Anyway, browsing the source code in 
https://cgit.kde.org/plasma-desktop.git/tree/applets/kickoff/package/contents/ui
I could find a suspicious function in KickoffItem.qml:

PlasmaCore.SvgItem {
        id: arrow

        anchors {
            right: parent.right
            rightMargin: units.gridUnit * 2
            verticalCenter: parent.verticalCenter
        }

        width: visible ? units.iconSizes.small : 0
        height: width

        visible: (model.hasChildren == true)
        opacity: (listItem.ListView.view.currentIndex == index) ? 1.0 : 0.4

        svg: arrowsSvg
        elementId: (Qt.application.layoutDirection == Qt.RightToLeft) ? "left-arrow" : "right-arrow"
    }

Here, visible: is used before it's set. Therefore, if it's been initialized to false, the SvgItem will not be visible at the first call (the first item), but visible on subsequent calls. Also the height and width properties will be 0, which is consistent with the observed behavior (see picture by MitraX).

I would simply set visible: before width: and see if it corrects the problem.
Unfortunately I don't have KDE dev tools installed so it's a bother to test. Would someone try it? Thanks!

NB: I don't use QML so my code reading might be wrong
Comment 12 David Edmundson 2018-12-05 20:33:13 UTC
>Here, visible: is used before it's set.


No, QML is a declarative language not a programmatic one, there's no concept of order at this level.
Comment 13 Dmitry Khlestkov 2019-02-19 22:08:38 UTC
I'm using locally modified version of kickoff with this modifications for "left" orientation (ui/FullRepresentation.qml):

  AnchorChanges {
    target: tabBar
    anchors {
      left: root.left
-     top: root.top
      right: undefined
      bottom: header.top
    }
  }

+ PropertyChanges {
+   target: tabBar
+   height: units.gridUnit * 29
+  }

E.g. anchors.top replaced with implicit height. Similar workaround may be applied to "right" orientation. Obviously height should be calculated from tab count instead of being hardcoded.

Yes, this is not a proper fix but we can't be picky at this moment, can we? I've reported this issue 10 months ago and no one seems to have skills and/or resolve to fix it properly.
Comment 14 Dmitry Khlestkov 2019-02-20 05:27:43 UTC
> implicit height

sorry, it is "explicit"
Comment 15 Piotr Mierzwinski 2019-02-20 21:55:23 UTC
(In reply to Dmitry Khlestkov from comment #13)
> I'm using locally modified version of kickoff with this modifications for
> "left" orientation (ui/FullRepresentation.qml):
> 
>   AnchorChanges {
>     target: tabBar
>     anchors {
>       left: root.left
> -     top: root.top
>       right: undefined
>       bottom: header.top
>     }
>   }
> 
> + PropertyChanges {
> +   target: tabBar
> +   height: units.gridUnit * 29
> +  }
> 
> E.g. anchors.top replaced with implicit height. Similar workaround may be
> applied to "right" orientation. Obviously height should be calculated from
> tab count instead of being hardcoded.
> 
> Yes, this is not a proper fix but we can't be picky at this moment, can we?
> I've reported this issue 10 months ago and no one seems to have skills
> and/or resolve to fix it properly.

I applied your changes to the "right" orientation. Issue with disappearing button seems to be fixed, but unfortunately body (place where I see for example "All Applications") just changed color or actually became much brightest (looks like all would be disabled) than right vertical bar with buttons. Note that in original version color body and vertical bar are the same. I suppose this is because of using "tabBar" in "PropertyChanges".

I use Breeze dark scheme and kvantum addon.
After changes I restarted plasmashell like this:
  kbuildsycoca5 && kquitapp5 plasmashell && kstart5 plasmashell
Comment 16 Piotr Mierzwinski 2019-02-20 22:00:49 UTC
Created attachment 118236 [details]
Changed colors of KickOff after applying Dmiry fix
Comment 17 Dmitry Khlestkov 2019-02-21 19:18:19 UTC
Piotr,

how it is supposed to look like? I checked your original Bug 396583 and both screenshots looks different from this one.

Anyway, I don't think I can help. You have to "play" with qml to find what is working for you.
Comment 18 Piotr Mierzwinski 2019-02-21 20:03:17 UTC
(In reply to Dmitry Khlestkov from comment #17)
> Piotr,
> 
> how it is supposed to look like? I checked your original Bug 396583 and both
> screenshots looks different from this one.
I meant that whole window should have the same color like vertical button bar or don't have such contrast   between body and vertical button bar. Just please take a look at attached (new) screen shot.
 
> Anyway, I don't think I can help. You have to "play" with qml to find what
> is working for you.
I was playing a little bit just changing code you proposed. Unfortunately without success, because usually vertical buttons bar just disappeared after my changes. I will wait maybe somebody more experienced in qml will look at out issue.
Comment 19 Piotr Mierzwinski 2019-02-21 20:04:38 UTC
Created attachment 118260 [details]
my original look of KickOff
Comment 20 HM 2019-03-04 13:56:42 UTC
I can confirm the bug on plasmashell 5.15.1. And although I remember this bug appearing only after I updated to a plasma version a while back, I unfortunately do not remember the version.
Comment 21 Björn Feber 2019-04-21 14:42:38 UTC
Ping
Comment 22 Nate Graham 2019-06-13 20:46:26 UTC
*** Bug 408648 has been marked as a duplicate of this bug. ***
Comment 23 MitraX 2019-07-02 10:46:52 UTC
Still present, in Plasma v5.16.2.
Comment 24 Konstantin L 2019-08-06 03:05:56 UTC
Created attachment 121955 [details]
Attempt to patch

Hello! I have attempted to fix it, or at least some portions of it that I did reproduce. I'm not sure how correct the code is, but so far it's working fine on my laptop and desktop.
Comment 25 Nate Graham 2019-08-06 19:18:08 UTC
Thanks very much! Looking at your patch, it seems like the changes to do round() instead of floor() are unrelated; if so, please omit them. Also code that's commented out should be deleted instead. After that, I would encourage you to submit your patch to https://phabricator.kde.org! Here's the documentation: https://community.kde.org/Infrastructure/Phabricator

For reviewers, you can add #plasma, @hein, and @ngraham

Looking forward to seeing it there!
Comment 26 Piotr Mierzwinski 2019-08-07 20:51:58 UTC
I can confirm that patch works. I mean that issue I reported here: Bug 396583 just disappeared. I followed for instruction placed here:
https://gitlab.com/snippets/1882509

BTW.
There is also thread on reddit mentioning about this issue:
https://www.reddit.com/r/kde/comments/cm8bef/i_forked_kickoff_and_made_favorites_display_in_a/
Comment 27 Nate Graham 2019-08-07 22:00:13 UTC
The patch was submitted on Phabricator: https://phabricator.kde.org/D22988

It's winding its way through the review process now :)
Comment 28 Nate Graham 2019-08-09 02:29:26 UTC
Git commit e2cd97d822d3c96754c875a83a41276db6114347 by Nate Graham.
Committed on 09/08/2019 at 02:28.
Pushed by ngraham into branch 'master'.

Fix incorrect initial tabs position for vertical tab bars

Summary:
This fixes the incorrect initial positioning of the tabs for vertical
tab bars that persisted until the user switched to another tab
manually.
FIXED-IN: 5.62

Reviewers: #plasma, ngraham, hein

Reviewed By: #plasma, ngraham, hein

Subscribers: kde-frameworks-devel

Tags: #frameworks

Maniphest Tasks: T10047

Differential Revision: https://phabricator.kde.org/D23036

M  +5    -11   src/declarativeimports/plasmacomponents/qml/TabBar.qml

https://commits.kde.org/plasma-framework/e2cd97d822d3c96754c875a83a41276db6114347
Comment 29 Nate Graham 2019-08-09 02:33:50 UTC
Git commit 144bb90715410178dd8334a73841d287d729e41f by Nate Graham, on behalf of Konstantin Lisin.
Committed on 09/08/2019 at 02:33.
Pushed by ngraham into branch 'master'.

Fix incorrect initial tabs position for vertical tab bars

Summary:
This fixes the incorrect initial positioning of the tabs for vertical
tab bars that persisted until the user switched to another tab
manually.
FIXED-IN: 5.62

Reviewers: #plasma, ngraham, hein

Reviewed By: #plasma, ngraham, hein

Subscribers: kde-frameworks-devel

Tags: #frameworks

Maniphest Tasks: T10047

Differential Revision: https://phabricator.kde.org/D23036

M  +5    -11   src/declarativeimports/plasmacomponents/qml/TabBar.qml

https://commits.kde.org/plasma-framework/144bb90715410178dd8334a73841d287d729e41f