X11 Cursor Themes

On Arch wiki is a really nice tutorial how to setup custom X11 cursor theme. The good thing is how solution is pretty desktop/wm neutral, so it works under EDE as charm.

I found Chameleon theme very nice; you also get three different sizes: large, medium and small. Neat!

Following above wiki tutorial, I would add how using "~/.icons/default/index.theme" is probably the best solution. You don't have to mess with "~/.Xdefaults", nor need to have permissions to play with "/usr/share/icons" folder.

After you populate "~/.icons/default/index.theme", X11 will instantly load selected cursor theme. The only thing I found are often crashes, originating from libXcursor library. This could be either from graphic driver (nVidia of course) or from older X-es I'm currently running (time to upgrade it).

Charting library

Sometimes you need to draw charts on more pragmatically way than is usually done. Unfortuately, most of the things out there pretty sucks or are in the good way to do so.

For some time I used PyChart, but due it's complexity and really odd api, I dumped it and get back to OpenOffice. Yes, I went back to stone age, from nice comfort of favorite editor to clicking on eat-all-available-memory OpenOffice.

From time to time, I stumble upon some library, but nothing I would be satisfied with. Until I found guile-charting.

Honestly, Guile is not my favorite package and I install it mostly to play with differences on Scheme implementations, but from no on, guile-charting will be probably the main reason why I will keep Guile package installed.

Here is the sample code (also on pastebin):

(use-modules (charting))

(make-bar-chart "Monthly status for Foo project"
'(("January"
   (232 "Download")
   (20 "Upload"))
 ("February"
   (80 "Download")
   (320 "Upload"))
 ("March"
   (130 "Download")
   (150 "Upload"))
 )

 #:write-to-png "usage.png"
 #:chart-height 200
)

and will produce this:


You will also need guile-cairo for guile-charting.

Communicating with desktop #2

I imported ede-scriptbus on the repo (it is in branches), adding few new stuff: setting XSETTINGS values and explicit XSETTINGS serialization, which was done implicitly when evoke quits. For example, to change current background color of EDE apps, this will be used:

./ede-scriptbus
> (set-xsettings "Fltk/Background" '(R G B A))

where, as you guessed correctly, you are using separated color components. The good thing about (set-xsettings) is how it will figure out parameter type and send correct message to evoke.

Due the nature of XSETTINGS protocol, changes will be instantly applied.

Too bad Gtk+ (as it implements XSETTINGS) does not implement some keys for changing foreground and background colors, so we could apply color changes on Gtk+ apps too.

Communicating with desktop

One of the major things I like and admire in KDE is DCOP. With DCOP, you can query, change or list desktop parts with a simple command and a few parameters. Or shortly, you can "inspect" your environment.

I'm not proficient with DCOP, nor had a chance to use it more than experimenting with the given examples, but knowing you can control your environment in the few commands is really powerful concept. Or maybe, controlling it via some language, like Apple did with AppleScript, if we are going to be more serious.

Last few days, I was playing with similar concept in EDE. Of course, for the start, it gives some rudimentary options and we will see how it will expand itself in the future.

I named it "ede-scriptbus"; the name left from my previous attempt to write some simple scripting suport for D-Bus things and, as expected, I ended up with different thing :)

ede-scriptbus comes with embedded Scheme language, via TinyScheme. Now, I hear someone is screaming Lua name, but I already had some code written with TinyScheme, plus I can easily hack interpreter if I need to adjust it. Remember, ede-scriptbus is still in prototype phase.

Now, what can be done with it? For now, it is capable to query application specific settings and XSETTINGS registry (yesterday evoke got changed to export XSETTINGS values via D-Bus). Here is sample image:


Basically, you query desired items, much like you do query on some database. I had to make distinction between XSETTINGS and application settings queries because keys have different format, but this can be easilly wrapped, providing unique query interface.

Adding ability to change existing values or set new key/value pairs should not be hard either and this is next in my TODO list. But, there is one issue I'm still contemplating: documentation of configuration values. Huh boy, this sounds scary :)

One of the greates irony of configuration files (meaning about those INI style files desktops are using extensively) is how they are readable and can be easily changed. Yes, you can easily view the content, but how much stuff you can understaind from it?

Here is excerpt of ede-desktop config file:

[Desktop]
color=0
wallpaper_use=1
wallpaper_mode=0
wallpaper=/home/sanelz/walls/diablo3.jpg

You already understaind how "wallpaper" key has full path to background image, but what "color" stands for? Background color? Yes, but what values it can have, or what values should be in "wallpaper_mode" when you want to stretch background image?

This problem is not only EDE related; look my qtrc (Qt configuration file) for example:

[General]
GUIEffects=none
XIMInputStyle=On The Spot
cursorFlashTime=1000
doubleClickInterval=400

The same problem here. GConf has ability to document these things, but GConf is story for itself.

Actually, the idea is that the person who changes the key/values via ede-scriptbus, can query their description too, like:

> (doc "Net/IconThemeName")
"(type string)"
"The name for currently used icon theme. Changing the name to different
icon theme will immediately be applied on all EDE and Gtk+ applications."

Would be neat, but, is it possible to do it?

First things first, I need to complete this tool and we will see the next steps :)