Monday, December 30, 2013

Quick update on the N9 vs Jolla sync

A step was missing; thanks to Christopher Lamb for pointing it out.

Wednesday, December 18, 2013

SailfishOS vs Self-signed Exchange server certificates

In case you self-signed your Exchange certificate, or are trying to access a server which has a self-signed certificate from your Jolla, make sure to download the certificate and copy it over to the phone. For this you will need to enable developer mode, and scp or WinSCP (if you navigate Windows waters).
  1. "Export" (download) the certificate from the website you are trying to access in PEM or CRT format
  2. enable developer mode on your Jolla
  3. copy the downloaded file to /etc/ssl/certs
  4. reboot

Thursday, November 28, 2013

Sailfish OS : dev mode of Other half / Jolla & Win 7

Developer mode under Windows 7 might not work as expected.
Reason for it seems to be Win7 host ip configuration to be not usable.
Fix for this is easy.
First, configure developer mode on the jPhone:
1) enable dev mode
2) set password
3) optional: set ip address for usb connectivity

Then configure Win7 host:
1) connect your jPhone with usb to the Win7
2) from the pc, open network & sharing center
3) select "Change adapter settings"
4) open the adapter labeled with "Remote NDIS based Internet sharing device"
5) go to properties
6) select entry  for IP V4
7) enter a static ip (in the same subnet of the phone). So if your phone has 192.168.2.15 (default), you can put 192.168.2.10 for example
8) set phone ip address as gateway & dns entries as well.

Wednesday, November 27, 2013

Sailfish OS vs N9 sync

So finally!
Sailfish OS in hand, happy me!
But! How to sync all data from n9?
Easy, four steps:
1) connect both phones via bluetooth
2) from n9, once devices are paired, go to "Settings" -> "Sync and backup"
3) select sync
From here you can select your Jolla phone, and by clicking on it you can define what to sync.
4) configure sync


Saturday, November 2, 2013

Sailfish development : application templates missing

It so happened that upgrading to the latest Sailfish Alpha release broke my QtCreator templates.
Symptom of this manifested in missing project templates for Sailfish applications. Exactly the same issue that is mentioned here . Luckily, removing   ~/SailfishOSAlpha2 directory fixed the problem.

Sunday, July 21, 2013

SailfishOS under Win7 and user's home restriction

So I have been hanging out in Jolla's waters lately.
SailfishOS comes packaged with two virtual machnes (running under Virtual Box);
one for the building tools
one for the emulator


Problem is by default the building tools vm requires projects to be placed under the user's home directory. Under Win7, that directory is C:\users\<username>;
in this folder, the installer will generate a .scratchbox2 folder, which configures (as the name says) sb2. This location is shared to the Virtual machine via VB's shared folders.
These can be relocated (whilst the machine is powered off) from the VM's configuration.

  1. Start Oracle Virtual Box
  2. Make sure MerSDK VM is powered off
  3. Open Settings page for MerSDK
  4. Select the "Shared folders" on the right
  5. Change the location of the "home" share to your wanted folder
  6. The new share will automatically be named as the same folder you just chose in step 5, rename it to "home"
Now you would think this to be enough; but whilst the machine will run fine in this setup, all your sb2 targets will be gone. Luckily copying the .scratchbox2 subfolder found in the original location (C:\users\<username>) to the new one fixes this issue.

So full steam ahead, yer scummy sea guls! No more excuses to soak the deck with your lazy ass'es swet anymore! Arr!

Friday, May 24, 2013

Planet MeeGo, Day #2 : THe lost bricks, or : if you go back now, you really are a n00b!

So!
We've landed on planet meego (intentionally or not, it is still unclear to me, but whatever).
We've understood there is more than QML on N9 : N9's soul is composed by MeeGo.
What is MeeGo? Or, wait, let me refrase : what was MeeGo?
MeeGo was meant to be the leading platform in mobile linux.
Born out of the two gods of linux Maemo and Moblin, the chimera MeeGo lasted, well, some laptops (funnily, my sister managed to get one by accident), and one mobile phone.
Reasons for this early death (Cripple Death Syndrome?) have been discussed and overdiscussed in other threads on other forums, and are not the center of the discussion here.
The center of the discussion is MeeGo, and more specifically developing under MeeGo.
So, how do you develope an application under MeeGo? You google : MeeGo Application, and this comes up. Too bad it's not MeeGo, it's QtQuick.
Let's try again:  google meego application example"; QML/QtQuick again!
"Wtf? Where is my MeeGo?". 

Right behind an obscure google term : meegotouch (third hit in Google, I mentioned even Google rules do not apply to MeeGo searches). Btw, according to some rumors, all the links should be removed by end of May by the Linux Foundation. This is not confirmed yet, so be not surprised if the links point to void. Just a heads up. In case it is going to happen, you should still be able to navigate the sites through the wayback machine (or some other mirror). Also, most likely many of the information in here might apply to SailfishOS as well, Jolla's upcoming MeeGo-based OS.

So anyway, we found our MeeGo! Wooho!
Building a MeeGo application seems easy. And it is, as can be seen from here.
According to Nokia Docs, a linux is preferred in order to build MeeGo apps.
I have been working with both WinXP and Win7 without many problems (well, maybe in WinXP some problems, but not under Win7 anymore). Yes, it is a bit more challenging, and yes, it is not as straightforward; and yes, if you are an absolute Free SW type of guy, and Wind0wz horrifies you, there is no reason to use anything else except linux (the only reason I am stuck on Wind0wz is due to lack of capacity to run a virtual machine with satisfying results). But this is not the point of the discussion now anyway.
Also, according to the above-mentioned docs, the MeeGo is referred by Nokias as part of the Platform SDK. But to me it seems more like meego *is* the PlatformSDK.

I think the most useful concept is the strictly Model-View-Controller architecture pattern of MeeGo.
As well as iOS (and probably Windows Phone), MeeGo separates the three in a very strict manner. This of course has positive and negative aspects. For example, if you do not know what MVC is, you will face a very hard time trying to figure out how to do things on your own.
Let's take the styling features as an example.
Did you know you can auto-generate styling components out of a simple interface (declared appropriately)? It is indeed, very easy. Two things are required:
  1. A (style) class declaration
  2. QtCreator declarations in .pro file to configure the helper tools to generate class stubs for the declared (style) class
Instructions on how to follow up on this can be found here.

Once the qmake is properly configured, and the files are properly included in your app, the MeeGo Application will autostyle itself, by looking up the stylesheets in predefined (Theme-based) paths.
This not only perfectly separates the look-and-feel from your C++ code; it also simplyfies your life as a programmer alot. Of course, this is deprecated technology, so it opens up doors to all kinds of weird (sometimes buggy) behaviours as well, but hey, it works, and so far I always found a work-around for some of the issues no problem.

But why MeeGo? Is this all it has to offer over, say, Qt and/or QML? Is it worth the catch?

Well, N9-technically speaking, yes. From a practical point of view, MeeGo tried to fuse the positive aspects of both worlds and combine them to a powerfull toolkit.
MeeGo escapes the clumsyness of QML (and well over its limits in many aspects, speed being the first one) and frees the programmer from the burden of managing alof of necessary UI-related functionalities, as well as giving a much better degree of flexibility and lean-ness, by providing out-of-the-box tools (like the styling, for instance) that Qt is missing.

Of course, there is also the fact that MeeGo is a dead platform (except for SailFishOS, but the extent of the compatibility with it is still to be confirmed IMHO. QML was supposed to be cross-platform, but as we have seen, on BB10 this is not the case (QtQuick vs Cascades)).

Monday, April 8, 2013

Planet MeeGo day #1 - The Dark side of N9, or : trust your instinct, n00b!

So!
I have been tricking around with N9 for a while now.
I must say.
This is a great Phone (if we consider it should have come out back in 2010/11)!
This could have been a great OS!

So I have developed so far two applications, LINKer, and BWizz (both are available in free and paid versions from OVI/Nokia store, btw).
In chronological order, they manifested as :
  1. BWizz, a bookmark editor.
  2. LINKer, an utility which gives you access to any file on your Phone, directly from your home screen (which originally only allows for Apps / Applets / URL bookmarks).
Whilst the first one is a "normal" QML-based application, the second one goes a step further, and dives a bit more into the wreck of MeeGo, specifically in the Share-ui capabilities of the OS (which I personally like as a concept, but is nothing new, as Android and now BB10 has as well).

Somehow, all this time I had been working with MeeGo, it felt as if I was working with a huge woolen ball;
twisted, complex, confused. The main reason for this feeling is most likely due to the fact that I could never get ahold of the "big picture". Already documentation is so fucking scattered around that your stamina will drop! There is harmattan-dev, when it is not offline, that is, and then there is the MeeGo Wiki (with it's own forum), the Maemo forums, the Qt documentation, some blog here and there (including this), the code base on gitorious - which btw is in the end the best resource for everything, really; the power of open source was strong in this OS indeed!

You would say with all these sources, the clearance (clearance, mind you, not coverage) about the OS is top-notch. Wrong! This whole scattering causes only frustration and loss of precious time spent jumping from one location to the other, trying to figure out which one is the one containing what you are looking for. For some kind of destiny joke, even Google seems to be obscure  So, if you were looking for information on architecture / QML / Qt, then most likely the Nokia pages in harmattan-dev are by far the better ones. For anything else, and I really mean anything else, everywhere else but harmattan-dev is a better place.
"Thank God there is everywhere else then", you would say. Wrong againg. harmattan-dev is the only place which actually has some structured information (albeit still messy and sometimes very, very vague).
So, whilst harmattan-dev is the normal starting point in your Journey To MeeGo,and is a good strating point,
since it covers every part required to publish a QML / Qt application to the Nokia store, everywhere else is nowhere else. It is a non-place! As you take a leap of faith and decide to step out of this "perfect Nokian Qt + QML" world, in which everything is perfect, but everything almost never works as it should, you will notice the even the normal laws of Googling do not apply anymore! Pages with the most hits for your search terms will not appear on Google's main page anymore! You will find yourself treasure-hunting together pieces of information for a certain topic from the most unexpected locations, and in the end you will still be back at square one because in the mean time the reason for the search will be erased from your mind. And this for every single problem you face. For example, Maemo forums is a great place to find even very obscure information tidbits of various topics. If you know what you are looking for. How do you know that? By trusting your instinct. Because that is the way it has to go.
After LINKer, I felt something was missing. In my decent experienced IT life, I have seen may OS'es, and somehow always managed to get a good glimpse of how they worked and what was going on "behind the scenes" in a fairly fast time. With MeeGo, this was not the case.
 I had made two applications. One on QML (BWizz), which in my opinion was already quite deep (based on Qt Plugins and so on), and the second one (LINKer) based on lower-level Platform services (Share-ui and libContentAction). So by then I had a pretty clear idea of the structure; and I started toying around with various concepts for my third application. For this application, I decided I wanted to make an overlay. An overlay like the notification banner, for instance. And this decision, like some crazy curse, or spell, opened up the dark hearth of MeeGo in front of me. There was no way to find how to make such beast in QML (QML requires a window, which I did not want). So, I had to start looking elsewhere.
After some initial lookaround, it became clear that at Nokia-(Platform) level I would have not found what I was looking for.
There must have been more to it!
So I decided to turn to the Gitorious codebase of MeeGo; as google kept on pushing up these results and as I am a n00b. And there, in all that which seemed to me like a pile of abandoned books, ruins of something that should have been but was not, I started searching through code and code. And guess what? The first thing I noticed, was that there was very little QML. NO QML! What the hell? I told to myself. N9 is supposed to be QML based? So wasnt I supposed to be able to make everything in QML? Where was the shiny and fancy, easy-to-use Nokia world of QML? Where were all the quick components? Why were they not used? Why was here libmeegotouch, meegotouch, contentlib, theming, a complete separate (MeeGo-) widget etimology based on Qt, buried and hidden away? Why did these MApplication, MButton, MLabel, and on keep on popping up? What was this...second personality of N9?
It turned up there was much more than QML. MUCH more than that.

Tuesday, March 5, 2013

BB10 screenshots from Alpha Device

It seems the easiest way to take a screenshot from the alpha device is to keep the volume up and down buttons simultaneously pressed! Wow!

LINKer goes BlackBerry!

Startin today LINKer is available on BB10!!!

http://appworld.blackberry.com/webstore/content/21197956/

Get it while it's hot! 

Thursday, February 7, 2013

Android apps

LINKer is now available on Android!
Grab it!

Wednesday, January 23, 2013

Walk the line : The hard way of the negative feedback

Today I was confronted heavily on many aspects of some tools (which I will mention as "ToolX") I have implemented. I will put this as "feedback" as calling it "critics" is limiting (it was not all disruptive but also constructive).

Anyway; the sense of it is simple : getting feedback is easy; taking it is hard.
The first reaction to feedback is usually very well described by the following situation:
You sit at work, a co-worker comes up to you.
"Hey xx, I have a problem with tool xx. It does not do it's job."
I am pretty sure that this situation hits (or has hitted) alot of us.
Out of the frequency this event happens, you can give a score to the value of your work. This is why it is important to not just say the following :
"What? Impossible, my tool xx is awesome and works!"
 or
 "You must have used it wrong!"

 Which, translated into practical sense, equals to NOT listening.
 An answer like the following:

"What is the issue?"
or
"What's the matter?"
would probably be more appropriated.
So this seems easy so far - unless you have attitude problems (like myself); but then it's bad luck and failure until you learn your lesson (which might take some time, I tell you).

So, assuming your colleague did not run away chasen by you, the next thing you will have to figure out what is wrong with ToolX. Is it working? Yes/No? If no, what is the cause? Your colleagues wrong usage of the tool? a bug in it? environmental conditions (for example file shares offline...)?
In the end, alot of issues to go through. Assuming there was actually an issue - either in the user's usage or in the tool / environment required by the tool to run, the result might be :
"Ah, I did not know I had to do it like this"
or
"Ah, there is a bug!"
or
"F*ck, why is this server offline?"
Anyway, the outcome can be various.Usually if a bug is found, a discussion about the tool might emerge, and if the galaxy stars happen to be in the right configuration, you might be as well as lucky as being able to collect some feedback on ToolX. The form of this collection is purely passive; meaning the User will give a (usually oral) list of issues that he / she has encountered during his/her life making use of ToolX. See, here is the first challenge: Organizing feedback transfer. But let's not focus about that, there is plenty of documentation on the topic already.
What I want to focus on, is the magic moments of the conversation in which you will get negative feedback on ToolX. Why? It is easier to put it in a metaphor:
a feedback collection (from your point of view) is a race that your tool is being putted into, to evaluate it's performance. If the tool fails to achieve the race's goal (which it probably already did, for an example in the situation given above) or completes the race poorly (which means the User's list of bad feedback is LONG), your tool is most likely not up to the task
This reality might hit you; but also, you might not even hear it, because your self-protection mechanism will automatically switch the areas in charge of common sense of the brain off.
So the reaction can be two fold, either you listen and do not take action (because you did not really listen to the feedback), which I will herein call SCENARIO#1, or you take the reality: you have a shitty tool and do something about it, which is SCENARIO#2.

So far for the consequences. But how to be able to decide which of the two abovementioned outcomes to go? In the case of SCENARIO#1, you are obviously not in control of yourself anymore (at least not directly), because you will simply ignore the input from the User. Do not get me wrong, you will still hear it; but it will go through your ear (in through one and out from the other) like air.

The solution is being able to recognize when your brain shuts down.

Whenever you get feedback, ask yourself:

- how many questions about the feedback have I asked?
- how many valid feedback points (out of the ones mentioned by the User) have I collected?
- how much chance for feedback have I given to the User?

I think the most tricky being the third one:
Usually, on negative feedback we react with defensive walls or "counterattacks" like
"No you did it wrong" 
or
"No the server was down" 
or even
"You do not know what you are talking about" 
and on.

The more of these whe shout out, the less feedback we have collected, the more we are sliding in SCENARIO#1.

Any of these "counterattack" reduce the chances of feedback for the User, for various reasons.
It makes absolutely sense to let the User speak. Even if his thoughts are nonsense, let the User speak.
You can decide later on what to do with it (provided you remember it).

I think this could be a good reminder for myself. Feel free to use it for you too, if you think it might help :).

Friday, January 18, 2013

LinkStation ROCKS!

So it happens I am starting to have some code laying around.
On my laptop. From 2007. Commercial code.
So I figured it is time to get a decent safety solution.
At work, we used this LinkStation Duo (or something) from Buffalo.
I was quite impressed, because once you get into it, it is almost a fully-fledged linux system.
So yeah, armed with the good experience earned on the LinkStation Duo I decided to go for a similar box,
and was lucky enough to hear from a colleague that he was selling this LinkStation LS-WXL.
I did not miss the chance, picked it up, brought it home, installed it, and worked my way into it.
It took some time, but thanks to the good articles over @ Buffalo NAS-central it was more or less straightforward.
So, I have hot source, and need a place to store it. Did I say SVN?
Piece of cake!
By following this link now I have a fully-fledged NAS running SVN :). Worktime? 1 hour! :)

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 syndrom 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.