SUMMARY I am writing to kindly request a new feature for the new Kickoff Menu which will be released with Plasma 5.21 I'd like to suggest to add the possibility to show the applications categories (Graphics,Internet, Multimedia, Office, etc...) both in a grid and in a list, Just the same way It can already be done for the category “favorites:” which by default shows fav applications in a grid similar to an "icons view" I think this would be much helpful in terms of speed and usability for all the visual thinkers among all the modern KDE users, I really believe it's the only thing the new stock menu is still lacking in terms of functionality and freedom of customization, otherwise it is luckily already way ahead compared to its predecessor and other linux and non-linux menus. I'm writing here because I'm not able to implement this feature myself, so I thought this would allow for anyone interested to pick this feature up and if they want, hopefully implement it. I also think It shouldn't be technically hard since the feature is already present in the new menu (and in its code). STEPS TO REPRODUCE 1. New Kickoff menù has "favorite" category set by default in a sort of "icon view" way, called "show in a grid". 2. In the “Configure Application Launcher...” Tab we can also set "favorite" view to "in a list". 3. Other Application categories have only the chance to be viewed "in a list", and there's no way of customizing their view as in "in a grid" like it happens for "favorite". OBSERVED RESULT No way of showing applications categories "in a grid" EXPECTED RESULT Allowing to set the view for application categories both in a grid and in a list, by modifying the parameters in the “Configure Application Launcher...” tab. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: KDE Plasma 5.21 (available in About System) KDE Plasma Version: KDE Plasma 5.21 KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Right now the categories are shown as a sidebar, and a sidebar which is tall and narrow inherently wants to display a list, not a grid. Are you saying that the list inside the sidebar should be a grid instead anyway? Or something else? Maybe you could produce a mockup that shows your proposal so it's more clear?
I think they meant the apps *inside* the category (aka the right panel)
(In reply to Mikel Johnson from comment #2) > I think they meant the apps *inside* the category (aka the right panel) Indeed, thank you Mikel, that's exactly what I meant.
Created attachment 137053 [details] Figure A: apps *inside* category "Internet" showed by default "in a list"
Created attachment 137054 [details] Figure B: apps *inside* category "Internet" showed "in a grid" (Mockup)
Created attachment 137055 [details] Favorites: apps *inside* category "Favorites" already shown "in a grid" by default
(In reply to Nate Graham from comment #1) > Right now the categories are shown as a sidebar, and a sidebar which is tall > and narrow inherently wants to display a list, not a grid. Are you saying > that the list inside the sidebar should be a grid instead anyway? Or > something else? Maybe you could produce a mockup that shows your proposal so > it's more clear? Hi Nate, as Mikel thankfully pointed out for me, I meant the apps *inside* the category (aka the right panel). In order to be clearer I attached 3 Pictures: - "Figure A" shows, as an example, the apps inside the "Internet" category as they are already shown now by default, aka "in a list". But that parameter is currently not modifiable in the menu setting tab. - "Figure B" shows a mockup I created in order to indicate the above mentioned apps inside the "Internet" category as if they could also be shown "in a grid", which is the same way the category "Favorites" is shown by default. - "Favorites" just shows how the "show in a grid" mode is already viewable by default (that is the only category inside which the apps can be shown both "in a grid" and "in a list" changing the parameters in the menu setting tab. I hope this helps finding someone who is willing to help implement this feature for all the apps present inside all other categories, and I think it shouldn't be hard because technically the code is already there, already used in the apps inside the "Favourite" category.
That, in addition with the chance to scroll down with the mouse wheel, on mouse over, when positioned to the right panel (aka over the apps) would allow a quicker and better usability for visual thinkers and users.
Thanks! To be honest, I'm not sure this would be a great idea. We would still want a list to display search results, since grid-based search results have no advantages over lists, and many disadvantages. So this means we would have to dynamically switch the display style between grid (when navigating normally) and a list (when displaying search results). I think this might be weird. Not convinced yet. :)
But at least leave the user the freedom over that, freedom of choice and customization to their needs, I don't think this switch would be weird at all when searching. It's a thing other KDE menus already do. Even vanilla Gnome does that. I, as a visual and usability designer myself working for 20 Years in this field (even though not in open source projects) don't think, and my point is this, that it is weirder than having that aspect covered only in One part of the menu and not in all the others, I can see why It has been chosen ti show "favorites" but then it's inconsistent to leave the chance to view them back "in a list". So, I'm asking where Is the consistecy of that First choicein First hand then?. It's Just handy. Handy as It would be applied to the rest for visual and very fast users. It's like being visually ergonomic and convenient. Not quite like removing One click or two to complete One task, but It goes really close to that for some users like me Who would like to see non proprietary software reach some peaks. We had tò wait for so long tò reach a functional vanilla menù ok KDE. Precipua kickoff wasn't so convenient. And the alternative basic menu always, always, renders poorly when there are a lot of applications installed If you Will, technically speaking, under the light of design principles What we have now It Is indeed inconsistent for perceptive reasons that are too long for me to express and define here (I spent 5 Years of university to learn about them) I don't mean by no means to offend anybody here, it's Just mere technical speech. Please seriously consider adding that option too (that has already been coded).
Unfortunately classic plain menu always "lags" in any circumstances when overloaded with installed applications, and with every graphic card. Other menus se can add as plasmoids are way too simple to cover all the functionality kickoff 2.0 finally covers in a functional way. We, as user, only lack the chance customize It a Little more to make It perfect to our needs. I always thought What distinguishes KDE from other DE Is High customization to one's needs.
https://youtu.be/qbAuxp_I0zk From minute 4:6 to minute 4:15 of the video above, there's proof that there are other users, too, Who notice this lack of customization. I'd like to point out that when you say: "I'm not sure this would be a great idea. We would still want a list to display search results, since grid-based search results have no advantages over lists, and many disadvantages. So this means we would have to dynamically switch the display style between grid (when navigating normally) and a list (when displaying search results). I think this might be weird." ...I think you don't seem to take in account the fact that what you just described already happens all the times you decide to perform a search just right after clicking the menu to open it (because "favorites" is already the first category you see when you open it, and applications there are already displayed in a grid). So basically what you called "weird" already happens in the vast majority of the times a user May make a search. Please Just consider using the code you already coded. Thanks
*** Bug 437262 has been marked as a duplicate of this bug. ***
Wow, who knew so many people liked the grid view.
(In reply to Nate Graham from comment #14) > Wow, who knew so many people liked the grid view. Wow, you're Bering very professional being sarcastico and only taking in account tour own view. That Just was to show the First impressions about a lack of customization like that, which by the way was not the only One I Met online, It Just seem counterintuitive, and people Who expressed that point of view Just pointed out, and they have been nice doing so, that It urely should be something "they" plan to do "in the future" as "they" Will fine tube the work. Thanks for taking in account Just your own point of view in a community. At least Just Say It Is not a priority. (And I don't understands why adding some code which has already been created Is hard work, but that's Just my point of view)
(In reply to Nate Graham from comment #14) > Wow, who knew so many people liked the grid view. Or, please allow me to understand, did I really have to write down anytime I saw examples like the above? I honestly did't think it was opportune, nor necessary, frankly. I just attached one example for all in real time to use as a citation before I would forget the random source,to explain a point and mostly because I thought it would suffice. I think I'm seeing some pride that I don't understand but I don't personally (and this Is just my opinion) think it's appropriate.
(In reply to Nate Graham from comment #14) > Wow, who knew so many people liked the grid view. For the record I don't want to convince you or anybody for that matters, I'm Just new to the community and I just wanted to productively discuss something in order to find a way for me and for others to optimize the menu possibily to our needs, just because I'm not able to do it myself, so I've been told that joining the community I might have met somebody (even if not the main developers) who could possibily have helped me join the effort to get there, maybe even forking the project, so I followed the advice and wrote here as a start but it didn't seem too productive. I don't know how to search for such people in order to get in touch and possibily work on it, that's the only reason I write here, anyway I'm sorry to say I don't feel taken articularly seriously or welcome.
Just for the record, I wasn't being sarcastic. It was a genuine expression of surprise. The more people want it, the more likely it is to get done in some capacity.
Actually, I think you will agree it was hard for me not to think your reply wasn't meant to generate some kind of sarcasm to be read between the lines, simply by given the fact that you did literally describe two people (me and the youtuber who uploaded that video) as "so many people, wow!". Well, I'm glad it was note the case, anyway if every the efforts I put in my "interventions" worked just for you to even keep in consideration the possibility, it was all worthy from my point of view.
I really want this functionality to be implemented in kickoff. This will make kde even better.
*** Bug 438629 has been marked as a duplicate of this bug. ***
Git commit 9d9c4f169ed424e976636a6d5fa23c7a1e40576b by Noah Davis. Committed on 19/07/2021 at 06:47. Pushed by ndavis into branch 'master'. Kickoff: Refactor and tweak design Changes: - Now uses implicit content size to set the size of the plasmoid, which fixes translated string elision issues. - Much simpler code. This is a red patch. - Reduced RAM usage. Pages that are not in use are unloaded. The models aren't unloaded, so it shouldn't negatively affect performance in other ways. - Vertical movement and opacity animation when switching from normal page to search view. - Single horizontal movement and opacity animation when switching from applications page to places page. - Opacity animation when switching from favorites grid to apps list. - KickoffListView and KickoffGridView now support PageUp, PageDown, Home, End, Ctrl+Home and Ctrl+End shortcuts like lists and grids do on the web. See https://www.w3.org/TR/wai-aria-practices-1.2/#grid - KickoffListView/KickoffGridView keyboard navigation disables hovering to change current item for 100ms. It's meant to filter out accidental mouse movement while using the arrow keys to navigate. - Add Ctrl+F shortcut to focus search bar - Focus the next item down when pressing down while the search bar is focused instead of focusing the 1st item. The old kickoff did this and made it faster to select and activate items. - Hovering near the bottom/top of a view no longer rapidly selects a series of new items lower down/higher up that are not yet visible. - Single letter section headers are now horizontally center aligned with icons. - Scroll to switch tabs. - Added pin button to keep the launcher open. - Show tooltips for list/grid items that have elided text. - Padding and spacing are more uniform. - List items have better vertical pixel alignment. - Fixed pixel alignment of arrows in sidebar category items - Sidebar list items line up with main content area list items and section headers - Labels in grid items now have consistent vertical positions. - Fixed error in tools.js with favoriteModel.enabled Related: bug 433103, bug 432270, bug 439140, bug 431913, bug 433146, bug 433241, bug 408313 FIXED-IN: 5.23 M +7 -3 applets/kickoff/package/contents/config/main.xml M +55 -97 applets/kickoff/package/contents/ui/ActionMenu.qml D +0 -142 applets/kickoff/package/contents/ui/ApplicationsGroupView.qml A +140 -0 applets/kickoff/package/contents/ui/ApplicationsPage.qml [License: LGPL(v2.0+)] D +0 -358 applets/kickoff/package/contents/ui/ApplicationsView.qml A +88 -0 applets/kickoff/package/contents/ui/BasePage.qml [License: GPL (v2+)] D +0 -55 applets/kickoff/package/contents/ui/BaseView.qml D +0 -70 applets/kickoff/package/contents/ui/Breadcrumb.qml D +0 -41 applets/kickoff/package/contents/ui/ComputerView.qml M +31 -11 applets/kickoff/package/contents/ui/ConfigGeneral.qml A +30 -0 applets/kickoff/package/contents/ui/EmptyPage.qml [License: LGPL(v2.0+)] D +0 -129 applets/kickoff/package/contents/ui/FavoritesGridView.qml D +0 -133 applets/kickoff/package/contents/ui/FavoritesView.qml A +193 -0 applets/kickoff/package/contents/ui/Footer.qml [License: GPL (v2+)] D +0 -20 applets/kickoff/package/contents/ui/FrequentlyUsedView.qml M +119 -736 applets/kickoff/package/contents/ui/FullRepresentation.qml M +186 -146 applets/kickoff/package/contents/ui/Header.qml A +59 -0 applets/kickoff/package/contents/ui/HorizontalStackView.qml [License: LGPL(v2.0+)] M +53 -27 applets/kickoff/package/contents/ui/Kickoff.qml D +0 -93 applets/kickoff/package/contents/ui/KickoffGridItem.qml M +200 -288 applets/kickoff/package/contents/ui/KickoffGridView.qml D +0 -175 applets/kickoff/package/contents/ui/KickoffItem.qml A +227 -0 applets/kickoff/package/contents/ui/KickoffItemDelegate.qml [License: GPL (v2+)] M +211 -288 applets/kickoff/package/contents/ui/KickoffListView.qml A +137 -0 applets/kickoff/package/contents/ui/KickoffSingleton.qml [License: LGPL(v2.0+)] M +43 -104 applets/kickoff/package/contents/ui/LeaveButtons.qml A +53 -0 applets/kickoff/package/contents/ui/NormalPage.qml [License: LGPL(v2.0+)] A +76 -0 applets/kickoff/package/contents/ui/PlacesPage.qml [License: LGPL(v2.0+)] D +0 -22 applets/kickoff/package/contents/ui/PlacesView.qml D +0 -18 applets/kickoff/package/contents/ui/RecentlyUsedView.qml D +0 -87 applets/kickoff/package/contents/ui/SearchView.qml D +0 -42 applets/kickoff/package/contents/ui/SectionDelegate.qml A +61 -0 applets/kickoff/package/contents/ui/VerticalStackView.qml [License: LGPL(v2.0+)] M +1 -1 applets/kickoff/package/contents/ui/code/tools.js A +2 -0 applets/kickoff/package/contents/ui/qmldir https://invent.kde.org/plasma/plasma-desktop/commit/9d9c4f169ed424e976636a6d5fa23c7a1e40576b
Are there any changes on this issue? maybe they fixed it in version 5.23? or is it expected at 5.24?
Yes, as the bug report's RESOLVED status and "version fixed in" field indicate, this is fixed in Plasma 5.23.