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

View Extended Entry

Posted by in Gtk | Add / View Comments()

Other than Enums which are now created and available in Javascript, I've tidied up the generation code quite a bit, so static methods are generated correctly. Less brute force generation is used, and made a start on the documentation generation.

So now most of the donkey work of the bindings are done, it's down to the last 20% (the long tail from what I've been reading recently). Something like the main developer[s] get's 80% of the project done, but since there's always those little niggly things that dont work it takes 1000's of developers to fix the last 20%... - interesting statistic, which explains why it's such a pain fixing all those bugs that crop up..

Anyway The GtkDjavascript Manual has been born.. While again not quite ready for production, (It desperately needs user comments, Enums, Signals ,hrefs linking all together and many other things.). I think it's a step in the right direction.

The navbar, and the XML method descriptions are generated from the code generation script. (The main body is a nice example of extjs - and should be portable to gtkdjs eventually) -

The biggest bug on the docs is that stuff that is manually overriden (eg. Gtk.init()) is flagged as broken in the manual. as I've not added any code to add the fact I've overridden it to the manual docs..

Anyway.. ticking along nicely.. now I wonder how much use it is....

View Extended Entry

Posted by in Javascript | Add / View Comments()

I'm still digging through the gtk api, checking it works as I go. (and still deciding on a name for the bindings). I've been looking at perhaps one of the two most complex widgets in Gtk, GtkTreeView. The tutorial for which looks like it weighs in at half the Full Gtk manual.

At present I've got through the first section, and got a roughed out GtkListStore to work with it. (TreeStore should come next).

For those who dont know GtkTreeView, it uses the concept of a Model, and a View.

The Model contains all the data (in rows or a tree) - GtkListStore is a model.

The View (eg. GtkTreeView and it's columns) describe how to render the view, and what columns to use from the model.

This API is pretty raw at present, Some of it can be tidied up in Javascript, others may need more work in the bindings

First part of using the tree is creating the Store.

var store = new Gtk.ListStore(
    "gchararray", 
    "gfloat",
    "gpointer",
    "gboolean",
    "GdkPixbuf");

At present I've used the Gtype names to define what is being stored where. - This may need simplifying, and integrating somehow with the writing mechanism as validating data types written to the tree is a bit haphazard at present.

Next, to add data, you must use what I think is the worst named Class in Gtk, Gtk.TreeIter. a better name would have probably been something like  GtkRowReaderAndWriter (bit of a mouthfull, but alot clearer.)

To use this Row reader/writer, we first have to create a blank version. Then call the append Method on the store (a bit ass backwards, but again this could be fixed with some Javascript prototype modifications.

var iter = new Gtk.TreeIter();
store.append(iter);

The append method loads the Row reader writer, so that it can access the new row.

Next we add data to the row. This is done via G.Values at present, although this may change in the future...

store.set(iter, 0, new G.Value("test"));
store.set(iter, 1, new G.Value(1.0));
store.set(iter, 2, new G.Value({ a: 1, c: 2})); 
store.set(iter, 3, new G.Value(true) ); 
var pixbuf = Gdk.Pixbuf.newFromFile("gnome-logo-icon.png");
store.set(iter, 4, new G.Value(pixbuf) ); 

all this could easily be abstracted by defining a simple prototype

Gtk.ListStore.prototype.appendRow = function(rdata) {
	var iter = new Gtk.TreeIter();
	this.append(iter);
	for(var i =0;i<rdata.length;i++) {
		this.set(iter,i, new G.Value(rdata[i]));
	}
}
.....
store.appendRow(["test", 1.0, {a: 1}, true, Gtk.Pixbuf.newFromFile(....)]);

Next step is to build the Widget. And the renderers (the classes that turn the data into visable data). Gtk comes with a few renderers, It will be interesting to see if creating them in Javascript is feasible.

var view = new Gtk.TreeView();
var renderer = new Gtk.CellRendererText ();
var pixrenderer = new Gtk.CellRendererPixbuf ();

Adding columns is again a little raw, as we cant use the varargs methods the C does, so we have to combine a few calls.

var col = new Gtk.TreeViewColumn();
col.setTitle("Name");
col.packStart(renderer, true);
col.addAttribute(renderer, "text", 0);
view.insertColumn( col, -1);

Again a nice wrapper could be written.

Gtk.TreeView.prototype.insertColumnAuto = function(config) {
	var col = new Gtk.TreeViewColumn();
	col.setTitle(config.title);
	col.packStart(config.renderer, true);
	col.addAttribute(config.renderer, 
		config.renderer.isPrototypeOf(GtkCellRenderText) ?
		 "text" : "pixbuf", 0);
	this.insertColumn( col, -1);
}
...
view.insertColumnAuto({
	title: "text here",
	renderer: new GtkCellRendererText(),
}

Merging the data and the view is done simply by setting the model.

view.setModel ( store );
window.add(view); // add it to a GtkWindow..
window.showAll();
Gtk.main();

I also had a few experiments with callbacks.

view.connect("row-activated", function(view, path, col) {
	var model = view.getModel();
	var iter = new Gtk.TreeIter();
	
	if (model.getIter(iter, path)) {
		var name = new G.Value();
		var name2 = new G.Value();
		model.getValue(iter, 0, name);
		model.getValue(iter, 1, name2);
		println (
			"The row containing the name '"+
			name.getString() + 
			"' has been double-clicked. holding" + 
			name2.getFloat()	
		);
		model = new Gtk.ListStore(model);
		model.remove(iter);
		println ("removed?");
	}
	
	
});

At present this is a little klunky, but again with some prototype modifications it should be pretty easy to solve.
Fetching values has to be done by creating an empty G.Value, them fetching and converting them.

The last line illustrates removing a line. - since we cant cast in Javascript, I've modified the ListStore constructor to accept either a list of strings (eg. creating it) or a store object which does effectively the same as casting.. enabling you to call the remove method on GtkListStore.

Anyway back to fighting fires with real work today...

View Extended Entry

Posted by in Javascript | Add / View Comments()

As I dig away at the Gtk wrappings, I'm testing the ideas that should make the bindings interesting.

One of the ideas is that extending core Gtk Objects should enable easier usage. I started with the basics of interface design, Making a Menubar as  simple as possible to build, and bind..

var menuBar = new Gtk.MenuBar.quick([
	new Gtk.MenuItem.quick("File" , function () {
		println("File");
	}),
	new Gtk.MenuItem.quick("Edit" , function () {
		println("Edit");
	}),
	new Gtk.MenuItem.quick("Search" , function () {
		println("Search");
	})
]);

In the above example, I've created an extended class Gtk.MenuItem.quick, and Gtk.MenuBar.quick (it could just be Ext.MenuBar / Ext.MenuItem...) - Just adding it to the Gtk.Menubar Class namespace seemed clever at the time.

As you can see, creating the menu, along with adding the handlers is very simple. - I could even use a standard Javascript object as the constructor (even more like ExtJs): eg.

new Gtk.MenuItem.quick({
	title: "Search" ,
	icon:  Gtk.Stock.SEARCH, // this doesnt work yet!
	handler: function () {
		println("Search");
	}
})

This morphing of the Gtk bindings is all done in the Javascript code,

Gtk.MenuItem.quick = function(label, activate) {
	Gtk.MenuItem.quick.superclass.constructor.call(this,label);
	this.connect("activate", activate);
}	
Ext.extend(Gtk.MenuItem.quick, Gtk.MenuItem,  {});


Gtk.MenuBar.quick = function(ar)
{
	Gtk.MenuBar.quick.superclass.constructor.call(this,label);
	for (var i in ar) {
		this.append(ar[i]);
	}
}

Ext.extend(Gtk.MenuBar.quick , Gtk.MenuBar,  {});

(using snippets of code from Extjs) to implement the extending.

On the backend however, I had to make a few changes to dmdscript, both the DObject definition (which is the class that handles Javascript objects in the script engine). Noteably adding generic support for bound void*'s to all Javascript objects. (so binding things like curl, mysql, sqlite etc. should be considerably easier..)

Along with this, dmdscript as available from digitalmars did not support  the {function}.call(this, args) syntax, a stub was there, and it was pretty simple to add.

Anyway the next big challange is understanding GtkTreeView, GtkTreeModel and GtkTreeIter so that building Trees can be made  more Javascript (and Extjs) like..

View Extended Entry

Posted by in Javascript | Add / View Comments()

Signals for the most part are working. I went with the GTK'ish style, rather than the more JS style, eg.

var a = new Gtk.Window(0);
a.connect("delete", function() { Gtk.exit(1); });

That's not to say that it's not trivial to use a more javascript style = in the client side!!!!

Gtk.Widget.prototype.on = function (sig, call) { return this.connect(sig,call); }

There is still quite a bit todo, especially around the more complex widget's like textview, tree and lists. but I suspect the majority of the main widgets should just work.

I'm kind of wondering If I'm announcing this to the wrong audience though, as I dont really get any sense of excitement. I have this wierd vision that GTK and Javascript could be a leap forward in application development. Having written a couple of projects both in scripted and compiled languages, The whole save/[compile]/run/test loop can get very slow, especially as the application grows.

The idea, that to edit the toolbar, and it's behaviour, I would pull up the debugger/editor in the running application (That it'self would be written in gtkjs). Navigate in the tree of objects (AKA Firebug DOM inspector) to the class definition or prototype for the menu. - click edit - bring up a scintilla or GtkSourceView editor, edit the code.. save it.. (editor both saves to disk overwriting the specific code that it needs to), along with compiling and altering the in-memory method - Then type something in the debug command line to for the refresh of the menu... - Or even have the editor know that saving that function would need some js run to test it.. - and it affecting the running application - changing the behavior and look!.

Not only that, the program would not crash, only output to the debug console any unhandled exceptions... - (with line/file/method etc.)

I'm just in awe of the concept of adding a small feature or fixing a bug would by so mind blowingly simple, that you would lower the barriers even further to make more of your users your development team..

Then again other days I wonder if I've been doing to many of those drugs....

View Extended Entry

Posted by in Javascript | Add / View Comments()

My last entry described how to create objects for dmdscript, I made a brief comment, that gtk javascript might be quite cool.. Well after a bit of hacking I got hello world to work. (well and a bit more..)

Gtk.init();

var w  = new Gtk.Window(0);
w.setTitle("hello world");
w.showAll();
Gtk.main();

run with

/tmp/gtkjs hello.ds

I started with the GtkD bindings code generator, and extracted out the HTML parser code (it parses the HTML API docs). The based on the code from the last post, and some of the ideas from GtkD generated all the classes for dmdscript.

At present:

• 317 Classes, Including Atk, Glib, Gobject, gthread, gdk, gdkpixbuf, glade gtk and pango
• 2554 Methods should be working.

What's left to do..

• Signals - I've got a prototype working for this, so It's mostly a matter of  writing the generation code.
• Enums - They are in the D code, but no exported to the Javascript side.
• Argument checking.. - Should be pretty trivial to add..
• Return checking.. again pretty trivial..
• Custom code for non-generated methods, Structs etc.
• Tiding up the APILookup files. - - they are pretty similar to the GtkD code at present, and my generator just ignores alot of them.
• Lots of code tidy ups.. (the class registration is a bit of a brute force hack)
  

If you want to try it out... (developers only.. dont expect to write applications with it yet.)

svn co http://www.akbkhome.com/svn/gtkDS
cd gtkDS/wrap
#download API Files (needs curl / tar etc.)
sh downloadFiles.sh
#compile it - needs dmd installed..
sh buildit.sh
cd ..
#build the bindings - requires compd from dsource.org/projects/dool
compd gdkds.compd
/tmp/gtkjs test/hello.ds

Now I just wonder what use it is ;)

View Extended Entry

Posted by in Javascript | Add / View Comments()

Having spent the last few weeks working with ExtJs, I'm been drinking quite a bit of Javascript Coolaid. (Actually being british, I never understood that phase, but I guess most people understand it these days.)

Doing all this a while back led me to investigate General Javascript engines, I had this weird vision that Javascript and Gtk may make an interesting combination.

As I mentioned in my last post about testing code the whole write-save-(compile)-run-test would in an ideal world be reduced to write-save-test. And since very few languages actually allow you to redefine objects, object methods, functions etc after you have actually run the application (without weird add-on etc), Javascript is pretty interesting in this area.

Anyway there are quite a few EMCAscript engines out there, most of them in C, and a few in other Bytecode or even scripting languages. But only one that is written in that new little magical language D!...

dmdscript, (also on dsource as walnut with a few hacks and the start of a new version), Has some serious benefits over all the other implementations.

- The source code is clear, readable, and not cluttered with memory allocation crap.
- It's fast
- It's small = small again making it easier to understand
- It's free of any major dependancies (apart from the compiler.. dmd or gdc )
- Writing extensions is (at least in theory) simple, and not full with learning about crazy cryptic macro's or custom memory allocation stuff (sound like anyone's favourite language?)

The only downside... - Dont expect alot of support, It looks like the project is one of Walter's little whims, that he lost interest in a bit. And licence-wise I'm not sure if GPL is the perfect licence for the project.. - but that's just a gut feeling, I'm far from a Licencing expert, but I suspect using it as a add-on for another project that is not GPL would be difficult. And I'm not sure how adding LGPL to a GPL application works either... Anyway..

I had a small amount of free time at the end of last week, Just having nailed the last few bugs in a project. So I thought I'd investigate dmdscript extensions on the pre-cursor to looking at modifying the GtkD bindings generator to create the dmdscript bindings...

First stage investigation, gave a little bit of imformation from the dmdscript site, along with a short note on the dsource Walnut project subversion server. But unfortunatly It's not really enough to get you started, and there are now 'Step by step' instructions on writing extensions, or adding Objects.

So here's my step by step guide to adding an object with methods to dmdscript... - in the extended entry..

View Extended Entry

Posted by in Javascript | Add / View Comments()

I thought I'd go some of my random thoughts of working with extjs, as creating quite large applicaitons with extjs is quite new, and as the projects I've used it on have been refactored a few times, I'm beginning to develop approaches that make code more maintainable, and faster to develop.

This is quite a big post - so the contents in the Extended body....

View Extended Entry

Posted by in Javascript | Add / View Comments()

When you spend a large proportion of your day working on internet applications, and a considerable amount of that time working around annoying browser bugs (IE and Safari win here). You do it out a sense of pride, that you are delivering the best possible product. Solving these problems is a mater of personal pride that I produced the best possible end user experience.

So when I see site that is not only mindbogglingly broken, but has been developed by large corporations with relatively unlimited budgets (well compared to most of mine anyway). It just really makes me wonder how such under qualified moron's managed to get such high paying jobs......

Here's my list of shame.

1. HSBC a) for taking years to realize that intra bank transfers where a phisher's dream, b) waiting until the government mandated two tier authentication and finally when they deploy it. Being so broken that it takes over 5 minutes to get through the authentication system. What is even worse, is the lack of acknowledgment that they have a problem.

2. EsdLife, our governments outsourced 'e' website. Run by a company owned by the largest tycoon in Hong Kong. Which initially only supported IE on Windows, (allegedly), and for what must be now, 5 years, Has never worked once for me. not even for simple things like setting up a e-password to file tax returns or booking tickets for tennis courts.

3. Verified by Visa, or better know as unverified by JavaScript errors. This site not only has numerous JavaScript bugs, but does not correctly identify mozilla compatible browsers. No you should not use the browser name for compatibility testing.

All of these have one thing in common. Huge amounts of money spend on a web site, by a large organization. Which needs only to do a relatively simple task (read "It's just HTML stupid"). Yet manages to complicate it to the point that it makes the sites almost completely useless...

Know of any other great examples. It's just a shame we cant name the project manager's names and shame them into fixing these problems.

View Extended Entry

Posted by in Hong Kong | Add / View Comments()

Having just completed one project with extjs, (otherwise known as yui-ext). I thought I would share my thoughts on it.

As a side project, if you liked FlexySvn, my little XUL based Subversion browser, I started playing with a Javascript only version (A single HTML page - no Server / PHP support required):
http://www.akbkhome.com/FlexySvn/templates/test1.html (Firefox only seems to work at present - although I would guess IE fixes should not be to difficult).

This uses XmlHttpRequest's to do roughly the same things that 'svn ls/log/cat' etc. do. - (Done by snooping the packets with Wireshark.). Using Extjs for the interface, and dp.SyntaxHighlighter to do all the syntax highlighting.

This little test does illustrate the key differences between XUL and the Extjs approach.

Ext js advantages/disadvantages

• In-page popups are faster than desktop popups - leading to a snappier interface. (not seen in my svn browser, but a serious issue for other applications)
  
• Interface 'can' work on other browsers, although doing anything complex tends to end up with considerable time taken dealing with IE or Safari bugs.
• Load times are problematic (even stripped down libraries can be a high load if you are offering just a simple form with validation).
• Difficult to see how to have a page degrade nicely for non-js browser - eg. mobile devices.
• extjs bugs tend to be browser specific bugs, and often with things like Safari, which can be exteremly time consuming to fix.
• Defining CSS styles for OL/UL/BODY etc. in the standard css file makes it a bit of a nightmare to work with existing HTML designs.
  

XUL development advantages/disadvantages.

• Single platform make debugging and testing considerably simpler (if it runs in Firefox, it will run everywhere.)
• Interface as XML has a more natural feel to it -  considerably simpler to spot and fix a  layout issue, rather than decyphering a large number of javascript statements.
  
• The approach we used where XUL is served up by PHP, and using frames/pages to react to different sections of the application, make inter-section communication more complex. Compared to a pretty much 'one-page' approach with extjs, which makes managing state considerably simpler.
• Difficult to mix HTML and XUL, using namespaces is klunky, normally we need to use <HTML:everything in here is HTML!>....</HTML> rather than having to ensure we are using XHTML and the namespace.
• bugs tend to be either browser related or security related. - modal dialogs comes to mind...

I have to say that Firebug has been a life saver for the projects I've been doing these last few weeks, and has overtaken the webdeveloper extension at the top of the list of essential extensions.

At the end of the day, When we start a new project that needs an administration system, (non-public), Neither of them offer a perfect solution yet. But I think XUL comes out marginally ahead, given the reduced time spend debugging non-mozilla browsers. (Although the modal windows and popup load times is a serious problem)

For a public front end, I think after some consideration, I will still recommend extjs except where support is needed for mobile devices. And Just hope that I dont get too caught out by IE and Safari's bugs.

View Extended Entry

Posted by in Javascript | Add / View Comments()