hope it's not too late, but...

So... I randomly brainstormed a way for us to 'redesign' Global Theme if we stick to the current simplistic approach of making it a main page for an overall 'Appearance' subsection. This would involve some light changes to Global Theme, as well as some potentially major undertakings for the sub-Appearance KCMs' code, but I'll outline it nonetheless:

If this can mean that GNOME Keyring can work properly, be unlocked on login properly, etc (even if it only does after tweaking its corresponding /etc/xdg/autostart files), then boy you can count me in on liking this idea.

To block stuff in APT itself, we could always refer to how Linux Mint blocks 'snapd' in the package 'mintsystem' in Linux Mint 20, but instead limit it to only blocking X (where X = the package needing blocking) package on the 'Ubuntu' component so that if users have external package sources for X package they can still install it from those external package sources. The method Mint uses can be used for any package, in principle.

I mean, if a difficulty with this is 'not simple for beginners', people can always push KDE as much as they can towards a direction, in the vanilla representation, that is a simple for beginners Operating System.

bump!

*runs*

Crystalline: -2
Grand Canyon: +1
Vera: +2
Beach: +1
Flow Dark: -2
Altai: -1
Milky Way: -2
Rainy Morning: -1
Slant: -2
Kay: -2 (Kay feels like it belongs more in Material Design IMHO)
Iridescent Shell: +2 (in its originally submitted form, even if it has a slight change of hues for its actual usage, but NOT THE V2s' oversaturation and/or over-flattening of V1)

I'd strongly suggest holding Milky Way from being the default wallpaper until we have a known release that brings about the official Breeze Theme Redesign.

So my current ideas are:

• Have the names of Virtual Desktops be more prominently shown by default (enable the name OSD, etc.)
• (maybe) have privacy settings work on a per-Virtual-Desktop basis if users really need it, otherwise make it into a general Privacy KCM
• Make desktop backgrounds be simply swapped to on a VD basis rather than Activities basis
• Get rid of the Activities switcher (just use Desktop Grid/Cube/etc. Effects)
• (maybe) Make desktop backgrounds, and the overall VD's Desktop Layout, be spanned across all monitors when there's multiple monitors.
• Have Latte have its current Activity-specific changing be VD-specific changing
• Allow 'Setting Aside' Virtual Desktops (literally the 'Shut Down Activity' feature in a shellnut but adapted to be for doing the same to Virtual Desktops instead)
• Allow for applications to start in their current workspaces if Restore Session on Startup is enabled (if not already implemented)
• When making a new Virtual Desktop, make it clone the configurations (and map Latte's current layout to also being used on that new workspace too), of the currently active Virtual Desktop, or the last Virtual Desktop in the list before that one's creation, to make sure that people who don't want the Activities aspect of these Virtual Desktops aren't alienated by a Virtual Desktop they make suddenly looking like the default configuration for Plasma rather than their own customisations to Plasma
• If no customisations are made to that new VD, have it sync its configs, until changes are made to that new VD, with the VD it got its configurations from when it was created
• Replace the Activities... options in Plasma with shortcuts to the appropriate Desktop Switcher effect.
• (maybe) have the option of different pins, etc be there for different Virtual Desktops if there's enough demand for that

I honestly think we should reserve Milky Way for Plasma 6 to make it a release that's 'out of this world'. ;)

In T12839#238041, @clel wrote:

Where does this come from? Has there been some discussion on Riot or somewhere else?

Would 44px be DPI-scalable?

Much as it sadly didn't get cameo'd in this task until now, my suggestion would be to take THE ORIGINAL version of Iridescent Shell, aka this: https://postimg.cc/8JgGKw5T

Here's my idea for how it could work:
Key:
ICON is a placeholder for the icon size in the applet. Also the same size as the general widget contents (icon, text, etc.) in the panel would be.
Silver ICON: Same as ICON, but for unhighlighted items to convey the icon size on those as well as on highlighted items
Dark Grey: Highlighted Widget/Item
White: Unhighlighted Widget/Item

In T13467#236623, @ndavis wrote:

In T13467#236621, @The-Feren-OS-Dev wrote:

If this also gets integrated into Kirigami as well, that'd be even better.

I don't think this would be integrated into Kirigami. Rather, Kirigami would get its theming from the QQC2 style.

If this also gets integrated into Kirigami as well, that'd be even better.

TBH, I currently vote for Ocean, but, here's my take on things:

+1

Definitely please do continue with this patch, and maybe link to it on invent in here.

In T12839#230326, @niccolove wrote:

Should the icons increase by fixed value steps, or smoothly scale as the panel is resized?

I'd rather not lose our Plasma theming, but apparently it might be possible to conditionally load either a Plasma or QtQuick style from the same component set.

I personally like the changes made, based on the screenshots, though TBH the buttons should probably be 1px higher or something... they seem a little too short to me.

In T13012#227542, @squeakypancakes wrote:

Here is some quick mockups.

Any update on the status of this?

Random thought about the View Button for a potential future patch if necessary: Couldn't the single view button just not be click-dragged from the single view button to the view mode in the resulting menu that the user wants in order to keep the same amount of clicks as having them separated?

Small idea for how I think implementing panel customisation in standard Global Edit Mode could go:

• Keep it as it is, but...
• No matter if Panel's Edit Mode popup is visible or not still have the whole panel Plasmoids movement addition that currently entering Panel Edit Mode gives you be accessible by simply editing Global Edit Mode and then only cease once Global Edit Mode is exited, rather than relying on the visibility of the Panel Edit Mode popup to do so (in other words make the state of the panel when the Panel Edit Mode popup is visible be the state the panels are always in when in Global Edit Mode, sans the Panel Edit Mode popup itself)
• Also keep the current toolbox on the right visible (when in G.E.M.) to enter the 'Advanced Panel Edit Mode' popup of that respective panel, just like how it's currently implemented

How about instead of a blue dot there's instead an option in the SySe hamburger button menu to use search to filter out any settings pages where settings haven't been changed, meaning that only settings with changes made to them are then listed in the search results?

IMHO this is wholly pointless a change, currently. Most people won't care about if they've made changes or not in SySe from the defaults, and quite frankly seeing that indicator on the sidebar would potentially even deter user customisation if not utterly confuse people. If it was an optional setting in settings to show these changed settings indicators on the sidebar (such as a checkbox item in the SySe menu) that you could turn off by default, I wouldn't mind this at all.

I know I'm late in saying this but BTW elementary OS uses circles on checkboxes IIRC.

In my honest opinion, it'd probably be good to also get rid of Breeze Light in a separate patch because as I see it right now Breeze will make Breeze Light redundant by default post-this-patch since they'll both be Breeze Light in a sense. It just seems redundant to me to be honest having Breeze Light next to Breeze... Light... by default.

In D28317#635865, @ngraham wrote:

Sure, that seems reasonable. I guess the question is whether we should ship it in this repo, or make it a GHNS thing, as with the other old colorschemes like Norway, Wonton Soup, Honeycomb, etc.

In D28281#634702, @sgoth wrote:

Cool thanks!

As this is my first contribution via phabricator, can you give me a short advice on how to proceed?
Do i "arc land" it myself? To master?

I'm not really sure about having that icon, that's shown as 'Home' icon in the demo video, on the left of the URL when it's inside the toolbar, but otherwise this looks great visually on first impressions.

For the lack of text on Full Name, is there any chance some hint text could appear in the full name text box when the textbox value is empty saying something along the lines of "Full Name" or something?

While we're at it, it'd be good to finally have one text size for the panel overall. That includes the font size for Digital Clock (all modes), Task Manager, etc. (only the parts of those applets that have text on the panel itself)

In T10201#208008, @joricke wrote:

Yes, I'm aware of that, but even on that screen there's a mention of "Application Style" that implies the decoration of the entire window. It's just a mass of redundancy and confusing naming all over again. Can we not declutter this? And coming back to a discussion on the evolution of breeze: dial back the usage of styled frames?

I think that the highlighting is guidance enough to let the user know what setting they are currently tweaking. The labeling on the "back" button should also imply where the user is going to go back to when they click it to connect the "<" icon and label to the general action that is happening when this is clicked.

Not gonna lie I prefer the last picture over the second last, but these dialog designs definitely look great.

Redone, again.

One more diff tweak to make it normal-er.

Rebased on master

Some more things that may or may not have already been mentioned, given that some of us are considering the idea of moving the hotcorner to the bottom since it'd get in the way of the panel up top:

• Bottom-right hotcorner: Gets in the way of scrollbars...? (also mouse resting area)
• Bottom-left hotcorner: Gets in the way of Show Desktop (and the Panel Toolbox in Global Edit Mode)
• Bottom-center hotcorner: You'd, er, have to implement that first.

There is currently an issue that might make this change cumbersome, unless it was fixed very recently as part of the patch work for this, being that preferred://browser causes duplicated entries for stuff like Vivaldi, etc (they'll be separate from the preferred:// pins meaning the preferred:// item basically acts as a quick launcher which is far from what is intended). Similar problem with preferred://filemanager. I would've used those instead of hard pins to vivaldi.desktop and org.kde.dolphin.desktop by default in Feren OS if it wasn't for that aforementioned issue being there.

The main point of this patch is the spacing increase between tray icons that this hitbox size increase gives, which makes the tray look less cramped as a result.

Went to check on different DPIs again to be sure it's fine and it definitely looks fine to me, scaling up the hitbox padding additions (and therefore the icon spacing) in sync with the DPI scaling very nicely, so that shouldn't be an issue.

In D27466#620052, @IlyaBizyaev wrote:

In D27466#620050, @The-Feren-OS-Dev wrote:

This patch only affects the System Tray widget itself, not anything else on the panel. Only the spacing around the icons that are part of the System Tray applet itself will be changed by this patch.

I understand, but, as I mentioned, for me it already looks like what you expect to achieve with this.
Is it maybe DPI or font dependent, causing the spacing to be smaller in your local setup?

In D27466#620037, @IlyaBizyaev wrote:

Repeating my comment on the previous diff for this change: on my machine, the current spacing for systray elements already looks like your "after" screenshot. With normal usage, my systray area (icons + clock + a note widget) takes up 1/4 of the panel. Does it mean that after this change, it's going to be even larger?

In D27466#619931, @ngraham wrote:

So at this point it's just one pixel, and I don't see the huge harm. :) However the last patch to adjust this (D27438) proved quite controversial, so we should wait for more opinions to avoid unduly ruffling feathers. :)

Updated diff

Updated diff

Moved baseSize declaration and changed it to a standard variable

You gotta love arc/git sometimes...

Arcanist please

Hopefully fixed the diff again

Updated diff to be in line with parent patch

Tidied up code a bit and introduced new baseSize variable - Slightly increase system tray icon hitboxes in Non Tablet Mode Plasma

...and now the split is complete.
https://phabricator.kde.org/D27466

Got rid of unnecessary rounding of smallSpacing at the end of the Tablet Mode padding addition

Make the click areas of system tray icons larger in Kirigami Tablet Mode

The initial patch of the three, now I've thought up a suitable way of doing this, has been made:
https://phabricator.kde.org/D27465

Actually, on second thought, @ngraham I'm not even sure if step 2 would even be worth it on its own, if possible.

In D27438#613097, @ngraham wrote:

...one to increase the spacing when in tablet mode, and another one to increase the spacing when in desktop mode. At this point each patch will be changing a different line in the function

In D27438#613104, @IlyaBizyaev wrote:

I agree with @broulik in that the spacing already feels quite excessive, or at least doesn't need to be increased (:

Does this depend on DPI/panel size maybe?

Alright, I'll start splitting the patches up now. Marking this one as Abandoned.

@ngraham How would I split it into two patches? Both patches would edit the exact same line.

Had to lower the cmake version requirement to be able to compile this, but this works just fine, and it's definitely something that'd be nice to have. I can't see any regressions nor leaks, either on this current patch version.

Tweaked an added comment

In D27438#613051, @davidre wrote:

In D27438#613050, @The-Feren-OS-Dev wrote:

In D27438#612719, @davidre wrote:

There is now not clickable space between items:

At least it should be clickable

For future reference, how do you get that size examining mode in Plasma Desktop Workspace?

That's inside gammaray

Changed method used for increasing spacing between tray icons to something that increases hitbox sizes as well