[RFC] Qi Bootmenu

[Carsten Haitzler (The Rasterman)]

On Fri, 9 Oct 2009 17:14:30 +0200 Marc Andre Tanner <openmoko at brain-dump.org>
said:

> On Sat, Oct 10, 2009 at 12:14:02AM +1100, Carsten Haitzler wrote:
> > On Fri, 9 Oct 2009 13:00:12 +0200 Marc Andre Tanner
> > <openmoko at brain-dump.org> said:
> > > On Fri, Oct 09, 2009 at 02:35:14PM +1100, Carsten Haitzler wrote:
> > > > On Thu, 8 Oct 2009 22:50:00 +0200 Marc Andre Tanner
> > > > >  - GUI based on elementary with framebuffer support?
> > > > > 
> > > > >    In theory this would be the best solution because we would
> > > > >    use the same technology as in a normal system just with a 
> > > > >    different backend.  This should ensure that it's actually
> > > > >    finger friendly. Although text entry remains a problem 
> > > > >    because the illume keyboard can't be used. But I hope that
> > > > >    text entry won't be necessary anyway (no kernel command line
> > > > >    changes through the GUI, sorry ;) In practice I don't know 
> > > > >    how mature the framebuffer backend actually is and it has 
> > > > >    quite a few dependcies[2]:
> > > > > 
> > > > >     * eina
> > > > >     * eet
> > > > >           o zlib
> > > > >           o libjpeg
> > > > >     * evas
> > > > >           o freetype
> > > > 
> > > > i think you missed fontconfig - though it is optional, all the default
> > > > themes for elementary etc. assume fontconfig support for font naming.
> > > 
> > > Ok now I am confused. Evas actually has support for reading fonts.
> > > {dir,alias} files and doesn't require fontconfig for this. Doesn't this
> > > work the way I think it does? 
> > 
> > oh wait. sorry. fonts.dir and fonts.alias are built-in. they are old x-stile
> > font naming schemes. its a simple parser. fontconfig provides things like
> > Sans etc. normally. i've actually totally forgotten about that code. it's
> > ancient. interesting that it still works! :)
> 
> Ok, I have to admit my knowledge about fonts is basically inexistent.
> 
> Does this mean the fonts.{dir,alias} files are useless because the mapping for
> special styles like bold/italic doesn't work? And I need fontconfig for these?
> I probably don't need special styles anyway and I certainly don't find the
> idea of storing font configuration in XML that appealing...

they only work in a very basic way - pretty much to create x-ish mappings to
font files but primarily aliases. you wont be able to use them to do
Sans:style=Bold. that is fontconfig. fontconfig is the xml beastie.

> > > > >     * ecore
> > > > >           o ecore-file
> > > > >           o ecore-evas
> > > > >           o ecore-input
> > > > >           o ecore-job
> > > > >           o ecore-txt
> > > > >           o libiconv (functionality can be provided by uClibc)
> > > > >           o tslib
> > > > >     * edje
> > > > >           o embryo
> > > > >           o lua
> > > > >     * libpng
> > > > 
> > > > nb. u can drop libpng. if all your image data is inside edje files (or
> > > > u can put it inot .eet files too) then you won't need this.
> > > 
> > > I added libpng because I saw that the default elementary themes uses png
> > > files and I thought it needs some way to read them, thus libpng.
> > 
> > the theme does. but its compiled into a .edj file. once there it is no
> > longer png :) no need for png.. unless u - un your app, specify png files
> > for things :)
> >
> 
> Thanks for the clarification I'm starting to understand how this all works. 
> 
> So if I want to load an external logo from the SD card I would need a image
> library. Since libjpeg is already a dependency of eet I could just require
> that the system images provide an jpeg logo and libpng can go away.

cxorrect. tho that means logos cant have transparency. they are solid blocks of
pixels. not sure everyone will want this. you could allow logos as .edj files
which would big the biggest flexibility for you, as this can be a single image
or a combination of image and text, animation and more. this does raise the bar
for the images to have to generate .edj files. but if you are happy with this,
this gives you the easies work for oyu and the greatest power/flexibility.

> Just out of interest: how is the image stored in the .edj file? Since eet 
> depends on libjpeg is it reencoded as jpeg? 

depends. LOSSY compression uses jpeg. it ALSO allows for an alpha channel,
unlike jpeg itself. it basically stores alpha as an extra greyscale jpeg as
well. for COMP compression the pixels are just passed through zlib (basically
gzip) for lossless compression. this works quite wel for artifcially drawn
icons that have solid colours, outlines or gradients. eet itself takes care of
all of this for you - it just takes RGBA pixles on encode and presents them
back to you on decode

> > > > >    I have cross compiled all this and without any special optimisation
> > > > >    (I just disabled everything in ./configure which seemed not
> > > > > critical) the whole system is about 6-7MB large this is without the
> > > > > kernel.
> > > > 
> > > > indeed.
> > > 
> > > As a said this is without any optimization, no special compilation flags, 
> > > nothing. I should try to link everything statically which has 2 main
> > > advantages:
> > 
> > you will save very little with things like -Os. maybe 5-10%. on a good day.
> > that ballpark.
> 
> Newer gcc's support whole build optimization that is you basically compile an
> entire project with one gcc inovacation. It will use lots of memory at compile
> time but because it has more knowledge about the whole project and how the 
> different parts work together it can use more advanced optimization techniques
> which should result in smaller/more efficient code. Anyway this is the theory
> I will see how this works in practice. There are enough other things to
> improve before I even want to start with this kind of thing. 

thats possible when making 1 executable. it's not possible to strip shared
libraries of code "not used by apps" as these are completely separate builds,
elements and more. example - evas will hve code for handling 8bit color
displays. nothing will ever make gcc get rid of it ... unless you statially
compile. even then it wont as evas runtime will chose conversion code based on
screen configuration... which gcc doesnt know. this is why evas has so many
--enable and --disable options for configure - uc an disable vast blobs of
support for things you dont need - like 8 bit and 24/32, 15bit, 12bit and 18bit
displays. look at configure --help for evas.

> > >  - the linker should be able to remove any code paths which aren't
> > > actually used.
> > 
> > not from share libraries. only if you statically compile with executables.
> 
> That's what I meant. I would statically compile my bootmenu app and just copy
> that over to the rootfs.

then you wont need libevas etc. - it'd end up being a single binary.

> > >  - at runtime the dynamic linker doesn't have to load all the libraries 
> > >    (less I/O + code relocation) which should speed up the application
> > > start. 
> > > 
> > > > >    I am not familiar with the EFL code base but what I have seen
> > > > >    so far seems like it isn't really optimized for size. So there
> > > > > could be some potential although it would require some work and
> > > > > upstream approval.
> > > > > 
> > > > >    Maybe the idea to use elementary is overkill but what are the 
> > > > >    alternatives? 
> > > > 
> > > > i'll shime in here. yes. efl has grown over the years, and well - the
> > > > more functionality you want, the more space it will take. if you are
> > > > hell-bent on smallest size you possibly would just write your own fb
> > > > gui that is very simple and ugly (with white/black boxes for example). 
> > > 
> > > I know that elf provides a lot of features and is rather small for what it
> > > does (don't get me started on gtk or qt). But what suprised me for example
> > > was that although I had compiled elementary with just the framebuffer
> > > backend it nevertheless tried to use the X backend unless it was told to
> > > not do so (with ELM_ENGINE=fb). So there apparently is code there which
> > > strictly speaking doesn't has to be there.
> > 
> > x11 engine is the default. thats just how the code is. :) if its not
> > coimpiled in you just get stubs trying to use the engine and returning 0
> > saying they cant (ie nothing compiled in) you wont save more than a dozen
> > or 2 bytes by trying to remove these stubs entirely. its not worth it.
> 
> Ok that's probably true, I was just arguing from the busybox mindset where a
> few bytes are actually a worthwhile saving ;)

i am happy to spend bytes when it makes life simpler and easier in the bigger
picture. :)

> > > Another thing is the lua/embryo thing. If I am not mistaken they
> > > basically do the same thing so it should be possible to only use one of
> > > the two. Lua was added recently and should become the default, right? So
> > > embryo will go away in the long run, correct? But I guess it will be
> > > needed for backwards compatibility anyway so in my opinion it should be
> > > possible to disable lua at compile time.
> > 
> > there .. no. embryo is there because it is a default feature of edje. lua
> > is as of recently also a default feature. it is required because all edje
> > files are equally capable. i do not want an edje that "might not work with
> > some edje files". it's not going to happen because as policy i want all
> > edje files and themes to work the same everywhere. not fail or work
> > stangely because someone happend to build without the support somewhere.
> > thus you will need both. note. embryo is TINY. its runtime library is on
> > the order of about 40kb. thats the footprint. the bits in edje that hook to
> > it might be another 10kb of code at worst. lua is much bigger - but we are
> > now using it because it saves us work and adds more power. it's not fully
> > up and ready yet, but it will be. so you're getting both embryo and lua.
> > one way or another.
> > 
> > (not embryo script is compiled to bytecode and put into the .edj files. its
> > is VERY fast to execute. about 2x faster than java. it wil be many times
> > faster than lua to execute the same logic, so as long as you want just
> > simple logic - use embryo script. if u want to get more complex and
> > imaginative.. then u want lua - so there is a very good reason to keep
> > both. efficiency)
> 
> Again thanks for the clarification. I understand your point of view regarding
> ejde files which should work everywhere to a certain degree. On the other
> hand I think that the peoples who actually use lua could enable it on their
> own, or there should at least be the possibility to disable it. Afterall
> special environments like the one we are talking about here don't need it.

but that's not going to happen. :) not for edje. i dont want it becoming that
where some feature may or may not work depending on how it was compiled. people
will download themes, icons, wallpapers etc. and find they appear nothing like
advertised, break, do bizarre things just because some feature was not compiled
in. i dont intend to make it easy by making it optional. i highly discourage it
being patched out. i have been doing open source, linux and e for more than a
decade and i know where many of the questions end up - they end up on my table
asking about something someone else patched and modified. to simply avoid the
pain of having to 1. figure why things are not working 2. having to explain
what may have been done, and 3. have to finally redirect the queries to the
people doing the patching. :) lua and embryo are non-negotiable features of
edje. jut like text, images and rectangles are non-optional features of evas,
etc. etc. :)

> I guess I could either use an older svn snapshot before the lua merge (I don't
> like this option because it of course means bugs wont be fixed in my version)
> or patch it manually out (don't know how complicated that would be). 

as above. you will create problems for yourself. you use elementary. elementary
has themes. themes are edje files. they are designed and intended to be
replaceable. people can/will replace do it. and they will then complain why
theme x, y, z etc. that uses lua "has bugs". from upstream it will be
documented that all edje files can do this. all. no conditions. :)

> > > > to reduce complexity i would even remove fonts. what i'd do is:
> > > >
> > > > 1. every bootable os provides as well as kernel in /boot/zImage (or
> > > > wherever), it provides a /boot/bootIcon - this is a simple zlib
> > > > compressed (see zlib docs on how to simply give it a chunk of data to
> > > > compress, or decompress). you could avoid compression if u want, but i
> > > > think this would be worthwhile. lets say the icon data is RGBA (lets
> > > > use a universal format to account for different devices with different
> > > > screen depths/formats). aany bootable os must provide this file or it
> > > > wont be listed. (yes it's an added requirementm but moving work to the
> > > > bootable os's i takes it out of the qui boot image)
> > > > 2. within the qui boot fs u include some /boot/wallpaper file - same
> > > > format as icons.
> > > > 3. you load wallpaper, convert to screen depth in the simplest/dumbest
> > > > way (speed isnt important. you are not doing realtime ui rendering). eg
> > > > for 16bpp this would be:
> > > > 
> > > > unsigned int *inpix;
> > > > unsigned short *outpix;
> > > > 
> > > > *outpix = (((*inpix & 0xff0000) >> 19) << 11) | (((*inpix & 0xff00) >>
> > > > 10) <<
> > > > 5) | ((*inpix & 0xff) >> 3);
> > > > 
> > > > i'll leave it up to you to handle other screen formats (32, 24, 18, 15,
> > > > 12, 8bpp etc.). but one per format.
> > > > 
> > > > now blend the icons u find (u'll probably just want to blend agaibnst
> > > > the original rgba wallpaper image and then convert thr result to screen
> > > > format like above - see google for alpha blending math. its rather
> > > > simple. it's easy to do, its much more work to do FAST. here speed isnt
> > > > important as u are just going to render this once and put it up - no
> > > > realtime ui), one at a time on the screen eg:
> > > > 
> > > > +-------------+
> > > > |             |
> > > > | [ 1 ] [ 2 ] |
> > > > |             |
> > > > | [ 3 ] [ 4 ] |
> > > > |             |
> > > > | [ 5 ] [ 6 ] |
> > > > |             |
> > > > +-------------+
> > > > ... etc.
> > > > 
> > > > as many as the screen fits - the icons themselves can just be an image
> > > > (eg a penguin) or image + text. u'll probably want to use tslib and get
> > > > coords when u press to see if up press on one of them - then boot that.
> > > > you should adjust the layout based on screen size. eg for landscape:
> > > > 
> > > > +-------------------+
> > > > |                   |
> > > > | [ 1 ] [ 2 ] [ 3 ] |
> > > > |                   |
> > > > | [ 4 ] [ 5 ] [ 6 ] |
> > > > |                   |
> > > > +-------------------+
> > > > 
> > > > this will provide all you need for a grahical boot. it wont be smooth.
> > > > it wont scroll or animate. it wont let you add much more complexity
> > > > without a lot of work (eg configuration panels or more than the above
> > > > hyper-simple boot), but it will function and be very small.
> > > 
> > > Thanks for your insight. I think it's a little to low level for me right
> > > now, afterall I have a limited amount of time I can spend on this. The
> > > key is probably to get the right balance between the amount of work and
> > > usability / performance. For now I will leave some abstraction layers in
> > > and see how small/fast this can be made. 
> > >  
> > > > of course it's easy for me to say this. i've done all this kind of stuff
> > > > before. many times. in fact deep down inside efl are semblances of some
> > > > of this, as just a subset of all that efl does. but it does so much
> > > > more so it's not small. in return for that footprint you get a small
> > > > mountain of features. but as i said - easy for me to say the above. i
> > > > can do it in my sleep - it'sw hat i do, but it's up to you to decide if
> > > > you are up to doing it at this low level or not. for any reasonable app
> > > > you'd end up using enough of efl's features to make it worth carrying
> > > > along its size. it'd be worth the expense, but... for you i don't know
> > > > if you will ever use all those features. it may simply not be worth it.
> > > > as long as u use efl your image is not going to be that small. then
> > > > again you are adding dropbear and thus also enough network config tools
> > > > to set up usbnet
> > > 
> > > This should be covered by busybox i hope.
> > 
> > hopefully, but every busybox feature added is more space. 
> > 
> > > > - what about wifi? wireless tools too? how much is the
> > > 
> > > Not going to happen (at least not by me). The network support is just to
> > > provide a kind of minimal rescue system to ssh in over usb, mount the sd
> > > card and then chroot into the regular system to fix something. It's not
> > > intended to get some kernel + root filesystem from a NFS server over
> > > wifi. Anyway if the usb network support should be the few KBs which make
> > > it to large/slow then I will probably drop them. 
> > 
> > ok.
> > 
> > > > image size when you remove any of the ui bits - all your other parts
> > > > (libc, busybox, dropbear, network tools to bring up usbnet and/or wifi,
> > > > wireless tools, dhclient if u have wifi... etc. first see how big that
> > > > is. how big is it? then relative to that, look at ui.
> > > 
> > > I agree that this is the right approach. Antoher interesting thing is how
> > > much an aditional MB actually costs in terms of speed (copy from NAND to
> > > RAM).
> > 
> > oh true. though it might work best as a real jffs or cramfs fs instead of
> > initrd - it's flash. you have no seek overhead so a linear read isnt going
> > to be much better than a sparse fetch of whats needed from jffs2 or cramfs.
> > in fact chancges are u'll be better off as u fecth "on demand" as opposed
> > to read everything even though some of it isnt needed. my suggestion might
> > be cramfs as its going to compress best. :)
> 
> This would require that the kernel partition in NAND is formated as a 
> filesystem but then Qi couldn't read from it. Or am missing something obvious
> here?

the fs can be mounted as an offset from the start of a partition. you cn even
split it into 2 partitions. 1 for kernel, 1 for rootfs. as such qi SHOULD be
able to technically - it can read krenels from a FILESYSTEM on sd. it can read
fs's.  no reason it cant read an fs from nand too (in principle) other than
simply that having not been written in or explicitly avoided (can't think of a
good reason myself if u handle fs's already).

> > > Below is a listing of my current initramfs files sorted by size. Now that
> > > I compare them to my SHR system I see that they are a lot larger. For
> > > example libevas-* is only 687K on my SHR. I will have to investigate if
> > > this is just because of the missing optimization flags in my $CFLAGS or
> > > what causes this. 
> > 
> > ok. for option 1, u can nuke libpng. thats 224k gone. libecore_con should be
> > able to go. i can't think of a reason you need it.
> 
> I enabled it because it seemed like ecore-file was going to need it. I will
> recheck this.

oh yeah. i forgot. the ecore_file_download stuff uses it. :)

> > another 44k gone. the
> > evas jpeg image loader can go. another 20k. 
> 
> I guess I will need this if I want to load logo's from the SD card.

if they are jpeg. if they are png - u'd need png loader. if u put them in edje
files, u need nothing. u already have support.

> > all the saver modules for evas can go 
> 
> I didn't find a way to disable them during ./configure should I just not copy
> them over to the rootfs?

just delete the modules. the way it builds - its intended to just install and
then have package builds split the install up into sub-sections, like a package
for each loader and each saver module, each engine etc. so just delete the
stuff u dont need.

> > and the png loader. thats a total of 32k gone.
> 
> Yay!
> 
> > now elementary's default them
> > can be very much trimmed. it has images - a fair few in it. if you used
> > fewer images and smaller ones that were much simpler and re-used a lot,
> > it'd make it smaller. you could get that default theme down to maybe
> > 50-100k without much trouble. 
> 
> As my designer skills are < 0 I will leave this as is for now.

welljust lettign u know there is space to be saved. and be prepared - the
elementary theme WILL getbigger over time. the default theme is expected to
provide every feature elementary has. thus everything elm can have - it will
get. :)

> >also you use DejaVuSans.ttf - its HUGE. 
> 
> Yes I just used it to test the font issue thing I posted about on e-devel.
> 
> > it has lots of chars for all
> > sorts of international text (outside of latin/western european). the
> > standard and much smaller Vera.ttf  is only 72k. (DejaVu was a modified
> > Vera with all these extra chars added). so you could save 512k by using
> > plain old vera instead (this i think has western european accented chars
> > like ö and é œ ß etc. so u could even handle that, but for a bootloader i
> > suspect normal lasting/ascii is just fine. right?).
> 
> Of course plain ascii is enough. I will switch to Vera.ttf.
> 
> > so.. lets see. for your #1 i can find 224+44+20+32+512k of savings without
> > changing any functionality or doing any real work except deleting files.
> > that's 832k to squeeze out there. you can add another probably 250k of
> > savings if u spend time in making a very lean theme. so we're about 1.1mb
> > now to lose (of uncomrpessed files - and of course this is rounding up all
> > files to 4k blocks of savings may be a little less).
> > 
> > now if u did option #2 and did a lower level ui with no text (text in the
> > icons) just with evas + ecore-evas, you could save an extra (on top of the
> > total savings above) if you put png loader back but remove eet (this means u
> > dont need libjpeg anymore), so... +224 -272 -108 -648 -72 -384 -78 -44 -8 +8
> > (trust me on this) ... another 1382k of savings on top of the reduction in
> > #1.
> > 
> > in #2 efl itself will have a footrpint of 928+448+224+168+100+84+28+24+24+16
> > +16 +32+8+8+8+8+4+4+4+4... 2100kb. so thats efl's footprint (approximately)
> > in addition to a minimal core os. thats whgat it costs you in space for efl
> > to save you work for #2 - of course #1 will cost an extra 1382kb on top of
> > this
> 
> Thanks for the calculations :) So for now I hope that those 1382kb won't have
> that much of an impact.  
> 
> > so that is about the best i can do for you. note these numebers are
> > uncomrpessed. comrprssed expect the numebrs to about halve. ie efl costs u
> > about 1mb of "storage" as after compression thats what u'll get. elementary,
> > edje and friends will cost u another about 700k on top. based on your
> > numbers below. :) that's not a hell of a lot.
> 
> I agree for what it does that's not a lot at all.
> 
> [snip file sizes]
> 
> > > > one thing i can suggest. you can drop edje and elementary and do this in
> > > > just ecore_evas + evas. you could even drop eet here. just 1 image
> > > > format loader (eg libpng), and you'd be able to i think have a subset
> > > > of ecore (ecore, ecore_evas, ecore_input, ecore_fb), and just evas +
> > > > buffer, software_generic and fb engine and just png loader module. no
> > > > savers modules.
> > > > 
> > > > now you'd need to create all your own "widgets" - but you could stick
> > > > to a simple design as above just an array of icons. load the icon files
> > > > (now u can make them .png files in the boot dirs of the os's) and put
> > > > them on the screen. you can now easily add callbacks for the mouse down
> > > > (or up really) on each icon and boot the appropriate os. wallpaper can
> > > > also be a png file in the qui boot fs. you will be using efl at a lower
> > > > level. you handle the callbacks directly and place the objects yourself
> > > > (and handle canvas resizes - yes it can happen even on the fb. eg a
> > > > resolution change, but in general handling this right just handles the
> > > > inital fb size right anyway). this will mean you donthave to handle
> > > > rendering code and different screen formats, image loading or tslib
> > > > interfacing etc. it should have you a much reduced efl footprint. but
> > > > keep you from the lowest ugliest bits. hell if you keep all the "os
> > > > info for the ui" inside the png font handling is moot. u will still
> > > > need freetype - but u just put name of the os image into the icon
> > > > itself (nothing 10 seconds in gimp cant do).
> > > > 
> > > > so to repeat
> > > > 
> > > > 1. either full efl, elementary etc. - but this will be a big footprint.
> > > > always
> > > > 2. subset of efl and keep your ui simple eg as i described above and
> > > > punt off all the os identification to a png icon as i described above
> > > > and justddumbly display it and handle events when the user presses it.
> > > > smaller than full efl but not totally minimal.
> > > > 3. do it all yourself at the lowest levesl. as small as it will get but
> > > > by far the most amount of work for you.
> > > 
> > > Thanks for this nice overview.
> > > 
> > > I would like to try it in that order and see how useable it is speed wise
> > > and if it's too slow then move to the next variant and remove one layer
> > > of abstraction.
> > > 
> > > For now I am working with option 1. As I said in my first mail it would be
> > > nice to use the same technology just with a different backend and
> > > therefore reuse all the work you and others have put into it.
> > > 
> > > Option 3 (although probably not as low level as you described it) is what 
> > > kexecboot does. It would therefore be an option to add touchscreen
> > > support to kexecboot. I would probably not be as pretty as an elementary
> > > based solution if there are people who actually care about the optical
> > > aspect of the thing. 
> > 
> > sure. as i said. options. #3 is by far the most work with the least visual
> > appealing results. #2 is probably a nice half-way-house. :)
> > 
> > > > > Proof of Concept
> > > > > ================
> > > > > 
> > > > > As a proof of concept I started to write a simple shell script (well
> > > > > in the beginning it was simple in the meantime it evolved in kind of 
> > > > > mini build system, maybe something like OpenWRT could be used but I
> > > > > wanted a simple solution where I actually understand what's going on) 
> > > > > which downloads and cross compiles everything with an uclibc based 
> > > > > toolchain.
> > > > > 
> > > > > So far I have cross compiled all the components mentioned in this 
> > > > > post the result is about 6-7MB large.
> > > > > 
> > > > > I then tried to run the elementary dialog application from the 
> > > > > elementary wiki page[3] in a chrooted system and this works
> > > > > (although there seems to be a problem with the touchscreen which
> > > > > doesn't quite work right and sometimes even causes a segfault).
> > > > 
> > > > do you have ts calibration working? 
> > > 
> > > Don't know yet, I have just copied over the ts.conf from SHR so that it at
> > > least uses the same/right modules. Touchscreen calibration is the next
> > > thing I need to look into. Because I tested this in a chroot from within
> > > a SHR system I thought the touchscreen would already be in a redy-to-use
> > > state (i.e calibrated) is this a wrong assumption? 
> > 
> > ok. chances are a pre-calibrated file will be ok. but if u want to work on
> > multiple devices (not just a freerunner and in the end this is a goal you
> > should have in mind as there will be more devices with different sized
> > screens, etc. etc. and its good to plan ahead).
> 
> True.
> 
> Thanks,
> Marc 
> 
> -- 
>  Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com