We heard that Munich Qt Developer Days was an awesome event, which is why I look forward to the San Francisco Qt Developer Days, which will be held November 1-3.
Now, if you are from outside US, drop me an email in case you fancy some quality tea/coffee time. Even better, on the next day (November 4), Sencha will host the first Meet the Sencha Team, the first Bay Area Mobile meetup. Our team will give an overview of Sencha and the mobile technologies we are developing. RSVP and drop by!
Are you in the Bay Area? Don't miss our Sencha Touch Hackathon this Saturday (Oct 16) in our Palo Alto Office, 1pm to 5pm. There will be food and drinks as well.
Drop by and upgrade your Sencha Touch kungfu!
While we're still on the topic of JavaScript, I took the afternoon break to create a command-line runner for jsbeautifier.org . In case you miss it, I did the similar thing using Qt Script module. This time however, the command-line tool uses and exploits Google V8 instead.
If you update your clone of js-beautify repository, check out the fresh v8 subdirectory. I also mirror the code in the usual X2 repository, under the javascript/jsbeautify8 subdirectory. Also, grok the included README.txt first.
Update: I added --overwrite option which (surprise!) will overwrite the original source file (and thus, use it with care). This is useful if you invoke the beautifier tool from your text editor. Nicolas also implemented various settings support so you can specify the indentation level, braces placement, etc.
This is probably the last thing the world needs now, but hey, it was a fun break.
If you are using a modern browser, likely you already have the (arguably) most widely deployed scripting environment: JavaScript engine (or ECMAScript, if you insist). There are many things you can do with it (just look at tons of cool web apps out there). However, since it is contained in the browser, there are also things the embedded JavaScript engine can not do for you.
If you are using KDE, you also have two excellent JavaScript engines: KJS and Qt Script. You can embed either of them (i.e. KJSEmbed) and make your application scriptable. In a not-so-strange twist, they both relate (distantly) to each other via JavaScriptCore, WebKit's default JavaScript engine, because long time ago Apple forked KJS and used it as the base for JavaScriptCore, and Qt Script (for version 4.6 and 4.7) also uses JavaScriptCore as the back-end.
If you are interested in learning, using, and/or dissecting other open-source JavaScript engines, have a look at JavaScript Engines: How to Compile Them I wrote for our Sencha blog, which covers Mozilla's SpiderMonkey, WebKit's JavaScriptCore, and Google V8. The instructions should work on the supported platforms, including ARM, in case (just like me) you want to have and carry around every JavaScript engines in this planet on your Maemo-powered Nokia N900. That is fun.
As the closing, just remember, "Ask not what the JavaScript engine can do for you — ask what you can do for the JavaScript engine".
'nuff said, head to www.sencha.com/contest!
Something I worked on during my last few weeks with Qualcomm was color inversion for the web browser in Android. The patch was then integrated by Enrico (see the diff) because I switched job.
Later on this feature was also pulled into CyanogenMod. Thus, if you are running CyanogenMod 6 on your shiny Android device, you can try this feature already! In the web browser, just pick the Settings menu and then scroll a bit until you see a checkbox for Invert Color. You should get something like the captured screens below:
The idea behind this is to reduce the power consumption of Organic LED display, because on mostly-white web page, it hungrily grabs to 3x more power compared to LCD. This is similar to Jeff's trick of applying color filter in SurfaceFlinger.
Doing it at the user-space level gives one advantage: we can keep the embedded images non-inverted. Blindly inverting the entire screen would result in web pages look rather funky, especially those new sites with photos to accompany the articles. Of course, this hackish approach will not work 100%, (hint: double XOR?) since the web designer likely never intend the page to be color inverted. However it seems to work most of the time, at least with pages which do not have ueberartistic look-and-feel.
Faithful followers of my blog know that I already played with the color inversion ages ago, in the form of giving night mode appearance for QWebView. Thus, it happened that in one afternoon break I played with QtWebKit to do something similar to this selective color inversion.
Now, in the case of Android WebKit, the effect was rather easy to achieve. This is because Skia's SkCanvas is basically an interface which can be subclassed easily, while none of the functions in QPainter is virtual. The trick using Skia was to use a proxy canvas (a slight variation of Skia's built-in SkProxyCanvas) which I invented for this purpose but somehow also useful for another feature.
For QtWebKit however, we need to tweak it with some QPaintEngine voodoo. Check out the code at the usual X2 repository, find it under webkit/nightcapture (it still has some rooms for improvement, left as exercises for the adventurous readers). For simplicity, I made it as capturing tool so you need to pass a URL and the output filename. Unless you do something wrong, expect to get something like this:
The trick is the same as my approach for the Android patch: invert the colors of each image before drawing it, at the end invert the entire viewport. This seems like slow, but it's the best compromise I found out working with most sites. Note how we skip inverting any brush pixmap as usually brush is for the tiled background (and thus we want to keep it that way, i.e. not inverted). You can do some fancy magic with clipping and whatnot, but I doubt the end result is much better. Again, this whole stuff is a hack anyway and there will be always corner cases which will not work, no matter what approach you pick, thus there is no need to make it more complicated that it should be.
Just like they say, we code for life, i.e. the battery life.
Fermi problem of the day, anyone?
Assume there is this large organization, say with over ten thousands employees. For some (legal) reason, each employee needs to write down what she has been doing for the week, usually by Friday afternoon. Some record everything in details (down to the hours), some prefer to just express "8 hours doing FooBar" for every working day.
Since this is 2010, usually the system is web-based. To prevent abuse, some login/credential check and anti-bot system are also in place. It is often unheard that people use their beloved smartphones to do the job.
Let us say it takes one minute to do this. With a really conservative $30/hour rate, this is worth 50 cents. Assume ten thousands do that, so it's worth $5,000. This translates to $260,000 per year.
Of course this is just a gross approximation. It does not even include/exclude the extra time the managers spend to double-check their staff's entries, typically (much) higher hourly rates, non-working (also known as vacation time), wasted effort to setup (and forget) the reminders, occasional weekend shock at times you forgot it, and other similar (intangible) overhead. Or if you just need 5 seconds to accomplish the task. But you get the idea.
Now, $260,000 is a lot of money. You can buy a decent house in San Diego. Or two shiny Maserati Quattroporte. Or several hundreds Hummingbird-powered phones. Or, in some parts of the world, access to fresh water for the entire city all year long.
Surely for a quarter million per year some smart people will figure something out?
Developing games using HTML5 Canvas and JavaScript is simply the future. Something classic like Egor Balishev's RGB Invader, an entry in the 10K Apart, is usually my favorite.
If for some reasons (which I would not elaborate in this post) you need to deploy the game as a desktop or a mobile application, using Canvas and JavaScript gives another advantage: just package it with WebKit, for example QtWebKit if you do not mind using Qt.
However, since usually it is just about Canvas, often it is enough to run the game logic with a JavaScript interpreter and use some Canvas implementation for the display. This was something that I demonstrated before, i.e. running the Monster Evolution demo via JavaScriptCore and V8. Applying the same technique, and adjusting the shim so that it layers whatever RGB Invader requires, gives the following:
Basically it is using Qt Script (also in attempt to popularize it even more) along with a mix of C++/QObject and JavaScript machinery to fool the game code to think it's running in a browser environment. It was a nice afternoon fun project.
The code is in the X2 repository, find it under the javascript/invader directory. Get it while it's hot, and save our Earth!
There are many different ways to autoformat JavaScript code, my favorite is always jsbeautifier.org. Apparently, you can also use it locally without a web browser since it supports running it with Rhino.
It took me just few minutes to reimplement the same functionality, but using Qt Script, the fantastic ECMAScript support built into Qt.
The code is in the usual X2 repository, under the javascript/jsbeautify. Note that this is just a convenient mirror as Einar's js-beautify repository already includes this Qt Script driver.
With the rise of server-side JavaScript and desktop-esque JavaScript tools, I hope Qt Script will become more popular. It is sadly still "underrated" right now.
I have been in Qt Developer Days twice, in the previous two years. This year I am still going there, but only the San Francisco event, for the first time as a participant (as opposed to as a speaker). I'll bring other new engineers at Sencha, too.
Since I live in the Bay Area these days, feel free to email me should you want to meet for coffee/lunch/dinner. See you there!
Given an IP address, there are different ways to obtain the approximate location: online web service or offline database. It is far from perfect, but it is very useful to give some initial guess before locking into GPS signals or using WiFi-based tracking.
Today's example for X2 is actually an old code lying around which does the former: relying on IpInfoDB web service to guess where your computer is. Combined with the previous example, MapSnap, the guessed position is used to center the shown map (OpenStreetMap, of course).
Of course, as with other examples, it works fine on Maemo-powered Nokia N900 as well. Feel free to give it a try on Symbian or other supported Qt platforms.
The code is found in the usual X2 repository, under the sensor/ipgeocoder subdirectory.
For completeness' sake, let me mention also that Matteo did something similar, using hostip.info and Google Maps via QtWebKit.
Over a year ago, I showed how to render OpenStreetMap on your Qt application. While there were few follow-ups after that, I never found some time to clean it up. But worry no more, here is one OpenStreetMap-related example (at roughly 250 lines of code) I just made public, freshly available from X2 repository under the graphics/mapsnap. It's operated from command line, basically you pass the center latitude and longitude, zoom level (1..17, with 17 is the detailed, street-level zoom), output filename (e.g. mymap.png), and the size.
The following image is the result of running:
mapsnap 37.45108 -122.15917 12 sample.png 600 450
The tool will grab the tiles, more precisely Mapnik-rendered tile images, and stitch them for the final outcome:
Few weeks ago I wrote about MapQuest embracing OpenStreetMap. One positive impact of this awesome move is that you can show OpenStreetMap-based MapQuest tiles in your application. It's just the same map data but rendered using different styles. Running the previous example but with MapQuest flavor gives the following:
When checking out Qt Mobility after its 1.1 TP announcement, I found out that its Maps/Navigation API actually uses the tile data from Ovi Maps. If you read the source code, the tile server encoding scheme is pretty obvious. Since it is also based on Mercator projection, changing this MapSnap example to use tiles from Ovi Maps is a breeze: it's a matter of setting up the correct tileURL.
I'm curious about the terms of such Ovi Maps tile usage, though. Although it is more or less "exposed" via Qt Mobility and there is no API key whatsoever, surely it should not mean the tiles are free for everyone, should it? As a comparison, Google Static Maps API specifically allows only browser-based application. Feel free to share your investigation!
