OpenOffice Impress toolbar click map

More information on what they’re doing can be found over on the GullFOSS Blog.

At Sun, and I’m sure at most other companies that support software products, we have to tell our customers in advance when (certain) features are going away. We can’t just drop them from one release to the next because we’ve gone off the idea.

Personally, I’d like to see GNOME manage this a lot better, perhaps (from the end user’s perspective) via a section in the GNOME release notes that said which features we intended to remove from the next release. The impact of such changes would then have to be thought through well in advance, and there’d be plenty of time to remove the feature, fix any related issues, and properly update the documentation prior to its actual disappearance. And users would have time to prepare for the change, and have the opportunity to raise any sensible objections before the fact, rather than after it.

(This thought isn’t especially new, nor directly aimed at the proposed Windows capplet removal… although I do know that’s a decision that would generate support calls for Sun users and customers, who always scream when anything related to their sloppy focus settings breaks, changes or goes away. Many of them have been using sloppy focus on UNIX desktops since before GNOME or even Linux were first thought of, so it’s not a feature we like to mess with…)

First of all, I should say that I actually have little personal involvement in this project—it’s being led by Kristin Travis and Jenya Gestrin of Sun’s xDesign team… I’m just abusing my position on Planet GNOME to plug what they’re doing And as yet, there’s no production code to speak of, just mockups and Flash prototypes, so there’s still plenty of scope for feedback.

You can download the latest protoypes, peruse numerous mockups, and read about the design process to date (including a usability study on the capplet categorisation) on the Usability Project’s Control Center Whiteboard pages.

Latest control center mockup

Feedback welcome here, on the control center mailing list, or direct to Kristin and Jenya.

A more accurate affiliation

It does require Java, there are only 8 slots available at any one time, and right now they’re still provisioning OpenSolaris 2008.11 rather than the newer and shinier 2009.06. But if you want to give OpenSolaris a quick whirl, you might find it more convenient than downloading the LiveCD.

More info in Brian Leonard’s blog entry.

Compiz running in VirtualBox

EDIT: I suppose I ought to add there’s some other cool stuff in 2.2.0 as well, particularly the ability to import/export appliances in OVF format.

.

• Support for hardware virtualization (VT-x and AMD-V) on Mac OS X hosts
• Support for 64-bit guests on 32-bit host operating systems (experimental; see user manual, chapter 1.6, 64-bit guests, page 16)
• Added support for Intel Nehalem virtualization enhancements (EPT and VPID; see user manual, chapter 1.2, Software vs. hardware virtualization (VT-x and AMD-V), page 10))
• Experimental 3D acceleration via OpenGL (see user manual, chapter 4.8, Hardware 3D acceleration (OpenGL), page 66)
• Experimental LsiLogic and BusLogic SCSI controllers (see user manual, chapter 5.1, Hard disk controllers: IDE, SATA (AHCI), SCSI, page 70)
• Full VMDK/VHD support including snapshots (see user manual, chapter 5.2, Disk image files (VDI, VMDK, VHD), page 72)
• New NAT engine with significantly better performance, reliability and ICMP echo (ping) support (bugs #1046, #2438, #2223, #1247)
• New Host Interface Networking implementations for Windows and Linux hosts with easier setup (replaces TUN/TAP on Linux and manual bridging on Windows)

Downloads for Solaris, OpenSolaris, Linux, OS X and Windows are available here.

Glynn has written up a good summary of new features, which include GNOME 2.24, ZFS Time Slider, accessible install, and big improvements to plug’n'play printer support, automatic network configuration, and laptop suspend/resume. The number of additional packages available in the repositories has greatly improved since the 2008.05 release, and we now have various repos and a new process that will make contributing packages easier than ever.

Roman Strobl has produced a 12 minute screencast to show off some of the new bits, and Erwann Chénedé has a shorter one that focuses exclusively on Time Slider, which seems to have been generating a lot of interest.

Of course, 2008.11 still has all the usual Solaris goodness like ZFS, Zones and Dtrace built-in, with the Solaris Trusted Extensions now just a click away too, giving you access to one of the most secure desktops on the planet*.

So why not give the LiveCD a spin? You can grab it via BitTorrent, or download the ISO directly from Sun (or alternatively, from the genunix mirror, or via FTP from LTH in Sweden).

* Probably (OpenSolaris Trusted Extensions hasn’t received Common Criteria Certfication yet, but the Solaris 10 version was most recently certified at EAL 4+. More information here.)

It works a bit like another company’s product of a similar name, except right now ours only takes regular snapshots to the same disk, rather than backing up to removable media (but we’ll probably end up doing that too). It’s not quite the auto-save function that Federico was talking about last week and at GUADEC, but it’s certainly nice to see some of the power of ZFS in use on the desktop at last.

It works fine for the hicolor icons, but the advice for themes that want to over-ride them is rather vague: “You can also provide icons for other themes in here [$pkgdatadir/icons], by installing them into a subdirectory for that theme.”The question is, who’s responsible for installing them? The theme or the app? Seems to me there are problems either way.

If the theme installs them, first it has to find out where that app installed its hicolor app-specific icons. It will usually be /usr/share/appname/icons/hicolor, but there’s no guarantee about the value of $pkgdatadir for any particular application.

Once over that hurdle, the theme is now stomping in the application’s territory. At best, uninstalling the app will leave a $pkgdatatdir/icons directory on your disk, containing a bunch of icons that aren’t going to be used any more. At worst, the app uninstall might just lazily blow away the $pkgdatadir directory altogether, wantonly deleting files that were installed by another package (the theme).

On the other hand, though, we surely can’t expect each app to be responsible for installing icons for every theme that wants to override them. Distros can of course patch those apps downstream with their branded icons du jour, but that will soon become cumbersome when there are more than two or three such apps. And independent theme artists, such as those who contribute to art.gnome.org, don’t have the luxury of patching any apps at all. So their themes would never be able to override app-specific icons.

So what to do? The more I work with themes, the more I wish they’d all go away and we’d just use a single, identifiably-GNOME look-and-feel like the grown-up desktops do