Wubble

As Joe’s blog doesn’t do comments, I’ll have to reply this way 🙂

Yes, we probably should have a FAQ somewhere that lists all the files you need to care about, but the reality is that tarring up the directory is good enough. It’s 2.8gb but almost all of that is stuff you want. The bits you can afford to skip are a few kilobytes at best. If you really want, I can put a list together – I don’t remember everything off the top of my head right now, but just grabbing the directory is your best bet.

If you want to copy a VM but discard all the snapshots, then you should first do a full clone of the VM and send the result to the other party. The full clone operation consolidates all the snapshot delta disks, and because it’s a full clone, there’s no dependency on the original VM.

As for the crash, if you read down through my blog, you’ll find the entry about the librsvg bug; guess what: you just hit it. But I was told this evening that the update *just* came out, so go run your SuSE update and get the fix.

As Joe observes, the kernel module code that ships with ws 5.0 is not happy to work with the latest kernels including the one that ships with SuSE 10. The userland code is happy but you’d need to grab Petr’s drivers to get it to work. Joe did the right thing by trying to get a hold of the 5.5 beta because it works great with SuSE 10, as demonstrated by our internal testing and the experience of other beta testers. However, the website let us down and that really is inexcusable. At the Boston Summit, some people tried to grab the beta based on our nagging and ran into the exact same error; I ended up having to VPN in to our internal network and download the beta build directly and then scp it over to them. When I get into the office tomorrow, you can be sure I’ll be making a lot of noise about this. Sorry for the trouble; if people are still having trouble downloading the beta, please post a comment to this post.

As a happy coincidence, on the same day that GNOME 2.12 is being released, we’ve managed to get everything sorted out over here to push out the initial release of VIEW, VMware’s Incredibly Exciting Widgets; so named by Christian without a hint of irony. Honest. 🙂

VIEW is a collection of widgets that we developed while working on Workstation 5 that we felt were general purpose enough to have value to the community. Our intention is for the VIEW sourceforge project to be the one place where these widgets are developed and maintained; so we’re not going to have a parallel internal tree which we push updates out from. We’re also planning to move a number of other widgets into the library in due course. Most of them are written in C++ on top of gtkmm but a couple of them are in C. I know that this is probably going to limit initial interest because the overwhelming majority of GTK+ applications are not written in C++, but if nothing else, someone may like some of them enough to rewrite them in C for wider consumption, or maybe Inkscape will want to use one. 🙂

Doxygen docs are available in the tarball and can be regenerated out of the sourcetree, but we currently don’t have a nice summary of the widgets in the library anywhere else (the web page is on the way), so it’ll be useful to put a quick one together here:

C++ Widgets and Objects

• view::ActionGroup: A very simple wrapper around gtk::ActionGroup that allows the group to carry it’s merge position around with it.
• view::BaseBGBox: A somewhat inaccurately named widget for historical reasons. This is a container that paints itself using its current state’s base colour. We use this to provide the background for the summary pages in Workstation. The BG is in the name because it used to always use the BG state’s colour. This implements the painting technique I described before to work around the way some themes treat event boxes.
• view::Header: A creative use of menuitems as a header for the sections of Workstation’s summary pages and About dialog. We originally hard-coded a silver/grey gradient for this but that’s obviously not very theme friendly, so this was the alternative I came up with, and it works surprisingly well. A small workaround is required to get the text right with a couple of themes, otherwise a separate widget wouldn’t really have been justified.
• view::MenuToggleAction: An action that provides a toggle action with a secondary menu. So, on a toolbar you get a toggle button with a context menu and in a menu, you get an item with a submenu with the actual toggle item as the first entry. It’s a little suboptimal as one would prefer to use a MenuToolButton in the toolbar but we can’t depend on GTK+ 2.6 yet.
• view::MotionTracker: Now this one’s pretty neat. It’s a specialised signal object that fires whenever a target widget moves. I was really surprised to find that GTK/GDK didn’t provide this information already – and in fact, GDK actually filters out the necessary X events early on, so we have to listen at a very low level to make this work.
• view::Reparenter: A helper object to aid in achieving flicker-free reparenting of children. Unfortuntately, the code you see here only works correctly with GTK+ 2.4. The reparenting mechanism changed in 2.6 and an additional workaround is needed, but this requires intimate knowledge of the widget being reparented because the map operation has to be blocked at a particular point. We plan to have the additional steps documented.
• view::Spinner:A subclass of Gtk::Image that holds a set of frames and knows how to advance through them. The mechanism of obtaining the frames and timing the animation is left to the user of the widget.
• view::SpinnerAction:An Action that provides a spinner using the Spinner widget. It can drive multiple spinner proxies and handles the tedious task of chopping up a multi-frame-single-image style spinner like the default gnome-spinner. Again, the precise animation timing is left up to the consumer or subclass.
• view::ToolTip: An actual tooltip widget! I’m sure most people are aware of what you can and can’t do with GtkTooltips, and one of the things you can’t do is programmtically make a tooltip appear when you want it, so I wrote this widget to fill that gap. As a bonus, it uses the MotionTracker so that it maintains its relative position to its ‘parent’ widget while its on the screen. The timeout is currently hardcoded but I intend to fix that.
• view::UIGroup: One thing that I always felt was missing from GtkUIManager and friends was an easy way to programmatically modify the UI definition, so I wrote this object to be broadly analogous to the ActionGroup, in that it encapsulates a UI definition fragment that can be merged and unmerged in the same way that ActionGroups can be inserted and removed. This allows us to use a pattern where an object, such as a virtual machine, provides its own UI definition and actions. This is particularly useful for dynamic menus, such as the list of virtual devices in a VM.
• view::Viewport: A subclass of Gtk::Viewport that works around an oddity (bug?) in how GtkViewport handles a size_request.
• view::VisibilityBox: Ever been annoyed at how you find that even though you have a visible container, like a GtkFrame, with no visible children, the container still has a non-zero size_request? Well, Régis was, so he wrote this to fix the problem. It’s a container that hides itself if it has no visible non-layout-providing children. So you stick your GtkFrame inside it and if the frame’s children happen to be hidden, the VisibilityBox will make sure that the Frame is hidden too.
• view::WeakPtr: A weak pointer template class. I’d really like to see this go into gtkmm. Hopefully Murray is interested 🙂
• view::WidthHeight: A very low level widget that is essentially a generalisation of the AspectFrame. It is configured so that one dimension is normally allocated causing a signal to be emitted. The callback then calculates what the other dimension should be and then sets it. If you think this is rather obscure, you’re right 🙂
• view::WrapLabel: A label widget that intelligently wraps onto new lines if it runs out of horizontal space, courtesy of Christian.

C Widgets

• ViewOvBox: A container with two children that can overlap. The foundation of the ViewDrawer widget.
• ViewDrawer: A subclass of ViewOvBox that can smoothly slide the one child over the other. We use this to implement the auto-hide toolbar in Workstation; it looks really nice and might be useful for the gnome-panel in auto-hide mode.

And where would we be without a screenshot? Here’s one of the new VM summary page (now theme compliant!) using the BaseBGBox and Header widgets. (And the theme is XFCE-Stellar):

Well, gnome-settings-daemon has been tamed thanks to sound advice from Jonathan and Ed. It’s unfortunate that GtkSettings isn’t documented in any meaningful way, because it turns out it wasn’t a hard problem.

But, I wasn’t able to enjoy my success for long, because I now had to confront the other major obstacle in the way of thematic bliss: gtk-qt-engine. This notionally friendly little library is a GTK+ theme that uses QT for drawing, with the result that GTK+ apps look pretty much like QT ones. SuSE and, I think, Mandrake use it as part of their KDE desktops. However, there are a couple of problems that mar this seemingly sensible picture.

• Firstly, SuSE uses a very unfriendly mechanism to include the theme: Rather than modifying ~/.gtkrc-2.0 and specifying the theme by name, they actually append the theme’s gtkrc to GTK2_RC_FILES in the user’s environment. This means that the theme’s rules are applied but not as a theme. As a result, it is not possible to ignore or override the theme! If we recall why gnome-settings-daemon was a problem (running on pre GTK+ 2.4 systems) we can quickly conclude that we’ve got a problem here too. Workstation 5.0 doesn’t address this because we wanted to helpful and not ignore the user’s GTK2_RC_FILES if at all possible, but I think that’s misplaced helpfulness, and it’s really going to be kinder to reset GTK2_RC_FILES to a sane value when we’re using our shipped GTK+ libs.
• The second problem is a fundamental flaw in gtk-qt-engine itself: If you’re running a recent enough SuSE (or Mandrake?) distro, then your GTK+ is new enough, and we can actually use the gtk-qt-engine and everything looks great – except that the virtual device icons which are supposed to flash when the device is active don’t flash… Now, why don’t they flash? The code in question switches between the NORMAL and SELECTED bg colours to create this flash (It’s probably more correct to use the base SELECTED colour, but that’s a separate issue). This seems at first glance to be a reasonable mechanism because it’s a pretty pathological theme that doesn’t distinguish NORMAL and SELECTED. Well, guess what’s a pathological theme?

  It seems that either as a side-effect or an un-noticed bug, gtk-qt-engine sets all the gtk symbolic colours to the same value and relies on the fact that QT is drawing (almost) everything to produce something that looks correct. So, simply switching colours is never going to product the desired result. What’s a guy to do?

  One option is to calculate the activity colour on the fly, probably by inverting the NORMAL colour. That, at least, will provide some sort of feedback. However, what I’m currently inclined to go with is to override the expose handler and tell the EventBox to paint itself like the selected cell of a treeview. This should amount to the same thing as the old code in most cases and actually produces results with gtk-qt-engine. Now, that seems like a pretty crazy workaround to me, and it really shouldn’t be necessary, but when a pathological theme ends up as the default for major distributions, you don’t have a lot of choice.