Recently i came across a post on the Webkit blog which demonstrates new support for transforms in the nightly builds of Apple’s Webkit (used in Safari and other browsers).
Quite simply it means that you can rotate, scale, and even skew any part of a web page. For example:
Click here
(Note that this currently only works in the nightly build of Webkit)
There is a slightly more impressive demonstration on the webkit blog. Which made me think… could i incorporate this neat functionality into OpenLaszlo’s DHTML runtime?
The answer is of course yes. OpenLaszlo already supports advanced transforms such as rotation, it’s just not implemented in the DHTML runtime as no web browser has supported it… until now that is. An extremely simple example of how to get it to work is as follows:
This rather simple “webkitrotatable” class allows one to make a view which can be rotated by modifying the “wrot” parameter. So you can make a little rotating thing like so:
Of course if i wanted a better solution, i’d just modify OpenLaszlo’s DHTML kernel and directly incorporate this functionality into the view class’ “rot” attribute. But for now, this is a pretty simple proof-of-concept.
After much deliberation, i finally got round to upgrading my Macbook from Mac OS X Tiger to Mac OS X Leopard.
Installation was mostly automated. I decided that as i still had Linux installed on the machine, i might as well just reformat it a start from scratch. After putting in everything needed, i sat back for nearly an hour until it finally finished installing.
After watching the fancy new intro movie and filling in all of the dialogs, i ended up with the desktop, which surprisingly wasn’t as bad as i had first imagined.
There was however a little issue i had to address: I had to copy across all of my files to the new installation. The only problem was that most of them were in a FileVault which i backed up from my Tiger installation.
Interestingly Leopard uses “.sparsebundle” files instead of “.sparseimage” files to store FileVault’s, so i couldn’t just copy my old FileVault over and log back in with all of my files and settings in tact. No, i had to figure out a workaround.
Firstly, i made sure i was logged into a different user account than the one i was restoring. I then opened up my old ”.sparseimage” file which mounted at ”/Volumes/jamesu”.
Now i could’ve just gone into Finder and copy all of my files over just like that, but then i realised that there were a lot of hidden files present so i needed to make sure they were copied too. Thus i decided to open up Terminal and use a command line tool called “ditto” to copy my stuff across, which tries its best to preserve all of the metadata.
So now i could just log-in and everything would more or less work. However i also remembered that i had some more files from when i was using my Linux installation. These were on another machine, so i first copied them across. For this i used SSHFS, but any method is applicable. I then utilised another command line tool called “rsync” which synchronises files between two locations in order to copy only the files which had changed from my last Mac backup (which my Linux copy was based off of).
And viola! I could now log-in, safe in the knowledge that all of my important files were accounted for. Of course, i also turned FileVault back on so my important documents were now safe from prying eyes again.
Now i’ve got everything sorted, i think i’m going to check up on the exciting new developer API’s present in Leopard.
For those of you have read my blog previously, you may have noticed i bumped in a fewlinuxrelatedposts here and there. This was mainly due to the fact that i was experimenting with using linux as a desktop operating system (something which i have tried in the past), as i wasn’t too confident of where Mac OS X was going. This ultimately included installing it via BootCamp on my Macbook.
Unfortunately i have now reached the end of my teather with regards to using Linux as a Desktop operating system. Quite simply i kept bumping into too many issues which required manual workarounds, if there was even a solution at all.
<!-more->
I started off by trying one of the release candidates for the latest release of Ubuntu, version 7.10. This initially impressed me as when i booted off the installation CD, almost everything appeared to work out-of-the-box. However upon installing it on my Macbook, the novelty wore off as i realised that crucial features of the Macbook – the camera, the IR, even the trackpad either didn’t work properly, or didn’t work at all.
For example:
The default trackpad configuration was abysmal, and i couldn’t find any configuration tool which gave me the same amount of customizability as the one in Mac OS X in order to fix it.
I never got the iSight working – though then again this wasn’t much of a problem as Skype for Linux doesn’t even support video cameras.
Whilst the sound worked, configuring it was a pain in the ass as there were too many confusing options to choose from.
I tried to get the DVI out to work. I ended up breaking the X server and spent ages trying to fix it. Safe to say i never got it to work.
OpenGL support on the Macbook was sub-par.
Intergration between applications varied from being good to abysmal.
( It should be stressed that all of these issues persisted through to the stable release of Ubuntu 7.10 )
In fact, you can see a nice list of all the problems you have to fix out of the box here.
A week or two ago, Ubuntu 7.10 became officially stable, so i decided to try out one of its variants to see if it fared any better on my Macbook. I chose Kubuntu as i had previous experience with using KDE from using SuSE Linux and figured it might turn out to be a better desktop experience.
On the contrary, Kubuntu was anything but a better desktop experience when compared to Ubuntu. A lot of the killer features present in Ubuntu – Compiz Fusion, simple administration tools, even mappings for the brightness controls were not present in Kubuntu. It was also more difficult to configure as there were simply too many configuration options to choose from, as is illustrated by the comparison of the “Keyboard Shortcuts” dialog in Kubuntu (which uses KDE) and Ubuntu (which uses Gnome) bellow:
I even tried the beta KDE4 packages, in the hope that maybe KDE4 had improved on KDE3. I was sorely dissapointed, as instead of this i got this.
Safe to say i have come to the conclusion that currently neither Ubuntu or Kubuntu are quite up to scratch when compared to the standards set by Mac OS X. In fact if suddenly all copies of Mac OS X were obliterated, i’d probably take a risk and use Haiku.
As for the future, who knows? But as for now, i think i’ll stick to what i like best – Mac OS X.
After browsing through the blogosphere, i came across this rather interesting OpenLaszlo-related post on the Doinet blog. It seems that they’ve managed to get a nice blur to appear behind their dialog boxes, which replicates what happens in Flex when a dialog appears.
Sadly i couldn’t post any comment on their blog, as i got a “403 – Not Japanese” error back. Annoyances aside, i quickly managed to figure out how they were achieving this rather simple effect.
It basically boils down to this:
<method name="doBlur">
// Get the filter list for this view
var myTempFilters = [];
// Create the blur filter and put it on the list of filters
var myBlur = new flash.filters.BlurFilter();
myTempFilters.push(myBlur); ;
// Set the filter for this view
this.sprite.__LZmovieClipRef.filters = myTempFilters;
</method>
To achieve the whole dialog effect, you basically need to insert a view on top of all the other elements in your UI, then call the “doBlur” method on it. You can then place your dialog on top of that view and you shall have your Flex-style dialog blur effect!
There are many effects you can play around with. For instance there is a “DropShadowFilter” which can be used to create a drop shadow effect for the dialog box.
Of course, there are a few snags. The most notable one is that you need to make sure you select the “swf8” (i.e. Flash 8) target instead of the default “swf7” (i.e. Flash 7). In addition there is no direct equivalent for flash filters in any of the other runtimes, so in the case of the blur filter you’ll have to resort to falling back to a boring old transparent overlay.
October 14, 2007 at 11:39 am · Filed under oldbrew
If you’ve ever read my blog before, you will probably have seen my variousexperiments with the OpenLaszlo RIA platform. Eventually i plan to put all of the various tidbits i have learned together, and make something of use with it.
Before i do that though, i still have a few things to get my head around. One of them is how OpenLaszlo manages to make layouts work in its DHTML runtime.
<!-more->
First of all, for those of you that don’t know, OpenLaszlo’s presentation model is quite simple – everything you see and manipulate is what is known as a view. It’s as simple as that. All other visual tags are derived from a “view”.
Comparing this to HTML with its multitude of base tags, the concept of everything being a view is a pretty generic concept. This is of course great for portability. But as with anything generic, it tends to skimp past the specifics.
As illustrated above, in mapping the concept of everything being a view to HTML OpenLaszlo makes every element a multitude of div tags, loosing a lot of the original semantics. Each div tag is positioned absolutely, and relies on supporting JavaScript code for positioning. To complicate matters, not all of these div’s are visible. These invisible div’s are typically used to handle click events.
Thinking further, mapping OpenLaszlo layouts to HTML in this way makes perfect sense. There are very few direct mappings of OpenLaszlo tags (or classes) to HTML tags.
However i fear that this approach has a lot of drawbacks particularly with regards to accessibility. Not having used any specific assistance tools for browsing the web, i can’t say anything definitive. But i’d imagine that the barrage of div tags would be much more difficult to process through than a W3C compliant website full of semantic markup like h1, p, a, img, etc.
All things considered though, this approach to Layout gives the designer unprecedented freedom of how a web site should look, which IMO is a good thing.
This has been mentioned a fewtimes earlier this year, but i only just realized how useful these “Generators” are.
One of my pet peeves about typical JavaScript is that it is more or less impossible to save and restore the state of a function. I have found this to be quite useful in languages such as Ruby in which it is practically used everywhere though the use of the “yield” keyword. For example:
def my_funky_iterator
yield 1
yield 2
yield 4
yield 8
end
my_funky_iterator do |yielded_item|
puts yielded_item
end
Which would print
1
2
4
8
So in essence, the “yield” keyword turns a function into an iterator. Each time the “yield” is invoked, Ruby passes control to the supplied block which then handles the yielded value – in this example, it just prints it. Finally, it returns control back to the function which called the yield.
This is where JavaScript 1.7 ’s “Generators” come into play. It is essentially the implementation of the “yield” keyword in JavaScript, so with a little tweaking we can rewrite the above code in JavaScript:
function myfunkyIterator()
{
yield 1;
yield 2;
yield 4;
yield 8;
}
var funky_iterator_instance = myfunkyIterator();
var yielded_item = null;
while (yielded_item = funky_iterator_instance.next())
{
alert(yielded_item);
}
my_funky_iterator_instance.close();
Which you can try out by clicking on one of these nice buttons. The former iterates over all the values, whilst the latter only iterates to the next value.
Click me!
Click me 2!
var glob_iterator_instance = null;
function myfunkyIterator()
{
yield 1;
yield 2;
yield 4;
yield 8;
}
function myfunkyIteratorCaller()
{
var funky_iterator_instance = myfunkyIterator();
var yielded_item = null;
while (yielded_item = funky_iterator_instance.next())
{
alert(yielded_item);
}
my_funky_iterator_instance.close();
}
function myfunkyreentrantCaller()
{
if (glob_iterator_instance == null)
{
glob_iterator_instance = myfunkyIterator();
}
var yielded_item = glob_iterator_instance.next();
if (yielded_item)
{
alert(yielded_item);
}
else
{
glob_iterator_instance.close();
glob_iterator_instance = null;
}
}
I can see Generators being quite useful in scripting, particularly with animations.
Sadly, the only web browser which supports generators is FireFox 2. Though it is interesting to note that there is a Mozilla project called ScreamingMonkey which might allow Internet Explorer to run next gen JavaScript 2.0 code, so i guess there is hope yet.
Soon after bumping into haXe and Doomed Online, i somehow got the strange idea that i could get flash to play SCUMM games, like ScummVM.
Safe to say, i ended up with this rather odd Flash-based app written in haXe which when provided with the ”.000” and ”.001” files of any unencrypted V6 SCUMM game will be able to load and play it. Or rather, attempt to.
Sadly i bumped into a problem in the image decode routines, so what is displayed isn’t pretty. But it is quite capable of executing enough opcode’s to get to the input event loop in Alban Bedel’s road example for his scummc compiler, which is great.
As for other games, i would doubt that they would get very far. A lot still needs to be implemented in the runtime.
In any case, if you dare you can try out my Flash-based SCUMM interpreter by downloading and extracting this archive. Simply load “test.html” into your web browser. Note though that you will need Flash 9 in order to run the interpreter.
In addition i also decided to open up the code for everyone to look at. It’s a mess, but it works. You can grab it from here.
Finally i would like to congratulate the ScummVM team for their SCUMM interpreter and Alban Bedel for his scummc compiler. Without their efforts, i wouldn’t have had any code or references from which to base my haXe-based SCUMM interpreter.
A while after i bumped into Doomed Online, i decided to investigate the pipeline for making Flash 9 games.
Compared to a few years ago, it seems like an increasingly lucrative game development platform. Pretty much everything you would need to implement for a game is possible with Flash 9, including such things as 3D Rendering. In a way it’s comparable to the late-90’s PC gaming scene. I have no doubt that you could probably make something as sophisticated as, say, Tomb Raider with Flash 9.
However my big problem with Flash is that it is still a closed platform. I have yet to find any open source re-implementation of the Flash runtime that fully runs Flash 7 files, let alone Flash 9. And whilst the Flash 9 compiler is supposedly going to be open source’d by Adobe, i have yet to see any indication that this is really going to happen.
Thankfully, i found a solution : HaXe. It is essentially a fully featured programming language that can output to one of three formats:
Adobe Flash (7, 8, or 9)
Neko VM (runs as a standalone app or a web app or perhaps embedded elsewhere)
JavaScript (though sadly doesn’t have a nice RIA toolkit which writes all the HTML like, say, OpenLaszlo)
So in essence, with HaXe i can bypass my “closed platform” nag point and instead make a version of my game or app that works in Neko or perhaps just in a bog standard Web Browser. In addition i can consolidate my web development into one cool programming language. Great!
