Monday, January 14, 2013

N9 Apps for everyone!

Let me showcase you my N9 apps here!

BWizz is a simple and efficient browser bookmark editing tool! Export, edit, delete bookmarks of Firefox, Opera and the N9 inbuilt browser!
LINKer transforms your home view in a full desktop! SHARE from any SHARE-enabled application documents, images, bookmarks (for example Spotify URI's) directly to your homeview and access them with one click!

Saturday, January 12, 2013

Supersize QT - > QT + BB10 = Awesome - kindof...

Hell yes.
So finally a new QT phone. I mean, a phone with *official* QT support  (that is available, that is - as we know, Android and WP will be supported thanks to Digia in the coming future too, and also Android is already supported unofficially via the Necessitas). This rocks. This is multiplatformness in it's purest form.
In it's perfect form! It's a perfect world! I build an application for one device (say, the only 100% swype-certified phone currently in existance, the N9 / N950) and then require *minimal* changes to my app's codebase in order for it to run on other OS'es like, for an example, Black Berry 10 (BB10). Well, not counting the few changes to support the few differences in the APIs but apart of these, there should be nothing else that would require anything more, or...is there...Because we do not WANT to have to change OTHER stuff, right? What we want, is to maximize monetization, by minimizing costs, no?
Well, f*ck that.
I think that is what is in the minds of most of the project planners of today's new OS'esses.
Why is that? Well, we have this nice and fancy UI scripting language which QT has introduced some time ago. QML, that's right. Now the C++ QT interfaces are standard. And you can't really benefit from them unless you use them; this architects seem to have understood. But the syndrome of NIH (=Not Invented Here) strikes back yet again in QML!
Yes!
BB10 supports QT Quick components (sort of). But also defines their own set of QML components: Cascades. Worst of it, they are completely incompatible. So you not only have an extremely limited support for the QtQuick components in the SDK. I am talking of out-of-the-box usage of components mind you, aka bundled in the SDK, aka I want to use a Button class from my QML file in my BB10 QT project, and it works out of the box when I press "Run" on the first time! I know now people will think "why don't you just include the ones from the Qt SDK" and on, but the heck, who wants to do it? Who takes the time? Qt is supposed to be officialy supported by BB10! OFFICIALLY goddammit! Why use that word if it is NOT true? So I was saying, on top of this, not only you get an SDK with limited support of QT's QtQuick QML, but you also get incompatibility between the QML components defined by Cascade versus the QtQuick ones! How's that? Well, check this out.

The following is an example of an out-of-the-box "QtQuick project for BlackBerry" from QtCreator 2.6.0:



#include <QApplication>
#include "qmlapplicationviewer.h"

int main(int argc, char *argv[])
{
QScopedPointer<QApplication> app(createApplication(argc, argv));

QmlApplicationViewer viewer;
viewer.addImportPath(QLatin1String("modules")); // ADDIMPORTPATH
viewer.setOrientation(QmlApplicationViewer::ScreenOrientationAuto); // ORIENTATION
viewer.setMainQmlFile(QLatin1String("qml/main.qml")); // MAINQML
viewer.showExpanded();

return app->exec();
}

Nothing special, we have our usual qmlapplicationviewer.h and stuff.

Now, the same for Cascades QML, please:

#include <bb/cascades/AbstractPane>
#include <bb/cascades/QmlDocument>
#include "myobject.h"
using namespace bb::cascades;

int main(int argc, char *argv[])
{
Application app(argc, argv);
//! [0]
// Load the UI description from main.qml
QmlDocument *qml = QmlDocument::create("asset:///qml/main.qml").parent(&app);
// Make the PizzeriaSearcher object available to the UI as context property
qml->setContextProperty("_someobject", new MyObject(&app));
//! [0]
// Create the application scene
AbstractPane *appPage = qml->createRootObject<AbstractPane>();
Application::instance()->setScene(appPage);
return Application::exec();
}

Can you spot the differences? Cause I can; and I tell you, this is *not* portable code. No SIR!
The main one is QmlDocument from BB10 Vs QmlApplicationViewer in QtQuick.

NIH wins again it seems.

Wednesday, November 21, 2012

QTCreator 4.7.4 (Harmattan) problems

If you ever happen to develope for Harmattan (probably very unlikely), and get the "Cannot deploy: You want to deploy to Qemu, but it is not enabled" error, the solution is simple.
From qtcreator -> tools -> options ->Linux devices page. Your saviour is the "Configuration" list.
Add an entry for your n9 / n950 (in case you have it not already), and put it as default. Tada.

Friday, November 2, 2012

Harmattan showcase API

Can be found from here:

http://harmattan-dev.nokia.com/docs/library/html/guide/html/examples/api_showcase.html?tab=3&q=gallery&sp=all


Showcases _everything_ your N9 can do. Including a great gallery example.

Sunday, August 12, 2012

Meego playtime #1 : libconic0

Network-aware apps on N9 usually are QT based.
But what if you want to, let's say, port an existing ubuntu package to work on the N9, say, pptp?
You have two choices:
a) you rely on QT and recode the pptp package to work on QT
b) you walk on your own legs.

I think everyone agrees on option b) being the smarter one. So let's walk!

What options do we have outside of Qt? There is an option, according to nokia development lib! It is called libconic0! How to use it? Example is here.

libconic0 has a few limitations. Namely:
  1. use non-blocking sockets
  2. have the system D-Bus running
  3. g_type_init() has to be called
  4. employ no threading support in the Libconic API  
To test the app, you can use scratchbox'es meego-run tool.

For that, you will need Xephir. See this..

(Dis)Adventures in the Land of QT

So I had bought this N9. Beautiful phone. It's only mistake was to be born 4 years too late into the world.
And to work on QT.


 I am a beginner QT developer. This might sound funny, but it is not. It is dead-serious. There is this app I am coding, and I NEED desperately in order to be able to edit the bookmarks from the default browser on my N9 (since Nokia did not deserve it the time, unfortunately).


QT sucks.

Well, not really to be honest. It is great. Really. It does NOT suck, as said, because it's portable, it's flexible, it has every thing that you need, it has tools for every thing (really!), and a language for everything. In short, in the world of multiplatform, QT is a very, very strong God. Nice. But it simply sucks. In some ways. Especially the Windows way. The multiplatformness for Windows is simply not there yet, or not as advanced as the user (=you or me) would think it is.

So, as a beginner QT developer, with a QT phone, a Windows-based machine, what do you do? You code! On your amazing N9 phone! So you download, install, and start fiddling around (and get to know) well, QT. The first thing you realize is that QT has a pretty strong and high learning curve. This is normal. It's huge. Multiplatform. Holy shit. But do not despair! There are examples! Bring up the examples, compile them, and realize after a whole bunch of time (approximately 1 hour of searching around) that some of them will never work on your phone, and for these the multiplatform lable is but that: a label.


Well, anyway. The good old extreme way of programming never failed you. So you fire up a new project in QTCreator (sounds like Populous all over again), start a new project, and...wait a moment, there are like, what, 15 project types to choose from! Wow! But which one is mines? The Qtmobile? Must be! Rewind.
So you fire up a new project on the QTCreator for Qt Mobile. A very simple "Hello world". The traditional.
Nothing extra. Compiles, packages, runs. Wow! It works! You have the proof!
Now you want to expand the feature set of your app. Where to start from? Google is your friend! Examples too, but as mentioned, not all of them work. If we assume that you :

a) have installed the examples through the SDK Installer (or QTCreator's updater).
b) have found them in the QT SDK
c) have managed to get the example to run

Suppose now you make it as far as having a C++ backend, a QML frontend for your nicely growing app.
You managed to get all the functionality in it, and have it running on the phone - but wtf? You just realized special characters are not displayed..instead, question marks (??) or other uncommon ASCII characters are not displayed. Where do you look first? I can tell you, in the string handling. And you will loose alot of time in there. Why? Because the problem is not in the string management. QT handles strings beautifully.
But there is the fact that (for apps that have to support UTF-8)  QML files need to saved as UTF-8 format in order for the QML viewer to be able to display correctly UTF-8 characters. WTF? Guess what't the default text file format ON WINDOWS?? UTF-8? Response : NO. It's some weird ISO number that I do not even want to remember. Time for searching : 1 hour & 1/2 (Total so far : 2 & 1/2).
Add another three hours to your count (if you are lucky enough to find this small note).

Want to have the confirmation of the crappy Windows support for QT?
Once this last hurdle is passed, you might actually find yourself wanting to test the app.
So you have two ways. Simulator for N9, or real device. My suggestion is : use the simulator whenever possible, debugging on real device is fucking slow. iPhone in this sense has alot better development setup.
But hah! Assume you developed a C++ QML plugin. You need to deploy it correctly. For that, you need to find the correct folder for it (which btw is /Simulator/Qt/mingw/imports). And then enter the battle of QMake, because the deployment option for the simulator is missing from QT Creator.

So, you see. All in all, Qt has alot of potential. Alot of features. And everything you need to code once and deploy everywhere. Really. The tools support for Windows, tho, can pose some challenges (especially QMake deployment).

Monday, May 21, 2012

A blast from the past - on N9!

Ah, the good old times of High school, and TP7.1...
TP stands for Turbo Pascal, in case you do not know it.
And this
is how it looked. Well, how it looks _now_ via a ssh terminal, on my N9 :).