csant/log

Norwegian survey calls have this in common: the callers are extraordinarily rude (extraordinary with respect to the generally mild and friendly nature of Norwegians). They start an all-smiles call in speedy Norwegian, and as soon as I ask them to either repeat at a slower pace or in English please - depending on my mood…

…they hang up. No sorry, no can we call you back at some more appropriate time?, no oh, we are doing this only in Norwegian. It really must be a bloody waste of time to get a foreigner on the other end of your call.

We decided to release the special Opera OLPC Edition for everybody to test on the target device. This build fixes the nasty javascript freeze that would kill your machine, and comes with its custom skin and toolbar.

What is different WRT a normal desktop build?

• made with gcc 4.1 (instead of 2.95)
  
• Qt 3.3.7 (instead of 3.3.5)
  
• custom skin
  
• custom toolbar
  
• custom opera6rc
  

Yes, that's all there is different Many thanks to Helmers and Toman for work on the skin, to Huibk for work on the toolbars, to Eddy for the packages - and many thanks to the full desktop team!

Opera runs smoothly out-of-the-box, and now even more so - at least on the BTest-1 machine we tested it on.

And how does Opera run on your OLPC XO?


P.S. Note that you can run the build also on a normal desktop Linux box - but make sure you read all the warnings first.

Elsewhere I already have declared my love for the CLI - as I said back then, interaction via the command line is all about dialog. When interacting through a keyboard, your two choices are either to remember the exact binding for a specific action, or to start a dialog, telling your application the actions in plain English. Well, almost…

I have never really understood why CLI and GUI should be antonyms, why you should either enjoy graphics and be forced to point-click-drag-and-drop interaction, or dwell in the terminal, uttering your commands in lonely dialogs with the machine. It's really not that I don't like terminals - but for a few tasks graphical approaches are simply better. And browsing is one such task.

There is no reason not to have the power a command line offers, available also in GUIs. I am not currently aware of any major GUI application that spouses the two interfaces - the closest you get are some TUIs, Emacs or (I am told - no gamer myself) some games, such as Quake. Well - until a few days ago Rune came to my office…

tab 0 > go http://opera.com/
Loading http://opera.com/
tab 0 > newtab
Created tab number 1
tab 0 > showtab 1
Switched to tab number 1

Imagine your focus moving only between the document and one mini-buffer to issue commands with, or to get some feedback from the active page:

tab 1 > go javascript:alert('hi');
Window got an alert:
"hi"
tab 1 > answer ok
Dismissed alert
tab 1 >

I could go on forever telling you how much more sense it makes to have the login dynamics of a terminal in the case of HTTP authentication, to be able to query document information from a prompt and not to have either move my focus to a panel or to get intrusive dialogs, etc… This approach is just the most fabulous interaction - made possible by… our WebUI. Yessir, a UI for Opera, created using only standard Web technologies, such as HTML, CSS, JavaScript and DOM. Let me note one thing: the console UI is not the default WebUI the SDK is shipped with - it is just another possible UI, one of infinite possibilities open there to Web developers: unleash the powers, be creative!

tab 0 > version
Web UI console rev. 2080

(And a very personal thank you to Rune for dreaming up this UI)

N.B. The WebUI is a feature of the opera 9 SDK for devices.
P.S. The screenshot shows one of the possible console UIs, à la Quake - there is a binding to toggle the mini-buffer overlay on or off.

I've been happily running the apache httpd server for quite some time now, and upgrade has always been only a matter of running ./config.nice from the previous installation - it's quite a hassle to get your initial configuration, but upgrading is trivial. But then, when upgrading from 2.2.3 to 2.2.4…

Configuring Apache Portable Runtime Utility library...

checking for APR-util... yes
configure: error: Cannot use an external APR-util with the bundled APR

I seem to be not the only one having this problem.

Running ./config.nice --with-included-apr configures fine and solves the problem. Would have been nice to point out somewhere that the changes done with respect to APR calls do require this flag to force use of the bundled version of APR at build time.

3DLabs is demonstrating its DMS-02 multimedia-oriented SoC (system-on-chip) running the Opera 9 browser […]

A small, neat piece of news, that easily slips through the meshes of the big media…