• Sweet Video

• Sweet Video

Some people prefer to have the tool icons unobtrusive, not to steal the focus form the actual artwork. Here’s a quick theme to do just that for GIMP 2.3. Untar to ~/.gimp-2.3/themes/ and select the Greyscale theme from the preferences. The gtkrc uses menu-sized icons for the toolbar and tiny fonts.

Click to download the theme.

You need to tweak the gtkrc to your liking if that’s not your choice. There is a dark widget gtkrc included, but is commented out as it looks weird for metacity to pick up light colors from the global theme, but have the window content dark. You can of course use that one globally. Just add your favorite engine to it.

Here we go again There’s quite a discussion among graphics designers on the Mac OS platform about vector icons at the moment. The drive for this seems to be that Leopard will allow icons as large as 512×512 pixels.

I think the major immediate need for the huge size is Front Row/iTV as the icons today are scaled up beyond their original size.

Small Canvas Needs Pixel Precision

I’ve expressed my opinion on creating a single icon that works on all resolutions in the past. I don’t believe in automatic ways to get crisp icons at lower sizes. Autohinters, non-scaled strokes would most likely make the problem much less drastic, but none of this is currently available. If you don’t have a simple cartoon style icons such as Gorilla or Gartoon, you have to bother with specific resolution tweaks. Once you see yourself adding a minor detail on a 128×128 pixel canvas, you’re not going to see any of it at below 32×32.

There is an amazing difference between looking at a 16×16 pixel canvas and something as huge as 512×512.

In the Tango project we cared about pixel precision and the low resolutions first. The largest size we actually design for, is 48×48 pixels. The artwork is vectors, it does scale up, but that doesn’t necessary mean it will look spiffy at 128×128 pixels. The images don’t have all that much detail.

Big Canvas Needs Detail

The Tango style guideline doesn’t deal with the territory of really large icons, yet. The need for high res icons will grow in time I guess. The amount of detail required will raise both the number of objects used and the effects such as blur or object masks. I agree the complexity will rise so that a simple pixbuf loader will be dramatically faster than using a runtime rasterizer.

The flexibility vectors give is definitely going to win for me for large sizes. Currently working on such complex artwork in Inkscape is quite a challenge and quite a factor for us to postpone this, until our tools are ready. It’s unlikely you will need toolbar icons with extra detail than the current scalables don’t provide. This is mostly about application icon context.

For the artist vectors are ineed sweet that they easily allow more dramatic changes to the artwork at any time during the creative process. Also it’s a lot easier to create derivate artwork. I don’t see them as the big win in that a single high-detail artork can be created for all resolutions though.

• Craig Hockenberry – Resolution Independence for Developers.
• Jasper Houser – Big Ass Icons?
• iSlayer.com – All roads lead to bitmap
• Josh Williams – Icon Design, Bitmap vs Vector.

Getting a wacom tablet running is still quite painful. Even if you are lucky and your distribution ships a working kernel driver/X driver combination, there’s still quirks that make the tablet not work.

A very common problem is that /dev/input/event* devices get shuffled around when you unplug mice or tablets or sometimes it happens on its own. There is a neat way to specify the device in the xorg.conf by ID, just look up your devices in /dev/input/by-id/. A better tool to check your input rather than doing cat /dev/input/event0 is using a utility called xxd.

Sometimes the wacom is fighting with a USB mouse if you use the /dev/input/mice combo-device in your xorg.conf. Use a specific mouse device (you can use by-id here as well).

Section "InputDevice"
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Device" "/dev/input/by-id/usb-Microsoft_Microsoft_5-Button_Mouse_with_IntelliEye_TM_-mouse"
    Option         "Protocol" "IMPS/2"
    Option         "Emulate3Buttons" "yes"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
    Identifier     "cursor"
    Driver         "wacom"
    Option         "Device" "/dev/input/by-id/usb-Tablet_GD-0405-U-event-mouse"
    Option         "Type" "cursor"
    Option         "Mode" "relative"
    Option         "USB" "on"
    Option         "Xinerama" "on"
EndSection

Section "InputDevice"
    Identifier     "stylus"
    Driver         "wacom"
    Option         "Device" "/dev/input/by-id/usb-Tablet_GD-0405-U-event-mouse"
    Option         "Type" "stylus"
    Option         "Mode" "absolute"
    Option         "USB" "on"
    Option         "Xinerama" "on"
    Option         "DebugLevel" "10"
EndSection

Section "InputDevice"
    Identifier     "eraser"
    Driver         "wacom"
    Option         "Device" "/dev/input/by-id/usb-Tablet_GD-0405-U-event-mouse"
    Option         "Type" "eraser"
    Option         "Mode" "absolute"
    Option         "USB" "on"
    Option         "Xinerama" "on"
    Option         "DebugLevel" "10"
EndSection

If you use Xinerama it’s very likely you don’t want the tablet to work in the central area in between the monitors That’s what the Option “xinerama” “on” is for.

However this is where the succes part of my journey ends. While GIMP provides two modes for the tablet to work, Window, where the tablet space is mapped onto the active image window (sadly I never figured how to make the cursor do that as well, creating a quite confusing situation where you paint while selecting random items on your desktop and moving them onto trash…) and screen which is likely what everyone wants. The problem is that with my dual monitor xinerama setup I have my cursor on the right one and I paint on the left one. Any tips, lazyweb?

• My current xorg.conf

Not everyone knows that F-Spot has a very neat viewer mode. By default
F-Spot manages a photo library, but if you invoke it with `f-spot –view $file-or-folder` it will work on the
provided pictures.

EOG in Gnome is a very decent viewer, but F-Spot has a nice RAW file support
for very quick previews. Another great advantage of f-spot-viewer is the
posibility to export to Flickr and other supported photo-sharing and
publication systems thanks to a recent patch by Thomas Van Machelen.^*

There are pictures I
certainly don’t want in my photo library, but are easily previewable and
uploadable.

* Update – corrected the original patch author.

Not everyone knows that F-Spot has a very neat viewer mode. By default
F-Spot manages a photo library, but if you invoke it with `f-spot –view $file-or-folder` it will work on the
provided pictures.

EOG in Gnome is a very decent viewer, but F-Spot has a nice RAW file support
for very quick previews. Another great advantage of f-spot-viewer is the
posibility to export to Flickr and other supported photo-sharing and
publication systems thanks to a recent patch by Thomas Van Machelen.^*

There are pictures I
certainly don’t want in my photo library, but are easily previewable and
uploadable.

* Update – corrected the original patch author.

A year ago I
posted about a neat short by Claude Lelouch. Now he explains how things
were done. For those speaking French at least.

• Youtube presentation

I’m joining Andreas in the
quest for less fuzz on the desktop!

Winter

Good timing today. I had my tires replaced this morning, only to get the
first snow in the evening. Now if only winter lasted only 3 months and not 6
like last year…