Archive for the ‘Ubuntu’ Category

April 11th, 2008 @ 18:07

Have you ever mistakenly shut down or rebooted your operation-critical server while you were willing to halt your desktop computer through ssh before going to bed, or anything like this? If so, and if you are on Debian/Ubuntu, molly-guard is designed for you: this nifty bash script gets between you and the shutdown/reboot/halt tools, checking if you are connecting through ssh and if so asking for the hostname of the machine before proceeding.

Wondering how it looks? Here is the output of a little test:

ixce@timmy:~$ sudo shutdown -r
W: molly-guard: SSH session detected!
Please type in hostname of the machine to shutdown: 
Good thing I asked; I won't shutdown timmy ...

Since it doesn’t correctly handle sudo yet (actually sudo is at fault here, since it drops SSH_CONNECTION environment variable when doing its stuff), you might want to add PRETEND_SSH around the beginning of /usr/sbin/shutdown as specified on Nico “nion” Golde’s blog.

You might also want to grab the molly-guard 0.3.2 etch package I backported from sid (all I changed is downgrade debhelper build-dep version and debhelper compatibility level in debian/compat since etch only has debhelper 5 and the sid package required debhelper 6 ; this shouldn’t break anything since the newer debhelper just seems to be needed to recognize a few fields in debian/control about where the package is maintained). Sources are also available, anyway.

Thanks hr for the tip :)

August 1st, 2007 @ 13:10

Worse and worse… 12 days and no news. I hate holidays, heh. Nevertheless, I have written more than 2500 lines during these 12 days. Let’s have a quick overview over all this code ;)

What’s new?
Two Compiz plugins!
The first one is something that I missed from Beryl, bottom cube caps. The new “cubecaps” plugin supports top and bottom caps, correctly blends caps color with the images (e.g. if you select a black cap color, the result won’t be completely black whatever the image is as with the previous “cube” plugin caps, but will be your image on a black background), and supports caps when there are more than 4 viewports (actually one could also enable them for 3 viewports by changing a single integer in the source file (currently at line 288 of cubecaps.c at commit 6d463e3), but it might look wrong if image is too big). Finally, clamping is done using clamp_to_border extension if available, which avoids weird lines when using non scaled images with alpha.

I’ll add some screenshots when I’ll be able to upload them… I am currently using my cellphone to post this, sadly.

The second one is a lot more specific : it displays some visual feedback of what you are doing with your mouse and your keyboards. More specifically, when you hit one of your mouse buttons it displays (when enabled) a little mouse in the bottom right of the screen with the button you hit highlighted, until you release it. Likewise, when you press a modifier key (Alt, Shift…) it displays a nice rounded rectangle in which the name of the modifier is written in the bottom left corner of the screen. It’s pretty hard to describe how it actually looks with words, but I hope you get it anyway. The main use case if for showing used key bindings when demonstrating/teaching the usage of an application.

Again, screenshots will come ;)

I began working on a third plugin that would handle metacity -> Compiz -> metacity switch and move windows from the workspace they were on to the corresponding viewport upon startup and do the opposite upon shutdown, but there’s another core problem that blocks it (plugins are initialized after screen and windows were initialized, during which windows are all moved to current workspace).

I also happened to need a quick way to test some Cairo drawing before using it for the final application (which could, for instance, require compiling before testing, which is kinda annoying when you are trying to find right values for a simple drawing). I wrote a “cairoDrawingArea” PyGTK widget which handles the drawing of a Cairo surface (plus a patterned background and/or borders). One just has to write a child of this function and write the draw () method to do the actual Cairo drawing. I included the whole thing at the end of this post. I know I could/should have just used the write_to_png function on the Cairo surface, but dealing with nautilus/eog is just so unhumane and slow, while I needed (again) a fast way to view the result of my changes.

Most of the code for this script comes from a quick PyGTK Tic Tac Toe game I wrote to show a friend how one could write a fully working “software” in less than 2 hours. By the way, I am wondering if it would be possible to write an AI that would have no clue on the rules of a simple game such as Tic Tac Toe, and learn them round after round.


Last but not least, I fixed some bugs and mem leaks in my colorfilter plugin and cleaned the code a lot. There is now only one remaining thing to do for this plugin before it gets considered as done : fragment program parameters. Shouldn’t be too hard, but I am not sure of the way to cumulate filters using parameters (maybe it is just impossible).

What’s wrong?
I definitely can’t fix Filters Manager problems :/ I tried writing the base rgb -> hsv -> rgb fragment program using Cg, but it resulted in a 120 lines long fragment program, while poor Intel 900 GMA chipsets only support 96. Pretty sad, heh. The other problems (randomly borked cumulative filters preview and a strange OpenGL Invalid Operation error on first action on one of the previews when they are both displayed) are still there as well, but I think I could probably workaround them by having just one OpenGL drawing area which would process a queue of drawing operations

What’s next?
I’m quite unsure… I’d like to finish my Summer of Code, but it’s sadly held by the Filters Manager problems and by some bugs in Compiz Core that won’t be fixed before next release (which should hopefully happen pretty soon… I guess I’ll have to wear back my release roller hat for Fusion). I have done a lot of Compiz coding (some patches which I discussed with David and finally got a wider solution, fixing numerous other problems, some other patches that might make it after next release, and the two plugins), and I currently don’t have much ideas on what I could do (even though I would be very happy to find a good reason to learn more about OpenGL ;)). I have some mathematics related things planned as well (involving convex hulls, hypercubes and such), and some web coding which is becoming really high priority. Getting CamlUI ready for Windows and fixing the handling of toplevels must also be done (I would like to write a similar gedit plugin, if I can find some time to do so). And I do need to finish cairo-swissknife. So much things to do and so little time :p

Off topic.
I am looking for a real touch screen bigger than 10″. I would really really like to try to code some touch screen specific apps, but all I found was either fake touchscreens or unavailable laptops (which would actually be better than a simple touchscreen, I don’t really care about money as long as it’s less than 2000€). Hints welcome :)


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 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

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

June 13th, 2007 @ 01:29

Meh, I’ve been way too busy these days with school. Happily I should be mostly done with this year in a bit more than 40 hours among which 7 hours of examinations.

Anyway, I was able to pack together a simple but nice shader editor. It currently only supports fragment programs, but it works well. It’s built around pygtkglext and python-opengl, and makes use of ctypes to bind all the fragment programs related functions. Supporting vertex programs shouldn’t be too hard, actually most of what’s needed for it is already in place, it just needs some GUIfication.
All the required dependencies are in Gutsy’s Universe (pygtkglext wasn’t in Feisty’s).

Here’s a screenshot (click on the thumbnail to view the full resolution picture) :
gShaderEdit Preview

Fresh-from-git source can be found at :
$ git clone
$ cd gshaderedit
$ python

Should you find any bug, please report it to me by mail (you can find my address in the AUTHORS file).

May 30th, 2007 @ 19:46

As part of Summer of Code 2007, I’m going to work on color filtering through Compiz/Beryl.
The final goal of this project is to provide a flexible and efficient way to filter colors, switch through different filtering schemes or easily create custom filters.

June 18 : fragment program shaders test application to check the effect of a filter on an area of the screen or a picture (there’s currently no such software, only QShaderEdit which doesn’t support shaders on textures).
June 20 : filters (both test filters to see what color blind or vision impaired people actually see and corrective filters)
June 30 : working plugin using pre-defined filters
July 2 : easy switching through a customizable list of filters
July 10 : cumulative filters support
July 31 : configurator enabling user to preview the effects of a filter or a set of filters (using as much parts of the program used for testing filters) as well as making his own
August : debug, improvements, random ideas implementation, testing

Please note that this roadmap is just a kind of draft, especially since I might be still quite busy with school until June 17th (*sigh*, there are three written tests remaining, one per Saturday).