RooJSolutions

Gtk3 introspection updates and Unusable Unity..

2011-04-25 00:00:00

Article originally from rooJSolutions blog

Well, as Gnome 3 is out, it has to be tested. Luckily I've not got a huge deployment to sort out, but as I have a few applications that use Gtk, I thought it was about time I upgraded one of my machines to see what chaos I will have to deal with in the future.

So it was one of my Ubuntu boxes that got the pleasure of a Natty and Gnome3 PPA upgrade. (I use debian on my other development box, which actually got destroyed last week with a complete disk failure, although I suspect the motherboard may have problems... It's getting old like me...)

Upgrading to Natty is not to bad, from what I remember it only took a small amount of brain surgery to get it to boot correctly after the upgrade. But once up, you get the pleasure of the Unity desktop. My first impressions where not to hot on unity, my wife uses it on her netbook, it's great there, after the initial shock of me upgrading without her knowing, she actually said it was alot better than compiz. Although she missed the special effects.

But after using Unity on the big screens, it just became unbearable. Detached menus may seem like a cool idea, and are quite handy on a netbook, but they are an absolute nightmare when using things like gimp on dual head full HD monitors, my wrists hurt after a few minutes....

Along with the removal of the Applications/Places/System menu's which while klunky are still handy for quickly finding applications. A classic example of this Alleyoop Memory Checker, a very nice wrapper around valgrind. In the Unity world if you do not know the name of the application, then finding it is a huge mouse journey around big icons.

As for the left icon menu, all I can say is that I'm not the worlds best designer (although at least I did study it), but it's so graphically noisy that it unusable. It's basically a bad re-invention of Docky/Cairo Dock, which do far better jobs at providing a similar task role.

So after all that I did try and get gnome-shell going, but unfortunatly the Gnome3 PPA build is not currrently working, and also has a rather nasty habit removing all usable desktop enviroments. I ended up adding xterm to one of the /etc/Xorg/X.sessiond files and starting up gnome-panel, mutter and docky to produce a usable desktop for the time being, while I wait to test out the latest gnome-shell.

So on with the harder stuff.. - Gtk3 and introspection.

One of the key applications I use to develop is app.Builder.js , it's a drag/drop interface to build web applications, that also allows you to fill in all the code and associate it clearly with the element and event occuring. It's written in Javascript, and uses Gnome seed to run on the desktop. As I've mentioned before Seed is a bridge layer between the Webkit Javascript engine, and Gobject-introspection, the now standard way to interface Gnome/Gtk/Glib etc. projects to non-C languages, eg. Python, Javascript (and others...)

With the introduction of Gtk3, GObject introspection has also been updated, and the updated mix between the two had quite a few knock on effects to the builder I had written using Gtk2 and pre-0.9 versions of Gobject introspections. Heres a general summary of the changes.

TreeIter and TextIter

The latest version of GObject introspection has a feature called caller allocates, this basically means that previously with Seed we had to create an instance of a TreeIter, the the TreeIter call would be of type 'inout' (eg. the Iter would be sent into the method, and returned out)

eg.

var iter = new Gtk.TreeIter();
model.get_iter_from_string(iter, path);
// iter would now contain the tree iter for that path..

In newer versions, the iter is an 'out' value, which means you have to create an object for the iter to be added to. eg.

var iret = {};
model.get_iter_from_string(iret, path);
// iret.iter now contains the tree iter.

TreeSelection

since the get_selected method for a GtkTreeSelection now has 2 out values, the call has change from

OLD:

var iter = new Gtk.TreeIter();
selection.get_selected(model, iter);

NEW

var sret = {};
selection.get_selected(sret);
// sret now contains { model: **THE MODEL**, iter: **THE ITER** }

TreeModel get_value

Since get_value does not have a return value, seed with return the 'out' values as the return object.

OLD:

var value = new GObject.Value('');
model.get_value(iter, 2, value);
print(value.value);

NEW

var str = model.get_value(iter, 2).value.get_string();
print(str);

Drag pixmap becomes surfaces

This is a pure Gtk3 API change (BC break)

OLD:

var pix = widget.create_row_drag_icon ( path);
Gtk.drag_set_icon_pixmap (ctx, pix.get_colormap(),   pix,  null, ..... )

NEW:

var pix = widget.create_row_drag_icon ( path);
Gtk.drag_set_icon_surface(ctx, pix);

Drag drop data passing..

The drag drop signals appear to work ok, however I've not managed to get the data to go back and forth,

a quick workaround is to just use some form of global variable to store the current dragged item (I doubt you will get more than one dragged item at once..)

Drag drop API

alot of these appear to have played musical chairs.

GtkWidget.prototype.drag_source_set -> Gtk.drag_source_set
Gtk.drag_source_set_target_list -> GtkWidget.prototype.drag_source_set_target_list
Gtk.drag_dest_set -> GtkWidget.prototype.drag_dest_set

Internal Seed changes

I've added a few more fixes to Seed in the last few weeks, mostly to handle compiling correctly and detecting the correct version of introspection. for the most part it's working fine, however I'm still a bit baffled by a Glib memory corruption bug, which occured after multiple model.set_value and model.get_value calls. After running valgrind, I managed to stop the corruption occuring by increasing the allocated size for a struct by 1 byte

Around line 546 and 640 of seed-engine.c the change goes something like this.

-                  out_args[n_out_args].v_pointer = g_malloc0 (size);
+                  out_args[n_out_args].v_pointer = g_malloc0 (size+ 1);

Arround line 738 of seed-structs.c

-  object = g_slice_alloc0 (size);
+  object = g_slice_alloc0 (size +1);

GtkDjs, daily builds, added libraries and much more..

2007-08-07 17:42:45

Article originally from rooJSolutions blog

Daily builds / downloads available

I've set up a cron job now, so all the bindings and binaries are built daily, you can download them from here.
http://devel.akbkhome.com/gtkjs/gtkjs_snapshot.tar.bz2
This includes gtkjs, mjs and jsfastcgi, In theory it would not take too much to build this on Windows... - Send me the fixes if you� attempt it...

Just download, unzip and try out

./gtkjs test/filetree.ds

etc.

the gtkdjs Documentation is updated daily to match

And I still need a better name for the project;)

Closure and scoping fixes.

After seeing a post on the DMDScript newsgroup concerning closures and scoping issues, I spent quite a while looking at the issue.

The basic problem, was that the original DMDscript code was designed to create a cache of function definitions, and re-use them whenever they where refered to. Along with this, they had no concept of creationScope. so variables in the creating scope where not available. Fixing this involved quite a few changes to the compiler and runtime. Basically creating new Function instances when they are found, rather than only once at compile time. Along with storing the scope inside the Function instance. so when they are called they understand the correct scope. Anyway standard Javascript scoping, and closures all work as expected.

Undefined Warnings improved

I mentioned in my last post that I added Warnings when undefined variables where accessed, I've modified this slightly as undefined is a valid type in Javascript, so unassigned arguments to a function call are flagged as undefined, but accessing them should not issue a warning. So only when the scope.Get(variablename) calls return null, rather than a Value.vtype[V_UNDEFINED] flag this warning now.�

LibSoup extension

LibSoup provides HTTP support, at present, basic sync requests work, the code is there for async calls, but I've not tested it yet. test code is in tests/Soup/.

This little bit of code get's my web site, and shows headers, then extracts all the�href from all the <a> tags.

var sess = new Soup.SessionSync();

var msg = new Soup.Message("GET", "http://www.akbkhome.com/");
status = sess.sendMessage(msg);

println("Status is " + status);
println("ResponseHeaders is " + msg.responseHeaders.toSource());


var imp = new Dom.Implementation;
var doc = imp.createHtmlDocFromMemory(msg.response);
var a_s = doc.getElementsByTagName("a");
for(var i =0; i < a_s.length; i++) {
    println("got href: " + a_s.item(i).getAttribute("href"));
}

XML2 limited support

To enable parsing of html documents for Gdome, I've added limited support for XML2, it's mostly used by the Gdome method: �Dom.Implementation.prototype.createHtmlDocFromMemory( String htmltext )
The Generator code is currently tied into the libxml header files on my system.. this needs fixing so it uses the gtkwrap download script. (but the code is a� nice example of how to automatically create bindings based on .h files..)

Gtk.SourceView support

In preperation for testing text editing (and eventually self-editing / morphing of applications), I've bound the GtkSourceView widget. Unlike the standard Leds editor which uses scintilla, I thought I'd try and see if using GtkSourceView would prove more robust. - The bindings had already been done for GtkD, so there was not much to change to the APILookupSourceView.txt code. I only used the full name "sourceview" rather than "gsv"

Handling of missing functions and Libraries improved

When I was testing GtkToolbar on one of my machines which had an old Gtk library, I discovered a segfault when it called a newer function that did not exist in the old library. To fix this, the Loader.d file now binds a simple function that throws and exception to any method it can not bind. So you can catch in javascript any call to unsupported methods in a library.

Phobos Path module added

all the methods from std.path are now exported to javascript, and in the manual. This enables a few usefull functions like

var file = "/etc/passwd"
println("Directory = " + Path.getDirName(file));
println("Filename  = " + Path.getBaseName(file));
println("combined filename  = " + Path.join("etc","passwd"));

Regex Fixes

In testing extjs parsing, I came across two bugs in D's regex implementation, that prevented it's loading.

forgetful parsing (?:abc|cde|xyz) - the fix for this was trivial and is in D's bugtracker, and there is a modified regex file in the dmdscript distribution.
the use of special chars in character range matching after the '-'. eg. �[\w-\*] and [\w-\.] which should be interpreted as [\w\*-] and [\w\.-]. �These currently parse correctly however I've not got round to fixing the implementation properly so they are pretty broken at present. (basically matching everything from \w onwards...) - the bugs in D's bugtraker, but the fix is not... I may get back to this...

Simplified exporting of Structures

One of the missing pieces for the Gtk Bindings, that I came accross with jLeds, was the event structures had not been bound. Since they are very simple structs, and you only need to get access to their properties, I developed a new action for the wrap file "structDump" which autogenerates the class file, forces the full Struct definition to be written and writes getter methods for all the exportable properties.

Bindings builder flexibility

Since we now have about 20 libraries bound, the Wrapping builder script can take a little while on slow systems to build all the bindings code. So I've added the ability to specify which APILookup files to action.
eg. to build LibSoup you can do.

sh buildit.sh APILookupGLib.txt APILookupGObject.txt APILookupSoup.txt

It cant do the dependancy resolution yet, so you have to list all the pre-requisite packages so it has access to all the required types when building the library you need.

The struct parser is also a �little more robust now, handling comments and lists of elements eg.
ushort x, y;

Minor Gtk Fixes

G.Object.setProperty(String key, Any value) now works, and converts value into G.Values automatically.
GtkTreePath[] Gtk.TreeSelection.prototype.getSelectedRows(Gtk.TreeModel model) �now works - although I need to look at generic ways to generate array of Objects from GList..
new Gtk.TreeStore(Array coltypes) now works (where coltypes is either an array of strings, or G.Types.) - this works along with the other constructor methods - eg. varargs......
Gtk.TreeStore.prototype.set(Gtk.TreeIter row, Array values) now works to quickly set the values of a tree row, rather than calling set(GtkTreeIter row, Number col, Mixed value)
Gtk.Container.prototype.remove(Number item) and Gtk.Container.prototype.remove(Gtk.Widget widget) are now working - I need to change this slightly, so you can remove all by sending '0' as the item, and waiting until it returns false...
Most of�the �GtkEvent Structures are now exported, and all the properties are available as getters.
new GdkColor(Number color) �is based on 0xRRGGBB hexidecimal values, rather than longintegers.. (you can use the long version to do more precise colours: new GdkColor(Number red, Number green , Number blue);
new Gdk.Pixbuf(Array xpmdata) is now supported so converting xpm data for use as icons is very simple (just replace "const char**" with "var")

ExtJs loading

One of the goals is to make the engine compatible with existing code out there, a nice test of this was extjs, which it can now load correctly (with a few lines of javascript prefixing the loading).�I've not actually tested any of the functionality yet, as XmlHttpRequest needs building from the libsoup bindings.

jLeds port underway..

What's a language without an editor (or an email client - if you know the old joke about every application eventually evolves until it can read email.).. So partly to test the bindings I've started looking at porting Leds to gtkjs - the code is in tests/jLeds, and gives a good example of some of the new Javascript2 features, along with the gtk bindings.

Try the newsgroup if you need support.
news://news.digitalmars.com/DMDScript

gtkds - more updates and better debugging..

2007-07-31 23:08:00

Article originally from rooJSolutions blog
Add one feature, and create a few bugs.. seems like it's always the way..

The two features added over the weekend where class syntax support and include support. My initial effort proved to be a little off the mark.

Read on if you want to know the nitty gritty details about writing an interperted language runtime... Along with a list of the Gtk binding improvements..

Compairing Adobe AIR to dmdscript / fastcgijs / gtkjs

2007-07-28 22:36:00

Article originally from rooJSolutions blog
A good friend of mine asked what's the difference between the dmdscript/fastcgijs/gtkjs stuff I'm doing and Adobe AIR.

I've not really looked at Adobe AIR much, noticed that it was mentioned on the extjs site, so I thought I'd do a quick "what's the difference"..

So what's the key differences

For Adobe AIR

Backed by a huge company with unknown reasons for hooking you in.
Lot's of support for Adobe technology, but any other libraries, you can forget about.
Probably written in C++ or C, so there are probably a few nice security holes difficult to find in the memory allocation. Even if you did have access to the source - it would be a pretty complex task to write bindings for libraries.
Great support for Windows, pretty good for Mac, and bugger all for other un*x's

For GtkJs / Fastcgijs / dmdscript

Absolutly no support ;) - obviously only done, because it's interesting and fun!
Lots of support for any open source library, as long as you are willing to waste a few days working out how mindblowingly simple it is to write bindings.
Written in D, which makes it pretty secure (well if you fix some of the bugs in my generator to do a small amount of sanity checks). And due to the fact that it's so similar in syntax to Javascript that makes the whole process of moving slow parts into compiled code considerable simpler than any other scripted language..
Great support for linux, and it might just work on any other platform, as long as you can find someone who knows those platforms.

Personally I think the Adobe AIR idea is pretty good, Javascript is a good basis for a language. But to be honest for the reasons above, I would not touch it with a barge pole..

javascript2, ECMAScript4 and dmdscript.

2007-07-27 16:59:01

Article originally from rooJSolutions blog
Last week I had a go using my little bindings for something useful, rather than just being a little toy. One of the projects I was working on was a hack to exim4, that logged all incomming and outgoing attachments into mysql and stored them on the filesystem.

The basic idea was that the company needed the ability to review if any sensitive data was being sent out by email. The exim hacks are pretty simple for this (hook into the mime handler). The web viewer uses extjs and PHP at the backend, it's a small addition to their current email management interface.

But one area that was needed was a little cron job that cleaned up the directories and deleted data and files older than 2 weeks (so they dont get too clogged up.)

I thought this would be an interesting test of the mysql and file system bindings. So I threw together a horrifically simplistic version of DataObjects, and a short script that did an SQL query and based on the results deleted records and files.

One issue was that I could not really do the DataObjects thing of overlaying the results, or query options into the dataobject as object variables in javascript are overlaid into the same namespaces as methods, so you could accidentally delete methods if your database had matching names. - So the data just gets put in (dataobject).data.*�

The other issue was that the syntax for javascript while fun and flexible could really do with a class construct. If you look through the specifications for ECMAScript4, There is a huge amount of changes making Javascript as we know it far more Java / PHP5'y.. with interfaces, public private etc. So I had a go at adding some of the new features into the dmdscript core.

I've managed to get class's and include working. although it probably needs quite a bit more testing. This basic syntax now works

include "mytest.ds"; // this is run at compile time (not runtime!)

class A {
        function A() {
                println("This is the constructor A");

        }
        var c = 12;
        function B() {
                println("This is B and c is " + this.c);
        }


}
class C extends A 
{
        function C() {
                println("This is the constructor C");
                A.prototype.constructor.call(this);
        }
        function D() {
                println("This is D and c is " + this.c);
        }
}
 
 
var a = new A();
a.B();

var c = new C();
c.B();
c.D();

Will successfully output

Hello from mytest
This is the constructor A
This is B and c is 12
This is the constructor C
This is the constructor A
This is B and c is 12
This is D and c is 12

Now I can start writing tidy little javascript libraries...

dmdscript with fastcgi

2007-07-13 18:25:37

Article originally from rooJSolutions blog
I've been slowly ticking away adding features to the gtk javascript bindings, in doing so, I'm adding extra libraries - Mysql works quite well, and Seeing the recent post on planet.dprogramming.com about fastcgi4d, I wondered if I could run dmdscript from fastcgi.

To enable a web version of dmdscript with my bindings, I had to do quite a bit of re-organization, enabling it to be built with random libraries added in and exclude the Gtk stuff. Core to this was to move all the registration code into the directories that hold the binding code. Each binding directory now contains 3 files, binding***.d, binding***type.d and register***.d. Which manage the dynamic loading of .so (or .dll if windows actually works). and the registering of all the javascript objects and methods.

For fastcgi, I had a look at the code described on the blog post, but was very reluctant to use it, as it

required tango, which is not a current requirement, and I'm a little concerned about using.
required knowlege of templates, which are still a bit of a black art. and I've only used very sparingly when absolutly every other alternative has been ruled out.

So after considerable digging through the code and trying to make head or tail of the code on fastcgi.com, I finally found the python fastcgi code, which ported easily to D.

The core files libraries that are helpers in dealing with fastcgi are here.
http://www.akbkhome.com/svn/gtkDS/src/fastcgi/

They need the loader.d and paths.d file from here
http://www.akbkhome.com/svn/gtkDS/wrap/
to be usable.

and the current, non-threaded simple responder is here
http://www.akbkhome.com/svn/gtkDS/src/fcgi.d

So for hello world example, this simple piece of code dumps all the server variables and says hello world.

println(Request.toSource());

println("hellow world from javascript");

Next job is to look at how GET/POST data is passed around and how to escape data on output. among a list of 100 ideas for how it could all work.

GtkD - Anatomy of the bindings generator.

2007-06-28 08:58:00

Article originally from rooJSolutions blog

To generate the Gtk bindings (and adding other features) for gtkDjs I use a code generator. This is pretty common to all the Gtk bindings. I worked on the PHP-GTK ones a long time ago, which in turn where based loosely off the Python bindings.

For GtkDjs, the starting point was the GtkD binding code. While the current code is still similar to it's parent, It has grown considerably since it's original birth. So In the vain of "if someone ever feels like helping out with the bindings", or wants to write and send me bindings for SQLite, Mysql, curl or libsoup etc. Here's the inside story of them.

The basic concept.

In essence, the bindings work using "generator scripts" called APILookup*.txt, which contain a series of either information, or instructions to do tasks.

Other than the overall configuration settings for the generator, or libraries, the core part of generating bindings is to create classes. In Gtk this is normally done by reading the HTML documentation for a specific Gtk Struct, and using that information to generate data about the Enums, Signals and Methods that are defined. This is all done by GtkClassParser.d

Finally after the File has been parsed, the Output classes "ClassOut, FuncOut, EnumOut, LibraryOut, PhobosOut, SignalOut" generate the code files in the src directory.

Unlike the original GtkD bindings GtkDjs does a double pass at generating each of the packages, as we use the first pass to calculate dependencies and inheritance, rather than relying on the list of imports in the APILookup files. This means that the APILookup*.txt files do not really have to list all the required imports.

More details on the APILookup files.

While I'm not going to explain all the possible commands available in the files, I will explain the concept and a few key ones. The file "GtkWrap.d" contains the parser, with a complete list of keywords and actions, it's a reasonably simple and obvious piece of code. I'm still adding new commands when I see them as necessary, and may even remove a few as some are pretty pointless or unused.. (like code: *** which is ignored but is usefull for reference on how GtkD did things).

The basic concept of the file is a list of data in the formats:

#for simple data
keyword : Value
# for building a list of key value pairs
keyword : key valuepair
#for long data - like code etc.
keyword : subject
......
keyword : end

#for long data - (older style)
keyword : start
......
keyword : end

Order is quite important, as the parser for the APIWrap is not forgiving and can easily go into infinite loops if you get the wrong or unknown keyword in the wrong place. Fortunately using the existing files as a basis for a new one should help out a bit.

The core APILookup.txt files contains a few key pieces of information

aliases of Gtk base types to D types (and a few kludges to work around other issues)
mappings of the D-Types to Javascript Types (really related to the method calls on dmdscript.value)
where the files are, like the gtk documentation and where the generated files should be written to.
List of packages, and how they related to directories (Note that the GtkDjs bindings also use a jsPackage command in the individual wrapping files to determine how they are exposed to Javascript)
A small bit of code to copy the dl() loader into the generated directory.
And finally a "include" like statement "lookup:" which tells the parser to start using the new file as it's input.

The individual Binding for the specific libraries (or packages as the tend to be called) are structured a little differently.

At present there are alot of add*: commands, which are generally ignored by GtkDjs, and will probably be removed. - As we auto generate most things
In the Gobject bindings, you will see an example of structCode: which is how structs are described if they can not be done by just pretending they are pointers to void.
Again in the Gobject you can see a manual enum description. necessary as the real Enum is not actually described in the documentation.
next are the two key information, wrap and jsPackage - wrap indicates which package it is wrapping (from those listed in APILookup) - so it knows where to write the files. and jsPackage tells it how to expose it to Javascript
structWrap: is used simply ensure that the struct is available usually as an empty struct.
nostruct: is used to prevent a struct from being bound.. usually an indicator that something needs fixing..
finally we have a small batch of code for each class to be written. The class: command indicates the filename of the code to be written, the real classname is based on the struct that is being wrapped usually.
some of the files have jscode, and jssig elements describing how the automatic code and documentation generation should be overridden.

The generator code.

In order of how they are used.

GtkWrap.d (includes main()) and is the command interpreter, data from the commands is stored in a ConvParms class (convparms.d), and passed to the Outputters. Any packages that are defined are stored in a class defined in Packages.d.
DefReader.d is the helper class that does the low level conversion of the APILookup.txt files into commands.
GtkClassParser.d does the legwork of collection all the described definitions in the HTML file into Classes from GtkStruct.d GtkFunc.d, GtkEnum.d (note signals re-use the GtkFunc class). The HtmlStrip.d library just removes the HTML tags making the documentation files a bit easier to parse.
Finally after a file is parsed, usually the outFile: command is found and the class code is generated by ClassOut.d. Which in turn loops through the functions, signals and generates the code using FuncOut.d and SignalOut.d
At the end of each package file, the loader, struct listing and enum lists are generated from LibraryOut.d which uses EnumsOut.d and GtkStruct.d (although that wasn't the best of design hacks)
PhobosOut.d is used by the non-gtk code to generate code that does not need library links.

The design differs a little from the original GtkD generator in that I separated the parsing of the documentation and the code generation into separate classes. I felt the original code was pretty huge and unwieldy done that way.

Anyway comment away if you have any further thoughts...

GtkDjs updates - manual in IE, user comments and treemodel object storage

2007-06-27 00:05:19

Article originally from rooJSolutions blog
Two minor updates this week, First the GtkDjs manual now works in IE, along with featuring user comments, - you can just add normal comments, code examples, rewrite the introduction, or note a bug. Eventually I plan to add an approval flag so it moves the comment into the documentation, along with the ability to create a comment based on another comments or the existing documentation. And maybe HTML comments...

As for the bindings I've been looking at the GtkTreeView and Gtk.TreeStore. To push it a bit, I built a little file navigator (in the tests folder). Key to this was the ability to store Javascript objects in the Treestore. My initial idea of just using a gpointer to the class turned into a bit of a disaster, as the garbage collector assumed that the object was not being used, (even though a pointer to it remained in the store), and free'ed it. This leed to segfaults later when trying to read it.

To solve this I ended up using boxed types, so hopefully I've implemented so the objects now get free'd correctly..

I've also simplified the setting method for the store (next on the list is to look at� the fetching methods). So storing data in a node/row is a mater of:

store.append(iter,parentIter); 
store.set(iter, 0, "node title");
store.set(iter, 1, {directory: pdir + name + "/" });

Getting a directory listing uses the new Phobos (or generic D binding backend) binding code.

var filelist = File.listdir("/home/alan");

I did notice one little gotcha for the dmdscript backend, that it does not support the "in" comparison operator So

if ("fred" in myobject) {...}
becomes
if (myobject.hasOwnProperty("fred")) {....}

Talking of gotcha's I spent quite a long time getting the manual to work in IE. My little extjs tricks noted that comma's are a bit of a nightmare in IE, in that It doesnt like trailing comma's in lists of object properties. As typical with any Microsoft product, this is totally inconsistant with the behaviour for arrays, in which case it quite happily accepts trailing commans. Not only does it accept them,� it adds an undefined element on the end of the array... - which broke my method list horribly in IE.

Otherwise getting it to work in IE basically consisted of using Ext.DomQuery rather than trying to use standard DOM calls which never seem to work as expected. Anyway comment away...