SwfMillEditor, the "break-apart"

After prototyping a single file with XML & hscript, i started creating proper classes for the different elements of the frontend application.

Currently, most of the work revolves the source editor, which is shown in the screenshot below.

When prototyping, the source editor was a simple window with an "onLoaded" action, that placed a textfield in it, made sure to resize it when needed, and maybe had a few other lines...

That code was replaced by a single line, instead of a window, an XmlEditor class, its imported into the main application, and sits in its own file, XmlEditor.hx, as something like:

class XmlEditor extends Window {
...
public static var layoutXml = Xml.parse('
// here comes its xml layout...
...').firstElement();

public function highlight() {...}
public function updateTree() {...}
...
}

This allowed much better writing, with the full power of haxe driving the bigger logic and small scripts handling the smaller, this is where it left its prototyping stage, and some of its features now are:

• Llightning-fast highlighting with regular expressions
• Tab\Shift-Tab indentation (with visual marks too)
• Auto-close of opened tags
• xsltproc can be called with indent.xsl to format the source
• XML is parsed to a tree to provide a document outline (still slow as hell though...)
• Attributes and values of the active tag (the one which contains the caret) are displayed in a list.

Second screenshot, shows the FileDialog class, tree is filled with directories, and the lists are filled with files and their stats, all data arrives via the neko backend, this should make it simpler to browse virtual filesystems too, like those that actually sit inside a remote database or in memory...

Checkout the shots below, and stay tuned for more, gershon.

P.S: sorry for the mis-spell on the note in the first screenshot, too late&lazy to fix it ;)

haxegui Ohloh page

Spawned by a webcraweler, https://www.ohloh.net/p/haxegui, is a nice page, somewhere between this overly-flash-embedded blog and the plain googlecode page... Its statistics complain, as i have before, that

Over the past twelve months, only 3 developers contributed new code to haxegui, making this a relatively small project.

Well, by no means can the codebase be considered small, and its getting bigger, approximately 20k of haxe code, with about 500k more backing it up in XML data and HTML docs, Considering its capabilities, that ain't bad at all... Please consider using, contributing, asking and commenting, here, on the new ohloh page, on the haxe mailing-list or in #haxe on irc, your support can mean a lot, a good comment's worth 1k line of code ;) In an effort to enlarge the number code contributers, i have been writing more text, the GC wiki has a number of tutorials on some basic haxegui components, soon i'll start writing task-specific tutorials ("real world" practical examples, custom components, skinning tutorials...) Off to do some coding....

Step Sequencer Demo

Another sample of the great look and power of the haxegui framework, this time, a step sequencer for flash9 in under 500 lines, still WIP, and requires some fixing and optimizing. Has been hacked up over the weekend, uses mp3 samples, has a nice FFT spectrum, individual channel volume and pan, no note velocities and patterns yet sorry...

The code is on svn as usual (single file, samples/Example4.xml), no "haxe" has been used when writing this, just XML and hscript, on top of the usual haxegui application skeleton. This means there was very little compilation to do while writing this, still the app takes a few seconds to boot, so please be patient.

I would love feedback on this post, but hate it if it came from my stereo... ;)

Prototyping the SwfMill Editor

Its been a great companion, and i just love it. How can you not love a program that takes 'simple' as an argument?

For me its been the simplest, whether i compile with MTASC and inject the logic into a swf containing assets linked to as2 classes, or add assets into haXe made swfs compiled to as3.

Its a small and wonderful tool, that integrated well into my workflow, saving me not only time, but also from the jaws of proprietary software...

But for a while now, i've been toying around with the thought of making it even simpler using a frontend. The screenshoot below shows that thought transformed to working code, you can see the application editing the very same files that have been embedded when creating it.

The details of what it does, and does'nt yet, are already annotated in the screenshot, i'll just add a word or two about its prototyping process. It took only a couple of hours to generate this little app, some of which involved fixing stuff in the framework, which takes longer and requires compilation in haxe, layouting and simple events are done in xml and only require a browser refresh. Other than the haxegui package, there are 3 files involved. First one is a xml file for the layout and some simple events, second is a hx file that is compiled to a flash9 target, it has a single class and static main function, it initializes haxegui, loads the layout and works the logic, like parsing xml and setting up event listeners. The 3rd file is also a single class hx, it compiles to neko, and is a server for files and for swfmill input and output. The whole thing is run in two stages, first i run a local neko daemon, using 'nekotools server', then i navigate to the server address to land in a 'index.html' page which embeds the swf.

No paid software, knowledge or service has been used to write, run and bring you this, i would love to have your ideas and comments on this one, a working demo and the code should be released soon...

Small online tutorial

Here's a little interactive tutorial, the black window in swf below is the Console class, its got one textfield which traces results, and another (the lighter, single-line input at the bottom) which parses hscript. Type the following code in the console, type 'help' to see a list of other commands:

new haxegui.Window().init();
// window name might vary here, can type 'ls' to make sure
cd Window19
// following is written in a single line to preserve the scope
var c = new haxegui.containers.Container(this); c.init();
// following also might differ at runtime
cd Container29
//
var tf = new flash.text.TextField(); this.addChild(tf);
this.firstChild().text="hello world"

ok now for something more fun:

cd ..
// should be back in root.Window19
this.updatePositionTween(new feffects.Tween(0,1,1000), new flash.geom.Point(200,200))

Update:

Here's a screencast of me following the tutorial, then loading an example layout from the svn and playing with it a little, please excuse the jittery mouse tracking...

jEdit and haXe

For a while now, i've been using GtkSourceView-based applications for writing (Geany&Gedit), but decided to move back to the old trusty friend. I must admit that i'm a newbie to java, my previous uses for jEdit were mainly as2 and php, this time its haxe and java.

There's a haxe mode for jEdit here, which does the highlighting, my intention is to write a proper haxe plugin for jedit, one which will install the mode above, add a haxe menu for easy access, options dialog for configuring general haxe stuff like paths, classpaths and the likes, sidekick integration, project integration, text completion, import tools and documentaion launchers.

I have'nt much thus far, but i'd like to share what i do.

Installing the console & errorlist plugins, you get a single click reference to the line on compilation error, and works for haxe\ant(i'm using anthx)\make\swfmill.

Installing the sidekick plugin, outline plugin, ctags plugin, and custom folds, will get you a couple of nice views on the sidebar.

So for a typical function that looks like this:

//{{{ doSomething
/** This function does something **/
public function doSomething() : Void {
trace("Done.")'
}
//}}}

I get 2 folds, one for the expilict fold (line #1), which opens up the comment and the function header, the second opens the function's body (#3). If 2 clicks seem much to get to the body, not to worry, keyboard shortcuts are a-plenty in jEdit, alt-enter and alt-bs will collapse and expand folds...

This needs a lot of cleanup, but basically works for the ctags plugins (place this at ~/.ctags on linux):

--langdef=haxe
--langmap=haxe:.hx

--regex-haxe=/^[ \t]*[import ]+[ \t]+([A-Za-z0-9_.]+)[ \t]*/\1 /F,import, imports/
--regex-haxe=/^[ \t]*[(enum) ( \t)]+ [ \t]+([A-Za-z0-9_.]+)[ \t]*\(/\1 /e,enum, enumerators/
--regex-haxe=/^[ \t]*[(typedef) ( \t)]+ [ \t]+([A-Za-z0-9_]+)[ \t]*\(/\1 /t,typedef, typedefs/
--regex-haXe=/^[ \t]*(private|public|static|inline) *[ \t]+var[ \t]+([A-Za-z0-9_]+)[ \t]*/\2 : \1/v,variable, variables/
--regex-haXe=/^[ \t]*(private|public|static|override) *[ \t]*function[ \t]+([A-Za-z0-9_]+)[ \t]*\(+([A-Za-z0-9_]+)*\)*/\1 \2 (\3)/f,function, functions/
--regex-haXe=/^[ \t]*[(class|interface) ( \t)]+([A-Za-z0-9_]+)+([ \t]?)(extends|implements)[ \t]+([A-Za-z0-9_]+)+[ \t]*/\1 \2 /c,class, classes/

The project viewer, buffer tabs, tasklist, svn, jdiff (uses the built-in splitting), whitespace, textautocomplete and textutils plugins are also great and must have.

Even with all these plugins loaded, the editor is very light compared to its java friends (eclipse and netbeans) both in size and resource usage.

Here are a couple of screenshots, to stop me yapping. have a great day!

Call for devs

About a month has past since the birth of this blog, 2 for the googlecode repository, and total of 3 for the whole project.

Since its my opinion that no self-respecting developer should put up a project like this online, without utilizing all of the resources available to him, i've been tracking these pages with analytics.

The score is 800 to 2, there's support, i'll grant that. A couple of devs on the mailing-list, and a few around #haxe, but in the code you'll still find only two names.

So this is a call to anyone doing anything gui-oriented in haxe, to chip in.

How about this for an interesting challenge, haxegui on the iphone via haxe cpp and nme\neash?

Some haxegui applications? an icon editor, map editor for tile-based games, sprite sheet editor with bitmap, swf and swfmill input\output, mp3 sample editor for trimming and looping, pattern & multi-track sequencers, image orgranisers, chat and im clients...

Or how about a haxe ide in haxe? regexing and highlighting, with dot completion, the hscript console, system shell, and a haxegui builder?

Hmm... ok, so seems like anyone doing anything haxe is welcome ;)

See you around, gershon.

A* First Test

So i started playing around, trying to implement A* into haxegui (AStar is a shortest-path finding algorithm, look here for probably the easiest tutorial about it), the good news are that sitnarf already wrote aPath is its easily imported and very generic, just give it a grid, mark the nodes and you're good to go. Bad news are that the benchmarks don't look that good, see the video below.

The drawing code does slow things down, but i had to visualize it somehow :) Here's a snippet, all this is done before the path calculation:

var container = this.getParentContainer();
container.redraw();

var s = Haxegui.gridSpacing;
var hs = s>>1;

var w = (container.box.width/s);
var h = (container.box.height/s);

var engine = new aPath.Engine();
engine.generateMap(w,h);

for(i in 0...w)
 for(j in 0...h) {
   // get top-most object
   var o = container.getObjectsUnderPoint(new flash.geom.Point(hs+i*s, hs+j*s)).pop();

   // mark it unwalkable if its a widget
   if(o!=container && !Std.is(o, toys.Socket) ) {
container.graphics.beginFill(Color.BLUE, .5);
container.graphics.drawRect(i*s, j*s, s, s);
container.graphics.endFill();

engine.map[i][j].close = true;
    }
   ...
   ...

Seen on the video, a 10x10px grid takes more than 3.5sec to be marked (this includes drawing "unwalkable" blue tiles, which is expensive, it takes about 0.55sec without, still not fast enough) I guess the most expensive is the getObjectsUnderPoint() but i'll need better profiling to be sure... The next step would be to get the target node, before doing all this, so i could minimize the gridded area to be checked. Any A*\haXe tips and optimizations will be more than welcome, have a great weekend!

Signal \ Slot experiments

A Short screencast showing how widgets can be visually connected, i've always liked node-based or "graphical programming" software like PureData, it allows even non-programmers an easy entry point, and saves time typing, besides the obvious eye-candy. Next step would either be the A* algorithm, so "patch cables" would go around widgets, or maybe use curves and drop-shadows to fake them being "on-top" (check this link for a cool sample)

Couple of changes

Changed the logo on the blog, started working on better documentation (the doc system itself and the commenting in the source) check the link above, its full of goodies! please leave any comments and have a great day!

Comparision of coding styles

this link has a tutorial for writing an analog clock in actionscript. I've ported it to haxe using two coding styles, one is pure haxe, the other in xml&hscript, to show you they are equally powerful, and the choice is completely yours. two things to note, clocks start ticking once loaded, from the time of creation, so the xml has the initialization offset of the all the xml parsing, its not a bug, as they could represent different time-zones. Secons, is that had this not been a demonstration, i would have probably gone with a 3rd hybrid coding style, using hscript in the haxe .hx file, instead of multiple classes...

haxegui screencast on youtube

Screencast of an earlier version

haxegui SVN

this is how the current svn looks like: press "`" (Backtick) to pop up the console. more info can be found at http://code.google.com/p/haxegui/ please comment below, have fun!