kdeuserk wrote:Therefore I suppose the gnome screenshot pasted here is not from an official gnome application.

Heh, as you see lots of official KDE apps don't really comply with KDE's HIG either currently

The checkbox + label concept is actually quite comon (also exists in HTML for example) and there's themes which highlight both label and checkbox on mouse over.

Definitely in the end you're right I'm just a member, not a developer or designer, sure the HIG of KDE as I have pointed out to have their own logic correct. Just my impression on present boxes seem like a blank sheet of paper with notes and test boxes, a bit spartan and crude.Sure you will find a better solution and visually it is correct with the KDE HIG.

I'm developing completely different things, in this area I'm certainly no more knowledgeable than you.

I think all the suggestions from around this thread are good, keep doing them! Just the switches vs. checkboxes issue is sort of decided already.

scummos wrote:The checkbox + label concept is actually quite comon (also exists in HTML for example) and there's themes which highlight both label and checkbox on mouse over.

Exactly, and I like those very much when they are done right (like highlighting both on hover), so I'm hoping that it could be a system wide design treat in KDE in the future.

Well just so everyone knows - I have written down "make it visibly appearent that check box and title belong together and can both be clicked" and the "make some room and use some layout skills, damn it!" was already in the notes.

Keep the ideas coming everyone we're on a roll here!

I've had a bash at the 'date and time' module. There are more date and time related settings in the 'locale' module, and would suggest that this module be merged with it at some point in the future. However, as it stands I have combined the current two tabs into one, and added a bit of colour. It's rough and ready, but it's a start right?




...and yes, this was the result of a mass of printscreening, copying and pasting. But see, it's so easy, you can do it too.

Power Saving. Colours are a bit wonky. In fact the whole thing's a bit wonky! Bed time for david I think.

lazyit wrote:Definitely in the end you're right I'm just a member, not a developer or designer, sure the HIG of KDE as I have pointed out to have their own logic correct. Just my impression on present boxes seem like a blank sheet of paper with notes and test boxes, a bit spartan and crude.Sure you will find a better solution and visually it is correct with the KDE HIG.

There are some valid arguments for introducing sliding switches on desktop UIs as well, and this topic has been discussed within KDE many times before. We just have not found the pro arguments convincing enough to introduce a new control for the same thing, especially since the interaction analogy to the real-world switch isn't really there as you wouldn't really move the switch with the mouse (it is possible, but impractical), but simply click it, like a checkbox. "Because they look better in this case" should not be the decision criterion here, however, because if we introduced switches in addition to checkboxes, the decision which one to use where would have to be based on semantics (like they do in the GNOME 3 HIG), not on aesthetics.
The example posted in this thread would indeed be in violation of the GNOME 3 HIG, since these are neither hardware that can be turned on or off, nor nor services that can be started or stopped. These are indeed merely options, so according to the GNOME 3 HIG, checkboxes should be used.

Personally, I'm not strongly against switches, but we had to make a decision at some point, and the decision was to only introduce them on Plasma Active. If we'd revise our decision later, I'm certain we would go in the same direction as the GNOME 3 HIG.

But please do not feel like you're "only a user". In Free Software, everyone who contributes anything - even if it's "just" ideas - is treated equal. If your arguments for switches convince us, we'll change the HIG, though rather reluctantly, given that this would re-open a can of worms that we were happy to have finally closed.

The GNOME argument of non-instant actions doesn't really make sense in the KDE world anyways, since our dialogs almost never do anything immediately on checking/unchecking a box but only on clicking apply or ok.

Currently Splashscreen is located under System Settings -> Workspace Appearance, KDM is in System Settings -> Logon Screen, Lockscreen is in System Settings -> Fencing and Video. They could not be put together in the "change wallpaper" redrawing the window? Or at least do not you think you could organize better?

Better organization is relevant... But its also tricky as there has been some of those before and we wanna really do it proper this time around

I suggest five fields

Personal
This is where all the personal and user settings get squeezed in. From Social Desktop (a suggestion for a combined Email and Chat app setting) to language and user admin. Let the Super User and the Common User be divided by a password and leave it at that.

Appearence
Everything about appearence. Wallpapers, windows, plasma theme, icons and fonts. Even the Font manager.

Network
Samba shares, Bluetooth, Internet whatever here

Hardware
Printers, Screen, Input Devices and Drivers

Other
Non specified distrospecific settings here: Yast in Opensuse, Software Manager in Mint, Manjaro Settings in Manjaro.

If we stick to these four - really stricty it would make more sense than the current layout. If we then, having edited the looks of the individual settings, go to work on each and every setting and see if it can me merged or edited and then the system settings interface in total - we have a complete and well worked through system settings.

And say that you edit the Wallpaper by rightclicking the desktop and instead of having its own window you automatically get into the system settings and in the correct area (so if you say clicked "Edit Wallpaper" instead of its own window with its own rules, it opens the Wallpaper settings in the System Settings)

The categories sound good, certainly much better than "Common appearance and behaviour" and "Workspace appearance and behaviour", which from a user perspective are the most useless categories you can come up with
However I'm not sure where a few modules would go, esp. Date&Time, Fonts, Permissions, Autostart, Shortcuts, and a few others. It's tricky.

Well Date/Time should be squeezed in with Locale anyway and as such be placed under "Personal". Shortcuts should be placed under Input Devices so "Hardware" for now. I don't have anything called "Permissions" but I guess its user management so "Personal" (if its not, then pretend I didn't say that). Fonts are under Appearance.

We just have to stop trying to be precise in our wording and start being correct.

But then you have Time under Personal. I wouldn't look for it there...

What do you do in Locales then?