- User Since
- Apr 15 2017, 7:18 PM (86 w, 5 d)
Now that this is landed, feel free to change the symlinks by hand.
Actually I feel like this regressed the visuals for the file dialog itself in the name of improving the situation for apps that use this view in a sidebar.
This fixes the issue in Discover for me and doesn't seem to regress anything in Gallery.
+1 for the idea and the UX as texted. No comment on the code change; I'm definitely not smart enough to understand it all!
Your proposed "Application Launcher Settings" Needs to stay as it it ("Configure Application Launcher") for consistency and HIG adherence. Also, "Alternative Widgets" needs to start with an action verb. Maybe "Show Alternative Widgets" or "Switch to an Alternative" or something like that?
Looks good visually, but the scalable test now fails:
Tue, Dec 11
I can confirm @zzag's bug.
That's much better! I think I would still prefer a bit more slope on the sides though. However at this point it's just aesthetic quibbling. :)
@ndavis To be honest, I liked the shape and composition of the original icon better than your proposed new one. I'm not a huge fan of the flat sides and lack of visual distinction between the body and handles. +1 on removing the superfluous Plasma logo though.
App icons shouldn't have monochrome versions except for very limited exceptions like on the system tray. The issue being solved here is a general problem that we have when a dark icon is used with a dark color scheme. It's by no means limited to this icon (see also D17469), but we have some visual restrictions on resolving it since this is an app icon and we can't really redesign the icon like we can in D17469.
Checking patch icons-dark/preferences/32/applications-internet.svg... Checking patch dev/null => icons-dark/categories/32/applications-internet.svg... error: dev/null: does not exist in index Checking patch icons-dark/apps/48/internet-web-browser.svg... Applied patch icons/preferences/32/preferences-web-browser-stylesheets.svg cleanly.
Mon, Dec 10
- This needs screenshots. :)
- Don't you think it's premature to submit code before we've settled on what it is we actually want? I don't see any consensus in T7927. Personally I am not at all sold on the idea of presenting users with ten font rendering options and expecting them to be able to choose their favorite. The differences between most of them are minuscule and seem all but impossible for someone who's not a font nerd to distinguish. The idea of visual previews seems sound, but I think we would need to limit them to choices that lay people actually have a chance of understanding and distinguishing between.
Um, the diff is now different, and it looks like the wrong patch was committed: https://cgit.kde.org/dolphin.git/commit/?id=55db38d5ecc1f13e17fecd7f3a5ea24421080b77
Semantically, this is the correct icon, though the actual imagery isn't super applicable. We can fix that with a better icon though.
The lock and login screens are already subtly inconsistent with one another, so changing that isn't currently on the table.
This is another example where a subtle outline could help visibility for dark themes, without having to resort to drawing a whole new version of it.
Looks great now!
Cool, landing now. If I can get some assistance, I might try my hand at submitting a Qt patch to add the requested resize mode.
Sun, Dec 9
Yeah, I do too. It's certainly more functional. Do you think I should just commit this now?
A slightly nicer solution would appear to be to keep column 0 using QHeaderView::Stretch like it already is, but give only that column a minimum size equal to the longest item. That way the name column would dynamically expand as the view was enlarged which keeps the other columns aligned to the right side, but would not compress as the view shrinks. Unfortunately this doesn't appear to be easily possible: https://bugreports.qt.io/browse/QTBUG-1248
Maybe the problem is with the monochrome version, not the color one. To me, that "half filled balls connected with struts" icon looks like something more related to chemistry than disk management.
@drosca, you'll need to land this for @GB_ with authorship information Björn Feber <firstname.lastname@example.org>.
Sorry, please ignore me...
Ah yeah, I guess that makes sense.
Yeah, as backup/additional shortcuts so we don't break workflows for people who currently use them.
Plasma folks, any comments, or shall we land this?
Ah, much better! This looks great to me now. KWin folks, any any concerns, or should we land this?
Yep, the PC one already does go clockwise
In terms of the submenu text, I just noticed that we already have "Find Variants" in the Edit menu, so I'm okay with using "Save Variants" and "Close variants" for consistency. We can decide later whether we want to keep that style.
Thanks for contributing to Spectacle! May it be the first of many more. :)
I always re-bind Find Next and and Find Previous to use Ctrl+G and Ctrl+⇧+G. These are the shortcuts that are used by most 3rd-party apps, as well as all GNOME and macOS apps. It might make more sense to standardize on those.
Sat, Dec 8
If view-private-symbolic is just a symlink to the regular icon, do we really need it?
Can you also bump the version numbers in the metadata.desktop files?
Hmm, why did you change the busy indicator? I think the current one is fine. The new one is something I haven't seen used anywhere else.
Good idea! I might suggest rewriting it as follows:
That's what I thought. Then it doesn't fully fix 401810, since people not using Kubuntu or Neon will still not have a way to change the update frequency.
Oh, probably a Cuttlefish bug then.
Hmm, I prefer the Dolphin one for the following reasons:
- Having the the "open with" item near the top makes sense because it's likely the most commonly used item
- Having the "open" items grouped together makes sense, since they're both similar actions, and all other platforms I'm familiar with have their context menu's "open" items on the top too
- The greater use of separators is an asset, not a drawback: separators provide structure and help the mind distinguish between logical groups. In particular having cut/copy/paste separated from other items makes sense.
- The current FV menu has bugs:
- The top item is Open, but it uses an inappropriate icon and is duplicated by another superior Open with [app name] item buried in the middle of the context menu.
- It doesn't show the Paste item unless there's something to paste. This is a HIG violation; we don't recommend modifying the visibility of inapplicable menu items; instead they should be disabled.
- The Properties item doesn't have a keyboard shortcut
Hmm, now it seems like his hat gets flat at the 48px size:
This helps for Kubuntu (and Neon ?) users, but what about everyone else?
Should these list items even become selected when clicked? Typically items are only selectable when there are some actions you can apply to selected items, which isn't the case here.
They generally look very good.
Looks great, thanks! Can you provide your email address so I can land this patch with correct authorship information?
We had a big discussion in the VDG room and concluded that Konsole shouldn't even use this icon for its tabs by default (https://bugs.kde.org/show_bug.cgi?id=401864), which partially solves the problem.
Works flawlessly! Very nice.
Neat, it seems to generally work well. I notice that when I click the new menu item, it somewhat unexpectedly exits from panel edit mode. I wonder if we could make it not do that, so it would stay in panel edit mode if invoked while in panel edit mode.
Fri, Dec 7
I like it! What do you think about making the bottom line of the hat a bit wider, so it's more clear that it's a hat?
I gotta say, these ideas are super sexy! I would not at all mind doing this. However since they all require removing the blur, maybe we should focus on getting that done first.