ivan stojic

Since the Facebook API is still a bit crippled, and I don’t feel like polishing up a turd right now, I’m releasing the complete source code for BlueWasp on github.

It’s incomplete but features:

• changing your status
• uploading photos and sharing them on your wall/stream
• viewing other users’ walls/streams
• partially viewing comments on stream/wall posts

Download the code, fiddle around, play with it and have fun.

Waiting for Oracle to compute index statistics on a huge fucking table is mind-numbing.

And absolutely required.

Fuck.

I’m not really sure if this means that the messages from the future haven’t been delivered yet, or what?!

It seems that Mojo.Log methods to send information to application’s log suffer from several issues.

Probably the one that has struck most people is that in some circumstances, a logging call will result in nothing more but the text “null” being sent to the log.

But the more painful part is that if you send too long values (the limit seems to be about 1 kilobyte) into the logging methods to be formatted with %s or %j, you’ll just get the formatting directive replaced by a null instead of the value.

Another day, another webOS development pitfall. Suppose you have a TextField focused, where the user can enter some sort of a message text. Suppose also that you have a button which triggers a FilePicker to choose an attachment to the message. After the FilePicker ends (either with a pick or a cancel) you want the focus to return back to the TextField.

Now, when you invoke the FilePicker it’ll push it’s own scene and deactivate your one. You might think that the proper way to return the focus to your TextField is to mojo.focus() it inside the FilePicker’s onSelect and onCancel event handlers, but that won’t work: the event handlers are called while your scene is still deactivated.

Instead, before you activate your FilePicker, mark wherever the focus is. Then, in your scene’s activate handler, check where the focus was and return it there.

Suppose that you are working on a webOS application that has a hidden TextField widget. This widget is supposed to be shown when the user taps a DIV with a text which should at that time dissapear – in the web world, we’d call it an “in place editor.” Since you are a caring developer, you would like the focus to automatically go to the TextField widget after the tap, so the user can simply proceed to type in text, instead of having to tap again into the TextField widget.

Here’s something along the lines of the required setup:

Okay… everything is set, now we just need the handler code to hide the DIV and show the TextField widget. Alas, there’s one tiny bit left that needs to be done

Take special note of the last line of the tap handler. What we are doing here is stopping event propagation from the DIV to the scene controller. The default handler will otherwise steal the focus away from your widget back to the scene, and your user will end up typing into something that doesn’t listen for key presses… whoops.

I’ve been fiddling for a while now with my own kind of a window manager for X11. The idea is to build a compositing tiling window manager that 21st century needs.

Since keeping all your eggs in one basket is a bad idea, I’ve pushed the source to GitHub so I can share it with others once it’s complete.

It’s been a few days since I last wrote about using the Dvorak keyboard layout. I’ve been kinda busy with other stuff, but I am still persistently training. I’m using it when I compose e-mails and even for instant messaging. Much slower than what I used to type with QWERTY, but I’m not giving up…

More in the days ahead…

This has been my (theoretically) third day of working on learning the Dvorak layout. I’m saying theoretically because I started late in the afternoon on the 21st.

I went through all the 29 lessons available on ABCD tutorial, and finished the last one today.

How far did I progress? Well, only today did I cover the entire keyboard and the letter placements through the tutorial. I’ve been pecking and hunting until today. I’m starting to feel at home with the positions, particularly early in the morning when the typing feels more automatic, as if I were still half-asleep and not forcing it.

There’s a definite rhythm to using it. I’m starting to see why it would be so beneficial in typing the English language. Even today, as I switched out to QWERTY for some work stuff, I found myself missing the ease and simplicity of some of the letter positions.

I expect that by tomorrow I’ll start regularly benchmarking my typing speeds. My current TypeRacer account clocks me in at 96WPM average. I’m looking forward to seeing just how well I can do with Dvorak, both tomorrow and in the days to come.

Even after three days I can say with certainty – my relationship with the Dvorak keyboard layout is going to be a long one.

Ever since I filed off the keyboard caps’ labels back when I was in high school, I typed faster and faster. I can consistently get just over 100WPM with my trusty QWERTY layout.

Some things that happened to me in the last two weeks or so motivated me to try something else. I’m going to go on a limb here and start training myself to use the Dvorak layout. Since I’m mostly concerned with text at the moment, I think I’ll start off by using the normal Dvorak keyboard, and work my way up to the Programmer Dvorak variant.

Wish me good luck. I’ll be sure to keep you posted. 120WPM, here I come.