So, what’s new in 0.3? Well, just about everything. I’ve renamed the bundle (at least its metadata), since webOS is not just limited to the Pre and I’ve modified the shortcuts of existing features to fit TextMate’s styling guidelines a bit better. I’ve also created some snippets which can be used for faster code-writing now and in addition to that, I’ve implemented a very own language for the bundle, which can’t be found in the document type picker named as “Mojo”. “Yeah baby!”, as Austin would say now. Actually, yet it’s just a copy & paste of the JavaScript-language implementation in TextMate, but I’m planning to extend it to fit the Mojo-framework even better.

The TextMate bundle is now also available on GitHub, for everyone who can’t wait for me packaging the releases and releasing them here. If you have any ideas for improvement, feel free to contact me by mail or just leave some lines here on my blog.

Enjoy!

Download: Palm_webOS-Bundle-0.3

Download: Palm_webOS-Bundle-0.3

I’ve been working on a web-site that used the jQuery framework to render content on the client side and get information from its back-end, via XmlHttpRequests. The whole built-up worked just fine of every modern, popular browser available in the market – like the Firefox, Internet Explorer or Safari (on the Mac platform). Now, I had to test the site and make it workable on the iPhone-plattform as well. The site itself uses OAuth as authentication method and provides the information within a HTTP-header named “Authorization”. The theory is pretty plain: The back-end receives a request, checks for this header and responses accordingly.

However, iPhone’s Safari didn’t behave like the other browsers did. For whatever reason, the XHR was sent to the back-end, including every header that was set on the JavaScript side – except the “Authorization”-header. First, I though that Safari maybe could not handle the parameters of this header, but when I just renamed the setRequestHeader-argument to “Auth”, it worked. It simply just worked.

This happening made me search for other users experiencing this problem, unfortunately there doesn’t really seem to be many users testing JavaScript-sites on their iPhone – to be more precise, I did not find one result on Google that describes the problem I’m experiencing. I though, “Oh well, why not call Apple’s Technical Support?” – bad mistake. I got connected to a very annoyed and stroppy telephone-support which tried to convince me, that the iPhone’s Safari yet does not support Java. When I repeated myself by saying “It’s about JavaScript“, he didn’t really make the impression to understand the difference. I told him what the actual scenario was and all I got as answer was “Fill out the Feedback form on Apple’s site”. This made me a bit angry, because I more and more got the feeling of him trying to simply get rid of me. I asked for someone who is more technically involved into the whole iPhone stuff and he answered with “You’re already calling the most-advanced technical support – there’s no way to go further!”. At this point total disappointment overcame me and the only thing I thought of saying before I would hang-up the phone was “FAIL!” – luckily I was behaving more polite than the support-guy himself. Eh.

The end of the story is, that I (once again) wrote a report via Apple’s Feedback form (which from my impression is saving the submitted content to /dev/null) and implemented a workaround for myself by renaming the “Authorization”-header to “Auth”. Yet again a scenario in which I’m feeling like talking to a wall of bricks and have no possibility to get any information regarding my problem or maybe even correct this sort of bug. I think, this is the other side of closed-source software.

WebKit Development Tools

In the past few weeks, I was involved into heavy JavaScript web-development at work and had to work with tools that allow me to debug dynamic web-content in an effortless way. Most people would now say “Use Firefox with FireBug addition!” and I would even agree with them, if I would be using some Windows operating-system instead of my lovely Mac. Everyone who has ever used Firefox on a Linux or a Mac OS X will know, that it’s a pain in the arse. Due to the way Mozilla-developers have taken to make Firefox available on multiple platforms, it lacks of any speed and integration within most implementations.

So what to do on a Mac, where Firefox trying to render a full-blown AJAX-site needs more space and CPU-power than a VMware or Parallels instance of Windows XP, running the IE? Most people don’t really know, that the Mac’s integrated browser already provides a very good toolset for web-development which just got even better with the version 4 (yet, still Beta) of Safari.

The toolset is hidden, on a regular OS X, but it can be unlocked pretty easy. The only thing you gotta do, is quit your Safari, open a Terminal and enter this command:

defaults write com.apple.Safari WebKitDeveloperExtras -bool true


It should quit without any output. After that, you can quit the Terminal and re-start Safari. You might not see any difference to Safari’s appearance before spawning the command, but now just try to do a right-click / command-click within a web-site. You will see, that your popup-menu has just been extended by one new item at its bottom, called “Inspect Element“. By clicking this entrie, Safari either opens a new window or separates your current one with an additional view, depending on what Safari version you’re using. This command works on 3 and 4.

Within that window, you will see a lot of useful information about the page. You can see time and size measurements, script-warnings and -errors and many many more. This extensions to Safari’s WebKit provides you nearly everything you might know from FireFox Add-Ons like FireBug. And besides of that, it allows you to profile your page in a sleek and easy, graphical way.

I’m now working quite some time with those tools, exactly because of all the problems I had with Firefox on my Mac, and I must say that I love them. I love the integration and the way it allows me to debug my sites. The only thing I liked more in FireBug was the precision of its GET/POST/PUT/…-output, but most of the time I don’t need that anyway.

Enjoy!

The GNOME Shell redefines user interactions with the GNOME desktop. In particular, it offers new paradigms for launching applications, accessing documents, and organizing open windows in GNOME. Later, it will introduce a new applets eco-system and offer new solutions for other desktop features, such as notifications and contacts management. The GNOME Shell is intended to replace functions handled by the GNOME Panel and by the window manager in previous versions of GNOME. The GNOME Shell has rich visual effects enabled by new graphical technologies.

So, the GNOME Shell is actually a more lickable and not-so-crappy version of what we can remember from old Windows 98/2k times, usually called something like Talisman Desktop or similar. Those applications were replacements for the actual explorer.exe binary, which hooked into the system logon and tried to build a better looking and feeling, theme-able interface for the end-user. Though, these applications never really found a market niche, last but not least because of the mostly exorbitant pricing policy. A few time later these add-ons were pushed away by Windows XP’s own theming abilities.

However, as it seems the GNOME community now starting writing a similar add-on for the GNOME desktop, using features provided by modern soft- and especially hardware. The whole Shell is hardware accelerated and seems to be working pretty fluent – not only because it’s exceptionally not written in Python or any other sick scripting language. Instead, it makes use of native C code, combined with Clutter and hooks for JavaScript plug-ins.

From what I’ve seen so far, it’s not that bad and finally seems to really be an add-on that integrates into the desktop, instead of being just another application which I need to bound somehow into my GNOME desktop. My colleague just quickly compiled and ran it and at least on his nVidia accelerated hardware it worked out pretty smooth and at least while testing it didn’t crash once.

It could become a pretty cool and promising project, if the people running it will find somebody concerned about UI-Design/-Usability and maybe some graphical artists, too and maybe make it look more “stable”. At the moment, the whole ‘shell’ still looks pretty half-cooked, but of course, they’re just at their beginning. So let’s wait and see – or better even contribute and change!

Since I’ve already posted a quite descriptive post regarding the theme itself, I won’t beat around the bush now. For those who haven’t read the initial story, here you can review it. You can download the theme by clicking the link at the bottom of this page. Note, that the theme needs the theme-switcher-reloaded Plugin for WordPress to be up and running to work properly. Additional to that, you will need to make some changes to your actual theme, which allows the user to actually switch to the iPhone theme. These changes depend on what theme you are using, but in general you need to modify your theme’s header.php and include a code like this one:

<?php
if(empty($_COOKIE["iphonetheme" . COOKIEHASH]))
{
if (stristr($_SERVER['HTTP_USER_AGENT'], 'iPhone'))
{
echo "<div style=\"background-color: #F66; color: #fff; padding: 8px;\">";
echo "You seem to be browsing this site from your iPhone or iPod Touch.";
echo "Would you like to <a href=\"?wptheme=iphone\" title=\"\">change to the optimized site</a>?";
echo "</div>";
}
}
?>


The iPhone Theme itself already contains a button which provides you to switch back to the regular theme.

However, feel free to download, distribute, modify and have fun with my WordPress iPhone Theme – it’s released under GNU GPLv2!

Download: WordPress iPhone 0.1

The red block let's you choose.

I’ve been now using Prologue for quite a very long time – I guess longer than I’ve ever used one WordPress theme before – and I’m highly pleased of it. However, even that Prologue has a built-in iPhone/iPod Touch browser-detection which cuts away the sidebar and only keeps the important news-stream in focus, I haven’t been very satisfied by that. The font is still pretty small, nearly unreadable, the links are therefor pretty hard to hit, et cetera.

However, yesterday then Andi showed me some pretty nice little framework he just found, what actually doesn’t have anything to do with WordPress itself, but made me think of a very cool idea. The iWebKit-Framework is a small set of CSS and image files that concentrates on building a website in a way so that it looks just like an iPhone or iPod Touch Application. The whole thing’s appearance is pretty sexy, you can take a look at the downloads and get the framework plus some example HTML files for testing.

My optimized front-page.

So, I took a closer look on the iWebKit stuff and did some (again better, a lot of!) PHP WordPress theme hacking. I think I spent the whole night building that thing – but I also think that it was worth it, heh. And I guess, I’ve created a revolutionary and new WordPress theme aimed for the usage on iPhones and iPod Touches – the only problem I had left was: How to I get WordPress to use this theme only on the tiny Safari, but on nothing else? After some more PHP hacking, which included modifying my Prologue theme but not the actual WordPress (what’s the really cool thing within the whole story), I’ve found a way.

When you browse my WordPress now using your iPhone, you should be getting a red message right on top of the site, which tells you that it has detected the tiny Safari and suggests you to use the iPhone optimized theme. If you confirm by clicking the first link, the whole site’s design should get to look just like on the pictures I’ve inserted here.

My contact information - optimized.

I will extend the theme some more, maybe by building in JavaScript effects or other Eye-Candy, to make it fit even better into the iPhones Look & Feel. I was also thinking of some Cover-Flow’ish effect for my Gallery (which at the moment just links to my Picasa-Site, but thanks to the great API provided by Google it shouldn’t be too hard to implement that right into the page).

Maybe, after some more testing I’ll be able to provide it for download, including a whole documentation of how to make it work. Until then, I hope you enjoy browsing my Blog, especially over the iPhone or your iPod Touch. Please feel free to write me your impressions, feedback and also suggestions for improvement by commenting here or writing me an e-mail. So far …

Have fun!

My first Dashboard Widget

So, I’ve just played around a bit with Dashcode, Apple’s IDE for Dashboard-Widget development, and I have to say that it’s pretty cool. It’s quite easy to use and provides excellent WYSIWYG features. I just started a default RSS-Reader project and customized the template it gave me the way I liked it. It’s really interesting what can be done with a little JavaScript. Of course, by using that script language, Dashboard Widgets might not be the best in performance or system-usage, but in my opinion this way is a better one for writing widgets, than for example OpenSource projects like Karamba provide. I don’t want to have to learn Python from ground up, just to be able to write my own RSS-Reader widget. And of course, for writing more advanced Widgets with Dashcode, the developer must know JavaScript – but it’s a small difference between the time it takes to learn simple JavaScript and the time it takes to just understand Python or whatever other language.

However, I think I might be doing some more playing around with Dashcode. I don’t know yet what widgets to implement, but I’m sure I’ll find some interesting ideas I could realize.

You can download the RSS-Reader for my Blog here. Enjoy!