| Summary: | After making the default panel vertically-oriented, Kickoff's layout is messed up until plasmashell is restarted | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | MitraX <mitrax> |
| Component: | Application Launcher (Kickoff) widget | Assignee: | David Edmundson <kde> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bfeber, bugseforuns, cupn8dles, darktori, domus.kopf, dsx.box, gisk+kdebugs, kde, kinetocore, kiril, mcmailface, nate, piotr.mierzwinski, plasma-bugs, reavertm, thomas.florenson.dev |
| Priority: | HI | Keywords: | usability |
| Version: | 5.16.2 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/plasma-framework/144bb90715410178dd8334a73841d287d729e41f | Version Fixed In: | 5.62 |
| Sentry Crash Report: | |||
| Attachments: |
KDE Application Launcher Favorite Panel
Changed colors of KickOff after applying Dmiry fix my original look of KickOff Attempt to patch |
||
Same bug on Arch Linux, plasma 5.13. I would like to confirm this bug and provide a video: https://imgur.com/a/z2R6pXo *** Bug 396583 has been marked as a duplicate of this bug. *** *** Bug 394626 has been marked as a duplicate of this bug. *** *** Bug 399493 has been marked as a duplicate of this bug. *** *** Bug 400063 has been marked as a duplicate of this bug. *** *** Bug 398423 has been marked as a duplicate of this bug. *** *** Bug 393697 has been marked as a duplicate of this bug. *** This may be caused by https://phabricator.kde.org/D11098 *** Bug 400885 has been marked as a duplicate of this bug. *** 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 >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.
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.
> implicit height
sorry, it is "explicit"
(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 Created attachment 118236 [details]
Changed colors of KickOff after applying Dmiry fix
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. (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. Created attachment 118260 [details]
my original look of KickOff
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. Ping *** Bug 408648 has been marked as a duplicate of this bug. *** Still present, in Plasma v5.16.2. 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.
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! 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/ The patch was submitted on Phabricator: https://phabricator.kde.org/D22988 It's winding its way through the review process now :) 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 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 |
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.