Sneak Preview of Conky 1.8.0

So...

I was tipped off whilst trolling the #conky channel on IRC that there would be new ARGB support in the 1.8.0 release candidate of Conky, so naturally I HAAAAD to try it out! I grabbed the latest version from here, and had a go...

First things first, I wanted to try out ARGB, in other words, REAL transparency, as opposed to pseudotransparency. For those of you who don't know the difference, pseudotransparency, rather than actually being see-through, detects what's drawn on the desktop window, and draws it as the Conky background, so it appears, on a blank desktop, as though it's clear. However, as we've seen before, pseudotransparency can cause some hiccups, if you're expecting it to behave like real transparency. It's a particular problem in KDE, for instance, which doesn't draw anything to the desktop window by default, so Conky ends up with a blank background.

In order to test the ARGB functionality, I made a little widget in Lua/Cairo that would be able to sit on top of my other windows, and here's what it came out as:

From My Little Desktop Photos

Note how you can see the corner of my window *through* the Conky widget...That's ARGB!

Some of you eagle-eyed readers may also have noticed that I said I used Lua/Cairo to draw the widget, but the last time I posted about text manipulation in Cairo, I was frustrated by the lack of a cairo_text_extents() object, which allows for centering and alignment of text. But it's now been compiled into the Cairo bindings Conky uses, so from v1.8.0, you'll be able to use it. The desktop I'm currently using has only Conky widgets on it:

From Screenshots

With the current setup, I'm starting to wonder what the benefits are of using Conky over Screenlets...I first thought that it would actually be more efficient to use Screenlets, because I thought they were compiled, but some clever clog pointed out to me that they are written in Python, so not compiled! I think the only barrier to Conky completely taking over Screenlets' territory now is the user-friendliness of Screenlets...Hm...

GTK Theming Isn't Really That Hard. Honest!

So, I've been away for awhile...

Been rebuilding a machine, getting fed up, buying a new computer, setting that up, and generally being ADHD with all my little projects...

Anyway, I've started working on GTK themes, and as it turns out, it's not as difficult as it seems at first. I've released two GTK themes recently on my DeviantArt account...Have a look!

From Screenshots

Ultrasuede is the first of the two themes, named after the sofa I sit on to do most of my work! I'm not entirely sure why I started with this one, after all, it's no secret that it's difficult to write dark GTK themes, and as it turns out, it's even harder when you want only parts of the theme to be dark (in this case, the menubar/menus and toolbar). I still consider this one a work-in-progress, but I still love it for its softness of colour and general readability. Plus, it's got lovely blue tooltips!

From Screenshots

Venus is my latest theme, and the one I'm currently using. I originally started it because I wanted to write a grey/silver theme, but the ones I find tend to be either too simple or too shiny. I don't like my widgets to be glassy; I prefer a more soft, smooth lighting effect. So I started with the colour scheme from elementary (one of my favourite packages, although like I said, I find the widgets too shiny) and went from there...Changing the accent colour from blue to green, and added soft yellow tooltips. Very soothing, I think!

But anyway, the point of this post was not to toot my own horn ("Too late!" I hear you cry...), it was to explain how I started in GTK theming, and point out some tips to get you started doing it for yourself.

First things first: Step 1 is to grab some GTK themes that you like. Some of my favourites are:

• Elementary GTK (eGTK)
• Espresso
• Human (any of the various versions that come packaged with Ubuntu)
• Dyne Dark (comes pre-installed with Crunchbang Linux)

Then, find and bookmark the GTK Hierarchy and the GTK reference manual. All of these things will help you later.

Now, close your eyes, hold your breath, and jump in.

Start by copying one of your themes into ~/.themes/ and changing the folder to something you can remember. I tend to use ~/.themes/Untitled for new themes I'm working on. The file structure of a GTK theme looks like:

~/
+-- .themes/
    +-- Untitled/
        +-- gtk-2.0/
            +-- gtkrc

If it's a theme like Human, you may also find folders for Metacity, an index.theme (for icons) and others inside the Untitled/ folder.

It's the gtkrc that we want to edit. It's a simple text file with a relatively simple layout.

First, you may define a colour scheme (this is what turns up in the Colors tab of the Customize... dialog in Gnome Appearance Preferences). It will look something like this:

gtk_color_scheme = "base_color:#F7F9FA\nfg_color:#4D4D4D\ntooltip_fg_color:#000000\nselected_bg_color:#a5b26b\nselected_fg_color:#ffffff\ntext_color:#4D4D4D\nbg_color:#D6D6D6\ntooltip_bg_color:#f2f29d"

Next, you should have a listing of styles, in the format

style "name"
{
    Various style properties
}

Start with a "default" style, which will be applied to all widgets, and then on to more specific styles that will apply to only certain widgets. The default style can contain as much as little as you like, but typically you will find:

• Some specific widget style properties, of the format GtkWidget::style-property = value
• Thickness parameters, which define the padding of the objects inside widgets, and look line xthickness = value and ythickness = value
• Colour definitions, of which there should be 20: foreground (fg), background (bg), background of entry fields (base) and text (text), and five states for each (normal, prelight, active, selected and insensitive)
• Default settings for the engine (if any) you choose to use

The "default" style for my latest theme, Venus, looks like this:

style "default"
{
 GtkButton ::child-displacement-x  = 1
 GtkButton ::child-displacement-y  = 1
 GtkButton ::default-border  = { 0, 0, 0, 0 }

 GtkPaned ::handle-size   = 6

 GtkRange ::trough-border   = 0
 GtkRange ::slider-width   = 13
 GtkRange ::stepper-size   = 13
 GtkRange ::stepper-spacing  = 1
 GtkRange ::activate-slider  = 1
 GtkRange ::arrow-displacement-x  = 1
 GtkRange ::arrow-displacement-y  = 1
 GtkRange ::arrow-scaling   = 0.7

  GtkScale ::slider-width  = 13 # Needs to be ODD in order to center evenly
  GtkScale ::slider-length  = 13
  GtkScale ::trough-side-details = 1 # 0 = empty slider, 1 = filled
  GtkScale ::trough-border  = 1

  GtkScrollbar ::min-slider-length = 42

 GtkScrolledWindow ::scrollbar-spacing = 3

 GtkNotebook ::tab-curvature   = 1
 GtkNotebook ::tab-overlap   = 1

 GtkMenuBar ::internal-padding  = 0

 GtkExpander ::expander-size   = 14

 GtkToolbar ::internal-padding  = 0
 GtkToolButton ::icon-spacing   = 3

 GtkTreeView ::expander-size   = 14
 GtkTreeView ::vertical-separator  = 0

 GtkMenu  ::horizontal-padding  = 0
 GtkMenu  ::vertical-padding  = 0

 xthickness = 1
 ythickness = 1

 fg[NORMAL]        = @fg_color
 fg[PRELIGHT]      = @fg_color
 fg[SELECTED]      = @selected_fg_color
 fg[ACTIVE]        = @fg_color
 fg[INSENSITIVE]   = shade (0.7, @bg_color)

 bg[NORMAL]        = @bg_color
 bg[PRELIGHT]      = shade (1.05, @bg_color)
 bg[SELECTED]   = @selected_bg_color
 bg[INSENSITIVE]   = @bg_color
 bg[ACTIVE]        = shade (0.95, @bg_color)

 base[NORMAL]      = @base_color
 base[PRELIGHT]    = shade (0.95, @bg_color)
 base[ACTIVE]      = shade (0.7, @bg_color) # Unfocused selected text background
 base[SELECTED]    = @selected_bg_color
 base[INSENSITIVE] = @bg_color

 text[NORMAL]      = @text_color
 text[PRELIGHT]    = @text_color
 text[ACTIVE]      = @selected_fg_color
 text[SELECTED]    = @selected_fg_color
 text[INSENSITIVE] = shade (0.7, @bg_color)

 engine "murrine" 
 {
  animation  = TRUE # FALSE = disabled, TRUE = enabled
  colorize_scrollbar = TRUE # FALSE = disabled, TRUE = enabled
  scrollbar_color  = @selected_bg_color
  contrast  = 0.8 # 0.8 for less contrast, more than 1.0 for more contrast on borders
  glazestyle  = 0  # 0 = flat highlight, 1 = curved highlight, 2 = concave style, 3 = top curved highlight, 4 = beryl highlight
  gradient_shades  = {1.05,1.02,1.02,1.0} # default: {1.1,1.0,1.0,1.1}
  gradients  = TRUE # FALSE = disabled, TRUE = enabled
  highlight_shade  = 1.0 # set highlight amount for buttons or widgets
  lightborder_shade = 1.0 # sets lightborder amount for buttons or widgets
  lightborderstyle = 0   # 0 = lightborder on top side, 1 = lightborder on all sides
  listviewheaderstyle = 1   # 0 = flat, 1 = glassy, 2 = raised
  listviewstyle  = 1   # 0 = nothing, 1 = dotted
  menubaritemstyle = 1   # 0 = menuitem look, 1 = button look
  menubarstyle  = 0   # 0 = flat, 1 = glassy, 2 = gradient, 3 = striped
  menuitemstyle  = 1  # 0 = flat, 1 = glassy, 2 = striped
  menustyle  = 0   # 0 = no vertical menu stripe, 1 = display vertical menu stripe
  reliefstyle  = 1   # 0 = flat, 1 = inset, 2 = shadow
  rgba   = FALSE # FALSE = disabled, TRUE = enabled
  roundness  = 3  # 0 = squared, 1 = old default, more will increase roundness
  scrollbarstyle  = 0     # 0 = nothing, 1 = circles, 2 = handles, 3 = diagonal stripes, 4 = diagonal stripes and handles, 5 = horizontal stripes, 6 = horizontal stripes and handles
  sliderstyle  = 0  # 0 = nothing added, 1 = handles
  stepperstyle  = 1  # 0 = standard, 1 = integrated stepper handles, 2 = unknown
  toolbarstyle  = 2  # 0 = flat, 1 = glassy, 2 = gradient
 }
}

Since you will apply the default style to all widgets and then pick out individual widgets to change after that, the other styles you define will typically only be a couple of lines long, which will override the corresponding lines from the default style.

After you've defined all your styles, then comes widget matching. It's how the theme applies your styles to all the various widgets that might pop up in GTK-based programs. There are three types of matching:

1. Class
2. Widget class
3. Widget

The first (class) is the most generic, and the last (widget) is most specific. Widget overrides widget class overrides class. Within each type of matching, later lines override earlier lines. So for instance:

class "GtkWidget" style "default"
widget_class "*GtkCombo*" style "wider"
widget "*.gtk-combobox-popup-menu.*" style "combobox-popup"

Here, all widgets first have the default theme applied. Then anything whose widget class contains GtkCombo (note the * wild card) has the "wider" style applied. Finally, the very specific case of a widget with .gtk-combobox-popup-menu. will have "combobox-popup" applied. (Please note there is some trickiness here to do with the wild card * -- you can also use $ for a single-character wild card -- and the best place to learn to navigate it is to use trial and error.)

And that's it...For the basics, that is! To get started making your own theme, I would start by tweaking with someone else's, so you get a feel for what changes what. Then if you get really brave, you can start from scratch (which after a few goes, I actually found was easiest!).

The hardest parts of GTK theming are the widget matching, understanding how the widgets are arranged in a hierarchy and understanding how their styles get inherited. I can't say I'm an expert, but that's where step 1 comes in! The best way to learn is a combination of looking at other people's themes and reading the GTK documentation. The latter is particularly useful because the widget hierarchy pages have listings of what style-properties you can specify in your styles.

I hope this gives some of you out there the courage to go ahead and try it...As with all things open-source, the more of us out there doing it, the easier it makes it for all of us!

Memory usage with imlib2 for Lua

I recently started working with imlib2 bindings for Lua as part of the work I'm doing with learning the whole Cairo thing...Please see my latest post over on the Conky Blog.

However, I ran into an interesting problem when I was writing that script, not having written anything with imlib2 bindings before! As I was testing my photo album script, I found that I had a memory leak...The longer I left my script to run, the more and more my memory usage would ramp up until it topped out and I found I couldn't display any more photos. Eep! Not really what you want from a photo album.

So I thought I'd share with you a little bit about how imlib2 draws pictures, as opposed to the way Cairo does it, because having had a bit of experience with Cairo actually led me to think about image drawing in a way that made it difficult to work with imlib2, because the two are so different.

First of all, why use imlib2 at all when you can, to some extent, use Cairo to draw pictures? Well, the reason I turned my hand to it was because I wanted to be able to render .jpg images in my Conky, and the Cairo bindings we use can only interpret .png at the moment, through cairo_image_surface_create_from_png(...). By contrast, if you load an image using imlib2, it auto-detects the type and scans its own internal libraries to find a suitable decoder. So imlib2 has a much broader range of image type support, with no fiddling.

If you want to manipulate existing images in imlib2, first you need to load the image into memory with imlib_load_image(...). Eventually, if you want to then draw that image onto the Conky window, you'll use the imlib_render_image_on_drawable(...) function. However, if you want to manipulate that image first, you will need to do all your manipulation on a "buffer" image before you render it onto the surface.

Now, I'm not very good (yet!) at working with transformations in Cairo, so I'm used to thinking of things like a plotter...Move to (a, b), draw a line to (x, y) and stroke. So when I want to draw an image to a window, what I really want to do is load an image, select the rectangle to draw it into, and then "fill" it in...But that's not really the way to do it with imlib2. My example will be my photo album script...Essentially, I wanted to load an image and draw it onto the Conky window at a set (smaller) size. However, I found that if I just load the image and then draw the image at a smaller size using the following:

imlib_blend_image_onto_image(image, 0, 0, 0, w_img, h_img, 0, 0, width, height)
imlib_render_image_on_drawable(xc - width/2, yc - height/2)

I wound up with a horrific memory leak...Basically, I was loading the images into memory and LEAVING THEM THERE. AT FULL SIZE. Ouch.

(For those of you who are wondering, the lines above shrink the image from w_img x h_img down to a specified width x height, then draw it on the Conky window at the coordinates in the second line...)

What you need to do to avoid the memory leak is to very carefully manage your memory usage by freeing your images after you're done with them. The good way, then, to draw my reduced images onto the Conky window is to use the following method:

image = imlib_load_image(album_dir .. filename)
if image == nil then return end
imlib_context_set_image(image)

w_img, h_img = imlib_image_get_width(), imlib_image_get_height()
buffer = imlib_create_image(width, height)
imlib_context_set_image(buffer)

imlib_blend_image_onto_image(image, 0, 0, 0, w_img, h_img, 0, 0, width, height)
imlib_context_set_image(image)
imlib_free_image()

imlib_context_set_image(buffer)
imlib_render_image_on_drawable(xc - width/2, yc - height/2)
imlib_free_image()

This code does the following:

1. loads the given image into memory, in a variable called "image"
2. checks to see if the image has loaded successfully; if not, breaks out of the function
3. sets the imlib2 context to be "image"
4. grabs the dimensions of the loaded image
5. creates a "buffer" image
6. sets the context to be "buffer", so we can blend onto it
7. draws a scaled-down version of the image onto "buffer"
8. sets the context back to "image", so we can release it
9. releases the original loaded image, so we are then just left with the scaled down version, still held in memory
10. sets the context back to "buffer", so we can draw what's on it onto the drawable window
11. draws whatever's in "buffer" onto the Conky window
12. releases the buffer image

You can start to see from this how you can also use the buffer image (or a series of them!) to do some fairly sophisticated image & text manipulation before rendering onto the drawable window.

For more information on the functions available to you in imlib2, check out their documentation.

In the meantime, here, have a screenie :)

From Screenshots

You can also grab the script that made it, from the Conky Blog, or my DevArt account.

A cheap little battery widget :)

I liked my last battery widget, but it was a bit resource-hungry, what with all the images and that...So in a previous Conky config, I came up with a quick and easy way to get a battery-widget-like-thing, by using two battery bars, one of which was for a battery that doesn't exist (so it always shows empty).

I used:

${battery_bar 40,165 BAT1}${voffset 10}${battery_bar 20,10 BAT2}

to get this:

From My Little Desktop Photos

Who needs screenlets when you can have Conky?!

I've just finished working on my latest Conky!

From Screenshots

There are two main features...
1) Use a combination of Conky and Compiz to get nifty transparency effects

I have my windows set to 95% transparency in Compiz, which never applied to Conky until recently when I started using the "own_window yes" option (see a couple posts previous). Then it occurred to me that I could use it to create a nifty effect! Here's I did to get the top text transparent whilst keeping the bottom text opaque:

+ Run two Conkys. You might not notice, but the top and bottom of this screenie are actually running two different Conkys simultaneously.
+ Specify the class of the Conky that will be semi-transparent, by using something like "own_window_class Conky-semi" (I used Conky-50 because I'd intended to use 50%, but 75% looks better!).
+ In Compiz Config Settings Manager, go to Opacity, Brightness & Saturation and add a new window type, "class=Conky-semi" and set the transparency to something like 75%:

From My Little Desktop Photos

+ Et voila!

2) Create a battery widget

There are a number of great sets of images you can download as icons for various dock programs; you can use one of these suites, combined with Conky's ${image} function and a big nested ${if_match ${battery_percent}} statement to create a battery widget, like so:

${if_match ${battery_percent BAT1} <= 14}${image /home/alison/Pictures/Batteries/battery_1.png -s 75x100 -p 0,20}${else}${if_match ${battery_percent BAT1} <= 27}${image /home/alison/Pictures/Batteries/battery_2.png -s 75x100 -p 0,20}${else}${if_match ${battery_percent BAT1} <= 41}${image /home/alison/Pictures/Batteries/battery_3.png -s 75x100 -p 0,20}${else}${if_match ${battery_percent BAT1} <= 54}${image /home/alison/Pictures/Batteries/battery_4.png -s 75x100 -p 0,20}${else}${if_match ${battery_percent BAT1} <= 68}${image /home/alison/Pictures/Batteries/battery_5.png -s 75x100 -p 0,20}${else}${if_match ${battery_percent BAT1} <= 82}${image /home/alison/Pictures/Batteries/battery_6.png -s 75x100 -p 0,20}${else}${if_match ${battery_percent BAT1} < 95}${image /home/alison/Pictures/Batteries/battery_7.png -s 75x100 -p 0,20}${else}${image /home/alison/Pictures/Batteries/battery_full.png -s 75x100 -p 0,20}${endif}${endif}${endif}${endif}${endif}${endif}${endif}

Not too pretty, I'll grant you, but it does the trick! Just make sure you've got all the ${endif}s you need :)

And yes, before you ask, I will package this one, and the battery widget separately, once I have permission from the artist to do so. The battery widget icons are by *MrStylo; please click on his DeviantArt account for more info.
-----
One final little nugget: a really nifty, pretty lightweight way to get a nice semi-transparent background for your Conky is to make a small semi-transparent square (I used a 50x50px square I made in GIMP), and stretch it to the size you need using the -s option in the ${image} variable.

Happy Conkying!