Through unimaginable hardships, we managed to pull a rabbit from the hat and get N9 done.
Schedule was just insanely tight, we got blows from all directions: Vanjoki leaving us, Ari leaving us, Elop dropping of meego from strategy, key developers leaving the company when we needed them the most.
Swipe UI, that we are now admiring, required every single application and framework to be rebuilt almost from scratch. All the blows and all the work in the course of 9 months. I never knew how much sweat and tears there needs to be to get this baby out.
What I want to say to the people who beared all that: Respect. You have my utmost respect and admiration. We didn't just do our best, we crafted the software to near perfection. Simplistic UI is easy to imagine, but extremely hard to execute. And execution includes design. Devil is in details and temptations are many. Keeping the boat steady on course needed a lot from you design and product management.
It's nothing short of miracle that the fruit of our labor is now admired by millions.
I am extremely proud of what I am holding in my hand right now. As a user, I'm loving every minute of using it and wouldn't change it for a thing.
All of maemo: I salute you. Job well done. Be proud.
Tuesday, June 21, 2011
Saturday, July 17, 2010
QML photoviewer demo on n900 with data from on-device webserver and tracker
Title says almost all.
I've been toying a bit with idea of adding a very lightweight http server to n900 to serve the primary data of the device so that development of the UI can be done nicely on PC while still accessing the real data. One might argue that just pulling the data to PC would solve this and using the existing APIs. Well, yeah, but that's also laborious if you are not linux developer, whereas this approach works beautifully for any web runtime developers as well as developers of qt quick apps.
Doing this on web paradigm allows reuse of many learnings from my past life and creates a very flexible middle layer between the data itself and the UI.
As the first thing to serve as the proof of concept, I created an ATOM image http service on the device. It follows directly the format of flickr, so any code written to show flickr images can be converted to showing n900 images - either on the pc or on the device itself. Data is retrieved from tracker and thumbnails are also trackers pre-generated thumbs.
And here's the beef of course. Once the UI code is working nice and all, it can be just copied to the device and it'll just work. As a demo, here's vanila n900 (no overclocking) running both the server and qt quick application without any noticeable lag. Of course the devices thumsbs suck, as they don't have an aspect-ratio retained version available.
Web server also works as a very nice access control layer between a runtime that can be now very sandboxed. Not that I care.
I've been toying a bit with idea of adding a very lightweight http server to n900 to serve the primary data of the device so that development of the UI can be done nicely on PC while still accessing the real data. One might argue that just pulling the data to PC would solve this and using the existing APIs. Well, yeah, but that's also laborious if you are not linux developer, whereas this approach works beautifully for any web runtime developers as well as developers of qt quick apps.
Doing this on web paradigm allows reuse of many learnings from my past life and creates a very flexible middle layer between the data itself and the UI.
As the first thing to serve as the proof of concept, I created an ATOM image http service on the device. It follows directly the format of flickr, so any code written to show flickr images can be converted to showing n900 images - either on the pc or on the device itself. Data is retrieved from tracker and thumbnails are also trackers pre-generated thumbs.
And here's the beef of course. Once the UI code is working nice and all, it can be just copied to the device and it'll just work. As a demo, here's vanila n900 (no overclocking) running both the server and qt quick application without any noticeable lag. Of course the devices thumsbs suck, as they don't have an aspect-ratio retained version available.
Web server also works as a very nice access control layer between a runtime that can be now very sandboxed. Not that I care.
Sunday, June 13, 2010
NuvoFre 1.0.8
A quick peek at the next nuvofre is out in case you want to try it out.
I'll fix an issue in calendar coloring before I will put the next version of theme maker out.
Theme is using the nice bundled tahoma font, icons are oxygen icons from kde (kudos guys), transitions have been tuned to feel more flowy.
Download: NuvoFre_1.08
As said, grave issues with calendar, otherwise it should rock.
A few shots:
I'll fix an issue in calendar coloring before I will put the next version of theme maker out.
Theme is using the nice bundled tahoma font, icons are oxygen icons from kde (kudos guys), transitions have been tuned to feel more flowy.
Download: NuvoFre_1.08
As said, grave issues with calendar, otherwise it should rock.
A few shots:
Wednesday, May 05, 2010
Harmattan + Meego Here I come
I have moved now away from Fremantle to Harmattan and Meego. This doesn't mean that the maintenance is stopping for Fremantle in any way, just that the coordination effort on OS & MW has lessened and my presence is not needed so much anymore.
I would like to take just a sec also to address the comments about the leaked firmware. It is indeed not the final Pr1.2 firmware, and there are reasons for it. So, if you find severe issues in it, don't be surprised. If it only had minor issues, it would have been published already. We are often finding still some new major issues in the stabilization phase. It's normal for big projects.
So, what am I doing now then? I am looking after the Harmattan Maemo API to make sure we have a solid 3rd party API and there is a clear continuation path for everything that would change for Meego. At the same time I'm working as a catalyst for the Harmattan software program. This catalyst role is naturally a bit vague and I'm often afraid whether I'm doing more harm than good after being so long time away from Harmattan development, but it looks like I'm able to pick issues every day that do push us a clear step closer to the target. Let's see how long this continues. But what I really focus all the time is the Maemo API.
What does the Maemo API work mean in practice? It's about defining together with the architects the Application development APIs and the platform APIs. The distiction between these two is that every single API of the former should stay the same in Meego and maintain API and ABI compatibility. For the latter, we yield that they are needed for development of many applications but we deem those may be subject to change for various reasons (be that that we know a better one is around the corner, the API is unstable or even that we just happen to be uncertain what will happen to the API in the future), and thus if you use those APIs on your app, they might need tuneups before they work on the Meego handheld platform.
In addition to only the pick and mix work of selecting the APIs, I'm also actively trying to look for issues we might have in the APIs that restrict certain types of development. It's a common case that we have been looking solely for our own needs (or Intels) on many cases, but we have forgotten that small detail that would mean the world for some 3rd party developers. I would be naive to think that I can somehow find all the issues and get them miraculously fixed. Indeed not, but I have some talented help and I'm sure every improvement is a step to a better direction.
I'm not exactly certain if I can discuss about the inititives that I have started or the issues I have found, so I'll leave discussion on those until I have chatted with Quim Gil about it. In the meanwhile, please do contact me if you find issues in the APIs that has been published in the SDKs or in the open repos like gitorious for Harmattan Maemo API.
Oh, why is it Maemo API and not Meego? Well, we are still using the low part of the stack from maemo and haven't merged to meego lower levels, we use still different packaging system, and tons of other reasons that have been voiced out probably many times before.
I would like to take just a sec also to address the comments about the leaked firmware. It is indeed not the final Pr1.2 firmware, and there are reasons for it. So, if you find severe issues in it, don't be surprised. If it only had minor issues, it would have been published already. We are often finding still some new major issues in the stabilization phase. It's normal for big projects.
So, what am I doing now then? I am looking after the Harmattan Maemo API to make sure we have a solid 3rd party API and there is a clear continuation path for everything that would change for Meego. At the same time I'm working as a catalyst for the Harmattan software program. This catalyst role is naturally a bit vague and I'm often afraid whether I'm doing more harm than good after being so long time away from Harmattan development, but it looks like I'm able to pick issues every day that do push us a clear step closer to the target. Let's see how long this continues. But what I really focus all the time is the Maemo API.
What does the Maemo API work mean in practice? It's about defining together with the architects the Application development APIs and the platform APIs. The distiction between these two is that every single API of the former should stay the same in Meego and maintain API and ABI compatibility. For the latter, we yield that they are needed for development of many applications but we deem those may be subject to change for various reasons (be that that we know a better one is around the corner, the API is unstable or even that we just happen to be uncertain what will happen to the API in the future), and thus if you use those APIs on your app, they might need tuneups before they work on the Meego handheld platform.
In addition to only the pick and mix work of selecting the APIs, I'm also actively trying to look for issues we might have in the APIs that restrict certain types of development. It's a common case that we have been looking solely for our own needs (or Intels) on many cases, but we have forgotten that small detail that would mean the world for some 3rd party developers. I would be naive to think that I can somehow find all the issues and get them miraculously fixed. Indeed not, but I have some talented help and I'm sure every improvement is a step to a better direction.
I'm not exactly certain if I can discuss about the inititives that I have started or the issues I have found, so I'll leave discussion on those until I have chatted with Quim Gil about it. In the meanwhile, please do contact me if you find issues in the APIs that has been published in the SDKs or in the open repos like gitorious for Harmattan Maemo API.
Oh, why is it Maemo API and not Meego? Well, we are still using the low part of the stack from maemo and haven't merged to meego lower levels, we use still different packaging system, and tons of other reasons that have been voiced out probably many times before.
Subscribe to:
Posts (Atom)