CTown wrote:Sorry, Heiko and colomar. I guess I jumped the gun. I forgot this is about organization and not functionality.

No no, fire all batteries! We have to prove the concept for the next generation layout as well.

Heiko Tietze wrote:I will update the graph tomorrow according the comments of both of you. But why should we start with Color, Font etc. and place the module that comes first in mind when talking about theming at last?

Sorry, I didn't explain the proposed Color, Font, Icons, Application Style, Workspace Theme module ordering. In a previous comment on this thread I suggested the following rationale for ordering the Appearance modules:

• Easiest customization concept
• Customization impact (how many areas of the visual experience are affected by the customization)
• Preserves visual design language
• Easiest to discover or add new customization choices (GHNS, user installation, etc.)
• Helpful for accessibility

The first 3 being the main considerations. I know it seems that changing the widget styles and the like is the first thing folks would typically want to do, but I'd offer that things like colors, fonts and icons are far easier appearance customization concepts to understand for a non-technical user. They impact most areas of the visual experience without completely dismantling the visual design language that we worked so hard here to put together. It is also relatively simple to find and install new colors, icons and fonts. I know history would suggest put the widget styles and the like first, but that history is partially informed by a somewhat lesser focus on visual design than we have now. Based on the hard work done here in the VDG I'm advocating for a break with the past with this new ordering for the Appearance modules with the accompanying rationale.

Hope this helps explain it.

alake wrote: In a previous comment on this thread I suggested the following rationale for ordering the Appearance modules...

Now I remember . Ease of use is not the best argument for prioritization when I have to accomplish a certain task. Changing colors might be something you do regularly as a designer but normal users (at least me) never change those options, nor any other than the workspace theme. I still think this one should be the first, and we have to focus on redesign of this module. But let's wait for other opinions.

Graph (not thumbnail) and raw data have been updated.
Just use the links from viewtopic.php?f=285&t=121053&start=30#p313837

Heiko Tietze wrote:Changing colors might be something you do regularly as a designer but normal users (at least me) never change those options...

Just to clarify what I actually said; Colors, Icons and Fonts are simpler customization concepts for non-technical users that don't completely dismantle the visual design. Note that I did not refer to what I do as a designer or what you do. Basing the order on what some folks felt compelled to do when the visual design fell out of favor for me communicates a lack of confidence in the new visual design. It basically says, "Here, the first customization we'd like to offer you is to rip apart the visual identity of this product."

This is about the ordering, not hiding functionality. If folks really want to completely dismantle the visual design of the product, the groups of modules to do that will be right there just three entries down from the top for them to find. I struggle to imagine how that would pose a critical barrier to any user.

I personally don't care a lot about the order. Andrew's proposal feels a bit weird to me at first, but that could very well just be because I'm used to the traditional ordering.

I don't think it has much of an impact. I do agree that the one thing which the biggest percentage of users may want to change is the colors (choosing a dark theme instead of the bright default because they live in a cavern).

On the other hand, we also have to remember that many distros will dismantle our carefully crafted design by default, anyway. Just because they think that they somehow need to create their own "visual identity" by default. They've done it in the past (even though all of them looked much less good than the default, if you ask me), they will do it in the future. It's distros being distros, nothing we can do about it.

@Heiko, I think it'd be just fine if Workspace Theme were at least higher than Application Styles in the ordering. I do not intend for my feedback to be the cause of any agonized delay getting to a result. So I apologize if I sounded pushy. While I think there is some value to the ordering, as I've already expressed, I'm perfectly fine if we just picked something for now and carry on. It's not the end of the world and we can always revisit it later if necessary.

alake wrote: I think it'd be just fine if Workspace Theme were at least higher than Application Styles in the ordering.

I'm not sticked to a certain ordering as well. And I understand your intention, but I still think color should be subordinate to themes. Since we do not find a consensus we have a stalemate unless someone else takes a side. Thus the doocracy comes into operation
PS: Application style is the last item now. That makes sense to me.

Heiko & a lake,

Re: Colmar's last post, if many distro's will change the theme & rip apart the style that we've created, wouldn't it make sense for the 'Theme' section to be the easiest to get to so that users could easily change it back?

Wouldn't the 'Theme' module, as well as being able to undo all our hard work by completely changing everything, also enable users to get from the modified theme that their distro has chosen to ship to the default KDE style if that's what they want?

Like if they've seen some cool screen shots & think 'I'll give KDE a try!' only to find that it looks nothing like the pictures that they've seen because it's not the standard theme.

I agree that it's not really important, it's just that if a user wants to get to 'vanilla' KDE it might be a bit more obvious if 'Theme' is top of the list.

ken300 wrote:Heiko & a lake,

Re: Colmar's last post, if many distro's will change the theme & rip apart the style that we've created, wouldn't it make sense for the 'Theme' section to be the easiest to get to so that users could easily change it back?

Wouldn't the 'Theme' module, as well as being able to undo all our hard work by completely changing everything, also enable users to get from the modified theme that their distro has chosen to ship to the default KDE style if that's what they want?

That will be the case once there will be "megathemes"/"experiences"/"whateverwe'llcallthem" which can change everything at once. That's for the future, though. For now, users would still have to change every aspect by hand to get the "vanilla Breeze look" back.
Once megathemes arrive, we might change the order of the KCMs again.

A quick heads up.

I've started implementing the new organisation, hoping to get it ready so we can include it in 5.0. We're already quite late, but there are a number of benefits to squeezing it into 5.0:

- Disruption to the user happens early on, we don't move around the whole of system settings amidst a cycle
- 3rd party modules need to be ported to KF5 anyway, and that will also mean changing the category (as one simple more porting step), I'll document the group names once I'm done with making it work, so it's easy to find for 3rd party KCMs

Changing all the categories is a bit tedious, I've counted 96 categories to create cq. modules to move around. I'm now about 40%, Appearance and Workspace are done on my system. I've not encountered any serious issues, which is promising. I can start pushing patches in a few days (hope early next week), but need to do so in a concerted fashion, as when I change the systemsettings categories, modules that aren't changed simply won't show up. (That on the other hand will give reviewers of the changes to all the kcmodules some motivation to accept my patches easily. )

I've noticed a few oddities when doing the first two categories. I'll explain those in a separate post.

Alright, some things I've noticed, some more, some less critical.

Missing icons for categories that didn't exist previously:
- Style (style, now using theme icon)
- Desktop Behavior (desktopbehavior)
- Window Behavior (windowbehavior)
- Startup and Shutdown (session)

* The name of the subcategory "Themes" (under "Appearance") is plural, all others are singular -- on purpose? Would it make sense to change this to "Theme"?
* Should GTK go under Theme, next to Widget style? (Widget style is for Qt apps, GTK is for GTK apps, both "theme" the application widget style.)
* The Themes and Style distinction seems a bit arbitrary to me. I couldn't come up with a good explanation why one would go into Style, and another into Theme. Jens proposed a distinction between "Workspace Theme" and "Application Style", which makes more sense to me. The above question about the GTK module plays into that.

I'll probably run into some more things, but that's what I've encountered for now. Overall, I think the new structure is already a huge improvement, it's very nicely balanced, logical and doesn't actually feel that different from the "old" categorization. Good stuff.

sebas wrote:* The name of the subcategory "Themes" (under "Appearance") is plural, all others are singular -- on purpose? Would it make sense to change this to "Theme"?
* Should GTK go under Theme, next to Widget style? (Widget style is for Qt apps, GTK is for GTK apps, both "theme" the application widget style.)
* The Themes and Style distinction seems a bit arbitrary to me. I couldn't come up with a good explanation why one would go into Style, and another into Theme. Jens proposed a distinction between "Workspace Theme" and "Application Style", which makes more sense to me. The above question about the GTK module plays into that.

Labels were changed according this idea, have a look at the updated graphic.

Appearance > Workspace Theme > Desktop Theme, Cursor Theme, Splash Screen
Appearance > Color > Colors
Appearance > Font > Fonts, Font Management
Appearance > Icon set > Icons, Emoticons
Appearance > Application Style > Window Decoration, Widget Style, GNOME Application Style (GTK)

Reason to make a distinction between Theme and Style is to balance categories and to sort by relevance. Of course all modules are related, more or less. Perhaps we will add a link to have direct access from the themes to decorations. But that's somewhat for a redesign, isn't it?

Rest sounds very promising. Keep us updated.

sebas wrote:* The name of the subcategory "Themes" (under "Appearance") is plural, all others are singular -- on purpose? Would it make sense to change this to "Theme"?
* Should GTK go under Theme, next to Widget style? (Widget style is for Qt apps, GTK is for GTK apps, both "theme" the application widget style.)
* The Themes and Style distinction seems a bit arbitrary to me. I couldn't come up with a good explanation why one would go into Style, and another into Theme. Jens proposed a distinction between "Workspace Theme" and "Application Style", which makes more sense to me. The above question about the GTK module plays into that.

I'll probably run into some more things, but that's what I've encountered for now. Overall, I think the new structure is already a huge improvement, it's very nicely balanced, logical and doesn't actually feel that different from the "old" categorization. Good stuff.

Awesome that you're working on it already!
However, the issues you name here show that you must be working from an outdated version of the concept (I don't know how this happened as Heiko has actually overwritten the file we linked to with the new version).
Please re-download the picture from here:
https://cloud.user-prompt.com/public.php?service=files&t=2fb60debcc1648685a59134b3a8c0eea
All the issues you mention are already fixed there!
I'm sorry that you now have to change some things again, it's really odd that you somehow got the outdated version...

I know how this happened: I printed the picture and draw into it, so I'm working off of a static version. I'll redownload, and will print again. I'll also have to revisit the parts you describe.

Please, in case you change anything: poke me to make sure it received me (I might not follow every discussion closely), and changing information that I'm working off of under my butt can lead to such problems.