LiveChat provides innovative web based customer support solutions including live web statistics and live customer chat. The company has great potential and impressive customer base, so you may be interested to follow their Twitter feed too here.

Checkout new L&F from just released alpha and tell me what do you think:

Now I am heading seaside to get some rest, because upcoming September will be busy for sure.

I should say it first – mostly Polish gossips, in Polish language. But anyway Kozaczek.pl is another nanoANT’s piece of craft (mind the spelling). After one week of its premier it topped 2nd in Polish AppStore. We had greater expectations, but some iPhone users here in Poland are really great bigots. I have seen many comments accusing some iPhone news editors that they have put a little news about this app, because this app ill befits there. Come on!

Anyway doing this app was a great fun and I believe using it is a great fun too, especially as an alternative to those grave TV news everyday. Checkout official release news here.

DrawIt was created and is maintained by its author Pieter Omvlee. While doing initial design of this application Pieter asked for help French designer Laurent Baumann (working now for Apple). Pieter’s skills and Laurent’s talent joint together created something extraordinary, the great UI of DrawIt made from scratch to give you an ability to quickly create web/bitmap designs with vector tools and stack of effects. I will not get into details here, as you can find few good articles about DrawIt over the Internet, but I will rather describe little experiment of mine I have made today and try to answer the question if DrawIt can be good Photoshop replacement for icon and web design.

Since lately I was forced to use Photoshop, I decided to give DrawIt a try and recreate one of outstanding Photoshop tutorial icons using DrawIt. My choice went for Basic House Icon from PSDTuts+ site. You can see the result of my work above and you can download the DrawIt source file here.

First of all DrawIt is non-destructive vector based program. Which means you can always revise any step and decision you have made during design process. The idea is based on shapes and effects applied onto them, something you could find in Macromedia Fireworks, Freehand (RiP) or Adobe Photoshop‘s layer’s effects.

Photoshop Layer With Effects

As seen on many Photoshop icon design tutorials, the starting point is a path filled with some gradient or simply filled with black color.  Then most of the folks apply effects created out of the path’s filling. The effects panel used all over again unfortunately is buried in Layers panel and requires extra interaction to pop it up.

In my opinion this really makes me wonder what made Photoshop to be considered better than Macromedia Fireworks or Illustrator for icon design when you are working constantly applying effect, closing and opening Effects window which is simply uncomfortable.

DrawIt Effect Stack

Here in DrawIt it is much easier to set effects for particular shape. First of all you are working only shapes, so you can always touch and redefine the shape’s shape using vector tools, while Photoshop it takes a bit more to redefine layer’s path, also when you did some manual touch to the layer then redefining its path will kill your modifications.

Also DrawIt effects may be applied in random user’s defined order. You can also double same effect, disable and reenable them on fly.

Photoshop’s touch to the image

There’s one thing that you can do in Photoshop but you can’t in vector based programs. It is some human touch to the color or shade using tools like burn, dodge. Such a “touch” can sometimes drastically improve  overall effect. Unfortunately this is impossible simply using DrawIt, as everything is an object here, so dodging particular area of an object is simply impossible.

Nevertheless there is always alternative ways to achieve same effect as you would get using hand drawing Photoshop tools in DrawIt. You just need “think vector”. Sometimes experimenting with various settings can result with amazing overall look of an object.

DrawIt’s perfection killed by some flaws

Unfortunately some minor but longstanding bugs are flies in the DrawIt’s ointment. Undo/redo is the basic thing you expect to work well in any program. It does work well in Photoshop, TextMate, iWork, but NOT in DrawIt, that tends to forget some actions in its undo chain, which makes unpleasant surprise when playing with effects.

Another thing that makes you suffer it a way you change colors of gradients and other various objects, sometimes you need to click few times to make DrawIt change the color of selected property. Again, color panel tends to forget what it was attached to, especially when you change switch objects Color panel is still on screen but attached to nothing.

Resizing objects can be very painful too. First, changing objects height makes it change its vertical position, this isn’t right! Second, trying to resize the document with all objects usually leads to misplacement of those objects.

Finally vector (shape) editing mode deserves more polish, as sometimes you may get crazy if you want to delete several points (no way to drag/select few points), or if you move the point out of the canvas you cannot control it anymore its handle disappears (clipped by canvas rectangle), while you expect shape’s vector handles should be visible outside of the canvas too.

Is it worth a price?

DrawIt is absolutely worth its price and I would glad pay for it again if those few annoying bugs were removed. The author is a very kind nice young fellow willing to listen for the new ideas for his project. One of such ideas is slicing functionality that is probably a result IM chat I did with the author while ago.

However peeking recently into author’s blog it seems he is more focused on his other applications – too bad, but that’s life – you are working on something that gives you best revenue, which may be not DrawIt in this case.

What about Photoshop? In my opinion it is definitely NOT worth a price if you want just an icon design software. I really regret all competing software producers such as Corel, ACD, Xara dropped support for Mac OS X, leaving us in hands of Adobe. Thank God there is DrawIt (and maybe Vectordesigner ;P).

This is the official method, and since SDK 4 does NOT come with 3.x headers, the only method to make your app run on 3.x. But it is not so simple, because now in your Xcode you are using iOS 4 API. So how do you know you are not using classes or methods that do not exist in 3.x and putting them into your code will crash your app on 3.x device? You don’t!

Unfortunately Xcode will warn you about deprecated API, but will NOT warn you about API that does not exist on your deployment target. I buy you a beer if you can find such warning option in Xcode project configuration.

This would be acceptable if you could test your application on iPhone 3.x OS Simulator, but there is no any in SDK 4 (neither as an option), hence you can’t absolutely tell your app won’t gonna blow on iPhone OS 3.x if you upgraded your TESTING devices to iOS 4.

I have spent a while trying to figure our what was Apple’s engineers official statement about that on devforums. And they say if you want to test 3.x compatibility you need get a device with iPhone OS 3.x. Huh? So I shall buy an new iPhone expecting it won’t have iOS 4 on board, because there is no (legal) way to downgrade existing device to 3.x.

Trying to find out a more reasonable way I have ended up with installing an OLD SDK 3.2 on /Developer-3.2. Finally tested my application… but fiddling with SDK 4 was not over. (NOTE: Obviously this method isn’t really free as you gonna lost 4GB for old SDK installation and 2.5GB for download, but it far less expensive than getting a new old 3.x device.)

Still there are few gotchas with this method

And here is one of them. If you happen to use iOS4 API in your code, Apple says that your shall check functions (and class) pointers against nil.

One of the new classes introduced by iOS4 API is UITapGestureRecognizer. I happened to know that because 3.x SDK complained about unknown UITapGestureRecognizer class. So I tried in my code:

UITapGestureRecognizer *singleTap = [[UITapGestureRecognizerClass alloc]
    initWithTarget:self action:@selector(handleSingleTap:)];
if( singleTap != nil ) {
    // do something, we shall be there only on iOS4

Should be enough to be compatible with 3.x device compiling on SDK 4, since UITapGestureRecognizer is introduced by iOS4 API I expected that on 3.x it will be nil so singleTap will be nil too! (BTW. It won’t compile with SDK 3.x I have just installed ;P)

I have sent my app to beta tester with 3.x device, that replied the app is still crashing. So my reasoning about nil was NOT true. Okay, fine, let’s try with:

Class TapGestureRecognizerClass = NSClassFromString(@"UITapGestureRecognizer");
if( TapGestureRecognizerClass != nil ) {
    // do something, we shall be there only on iOS4

Again crashes on 3.x device.

I have lost one day on communication with beta tester and scratching my head. You know why? Because UITapGestureRecognizer actually do EXIST in iPhone OS 3.x but it is NOT in the public API. Moreover it misses some methods that do exist in iOS 4 API, so finally I ended up with something like this:

Class TapGestureRecognizerClass = NSClassFromString(@"UITapGestureRecognizer");
if( TapGestureRecognizerClass != nil ) {
    UITapGestureRecognizer *singleTap = [[TapGestureRecognizerClass alloc] initWithTarget:self action:@selector(handleSingleTap:)];
    if( singleTap != nil ) {
        if( [singleTap respondsToSelector:@selector(setNumberOfTapsRequired:)] ) {
            [singleTap setNumberOfTapsRequired:1];
        }
        // .. and checking other selectors

And this was my WORKING method to be compatible with 3.x and using some of iOS 4 API. Crazy enough?

If you have one, check out http://developer.apple.com/iphone/library/ on it.

Do you like my iPad stand? It is a table easel, paid 25zł (about $10) and it is far more flexible and sexy than all those overpriced dedicated stands. By the way, iPad screen seems to be more blueish than MacBook’s. Both are led backlit, so I wonder why?

I have just learned that AppStore is amazing phenomenon. It is quite impossible to predict impact of an application before it gets released. Some “silly” apps stay on top for weeks, while some real gems are quickly forgotten. So it is worth to test even most crazy wicked ideas against iPhone users putting them into life as AppStore app.

It is high time to release own application iPhone after spending a while doing apps for companies. So I decided to make something useful for myself what others can appreciate too.

Here are my very own apps:

• Strefa a Wirtualna Polska Strefa MP3 streaming audio client. Strefa MP3 is a portal containing over 100’000 songs of amateur and professional polish artists, every day brings tens of new songs. IMHO that is much better than commercial radio stations serving all those boring pieces we already heard before thousand times.
• Wezwij Taxi a polish taxi catalog and taximeter in one app. Now this program has one purpose: keep updated database of taxis for major cities of Poland. But in the future, I think this app can turn into some kind of one button taxi call, using your GPS position without a need to call or name your position to the operator. Useful for those traveling to unfamiliar cities.

Update: Strefa is already available at AppStore, Wezwij Taxi waits for fixes and resubmit.

Intel

Fortunately Intel provides binary driver set called Intel® Embedded Graphics Driver (IEGD) supporting all embedded video chipsets, containing binary form of video driver libraries for latest Xorg, OpenGL and VA.

While most of the work you need to do is to have IEGD_10_3_Linux.tgz file (in case of IEGD 10.3) extracted onto the target box and to copy various .so files in proper places (follow IEGD documentation). Yet there is one more complicated thing extra – IEGD Kernel Module (IKM) iegd_mod.ko that has to be compiled out of the source shipped with IEGD.

Linux Kernel module

IEGD documentation clearly states that only few distributions are supported by this driver, and those are i.e. Fedora 8 & 10, some older Ubuntu 8.x and finally Moblin. But what about others, such as Debian, newer Ubuntu. You think you are unlucky running other distro? You shall understand word “supported” here as “tested”.

Reading the documentation, in all cases your are supposed to enter IKM folder of extracted drivers and launch install.sh script. This script shall compile and install without any hassle IKM on “supported” distributions. Surprisingly trying that on your distribution even it is not supported may work too! With one important exception it produces bogus driver that will crash your kernel.

Finding the proper way for your distribution

This recipe will save some few hours upto few days of struggling with fancy errors trying to compile and run the IKM module on your system

Investigating the driver and install.sh first thing to notice is that it checks you Kernel version, it also takes (false) assumption that your are running one of the “supported” distros, so i.e 2.6.27 may mean Fedora version of the 2.6.27 Kernel not any 2.6.27 kernel.

Linux distributions have this fancy characteristic that they usually come with heavily patched kernel, so when you take 2.6.xx driver module from one distro and try to run it on the same version kernel on the other distro it will likely crash your kernel. Why? Incompatible ABI.

What Intel (Tungsten?) did in IKM is prepared IKM/val subfolder with headers extracted from several kernel sources of “supported” distributions. And what install.sh does, it tries to guess which one of DRM and AGP kernel module headers placed in that subfolder are OK for your Kernel.

In case you are running on the “unsupported” distribution the answer in 95% cases is NONE! Even you will be able to compile the iegd_mod.ko using Makefile produced by install.sh the module will crash you kernel as soon you will try to use it. Since your kernel has incompatible ABI (different structures) with the ABI provided inside IKM/val subfolder.

Preparing for compilation of IKM for your own kernel

If you are running “unsupported” distribution you should avoid then using headers in IKM/val subfolder. The right way is to take AGP and DRM headers out of your running kernel sources (you don’t have to compile the whole kernel of course).

So go to IEGD_10_3_Linux folder and launch:

sudo apt-get install linux-headers-x.y.zz
apt-get source linux-image-x.y.zz

Where x.y.zz is your running kernel version. (Use your own distro command to grab kernel source if you don’t run on Debian or Ubuntu)

This will install kernel headers and scripts to build kernel modules and also produce linux-x.y.zz folder containing source code of your running Kernel. The whole trick if to place (replace) Makefile in IKM folder as below:

KERNELVER ?= $(shell uname -r)
KERNELDIR ?= /lib/modules/$(KERNELVER)/build
INSTALLDIR ?= /lib/modules/$(KERNELVER)/kernel/drivers/char/agp
PWD ?= $(realpath .)

EXTRA_CFLAGS += -I$(PWD)/include
EXTRA_CFLAGS += -I$(PWD)/../linux-$(KERNELVER)/drivers/char/agp
EXTRA_CFLAGS += -I/lib/modules/$(KERNELVER)/build/include/drm

all: clean modules

modules:
	@echo $(PWD)
	@$(MAKE) -C $(KERNELDIR) M=$(PWD) modules

install:
	install -o root -g root -m 755 -d $(INSTALLDIR)
	install -o root -g root -m 744 iegd_mod.ko $(INSTALLDIR)
	/sbin/depmod -a

uninstall:
	rm -rf $(INSTALLDIR)/iegd_mod.ko
	/sbin/depmod -a

clean:
	@rm -f *.o iegd*.ko iegd*.mod.c iegd*.o agp/*.o drm/*.o Module.symvers
	@rm -fr .intel* .tmp* .*.cmd agp/.*.cmd drm/.*.cmd

obj-m := iegd_mod.o
iegd_mod-objs := agp/pci.o agp/global.o agp/drv_alm.o agp/drv_nap.o agp/drv_plb.o agp/drv_cmn.o agp/drv_gn4.o drm/iegd_drv.o drm/iegd_interface.o drm/iegd_interface_265.o drm/iegd_interface_2611.o drm/iegd_interface_2615.o drm/iegd_interface_2624.o drm/psb_irq.o

You don’t need to launch install.sh at all. Just paste the file as above.

As you see now, this Makefile references to ../linux-$(KERNELVER) for your running Kernel source AGP & DRM headers. Yet however you may still need to do few tweaks in your Makefile, see notes below:

Note (1) In case you are running older kernel, /lib/modules/$(KERNELVER)/build/include/drm may not exist, then $(PWD)/../linux-$(KERNELVER)/drivers/char/drm should be right path to put in the Makefile instead.

Note (2) The Kernel source code folder you downloaded (i.e. via apt-get source) may not actually match exactly linux-$(KERNELVER), so you may change that EXTRA_CFLAGS setting manually:

• In case of Ubuntu `uname -r` is 2.6.31-19-generic while the extracted source folder name has no -generic suffix and it is just linux-2.6.31-19.
• In case of Debian `uname -r` is 2.6.26-21 while the extracted source folder name is linux-2.6-2.6.26-21. Weird huh?

Final fixes before compilation

There is a file still missing if you try now to `make`. It is file that exists in IKM/val/agp but does not exist in your $(PWD)/../linux-$(KERNELVER)/drivers/char/agp. It is called interface_abs.h.

Wonder why the heck it is NOT in IKM/include!? This is a little lack of consequence from Intel here.

Anyway just copy interface_abs.h into IKM/include out of IKM/val/agp/agpm0vmob2 if you are running on >= 2.6.30 Kernel or from IKM/val/agp/agpm0v103 otherwise. The only difference between interface_abs.h from agpm0vmob2 and agpm0v103 is one macro definition.

Finally we need two little extra fixes.

(1) Trying to compile on Debian Lenny we will get many nasty errors from kernel headers for IKM/drm/iegd_interface.c. Moving igd_abs.h inclusion in this source file little down fixes the issue. Edit IKM/drm/iegd_interface.c as below:

 #include "iegd.h"
-#include "igd_abs.h"
 #include "drmP.h"
 #include "drm.h"

+#include "igd_abs.h"
 #include "iegd_drm.h"
 #include "iegd_drv.h"
 #include "psb_intregs.h"

(2) IKM/drm/iegd_drv.c tries to include linux/config.h at the very begining of the file. This is not actually necessary, and anyway does not exist, so you may comment that out:

-#include <linux/config.h>
+/* #include <linux/config.h> */

Compiling at last

Now you are ready to so `make` and `sudo make install`. This time  iegd_mod.ko should be ABI compatible with your kernel.

I have tested this method on Debian 5.0 Lenny and Ubuntu 9.10 Karmic Koala.

To ensure everything works fine after driver installation try:

sudo modprobe iegd_mod

And try to go into IKM/agp and compile and run agp_test.c:

gcc -o agp_test agp_test.c
sudo ./agp_test

Next try the same with IKM/drm compiling and running drm_test.c.

If those two test won’t fail and won’t blow your kernel it means you have fully working IEGD module on your own Linux distro.

Notes for users of old psb-modules or psb-kernel-source Ubuntu package

Older psb-modules and psb-kernel-source Ubuntu packages install their own incompatible drm.ko module at /lib/modules/`uname -r`/updates/char/drm.

Check find /lib/modules/`uname -r` -type f -name 'drm*' you should have only one: /lib/modules/`uname -r`/kernel/drivers/gpu/drm/drm.ko

In case if you find other drm.ko, probably in updates/char/drm delete it. That one came from psb-kernel-source and is causing you a trouble. You may ensure you got only valid drm.ko reinstalling your kernel image with:

apt-get install --reinstall linux-image-`uname -r`

Notes for curious

The difference of Makefile of mine and Makefile produced of install.sh is the beginning:

KERNELVER ?= $(shell uname -r)
KERNELDIR ?= /lib/modules/$(KERNELVER)/build
INSTALLDIR ?= /lib/modules/$(KERNELVER)/kernel/drivers/char/agp
PWD ?= $(realpath .)

EXTRA_CFLAGS += -I$(PWD)/include
EXTRA_CFLAGS += -I$(PWD)/../linux-$(KERNELVER)/drivers/char/agp
EXTRA_CFLAGS += -I/lib/modules/$(KERNELVER)/build/include/drm

If you try to run install.sh EXTRA_CFLAGS will include two of IKM/val folders which contain some Kernel source extracted header definitions that are likely not compatible with your Kernel.

I use also PWD ?= $(realpath .) here instead of PWD ?= $(shell pwd) because with some Linux headers versions $(shell pwd) resolves to /lib/modules path not the path where IKM sources are.

Notes for Intel

It would be nice for next IEGD release if IKM source tree would be made for readable and clear:

1. IKM/val should be renamed to IKM/kernel-headers (what the heck “val” means here ?!) and this should be noted somewhere in docs that files here are NOT made by Intel but extracted of “supported” Linux distributions Kernel sources
2. interface_abs.h should moved away from IKM/val (IKM/kernel-headers) to avoid confusion (with point 1) and placed into IKM/includes (and there should be #ifdef for this one macro that makes it different for across 2.6.30)
3. IKM/drm/iegd_interface.c should be fixed as described above (moving iegd_abs.h inclusion little bit down).
4. IKM/drm/iegd_drv.c inclusion of <include/config.h> is not necessary, may be removed.
5. Finally install.sh should contain case when running on “unsupported” distribution.
   So it shall make SURE if running on “supported” distributions and then and only then use files from IKM/kernel-headers, OTHERWISE ask for a path for your own Linux distribution Kernel source’s to find a path for your own kernel/drivers/char/agp and kernel/drivers/char/drm (include/drm) i.e. by showing:

   Your Linux distribution and Kernel version was untested, however you may try to compile and run driver on your own risk.
   Please provide your running kernel sources extracted i.e. on Debian or Ubuntu using apt-get source linux-image-2.6-686:
   [path to your kernel]:

Fell free to post your comments and problems with method presented here below using comment form!

Seems it is very hard to spread the news about CMSity around the world, and acquire some user base of this project. Till now I did few commercial deployments of CMSity, however the cmsity.com page hits look really miserable.

I wrote mails to many CMS magazines asking to drop a note about my project. However only two of them replied and posted something on their sites about CMSity. So I still miss some more reviews that can put a breathe into the project. But it seems my mails are ignored by majority of big CMS related sites making very hard to promote new project like CMSity nowadays.

Since I believe this software presents great value and outperforms other popular solutions I consider releasing it as open-source, however probably not GPL but some license that will force the code to stay by the author (me), deny all the forks, making all community changes happen to be included in the source code base.

Open-source is a great idea, but I have seen too many projects that were just bloated, forked and spoiled by masses of developers that were just about put something of themselves in the project regardless of quality of the included changes, missing overall sense and directions of the project itself. That is why I decided to keep the code closed initially, while giving the licenses for free, but it seems non-open source project are just kicked out of the focus today, and releasing the source code is a “must” to gain the momentum.

So I decided to create Haml “mod” that uses GetText (FastGettext alternatively) to automagically translate static texts from Haml templates during precompilation stage. So something that you don’t see and you don’t need to worry about.

Normally you would use _(text) calls to translate string in your templates as below:

%h1= _('Items')
- items.each do |item|
  .item
    %h1= item.title
    %a{ href='/edit' }= _('Edit')
    %a{ href='/delete' }= _('Delete')

You can see this is pretty ugly and unreadable. If you gonna have multi-language site you want to translate all of the static texts there anyway, without doing anything extra. So you would prefer to type:

%h1= Items
- items.each do |item|
  .item
    %h1= item.title
    %a{ href='/edit' } Edit
    %a{ href='/delete' } Delete

And have “Items”, “Edit”, “Delete” just translated, right? This is what my mod does. It translates all of those at precompilation stage which also is much better for your application performance, since GetText routines are called only once at precompilation stage. Here it goes.

haml_gettext.rb

# Haml gettext module providing gettext translation for all Haml plain text calls
#
# http://pastie.org/445295

class Haml::Engine
  # Inject _ gettext into plain text and tag plain text calls
  def push_plain(text)
    super(_(text))
  end
  def parse_tag(line)
    tag_name, attributes, attributes_hash, object_ref, nuke_outer_whitespace,
      nuke_inner_whitespace, action, value = super(line)
    value = _(value) unless action || value.empty?
    [tag_name, attributes, attributes_hash, object_ref, nuke_outer_whitespace,
        nuke_inner_whitespace, action, value]
  end
end

All you need is to choose GetText or FastGettext and load my mod later on.

require 'haml'
require 'fast_gettext'
include FastGettext::Translation
require 'haml_gettext'

You probably want to know the way to your gettext pot/po files out of the tempaltes. I have prepared here Rake tasks for you as well (based on work I found somewhere over Ruby blogs) to parse Haml templates extended to include static texts in the translation.

Rakefile

desc "Update pot/po files."
task :updatepo do
  require 'gettext/tools'
  require 'haml_parser'
  GetText.update_pofiles("rbigg", Dir.glob("{lib,views}/**/*.{rb,haml}") << "rbigg.rb", "rbigg 1.0.0", :po_root => 'locale')
end

haml_parser.rb

# Haml gettext parser module
#
# http://pastie.org/445297
require 'gettext/tools/rgettext'
require 'gettext/parser/ruby'
require 'haml'

class Haml::Engine
  # Overriden function that parses Haml tags
  # Injects gettext call for plain text action.
  def parse_tag(line)
    tag_name, attributes, attributes_hash, object_ref, nuke_outer_whitespace,
      nuke_inner_whitespace, action, value = super(line)
    @precompiled << "_(\"#{value}\")\n" unless action || value.empty?
    [tag_name, attributes, attributes_hash, object_ref, nuke_outer_whitespace,
        nuke_inner_whitespace, action, value]
  end
  # Overriden function that producted Haml plain text
  # Injects gettext call for plain text action.
  def push_plain(text)
    @precompiled << "_(\"#{text}\")\n"
  end
end

# Haml gettext parser
module HamlParser
  module_function

  def target?(file)
    File.extname(file) == ".haml"
  end

  def parse(file, ary = [])
    haml = Haml::Engine.new(IO.readlines(file).join)
    code = haml.precompiled.split(/$/)
    GetText::RubyParser.parse_lines(file, code, ary)
  end
end

GetText::RGetText.add_parser(HamlParser)

So this is it. Have fun with nice and clean templates that are translated on the fly

See & get more…

You can find more recent and complete code at my Sinatra Hat GitHub hosted Ruby gem project.