July 8th, 2007 @ 22:50

We are now reaching the half of this Summer of Code, and it is about time to review what has been done so far.

Read the rest of this entry »

July 4th, 2007 @ 20:29

One of the things that are particularly boring when working on a Compiz plugin is that you have to reload it all the time, and there is no quick way to do it (I usually unload/reload it through ccsm, which involves some mouse deplacement and needs a ccsm window, or or I just reload compiz, which takes quite a bit of time).

Consequently I thought I could write a little script that would reload one or more plugins for me quickly. It took less than 5 minutes with the neat libcompizconfig python bindings, and works pretty well as far as I can see. (so yes, it depends on libcompizconfig, but heh, that’s worth it)

Here is the code :

#!/usr/bin/env python
'''Compiz plugin reloader (through compizconfig)
Copyright (c) 2007 Guillaume Seguin <guillaume@segu.in>
Licensed under GNU GPLv2'''
import compizconfig
from sys import argv, exit
from time import sleep
if __name__ == "__main__":
    if len (argv) < 2:
        print "Usage : %s plugin1 [plugin2 ... pluginN]" % argv[0]
        exit (2)
    plugins = argv[1:]
    context = compizconfig.Context (basic_metadata = True)
    print "Unloading " + " ".join (plugins)
    for plugin in plugins:
        if plugin not in context.Plugins:
            print "Warning : %s plugin not found" % plugin
            plugins.remove (plugin)
        context.Plugins[plugin].Enabled = False
    if len (plugins) == 0:
        print "Error : no plugin found"
        exit (1)
    context.Write ()
    print "Waiting for settings update"
    sleep (2)
    print "Loading " + " ".join (plugins)
    for plugin in plugins:
        context.Plugins[plugin].Enabled = True
    context.Write ()
July 2nd, 2007 @ 02:30

Here is a quick preview of the filter generator UI that will allow users to create their own color filters :

Filter generator preview

That’s just a preview of the UI though, mainly because I need to write a fragment program that can handle HSV color representation (HSV => RGB and RGB => HSV translations).
Comments welcome, especially since I really suck when it comes to usable & humane user interface design :p

July 2nd, 2007 @ 01:36

After yesterday’s rant, I wrote my very own Hue Picker in pyGTK. It is meant to be very simple and straight forward : it just exposes a “changed” signal and two useful functions (get_hue / set_hue).

The usual preview :
Hue Picker Preview
(the “Source hue : [23 ^]” is just a placeholder and isn’t part of the widget)

Full source included below.
The ring drawing code is a mostly direct python port of C GtkHSV’s one.

Read the rest of this entry »

July 1st, 2007 @ 15:11

pyGTK seriously lacks a good and simple color picker!
The current color picking widget, gtk.ColorSelection, is just way too huge and complicated : it provides several numeric entries for finer selection of HSV or RGB values, or can feature a customizable palette, but I don’t need all that (indeed I just need a Hue picker)
The worst thing is that it looks like there’s already a much simpler widget, which is available in C gtk+ (namely GtkHSV) and that it even has some form of bindings in pyGTK (type (gtk.ColorSelection ().get_children ()[0].get_children ()[0].get_children ()[0]) returns <class ‘__main__.gtk.HSV’>) but it doesn’t expose any of the interesting functions (such as get_color)
Anyway, I guess it’s about time to write another custom widget.

June 20th, 2007 @ 01:20

Hurray! School is (pretty much) done for this year, and my some of my long delayed work-in-progress projects are getting to an usable point. Summer of Code is now – at last – my main and only focus for the rest of the summer :)

I have just packed all my previous thoughts and finally decided on how to do it all.

  1. Use HSV (Hue, Saturation, Value) color representation – it is just the most appropriate color space for that kind of stuff, especially since it’s the representation used by most color pickers (a color ring to choose hue and a triangle to choose saturation and value).
  2. Write a generic fragment program loading plugin for Compiz. This generic plugin will have to parse fragment program source to plug it into Compiz’s fragment interface (which makes programs combinations (for example blur + negative + blur) possible). I’m probably going to make sure that other plugins would be able to easily reuse the loader (it would have been pretty easy with the basic library functions in Beryl, I will have to check what can be done at the moment in Compiz, using the newly introduced cube/rotate sharing bits might just be the solution, but I haven’t had the time to actually read it).
  3. Extend the generic plugin to match the required features (mainly cumulative filters and filter quick switch).

I will hopefully have a “working” generic plugin by the end of the week. The parser shouldn’t be a huge deal (5 or 6 hours in the worst case), and wrapping the generated code in a Compiz plugin shouldn’t take more than 2 hours. Sounds doable :))

On a side note, gShaderEdit now also supports vertex programs (the detection of the program type is done on the fly according to the header of the program, which should either be !!ARBvp1.0 or !!ARBfp1.0 as standardized by the ARB)

June 18th, 2007 @ 22:03

As part of my courses, I had to learn camllight programming this year. Sadly, all my school’s computers are powered by Windows, a non free closed source operating system, and the default frontend is the less usable thing around : copy pasting is completely broken, dumb default configuration, oldish user interface, no syntax highligting… The worst thing is that the sources aren’t published, I was just able to get those of the Objective Camlui frontend (which is quite the same, but in a much better fashion).

I know that there are already several other ways to have better “frontends”, such as cmdcaml, or using XEmacs with the tuareg mode, but heh, I was willing to provide something all-in-one that looks good. And I needed a good excuse to learn Python and PyGTK.

After a huge rewrite, exploding the original 1500 lines long source, here is a publishable version, embedding the camllight interpreter and using gtksourceview2 for syntax highlighting.

The usual preview :
CamlUI preview (thumbnail)

Feisty debs are published at http://guillaume.segu.in/code/debs/camlui/, with a helper script which fetches the 4 required debs (camlui + gtksourceview2(-common) + python-gtksourceview2) and installs them.
Source is versionned in a git repo at http://guillaume.segu.in/code/camlui.git/

Feedback welcome :)

June 16th, 2007 @ 22:04

As part of a still unpublished (or unadvertised, whatever) project, I was looking for how to do a simple window on top of the screen that would not steal focus but would still be able to receive keyboard events. Furthermore I was also looking for how to easily make this window partly transparent. It’s just all simple code-wise, but when you have no clue on how to do it, it’s not that easy.

I learnt that popup windows aren’t stealing focus, that I could grab the keyboard only (but that I can not grab it while a key is pressed because there is already another active grab then), and that using Composite extension was just about setting the right colormap and using Cairo to draw on the window surface by hooking in the expose events.

Sadly I also learnt that it wasn’t currently possible to draw transparent widgets since they own their region so that what’s under it (in the same window) can not be used for compositing (which results into an awful dark background behind the widget). The only workaround I found was drawing the widget on its own Cairo surface and draw that surface at the right place after painting the window background.

drawing sample - thumbnail

I have included the full sample code featuring all this but the workaround for transparent widgets.

Read the rest of this entry »

June 16th, 2007 @ 01:56

I’ve just spent half of my evening packaging gtksourceview2 and it’s python bindings for Feisty.
gtksourceview2 is full of good promises with a much better and smarter highlighting engine. The gnomeprint dependancy has been dropped which basically means that it will be possible to use it on windows without too much harm (compiling gtksourceview1 on windows was a real hassle). You can read more about it at Tainted Words.

Preview :
gtksourceview2 in action

After fighting a bit with the 1.90 release, I eventually packaged current svn, since the 1.90 python module wouldn’t import.
Both packages and sources can be found at http://guillaume.segu.in/code/debs/.

Once installed, checkout the python test file and run it :)

June 15th, 2007 @ 22:10

I’ve been a huge fan of the Screenshot with Style GIMP script for a while. The result always looks cool and pretty. Nevertheless, opening the gimp, resizing the picture, finding the script through menus and applying it takes a while (at least a minute or two).
Consequently, I had a bit of fun with Cairo today, and wrote a simple but nice python script that does almost the same in a single command :)
It’s not as pretty as with the GIMP, but it’s good enough for now (I could probably improve it, but I’m a bit lazy)

Quick example (using the screenshot from the previous article) :
screenshot-beautifier sample

If you fancy trying it, just grab the code from git :)
$ git clone http://guillaume.segu.in/code/screenshot-beautifier.git/
$ cd screenshot-beautifier
$ python beautifier.py [source file] [result file]

Have fun :)