In KDE3 (openSUSE) panel "size" options are Tiny Small Medium Large Custom For custom, both a slider and pixel select list are presented. I agree with http://www.joelonsoftware.com/uibook/chapters/fog0000000063.html that DND as sole sizing method, the current state of KDE4 panel, is bad UI. I want all my many logins/systems conformed to each other, which is for all practical purposes impossible via DND. Therefore in systemsettings there shoud be an option to select horizontal panel height/vertical panel width from list in some fashion similar to that in KDE3. The panel settings menu could also have its height/width item expanded so that a click on it would bring up a mirror of such systemsettings object for panel size select function.
There should also be a checkbox accessible via root passwd to set the specified height systemwide.
How would you pick which panel would you modify? Further, what happens when (or if) they implement per-activity panels? There could be better ways to set the properties of the panels, but I don't think system settings is the proper place. Any such settings interface would need to essentially replicate the desktop, in which case having the settings in the panel settings interface would be simpler and clearer.
(In reply to comment #2) > How would you pick which panel would you modify? Further, what happens when > (or if) they implement per-activity panels? To me, there is only one panel, replicated on each of my 6 or 8 desktops, differing only in open window selections on the taskbar component of the panel. To me, each desktop is an activity, and I can't imagine me mixing different "activities" on a single desktop. > There could be better ways to set > the properties of the panels, but I don't think system settings is the proper > place. To me, systemsettings is a common place for changing virtually if not totally every user preference setting that is not app-specific. I don't want to have to remember different methodologies for changing settings because a setting I want to change is in this or that context instead of fu or bar context. The panel is a main component of the environment. A central location for all such settings as in KDE3's KControl is eminently sensible. > Any such settings interface would need to essentially replicate the > desktop, in which case having the settings in the panel settings interface > would be simpler and clearer. "Replication" is what KDE3 does, but AFAICT, it's nothing but 's Kicker's settings menu called as a submenu in KControl, maybe a line or three of extra code to add considerable convenience.
> To me, there is only one panel, replicated on each of my 6 or 8 desktops, > differing only in open window selections on the taskbar component of the > panel. To me, each desktop is an activity, and I can't imagine me mixing > different "activities" on a single desktop. I have two screens, one with 4 panels and one with 3 panels. For your proposal to work it would need to accommodate my set-up as well as it does yours. Add to that that there are different types of panels (there are currently at least 3), no guarantee that a panel would necessarily be docked to the edge of a screen, overlapping panels, and maybe per-activity panels and the situation rapidly becomes extremely complicated. On the other hand right-click -> panel settings is simple, convenient, consistent, and unambiguous. None of those issues I listed would interfere with that. As long as plasma supports a particular set-up, the configuration tool will need to support it as well. > To me, systemsettings is a common place for changing virtually if not totally > every user preference setting that is not app-specific. But it is app-specific, the settings are specific to a particular panel. Just like you have separate settings for each plasma widget, and each plasma desktop, you also have settings for each panel. The panel is supposed to be similar in principle to a widget, so having their settings behave in a similar manner as well makes sense. > I don't want to have to remember different methodologies for changing > settings because a setting I want to change is in this or that context > instead of fu or bar context. The panel is a main component of the > environment. A central location for all such settings > as in KDE3's KControl is eminently sensible. First, whether you consider it sensible or not, you have to explain how to actually do it in practice. I've heard lots of people requesting things like this, but so far nobody has been able to explain specifically how it could actually work. Second, everything in plasma, besides the overall theme, is based on per-item context and settings. This is consistent for widgets, panels, and desktops. You don't have to remember it individually. If it is on the desktop, it has its own settings. What you are requesting is taking one thing on the desktop and making it completely different from everything else, which would make it less consistent and harder for people to keep track of. > "Replication" is what KDE3 does, but AFAICT, it's nothing but 's Kicker's > settings menu called as a submenu in KControl, maybe a line or three of extra > code to add considerable convenience. Once again, that doesn't really explain how it would deal with multiple panels. I also fail to see why it is better. Putting the settings with the application they belong to instead of dumping them in system settings seems to be a big improvement in KDE 4 to me. Only global settings go in system settings, and the panel setting is not a global setting, for the reasons I have listed.
(In reply to comment #4) > the situation rapidly becomes extremely complicated. ... > I've heard lots of people requesting things like > this, but so far nobody has been able to explain specifically how it could > actually work. It need not. Web browsers preview web page content when hovering a tab. System settings could do likewise in the case of multiple instances of what you call apps but I call system settings, with the individual instances clickable to choose to open a particular panel's settings, similar to how in KDE3 KControl opens the same settings panel as opened by right clicking Kicker. It's simply two ways to get to the same place, centrally for those who prefer that method, and from context menus for those who prefer that method. > On the other hand right-click -> panel settings is simple, convenient, > consistent, and unambiguous. And easy to do by accident. > I also fail to see why it is better. Putting the settings with the application > they belong to instead of dumping them in system settings seems to be a big > improvement in KDE 4 to me. You call it improvement, I call it justification for continuing with KDE3 for production work, and dabbling with KDE4 only as an adjunct to overall testing of devel versions of various distros that feature KDE until such time KDE4 might actually feel better than KDE3. ATM, there's still too much wrong with KDE4, some of which I summarized in part earlier today on the openSUSE Factory mailing list: http://lists.opensuse.org/opensuse-factory/2011-03/msg00518.html
Now I'm not sure I understand what you are requesting. Are you requesting that the configuration go in system settings, or are you requesting it go in a separate, stand-alone configuration dialog that you access from the panel itself?
I really don't care about the details of how the settings dialog or applet is implemented, only that it is at least optionally reachable via systemsettings, and that if opened from systemsettings, exit from panel settings leaves one back in systemsettings, just like anything else opened from it. Plus, height should be settable by typing a number or selecting a number from a select list, plus a global default kept where configurable global defaults belong, somewhere in /etc/kd* (not lost 9 levels deep in the massive /usr/share tree in a .js file). 27px & 28px, which subjectively may or may not be reasonable on 96 DPI systems, are categorically too short at 144 DPI & higher. Probably this belongs in bug 263562 comments, but I see that and this as closely related.
Then you need to explain exactly how someone will pick which panel they want to modify. And this needs to be easier and clearer than the existing method. For the record, I am against this idea in general since it breaks the consistency of desktop configuration. Further, it violates the rules for what system settings is used for (global settings only). I know you think your special case is important. But I've seen lots of other people requests breaking these rules for lots of other special cases (such as wallpaper configuration). If everyone got their special cases put in system settings it would be a mess with nobody able to find anything. Further, having multiple paths for the same configuration just confuses people. It is unclear whether these are the same settings in different places, or different settings that alter the same thing, or different things entirely. These were serious problems in 3.5, you couldn't predict whether a setting would be in system settings, in the application's settings, or both. I am glad they took steps to correct it for 4, making sure application and widget-specific setting go with the application or widget, and only global settings going in system settings. I am against any move this would reverse this clear and consistent separation unless there is an extremely good reason, and I haven't seen one put forward in this case (personal preference or habits from 3.5 are not good reasons).
FYI, there is bug 186739 which requests to specify width/height by entering a value (in panel settings).
Still wanted for v5.
.
If you want to make panels the same, the config is available in ~/.config/plasmashellrc thickness=<somenumber> I have no intention of exposing multiple ways to configure the same thing in the UI.