Genetic Algorithms and Mona Lisa

Genetic Algorithms try to apply evolution mechanisms to find solutions to hard problems (typically, where no "proper" solution is known and where the search area is large).

Roger Alsing posted a couple of days ago an extremely cool article showing the convergence of 50 polygons to represent the Mona Lisa, using a random approach.

That was too cool to not try to implement it :)

The screenshot shows a rendering of the Mona Lisa using 50 polygons (16 points each), after 40818 total iterations, with 4577 elected states; the middle image is the original (i.e. the target) and the right image the difference between the current polygon-based image and the target (i.e. a representation of the fitness function).
Underneath was an earlier attempt using ovals instead of polygons.

Now, to be more exact, Roger Alsing's algo is more a hill climber algorithm or possibly a simulated annealing algorithm than a good example of a genetic algorithm; it should be interesting to actually implement a proper genetic algorithm approach (i.e. a population > 1) and see how the convergence rate compares... combining polygons and ovals might also result into interesting things.

Iliad iRex note taking and hand-writing recognition

I recently bought an Iliad iRex, a pretty awesome eBook reader. Among the cool features, it's running linux, an sdk is available, and it's really easy to hack stuff for it (for instance I wrote a simple script for downloading the 24h edition of The Guardian). Also, as shown with the previous link, the community is quite active :)

Just a couple of words about the iliad itself... the hardware is pretty awesome, with wifi, ethernet, wacom tablet, usb, mmc card and compactflash, audio jack...
the e-ink display is quite amazing too -- 768x1024 makes it precise enough to be able to read A4 PDF without too much problem (a great thing to review lots of research papers, believe me !).

The software side on the other hand... is a bit disappointing. Don't get me wrong: it's good enough, and some aspects are pretty cool. But you really unlock the possibilities of the devices by getting the root access and adding applications developed by the community (notably, the PDF viewer hacked by the community is fantastic, with gestures, etc.). Which means it's fine if you are a geek and not afraid to hack your device, but more annoying for your average consumer :-/
The other disappointing aspect is the (comparatively) low battery life: about 12-15 hours depending on the model (mine is a v1, the v2 do better), which is mostly caused by the fact that no sleep mode is available. Other eBook readers perform much better on that metric. To be fair they don't have wifi nor a wacom tablet :D ... so it's really a matter of choice.

All in all, it's a bit of a shame as really the platform is very nice, and with a bit more effort on the software side, Iliad would have a killer product on their hands. Oh, and yes the e-ink display refresh rate is slow, but curiously it's not that annoying, and having its full library in such small factor is absolutely fantastic.

Anyway... one of the really, really cool feature of the iliad is the presence of a stylus (i.e. the iliad display sports a wacom tablet), which allows you to annotate PDFs, take notes, etc.

I started to experiment a bit with the note taking feature of the iliad; the idea is that you can open a PNG image in the notes folder, and a copy will automatically be made where you can write on it (the image is being used as a background, so it's trivial to have customized backgrounds). But I then wanted to generate a PDF from those notes (i.e. combining the scribbles+PNG).

Iliad do provide a windows application to do all that, but it's a windows app, not really useful for me... there is a nice java application written by the community that allows merging scribbles with the PDF as well. Alas, the java scribble merging application only seems to work for PDF scribble; I guess it would be trivial to modify the java app, but I had a look at the xml scribbling format, and I saw that the format was really simple.

So I quickly wrote myself a MacOSX viewer for the notes, using the png image as a background, letting me print notes easily or convert them to PDF.

But then... I suddenly remembered the Ink handwriting recognition engine.

This thing comes straight from the ill-fated Apple Newton PDA (such a loss!), but what is nice is that it is available and installed by default on OSX.

Turns out it's not too difficult to feed Ink a set of custom datapoints, and after some tweaking it doesn't work too bad apparently, as can be seen on the screenshot...

So far, this is only highly experimental code, and it'll probably take a bit more time to have a really usable application. Still, pretty cool!

AlpenStep '07

I was at AlpenStep this weekend, you can check some pictures.

It was a very cool event, thanks in particular to gerold's organisation. The location, in a small swiss village, was really nice -- I can say that some fresh air after beeing in london is good !

It was also a small-scale event -- only 7 persons (though gurkan came but left saturday before lunch :-/), which made it a very intensive event as well: lots of discussion, lots of coding too. Fred Kiefer was probably the busiest person in the room, as everybody wanted to ask him questions/advices... ;-)

Riccardo Mottola gave a nice GAP demonstration, and during the weekend he and Nikolaus Schaller were busy working on SimpleWebKit:

Nikolaus also made a cool presentation of QuantumSTEP running on the OpenMoko platform :)

The OpenMoko device is actually fairly nice, very high-res screen, and some interesting hardware to tinker with.

Quentin was working on ContainerKit for Etoile, a very interesting way of specifying UI using a generic data model (so you can switch representations on the fly for instance), also allowing very nice introspection features with inspectors generated on the fly. I tried to convaince him to introduce some Magritte-like magic, i.e. adding metadatas to your model...

Quentin and I also made a presention of Etoile, describing the various components/frameworks/applications, and how everything is supposed to fit...

Finally, I can only be admirative of gerold organisation skills... to the point were he got us a GNUstep cake:

Which was delicious !

In short, looking forward for AlpenStep'08 ! (and Fosdem'08 before...)

Cairo/GNUstep

I was at AlpenStep this weekend (photos will follow..) which was quite cool. I teamed with Fred Kiefer (the GNUstep gui maintainer) to try to iron out some of the quirks of the Cairo backend. The main problem (recopy of surfaces is not always done well, which impact scrolling) is still here, although we improved some things, and it looks now like it should be solvable with a bit more work. We also added 32 bit surface support when choosing x11 visuals : a cool side-effect is that you can then use directly the alpha channel on the window :) and thus draw semi-transparent windows.

David will like that ;-) -- he's working at the moment on Etoile's compositing manager...

In the above screenshot, I simply fill the view with NSCompositeClear (so it's just transparent), and then composite an image on it, with 0.8 transparency. You can then see that parts of the window are fully solid, while some are completely transparent, and others partially transparent.

Hard Disk Crash

...You know when people tell you to do backups ? Feeling guilty ? :-)

Well, most of my data is usually backed up, but... even so, there's still a lag usually, particularly for "not-so-important data", etc. Add to this usual mix some data put away "temporarily" from my main computer... and that's when my LaCie 250Gb external drive choose to die. Around 200Gb of data lost, among them some that I could get back with various difficulty somewhere else, eg on some dvd or other computers (the LaCie *was* the main/more used backup plan), and some truly lost (yes, this "temporarily moved" data, yes, it's you I'm talking about), or some data recently copied only on the LaCie... Of course this drive is around 3 years old, and I actually had some thoughts recently of doing a proper backup of everything there was on it, for convenience, and for fear of such an accident. Of course too, I ended up way too busy to actually do it...

Still, a bit of luck: there was no scratching noise, in fact, there wasn't any noise at all: the disk just didn't start, which meant that it was more likely an electronic fault than a mechanical one. Removing the hdd from the LaCie enclosure and plugging it directly on a computer didn't do anything either (so it sadly wasn't the LaCie controller board). So that left us with the actual hdd electronic board... I then looked on the web for an hdd from the same brand and the same model -- and found a cheap one from an online reseller. After receiving it, I checked it -- yes, it was the same model, yes, the same year, yes the same firmware... ah. No. not the same firmware ! well, still, only two months separated those drives, so I crossed my fingers and started removing the controlling board of the "new" drive to swap it with the one on my crashed drive. Never having done that, I wasn't quite sure what to expect :-) but it's in fact really straightforward (you just need the right kind of screwdrivers -- Torx). The only difficulty is in finding a control board that is compatible with your hdd!

To cut the story short, the "patched" drive started happily and worked fine, so I passed the day swapping and burning dvd of the drive's content ;-)

One thing for sure is that I will seriously think of building a proper backup solution (ie, automated/redundant) for hosting "home" data (photos, videos, music...) asap... I was lucky to save this drive ! these kind of content is annoying as they quickly take so much space, yet (for at least some of them) they are invaluable...

Fun with Objective-C

Following a mail from david on étoilé dev about how it could be nice to try allocating ObjC objects on the stack, I played with a couple of things...

First I wrote a mini benchmark -- get a very basic object (a couple of ivars, one method "plop" assigning a value to an ivar), and then create an instance, initialize it (call the init method), call the one method the object has, then deallocate the object. 10000000 times. As far as micro benchark goes this one is pretty stupid but well, that'll give us some ideas of what's going on.

Without optimizations: ~4.10s (on a macbook pro 2.16Ghz, core duo)

Not that great -- doing the same thing in C++ with a similar object here is the timings I get:

Objects created on the stack: 0.24s (17 times faster !)
Objects created on the heap: 1.37s (3 times faster)

Ouch, the poor Objective-C... not a surprise when allocating objects on the stack, but even allocating them on the heap C++ is still 3 times faster.

One obvious reason is that Objective-C calls a lot of methods when creating an object; and a method call is more costly than a C++ function call. Still...

So the obvious idea here is to cache some method calls (ask their address then call the function directly -- as a C function). I restrained myself to alloc/init, the method the object had ("plop"), and the release method. Of course, there's other methods that are called by those, that won't be cached.

Caching method calls: 2.77s

It's still twice as slow as creating the C++ object on the heap, but it's anyway a nice performance increase.

Ok, then our only option left is to allocate the Objective-C object on the stack. Surprise:

ObjC objects created on the stack: 0.23s
ObjC objects created on the stack + cached imps: 0.13s

:-)

[note of course that it's a stupid micro-benchmark that doesn't prove much, but it's fun]


...


What ? how can you allocate objective-c objects on the stack ? ah well... you can:

#define STACKCLASS(class) typedef struct { @defs(class) } \
    __CLASS_ON_STACK__ ## class;


#define STACKOBJECTISA(objectName,className,classIsa) \
    __CLASS_ON_STACK__ ## className __INSTANCE_ON_STACK__ ## objectName; \
    __INSTANCE_ON_STACK__ ## objectName.isa = classIsa; \
    className* objectName = (className*)& __INSTANCE_ON_STACK__ ## objectName;


#define STACKOBJECT(objectName,className) \
    STACKOBJECTISA(objectName,className,[className class]);

Here is an example:

STACKCLASS(Test);

int i;
for (i=0; i< 10000000; i++)
{
  STACKOBJECT(test,Test);
  [test init];
  [test plop];
}

Basically, create the corresponding struct for the class and set the isa member (you can also cache the class isa to gain one message send). A bit of a hack, but that seem to work ok :)

Note of course that by doing that, you loose flexibility -- exit class clusters for instance (eg classes that actually returns another class instance, such as NSNumber), you can only work with concrete classes. And also, don't call directly -dealloc as it would try to deallocate the object, which is not needed as it was created on the stack (so if you need to do some cleanup you should do it in another method).

Here's the macros I used for imp caching (fairly straightforward):

#define CALLIMP(imp,object,sel,args...) \
    (*imp)(object, @selector(sel) , ##args)
#define GETIMP(class,sel) [class methodForSelector: @selector(sel)];

You use them like that:

IMP imp1 = GETIMP(Test,alloc);
id p = [Test new];
IMP imp2 = GETIMP(p,init);
IMP imp3 = GETIMP(p,plop);
IMP imp4 = GETIMP(p,release);
[p release];

int i;
for (i=0; i< 10000000; i++)
{
   id test = CALLIMP (imp1, c, alloc);
   CALLIMP (imp2, test, init);
   CALLIMP (imp4, test, plop);
   CALLIMP (imp3, test, release);
}

e-book

I just read that article about the new Sony's e-book reader (from the osnews story). That made me think a bit about e-book.

I would love to have a "true" ebook. For what ? well, in my case, for reading technical documentation and research papers, possibly some websites. Another excellent usage would be to read newspapers and magazines, or research journals. Or if you are a student, another really obvious target are textbooks. And think about the manga/comics market.

Why would it be interesting to have an ebook for all that ? What's the pattern ? Simply, it's the volume: in all these use cases, you end up with lots of paper very easily (and in a short time frame), and having one device to gather everything would be nice.

But books ? books do not really have a volume problem -- most persons do not read or carry dozen of books at the same time, and the minor inconvenience to carry 2-3 books for a very long journey is not enough to warrant paying premium to have an ebook. Sure, if you have a device able to read pdf and newspapers, it can handles a book, so you'll have books too of course. Having your whole library in one device could be appealing to some too, I guess. But if the main advantage of an ebook reader is answering the "volume" problem, then it means books almost certainly shouldn't be the main target.

So if books aren't (or should not be) the real target, and if things like documentation, newspapers, textbooks are, what does it mean ? Well, it means your device should provide the same features you'd expect from paper when dealing with these. Specifically, you absolutely need annotation. But more than annotation, the device shouldn't be content to only be "as good as paper" -- if you want people to buy it, you need to be better. An obvious candidate feature (come on, we are talking about electronic documents) is to provide a much better way to manage your document collection. Things like searching, grouping, sorting, adding whatever annotation/metadata you want, do specific things that use these categories (like marking some documents, pages or text to be sent to somebody else via email, etc)...

Then, you will have something that people (and companies, and schools) might be interested in.

The screen technology is imho nearly irrelevant, as long as the battery life is good enough (~7-8 hours in continuous usage) and with a good enough resolution. While e-ink is extremely interesting and answers perfectly the battery/resolution problem, it's too slow for the moment (it's also black and white, not absolutely dramatic but something that reduce a bit its impact). Between an e-ink display and a high resolution lcd screen, even if the battery life would be much shorter on the device with the lcd screen, if it provides the kind of characteristics I described above, I will definitely choose it over the e-ink display, and I bet that many persons would do just the same.

Right now, the sony ebook looks more like a solution looking for a problem than anything else, and they focus their efforts on the wrong side (books).

They fail at everything I described above: it's slow to navigate, management of your documents seems inexistant, pdf aren't even there apparently (seriously!), no annotations... the only good thing (while not perfect) is the e-ink display, but they seem to think it's enough. It's not.

If I had money (and time) and more electronic skills I'd definitely want to create a good e-book device. Why not something based on gumstix + a high resolution lcd screen. There's a market waiting to be picked here.

edit: to be fair, checking the sony page they indicate that the device actually CAN read pdf and doc... But only after converting them to the proprietary format Sony uses. Crap ! :D (oh and it plays AAC and MP3 too)

Foundation

After some efforts, I had everything compiled -- ffcall, foundation, appkit, etc. for the nokia. But then my test program crashed :-)

Removing extra libs (hm.. ffcall.. :-/ ) I have something working though: Foundation !

[ note that I got the NXConstantString error, so it looks like library loading order matters (lobjc / lgnustep-base)... changing the ordering in the makefiles make it works though ]

Now.. I compiled gnustep-gui and gnustep-back, both with xlib and art. But the xlib backend crash (it can't find any available font on the nokia apparently..), and the art backend (after some efforts -- #ifdef XSHM to get rid of any XShm calls...) "nearly" works: with my test application (a simple info panel) it displays a window, but without any content (plain white), and complains about bad window... Yet it seems to receive events (I can click on the invisible buttons ;-) so it looks like some art display problem, perhaps just because the nokia uses a non conventional color ordering / depth.

Well I need to come back on ffcall and check if it's the culprit or not for the crashing thing -- having ffcall won't be bad for the gui :-) and try to understand what's wrong with backart... but all in all things progress ;-)

ah, I also did a very stupid mistake the other day, compiling gcc for arm-softfloat. Naively I thought you needed a soft fp implementation, as the arm doesn't have a hardware fp. But what I didn't know is that there's two kind of soft fp -- kernel and softfloat. Worse, you can't link binaries compiled with different fp emulation. And of course, the nokia is compiled with kernel fp emulation, not arm-softfloat.. So I was good for recompiling gcc ...

Though, one good thing is that with arm-softfloat ffcall didn't compile at all (seems that the asm bits of ffcall uses the fp registers for the arm platform), while now it compiles (but as I said it seemed to be the cause of the program's crash, so it's perhaps not as encouraging as it seems ^_^ -- although I need to double-check and recompile things nicely). Considering libffi closures don't work on the arm, if ffcall works that's a good thing :)

Anyway as soon as I have something working decently I'll post a full guide to cross-compile GNUstep on the nokia (and probably some binary packages too if you just want to install it on the nokia).

Structured Edition

I have been playing since a week or so with the Text System on Cocoa/GNUstep... it's not immediately easy to understand, but it's really nice and powerful :-)
It handles automatically lots of things, you can redefine many things too (create specific layout manager to change the way the text is displayed, eg, to "flow" around an image, etc.)..

For instance, you're supposed to work with NSTextStorage, which contains the content you're editing, and which is supposedly an attributed string (a string plus related attributes -- fonts, links, attachments, etc), and you edit it via a NSTextView. But what if you want MORE than edit an attributed string ? like, say, edit some structured content ?

Well in fact,the answer is to create a subclass of NSTextStorage that will answer the base methods (just four) of NSTextStorage -- it's in fact a class cluster. So the idea is simply to have on one side your structured document (in my case, a simple array of "Section" objects, containing (optionally) a title and a content), and to have a NSTextStorage that will actually serve as a gateway between the text system (which expect a simple NSAttributedString) and your own structured model... Pretty cool :-) and that way you benefit of all the niceties of the text system..

The above screenshot is my current editor (which btw I wrote under Cocoa, and recompiled this evening on GNUstep), the button is there to define a selected text as a title.

How to make a flash video recording on linux ?

It's rather easy -- first, you need vnc2swf, and a vnc server.
Start the vnc server on a second X port:

vncserver -geometry 1024x768 :1

Then you can launch vnc2swf:

vnc2swf out.swf :1

That will connect it to the vncserver running on localhost:1, and will output the swf file to out.swf. Start the recording by hitting F9; hitting it again will pause, etc.

Now, to add sound, there isn't a nice way of doing it... but what you can do (and that's what I did) is to launch a sound recorder application in parallel, and start the recording at the same time as the video. At the end of your video recording, you should have the video (out.swf) and a sound file from your recorder app, say "voice.aif". You then need to convert the sound file in mp3 (use the mp3 encoder lame for example).

After that, you just need to add the mp3 to the swf file, and you can do that using edit_vnc2swf :

edit_vnc2swf.py -o final.swf -a voice.mp3 out.swf

The last step is to create a html file containing the following section:

<object width="1024" height="768"
CODEBASE="http://active.macromedia.com/flash5/cabs/swflash.cab#version=5,0,0,0">
<param name="MOVIE" value="final.swf">
<param name="PLAY" value="true">
<param name="LOOP" value="false">
<param name="QUALITY" value="high">
<embed src="final.swf" width="1024" height="768"
 play="true" align="" loop="true" quality="high"
 type="application/x-shockwave-flash"
 pluginspage="http://www.macromedia.com/go/getflashplayer">
</embed>
</object>

Note that you need to set the same dimension as the video, else you'll have artifacts.

And... that's it :-)

STPalette 1.2

I uploaded STPalette 1.2, you can find it here: http://www.roard.com/gnustep/STPalette-1.2.tgz

The archive contains libStepTalkView, the StepTalkPalette, and CalculatorExample containing the sourcecode and the gorm file of the Calculator done in the flash demo...

It works :-)

After fixing a couple of bugs, I was able to code a simple calculator entirely in Gorm :-)



I need to finish properly the NSMethodSignature encoding, but after that I'll probably make a release.

StepTalkClass !

Well, after messing a bit, I have now the following code working:

@implementation Transcript 
+ (void) show: (NSString*) str
{
        NSLog (@"<Transcript> %@", str);
}
@end

...

  StepTalkClass* myClass = [[StepTalkClass alloc] init];

  [myClass setName: @"NewClass"];

  [myClass addIVar: @"Transcript"];
  [myClass setTranscript: [Transcript class]];

  [myClass addMethod: @"display: str" 
        withContent: @"Transcript show: str."];
  [myClass display: @"Hello World!"];

...

<Transcript> Hello World!

...

:-)

Basically, it means I have objects written using StepTalk, integrated in the ObjC runtime. So what it really means is that we'll be able to develop complete applications in StepTalk, directly in Gorm :-)

Well, I still need to do a bit of work -- I need to hook that into the StepTalk palette, and add a reasonably good class browser in Gorm for theses "Steptalk classes", but it shouldn't be to complex.

I will probably have a Smalltalk-like browser, and in the future I'll try to implement some of the ideas described here...

Also, as the metamodel is easily modifiable (obviously :), it's possible to implement interesting things... first, I need to implement single inheritance, categories, class methods, class variables to the current simple model...

StepTalk "objects"

As I said previously, what I want now is "real" objects in Steptalk, not just scripts. Basically, to abuse the runtime thinking classes really exist as objective-c classes, while in fact they will be a special class containing dictionaries for its ivars and its methods, and that will execute theses methods (mere NSString containing a script) via Steptalk.

It's not done yet... but I have a basic behavior done: I can add a class to the GormClassManager, add a method to it, and connect a button to this virtual method. And that works -- clicking one button connected to the standard execute: method does something, clicking on a second button connected to the virtual method does something else :-)

So, well, it's not ready yet, but things looks good :-)

StepTalk Palette 1.0 released :-)

Well, I had the time this evening to create a small libStepTalkView library (containing... the StepTalkView widget...) and correct a few things, so I thought it was good enough for a release ! For once I'm trying to do "release early, release often". Although I'm not sure about the latter... ;-)

Anyway, the whole package (libStepTalkView and StepTalkPalette) is here: http://www.roard.com/gnustep/STPalette-1.0.tgz

What's wrong at the moment ? well, it seems the StepTalkView class is not properly exported somehow, so you need to reload manually the class in Gorm (Classes->load class, load StepTalkView.h from libStepTalkView) before drag'n dropping a StepTalkView -- I guess that's probably easy to fix. Else it seems to work..

What I'd like to do now is to create outlets/actions on the fly (well, actually, tell Gorm about them) -- if I can do that, then I can create an object that will let you dynamically create "StepTalk objects" -- add instance variables, methods, etc. Each "methods" will contains a script, executed on the fly, and each instance variables will be passed to the scripts. Not completely sure about methods parameters, but I'll probably find a nice way to deal with them...

Anyway, if I can do that (and that seem doable..), then you could really program entirely in Gorm :-)

(although it probably won't be very fast, for sure... but for prototyping that would be quite useful I think, and if you need perfs, you can create an ObjC object!).

Have fun, and contact me if you have ideas :-)

Steptalk palette :-)

Making a StepTalk palette was quite simple, as it turned out...



Now I just need to build a proper framework and add a non-view StepTalk object in addition to the current one... :-)

Steptalk integration ..

Now that I have something mostly working on the "stack" side .. what would be neat is to have a way of adding some little code snippets directly in Gorm and link them to actions; it's not meant to replace ObjC coding, but in my "hypercard"-like idea, it's ok -- you'll use small scripts to do some of the things, and if you want really complex stuff you can use objc objects. Well I guess people could abuse the script system, but hey..

So, the obvious way to add scripting is to use Steptalk, Stefan Urbanek's script engine for GNUstep. Furthermore, Steptalk isn't tied to a specific language (actually it can support a smalltalk-like language and scheme, and we could have something else like ruby in the future...).

I had a look to F-Script but I was disappointed by its IB palette.. basically it's not really useable for what I want ;-) -- even if I didn't want to use it, I was wondering how the palette was working, as I thought it permitted what I want... in fact, it kinda does, but by setting manually the targets/actions of objects in the script .. bah :-) -- I want something more easy to use.

Well, I compiled Steptalk on OSX to play a bit with it, and I'm trying to think about how the palette could work to provide an environment as easy to use as possible... F-Script palette's idea of defining a bunch of outlets (object1, object2, .. object9) on the F-Script view where you link objects to have them accessible from the script is a bit crude, but for a start it will do the work. Though I think it should be possible to create a custom editor/connector that will let you add outlets on the fly, which would be a better way. Need to ask greg about that :-)

So the idea is to create a Steptalk palette that will contain a "Steptalk object" (which will contains a steptalk environment and
a text containing the script). You will be able to connect outlets to this object (and theses outlets will then be accessible from the script), and also use it as a target (so you could connect a button to it, when the button is clicked it will execute the content of the script). That won't be a perfect system and not as transparent as visual basic / hypercard (eg, click on the button, you get a window with the corresponding code executed onClick), but that would be a start. This "Steptalk object" won't be a view, but we could have a simple view so you could put the script on your windows (this view won't show when the program is running...).

Something that could be interesting too is to use custom widgets that already contains a steptalk object, with their target/action set to it. For example, the Stack could (and probably should) contains such an object. Same for the cards. And we could have a custom button containing a steptalk object too, which will then permit the "I click on the button and the code appears" scenario...

update on the hypercard idea...

Well, after backuping OSX, then formatting my hard drive, then reinstalling the backup image on it.. I was able to easily install ubuntu on my powerbook, and now I've got a working gnustep env :-)
Ok, no touchpad support, no wifi support (damn you broadcom !), no luminous keyboard support... but it works :-)

So I was able to start recoding a palette for Gorm.. with a bit of help from gregory casamento, it now works :-)
Well, sort of. It's not persistent in "test mode" yet. And I need to finish my IB Editor subclass to support the Card connections (eg, connect something to the Card, not just to the Stack object). So what's working ? Well:

• There's a palette containing a Stack object -- you can drag'n drop it on you window


• The Stack object contains one Card by default, and you can drag'n drop things on it (buttons, textfields...)


• There's a Stack inspector, so you can add new cards, and navigate through the existing cards


• There's also the possibility of creating a card from an existing one (eg, the second card will be a copy), which I need to implement the "background elements" thing, useful in the database case

So what needs to be done ? Well, as said before, add connection support to the Card view (so you could for example add a button that when clicked go directly to the card); then add persistency to the cards (I will probably just encode them for a first try... perhaps in the future something with CoreData (if we have a clone ..) or GDL2 ? or a custom solution ? but who knows, simply using encoding will perhaps be good enough for the use I expect, eg, very small databases...)

So anyway, good progresses... and now I have a much better idea about palettes ;-) so i'll probably do some more -- for example, a palette containing NSArray/NSDictionary could be rather useful, particularly if they have an editor to let you add data, and particularly in my "hypercard"-like scenario.. then, I'll just need a Steptalk palette ! :-D

Hypercard and Gorm ?

Hypercard ? Never used it, but always heard good things about it.. (starting from Dave Small's articles ;-)
So in another round of web procrastination, I tried to find more infos about it. Turns out it was quite interesting, and modern incarnations such as Revolution are quite cool too.

So what's cool with Hypercard ?

• You could say that it was one of the first easy to use "gui builder" -- you just drag'n drop elements on your screen, click on them to open a script function that will be triggered (for example when the user click on the element), etc. And it's not limited to widgets, you can draw, add images, sound... More than a gui builder, Hypercard was the first multimedia authoring system..


• You program it using Hypertalk, a "natural" programming language (ie, close to english, rather lax). Interesting.


• The real interesting bit: everything revolves around the concept of Stacks of Cards. Basically, you start with a stack containing one card. You can have more than one card in a stack (duh), and only one card is displayed at a time. So, a card is a "screen" if you want. And then you have the possibility to navigate through the cards, going from one card to another, to add cards, etc. Which is basically a hypertext (or hypermedia in that case) system. Now, the other great thing is that cards are persistants : if you add something to a card, it will stay. If you quit hypercard, restart it, reload your stack, what you added on the card is still there. Combine that with the ability to specify some of the elements on a card as "background elements" (meaning they'll be there on any cards of the stack) and you have a really simple method to define databases. Which is why Hypercard was also considered as a database. Pfew, quite a lot of possibilites, no wonder Apple's management had a hard time figuring it out ;-)
  

An example of creating a database: Just create a new card, add some textfields... add buttons to navigate (prev card, next card) and a button to add / remove a card. Set the textfields as background elements. And voila ! you're done ! Now you can run your stack, fill in the card, and when you need to add a new card, just click on the button. Great no ? In addition Hypercard could easily search through a stack, so it wasn't difficult to add search possibilities too.. And if you need to add a new information ? just add a new textfield :-)

So to sum up, quite a neat system. As I never used it, I perhaps misunderstood some of the possibilites, but playing a bit with Revolution, I'm not too far from what I describe..

I now understand more why lots of people liked it -- it was really a great system for "non programmers" to actually do great things with their computer. It's a shame Apple didn't push it more...

Anyway... I needed to explain all that to introduce my idea : Gorm is the InterfaceBuilder-like program for the GNUstep framework. You could say it's just another "gui builder" ... and you would be rather wrong ! Because instead of limiting itself to describe UI elements layout.. it really only deals with objects. Live objects. Which means you can even try your user interface, link buttons to actions, etc., all without compiling. And it's any objects -- not just graphical objects.

When you set options of the elements on your UI, you really work on the objects themselves. Then the UI is saved -- in fact, the objects graph is simply serialized in a file. When your GNUstep (or Cocoa) program starts, it just load this serialized graph of objects back in memory. That's the great thing with InterfaceBuilder and Gorm : you can set up a lot of things directly, without writing a line of code. The other good thing is you can define your own palettes of objects :-) so at the end, you can build complex program simply by drag'n drop... well, that's the idea anyway. Recent Apple's additions to the Cocoa API goes toward that (NSController, CoreData...).

So what's my idea then ? Well, it occured to me that you could simply have two objects -- a "Card" object and a "Stack" object, and put them on a Gorm (or IB) palette. The "Card" object will accept other objects (textfields, images...) and will also be in charge of saving their state. So there you'd have a persistant Card. The "Stack" object will maintain a collection of Cards, and will answer to messages like "go to card #2", "go to next card", or "create a new card".

Thoses two objects will provide you with Hypercard-like functionalities -- just start Gorm, select the "hypercard" palette, drag'n drop a Stack view on your window, and then add what you want on it. Want another card, open the Stack inspector and add one. Add new objects on it. Add some buttons on your window, and link the buttons' actions to some methods of the Stack or of the current card. And of course, instead of widgets, you could drop images or sound ... why not ?

Now, imagine we'd have a Steptalk palette to create scripts objects... and voila, you have an hypertalk-like system :-) -- all that inside Gorm (or InterfaceBuilder), leveraging the Gorm's UI builder possibilities. Imagine now we add a few nice graphical transitions or other niceties... and you end up with a rather good multimedia authoring system that generates binaries :-)
-- and if you want to add your own objects to it, to extend it.. well, it's still Gorm and GNUstep, so you can easily do that, obviously :-)

Ok, that was a long post... :-)

So in short, the idea sounds quite cool to me, and I actually started to implement a palette with thoses two objects on InterfaceBuilder (MacOSX). Sadly, palette creation isn't that well documented and I ran into a couple of strange problems .. so ... I'll do that with Gorm first, it'll be easier. Didn't start with Gorm for a very simple reason -- since Tiger, my GNUstep/OSX installation is b0rked. In the end, I'm installing a linux distrib (ubuntu PPC) ... Should be easier to have a working GNUstep environment ! :D