- User Since
- Sep 6 2017, 10:33 AM (117 w, 3 d)
@niccolove Do you mind if I commandeer this? I know dealing with these kinds of issues can be super annoying and I'm already used to it.
Something else to think about:
The search bar is put on the same side of the screen as the content area on the right. Should it only search for content related to the selected tab or search for all content at once? I feel like the layout in the most recent mockup works best for finding content related to the selected tab.
It's still going to be a PITA with manual editing. Maybe there's a way to automate it with awk, but I don't know that tool well enough. This should at least make the deleting part easier: sed --follow-symlinks -i 's/style="opacity:0.05"//' tasks.svg
Oh wait, here's the problem
Wait, is a change to tabbar.svg supposed to be in this diff?
Fri, Dec 6
Or rather than being Categories/A-Z, do Applications/Files with places in the sidebar and folder contents in the main area, like a built in folder view. That could actually be super convenient, but I don't know if it's really needed.
What if we just drop the A-Z tab or put it in the sidebar with the rest of the categories?
Welp, there's nothing objectively wrong with making this patch. LGTM
This doesn't seem wrong, but why is it needed? Do people get confused about the type of shortcuts? Are there non-keyboard shortcuts? If there are, would we put their configuration menu under a different menu option?
Thu, Dec 5
I personally prefer file manager, web browser for the order.
Wed, Dec 4
I could agree with using a grid view for Favorites and a list view for browsing through app categories. We could also put the app comment/generic name near the app name in the list view like Kickoff.
@mart, I think the mockups on the right are actually the A-Z list (notice where the separators are placed), not a separate version of the mockup. I think @manueljlin just forgot to highlight the A-Z tab. It's the top and bottom rows that are different versions.
Tue, Dec 3
I'm thinking maybe the breadcrumb shouldn't go in the toolbar. If you have to make all toolbuttons icons only to get the breadcrumb to fit, it's not good. There is real usability research that shows how labels are important for buttons with non-standard icons: https://www.nngroup.com/articles/icon-usability/
More code formatting
Mon, Dec 2
- [KColorScheme/KStatefulBrush] Switch hardcoded numbers for enum items
- fix code style
- Split up Effects enum
- Also do Effects enum
Sat, Nov 30
close tie between Noto and Lato for me
-1 to Deja
It took me a while to realize what the feature was, but now that I do, I might prefer to using it.
Fri, Nov 29
Thu, Nov 28
Is there a way to tell the revert timer not to be used if the user only makes a change that requires a session restart? It wouldn't be very useful to ask a user to confirm if the screen is displaying correctly if the change can't be seen.
Wed, Nov 27
I'll abandon this and see how starting my own theme goes.
Tue, Nov 26
- Actually rename all occurrences of combobox.h and tabbar.h
- Rename combobox.h and tabbar.h to be like private headers
I plan to do the existing files in another patch
- Move renderSidePanelFrame and renderSelection into itemview.cpp
- Move renderDecorationButton into mdi.cpp
Please say if something about the structure does not make sense to you or if you think improvements could be made.
+1 for this safety feature
It would be nice to have a visible countdown timer though.
Mon, Nov 25
Sat, Nov 23
In that case, maybe 5% opacity for minimized?
I'm not convinced that we need arrows pointing to the right between the separating lines, even if they rotate to down arrows on hover. With touch screens, they won't rotate at all unless clicked anyway. The original mockup design, while not as clean looking, made it perfectly clear what the hierarchy was and the non-rotating down arrows make it clear that a menu exists there. Even just straight lines as separators with no arrows is good enough for GNOME's Nautilus file browser because most people read from left to right (Qt can reverse the layout for RTL languages). The names in the breadcrumb match the folder names, so the hierarchy should still be pretty clear.
Rather than requiring a click to go back and then another click to go into another category, create a way for categories to be hovered through like the tabs. Those usually useless subcategories shouldn't appear by default. Favorites, History and Often Used can be split into optional categories under the Applications and Computer tabs. Then you're left with just Applications, Computer and Leave.
I'd be all for making something similar to Simple Menu the default menu.
Fri, Nov 22
Here's a mockup with straight lines:
I see how you were thinking of rotate on hover now and I agree that it would be effective for showing both hierarchy and the control for switching to nearby folders. It still has the problem of having arrows to the left of the labels they affect though.
I played with the margins on the original mockup style a bit:
Played with the strength of the inner arrow separators a bit too:
Thu, Nov 21
Here's the fixed file:
Unfortunately, it still doesn't look right.
This is what happens when icon size is set to 32px or more (48px here):
size.setHeight(toolButtonOption->fontMetrics.height()); doesn't take icon size into account.
Also, still -1 to making flat buttons and non-flat buttons the same size at the same icon sizes in this patch. That change has potential consequences that can reach much farther than the button vs line edit height inconsistency that originally needed to be solved.