I took one of the font definitions from a running wmCalClock and put it in
the 'background' pixelmask. this works quite good. the name of the
parameter is rather confusing, it's not a background actually but a
collection of templates... but that's an other problem.
removed the definition of defaultRGBFiles from the examples: it is now
hosted in the library.
removed function parseColors from examples. this is done during initPixmap.
added wmdocklib.defaultRGBFileList
removed wmdocklib.setColor (superseded by wmdocklib.initPixmap)
extended wmdocklib.initPixmap:
basic 16 colour palette [basic_colours] from rgb.txt (not hard coded)
alter_palette to (re)define an indexed colour in the xpm.
bg/fg can be a single character or a number [0..15]
' ' as transparent colour.
some debugging 'if 0:' code.
extended wmdocklib.getColorCode:
it reads either the given rgb file or the first accessible file from
defaultRGBFileList
corrected url in setup.py: it used to point to ibo!
this is an important modification. I hope it won't break too many programs
based on this library, or at least not in such a way that will make you
upset with me and my work...
well: the library offers now three charsets and a 16 colours palette.
but: you must use them.
there is no support yet for named colours.
the only working examples are pywmdatetime and pywmhdmon.
just preparing for a bigger change...
introduced a global font (just one), it is lower case per default.
I intend to modify the function for registering the default xpm to something
accepting the 64x64 bitmap (application dependent) and insert it into the
global pixmap. an other function could be used to register the alfabet
pixmap and correspondently setting the variables indicating the position of
each character. we would only support monospace alfabets.
the 'printing' functions would also be simpler (less arguments), since it
would be the library knowing which is the alfabet in use.
fixed the original error "ValueError: too many values to unpack" (was due to
/proc/stat).
then the application had problems interpreting /proc/meminfo: "Can't find
memory information in /proc/meminfo."
I hope, but I'm not 100% sure, that the repairs didn't break the application on kernel 2.4.
