Botching the Trivial

As a developer, I’m used to screwing things up. It comes with the job, and that’s why we have beta testers, QA, and code reviewers. You get used to it, and usually it ends up not being too big a deal.

What’s really embarrassing is when the screwup is literally staring you in the face and makes it into a major release. This was the case with the VMware Workstation and Player application icons in Workstation 6.0.

During development of Workstation 6.0, I felt the icon set needed a refresh. We try to fit in well with the GNOME desktop, and our icons just didn’t match. They weren’t bad, but they could have been better. I spent a lot of my free time creating a new set of icons for the application in the Tango style. This included application icons.

Our previous application icons were beveled and out of place in a Tango-themed desktop, so I replaced those as well. The result was really nice. After getting people to look at them, I committed them and wrote scripts to install all our fancy new icons with the product.

But something wasn’t quite right. I knew it but didn’t really think about it until after the release. There was something about the icons in the panel and menus. They looked fine on my development system toward the end of the Workstation 6 development cycle, but didn’t look right when I next installed a build on that system. I guess I shrugged it off as just being something screwy with my setup, but when I installed Workstation 6 on my laptop, the icons still looked wrong.

They were blurry. I made nice crisp icons! Where did these blurry ones come from? I figured it had to do with my panel size and that it scaled the 24×24 ones down to 22×22. That must be it, I thought.

It wasn’t until a couple of days ago when I finally decided to look into this thoroughly. What I saw made me so sad. The .desktop files for the applications contained:

Icon=/usr/share/icons/hicolor/48x48/apps/vmware-workstation.png

Yes. I never updated the old .desktop file generation code to use an icontheme name. It was still using the really old code querying the 48×48 icon we used to ship.

I suddenly realized why it used to look fine on my box. When I first tested these icons, I hand-modified my .desktop file to test the icons. It wasn’t until I installed a new build that I got the shipped .desktop file.

As you can imagine, I felt like an idiot. I decided to fix this quietly without making my idiocy too obvious to everyone else. (Don’t tell anyone, please. They think I’m smart.)

Just to give a sense, here’s a before and after shot.

Before
Broken WS6 icons

After
Fixed WS6 icons

Ah, much better. We have pretty icons again! Of course, had I fixed one single line of code and looked at a generated .desktop file once before release, that wouldn’t have happened.

But everyone makes at least one stupid mistake in a release, right?

Working outside the box with Unity

A Brief History of Boxes

In the days of old, working on your computer meant working inside a limited contained box. You could run programs but only one at a time, because running two at the same time would require two computers. This was the status quo for years. It’s just how computers worked.

Then a new technology changed everything. Multitasking. Now you could buy one computer and your operating system would allow you to run multiple programs at once. No longer were you tied to one box at a time. You could have one for your word processor, one for your spreadsheet, and one for solitaire. It was a spectacular invention, one that we quickly took for granted. Relatively few computer users today even know what it’s like to use a computer without this ability.

As time went on, new operating systems began to develop substantial user bases. The competition between them grew, and most applications were tied to a particular operating system. You were limited to one operating system at a time, and if you wanted to run two at once you would need two computers.

Then came modern virtualization, which shattered this barrier. Now you could have one or more giant boxes on your computer containing a full operating system, each with different applications running. These boxes could sit side by side. Some people are already taking it for granted. Soon grade school children will be using virtualization without even knowing that there was a world before it.

But up until now, working in a virtualized environment meant working in a big box on your screen. Sure you could have several going at once, but you realistically could only interact with one at a time. These boxes represented screens, and you can only fit so many screens on a single screen at once before you start feeling really cramped.

Shattering the box

Earlier this year, we released VMware Fusion 1.0 for the Macintosh. This was our first virtualization product for the Mac and it has been met with high praise. And jealousy. VMware Fusion managed to change how users thought about virtualization. Thanks to Unity, you were no longer forced into having a big box on your screen. With the click of a button, the applications inside your virtual machine would appear outside of the box, sitting alongside your other applications. The Mac users loved this and Windows and Linux users were left feeling like they missed out.

I can’t recall how many times I’ve been asked if Workstation is going to include Unity in Workstation.

Unity
The answer is yes. Well, eventually.

I’m working on adding Unity support to the Linux codebase, which may in time be part of Workstation or Player. This will allow your Windows and Linux programs to intermingle with the click of a button. As of right now, here are the current state of things:

Unity Today

Unity today works in Linux on my system. It’s known to work in Metacity but hasn’t been thoroughly tested in other window managers yet. The basic things you’d expect all work for the most part. The rest will come later.

What I have working today

So far, the very basic window management works today, for the most part. It’s usable just enough to go “Oh neat” and to play a game of solitaire.

Many things do not work today, though.

  • Virtual desktops do not work. If you move windows to other desktops, you’ll have problems.
  • Multiple monitors might work but probably won’t.
  • Alt-dragging or otherwise moving a window in a way other than by using the titlebar will cause us to get out of sync.
  • If you attempt to drag a window off-screen, the window manager may block it, but the events will still be sent to the guest. This could cause the window to get “stuck.”
  • Minimizing a window using the taskbar may cause visual oddities.
  • Partially obscured windows may look wrong when in Compiz’s Expose mode or similar modes where all windows are displayed at once.
  • There’s no proper start menu integration. Exit Unity mode to launch new applications or press the Windows key or Control-escape while in a guest application to bring up the guest start menu.

These issues are being addressed. In many cases where windows become “stuck,” simply leaving Unity and then going back into it should fix the problem.

Going forward…

There’s a lot we have in the works for Unity, and while I cannot yet talk about it all, the end result should be just awesome. I’m hoping to have a video demoing it at some point.

P.S. For those who notice the borders and VMware logo badges on the Windows windows in the screenshot and find them annoying, you will be able to disable them. The idea is to allow you to easily determine the guest windows from the host windows when the OS and theme are the same.