> > > 3) Desktop Theme is a global setting, so it's confusing and moreover it > > doesn't make any sense to have it on desktop settings dialog. > > it's confusing in the sense that it doesn't strictly belong to the same > scope. but then again .. find me a user who looks at that, scratches their > head and goes, "gosh darn, i have no idea what the desktop theme will do > because it's next walpaper!" > > the question is whether people will find it or not, and we have the same > issue with the desktop settings themselves. > > now, strictly speaking, we could move the desktop theme into system > settings. then we would need to have a d-bus interface for the affected > applications and the ability to write the config file properly. > > i'm on the fence with moving the desktop theme setting to somewhere in > system settings, but this other work would need to be done first. > > why am i on the fence? it will be slightly less convenient as the user will > now have to go to two diferent places to configure things that are > reflected in the same place. that's one of those things about "usability" > when applied via straight logic versus considering actual user goals and > patterns.
if I change the theme in plasma, does it change the screensaver widgets' theme? what about if I change it in this hypothetical kcm? > > 5) we must hide other activities that aren't usable as desktop activity > > (having a panel as desktop activity is a so bad idea)... > > yes, this is something that we'll want to add to the .desktop files i > think... yes. marco mentioned the formfactor, but that's not enough to tell: the screensaver containment would not work as a desktop containment, even though it is of type DesktopContainment... (I'm actually still unsure of whether it should be a CustomContainment) -- This message brought to you by eevil bananas and the number 3. www.chani3.com _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
