With the summit almost finished, here’s a quick summary of what we came up about control-center development for 2.22 and beyond.
- There should be no distinction between a11y settings and others, a11y should just be part of the “normal” settings, like we did for the preferred applications capplet in 2.20.
- libslab (the library from gnome-main-menu used for the control-center shell) might need to be, either part of control-center itself, or a desktop/platform library. For that, it would need an API review, as well as the removal of Bonobo (used for unique application).
- Should keyboard shortcuts be part of the keyboard capplet?
- A11y keyboard in keyboard capplet?
- Proxy settings might be better placed as part of NetworkManager configuration, given NM allows now the distinction between system-wide and user-specific settings.
- about-me, in its current form, seems quite useless, so it might be a good idea to use it as a configuration point for online desktop.
- What to do with typing break? It might either be kept on the keyboard capplet, or moved to screensaver preferences, or enabled by default with a much friendlier 1st time configuration dialog.
- We’re adding a localization capplet, which will contain settings for time/date, timezone, keyboard layouts and language.
- New screen capplet containing screen resolution, screensaver and xrandr settings?
- PulseAudio integration
- Rename sound capplet to multimedia and add video device support?
- Some of the settings in control-center might be very useful if available from GDM.
Related to the discussion, and seeing all the icons that are in the systray, it would probably a good idea, now that there’s a discussion about a new panel, to have, in the new panel, separate systrays, each of which would be for specific categories (hardware, normal applications, temporary status, etc).
If anyone’s interested in participating in the discussion, please join the control-center mailing list and help us make it better.
Just one comment: I really don’t think typing break should be moved to screensaver settings. Sure, they’re both things that are triggered by time delays… or something? But I don’t see how they’re really related at all. One is for locking and blanking the screen, the other to rest your hands. They really just don’t seem related at all to me.
Two questions – why list is talking about something new, why not restore gnome-control-center efforts? And what PulseAudio is doing there? Yes, When I install it, I will get nice control applet, but before that…
I’m not dissing anyone in particular, but I wanted a slab-like interface for the new Matchbox Desktop and after reviewing libslab decided it was dramaticaly over-complicated.
libtaku, the slab clone in Matchbox Desktop (and Dates, and OpenMoko’s Today application) is 1600 lines of code in total.
like the ideas for integrating the capplets very much!
Some other feedback:
* keyboard shortcuts does seem something ‘else’ than other keyboard configuration. I would leave it out because it also has something to do with controlling the desktop and applications, not just the keyboard.
* screen applet with resolution and xrandr is okay, but selecting screensaver seems again less coherent with the rest.
* pulseaudio: I’m all for pulseaudio replacing esound, but the current configuration windows of pulse are too techy (sources, sinks, etc). I hope users won’t have to use them by default.
* I’d leave typing break as part of the configuration window, it should always be configurable, not only on first time or usage, and is different from screensaver settings.
* about keyboard a11y:
** the current ‘enable keyboard accessibility functions’ checkbox is a bit weird from user perspective (why necessary, why does it disable only part of the configs)
** there should be a link from the mouse capplet to mouse keys, because that’s where people go first when having problems using the mouse
Links between related capplets are good since they make finding things easier. But I think real links (like in blue and underlined) should be used in stead of buttons. People know them very well from the internet anyway so they know they can click on it without doing anything wrong. Buttons on the other hand give the impression that something will be changed and make the user interface feel more complicated (they jump out of the background). In the eclipse IDE for example, they are very handy without cluttering the UI even more.