The new control center shell (from Novell’s SLAB) is now on for GNOME 2.17.
As you can see in the dialog, it looks a bit ugly, not only because of the missing icons (my setup’s fault), but because there is only one category (“Preferences”). So, next step, categorize the capplets.
BTW, I couldn’t get CVSROOT/modules from GNOME CVS, so until I fix it, you’ll have to download by hand slab/libslab and put that libslab directory into gnome-control-center source tree.
With all the talk about the GNOME desktop integration lib, one of the things I had wrote down is the inclusion of notifications (proposed for Freedesktop.org) in GTK. This is something lots of desktop applications might take advantage of.
So, what do people think about it? There’s even a bug about it.
I have been doing a bad job on getting people interested in Atomato, mainly because of my lack of time for working on it. But now this is going to end, with the creation, yesterday, of the Atomato mailing list. If interested in the project, please subscribe, and if you sent me some mail in the last months about it, it would be great if you could resend it to the list once subscribed (if not, I’ll forward those mails to the list myself in a few days, once all interested people are subscribed).
Update: the web interface seems to not work at all, not even the admin interface, so the only way to subscribe to the list is to send a mail with the subject ‘subscribe’ to this address.
We have been discussing about the best way to reduce the overcrowded preferences menu, that is, the number of control center applets. The ideal solution, which we are discussing on the Control Center mailing list, is to have a new control center shell. More news on that soon.
The other things we discussed was about merging some of the applets, since some seem redundant. A good example is the keyboard capplets, which are 3!:
So this looked like the best candidate for the first merge, so after some discussion, two of them have been merged in the mockups below:
The a11y bits were not merged, mainly because the a11y guys seem to think it is better to keep it separated. And merging it with the already crowded keyboard preferences dialog seems a bad idea, given the a11y capplet has its own tabs, which would be inside the keyboard prefs capplet tab.
Any comments, suggestions, etc, please send it to the Control Center mailing list.
Being last week in Boston, for a Novell desktop team meeting, I met some people from SuSE, including Duncan MacVicar from Chile (hard to know he is from Chile with that name :-). Very nice guy, and while being KDE people, with lots of ideas and plans that mostly matched mine. Mainly, Duncan and I agreed in that KDE and GNOME should be seen as different frontends to the Linux Desktop, and this Linux Desktop should be a complete set of specifications, interfaces and shared storage data for both frontends. We talked about some things that could be shared, like addressbook and calendar data (and concurrent access to it) and Will Stephenson, another of the SuSE guys I met last week, told us about his plans to add an evolution-data-server backend for KDE, for live data sharing.
Things like Freedesktop.org should have more influence on both GNOME and KDE, so we should try to push for more specifications there. Once we have a shared infrastructure, 3rd party developers would choose one or the other based on the same reasons people choose Visual Studio/Java/Borland/.NET/etc to develop Windows applications now, and users would choose one or the other for whatever reason they feel like.
Now that KDE has officially switched to D-BUS, GNOME should be following the same path (despite poor good old Bonobo, in the spirit of cross-desktop interaction). Iain has a patch for GNOME Terminal, Sergey is working on another patch for GNOME Control Center, and… any other apps planning to do so? Should we have this as a goal for 2.16/2.18?
We all know now about Nautilus Actions, and I think people agreed, while discussing its inclusion in 2.14, on having this much better integrated into Nautilus itself. And, you know, I am in a quest to provide UNIX power to all kinds of users 🙂 So, I’ve been wondering for a few days about some ideas, which can be summarised in a mix of nautilus-actions, Automator and, of course, Nautilus.
What I’m thinking is about the Scripts menu in Nautilus context menu to provide better tools to write scripts. One, the simplest, is to create scripts directly (by allowing the user to enter a command or a full script in any language), and allowing the user the kind of tweaks nautilus-actions offers, like specifiying for which files/protocols to show the script in the menu. The other is to provide a mechanism for writing scripts like what Automator does.
In Automator, there are ‘actions’, which are just calls to AppleScript/Automator modules (and which could be calls to D-BUS services and normal commands in our case), and then there are ‘workflows’, which are combinations of actions in a specific order and with specific input parameters/sources. In our case, a XML file describing all the actions and their relationships, and an accompanying command-line tool to run those files through, could be enough for users to write scripts without even knowing a thing about programming. Experienced users could also define more actions, by just specifying commands to be run. And applications could provide even more actions, via D-BUS.
As you can see, my ideas are not still very clear, so would appreciate any opinion on how this could be done, or if it should be done at all.
Yeah, I know, I don’t blog for weeks, and now, suddenly, 3 posts in a row, but this is important, really 🙂
Our friends from the Universidad de Manizales, in Colombia, have just announced their GERvoice project, a voice recognition software used to give orders to the desktop through voice commands.
After some great advise from Michael, I’ve committed 2 changes that improve a little bit more the GNOME startup time. This, with the previous changes (to gnome-settings-daemon to lazy load not critical services, like screensaver and typing break and use a single GConf client instead of calling gconf_client_get_default repeatedly), along with the GConf improvements recently announced, login time for CVS HEAD is, for me:
My “benchmark” is very basic (chronometer), so if anyone could benchmark it better, I’d appreciate it.
I am in the process of installing many distros on a single machine, and would like to have all of them available at all times (ie, no need to reboot to switch to another one). So, I’ve heard about PXES, which, if I understood correctly, should allow to do that.
Anyone with experience on this able to give some advise?