Press Release
Every day Packt Publishing is giving away books for free to help teach new tech skills.
From 30th April, 2015 Packt Publishing has thrown open the virtual doors of its new Free Learning
Library and offering its customers a daily chance to grab a fresh free eBook from its website. The publisher is encouraging people to learn new skills and try out new technologies and so every day it will be offering a different eBook from its huge list of titles free for anyone to download.
The Free Learning Library will be open all year-round but each title will only be up for 24 hours, so make sure you keep checking back to get your hands on the latest book! Packt has well over 2000 titles published and the range of topics that could potentially feature is huge. From AngularJS to Zabbix, there's going to be something to appeal to everyone - this is a great opportunity to try out a different technology or a new technique.
All you'll have to do is simply click on the day’s free eBook and it will instantly be added to your account.
New customers are also encouraged to take advantage, with the offer being a brilliant chance to try out
Packt's great range of books and products – all that’s required is a Packt account.
Wednesday, May 27, 2015
Free Learning Forever Campaign
Wednesday, May 6, 2015
Packt Publishing offering about DRM-free content
Packt running a campaign to
support 'Day Against DRM':
Packt Publishing is offering all its DRM-free content like ebooks & videos at $10 for 24 hours only on May 6th. Please find the link here : bit.ly/1clU3YZ
We believe that you should be able to read and interact with your content when you want, where you want, and how you want – and to that end we've been advocates of DRM-free content since our very first eBook was published back in 2004.
Packt Publishing is offering all its DRM-free content like ebooks & videos at $10 for 24 hours only on May 6th. Please find the link here : bit.ly/1clU3YZ
Packt celebrates International Day Against DRM, May 6th 2015
Packt Publishing firmly believes that you should be able to read and interact with
your content when you want, where you want, and how you want – to that end they
have been advocates of DRM-free content since their very first eBook was published
back in 2004.
This year, to demonstrate their continuing support for Day Against DRM, Packt is
offering all its DRM-free content at $10 for 24 hours only on May 6th – with more than
3000 eBooks and 100 Videos available across the publisher’s website
www.packtpub.com, there’s plenty to discover, whatever you’re interested in.
“Our top priority at Packt has always been to meet the evolving needs of developers
in the most practical way possible, while at the same time protecting the hard work of
our authors. DRM-free content continues to be instrumental in making that happen,
providing the flexibility and freedom that is essential for an efficient and enhanced
learning experience. That’s why we’ve been DRM-free from the beginning – we’ll
never put limits on the innovation of our users.”
– Dave Maclean, CEO
Advocates of Day Against DRM are invited to spread the word and celebrate on May
6th by exploring the full range of DRM-free content at www.packtpub.com - all eBooks
and Videos will be $10 for 24 hours, including the latest hot titles.
Packt Publishing firmly believes that you should be able to read and interact with
your content when you want, where you want, and how you want – to that end they
have been advocates of DRM-free content since their very first eBook was published
back in 2004.
This year, to demonstrate their continuing support for Day Against DRM, Packt is
offering all its DRM-free content at $10 for 24 hours only on May 6th – with more than
3000 eBooks and 100 Videos available across the publisher’s website
www.packtpub.com, there’s plenty to discover, whatever you’re interested in.
“Our top priority at Packt has always been to meet the evolving needs of developers
in the most practical way possible, while at the same time protecting the hard work of
our authors. DRM-free content continues to be instrumental in making that happen,
providing the flexibility and freedom that is essential for an efficient and enhanced
learning experience. That’s why we’ve been DRM-free from the beginning – we’ll
never put limits on the innovation of our users.”
– Dave Maclean, CEO
Advocates of Day Against DRM are invited to spread the word and celebrate on May
6th by exploring the full range of DRM-free content at www.packtpub.com - all eBooks
and Videos will be $10 for 24 hours, including the latest hot titles.
Thursday, February 19, 2015
Wonderful opportunity to grab some free and nice books
Press
Release
Packt
Publishing Encourages Customers to Learn New Skills with 18 Days of
Free Learning
Packt Publishing
is encouraging customers to develop new skills and try new
technologies with 18 days of Free Learning. Beginning on Monday 16th
February, the publisher is inviting customers to claim a free eBook
every day to learn a new skill and to get to know the wide range of
technologies and subjects that can be found across their extensive
library of titles.
Each eBook will
only be available for free for 24 hours – so make sure you visit
Packt’s website every day from the 16th February to
March 5th to grab your daily Free Learning fix. With such
a wide range of topics tipped to potentially feature – from Drupal
to Learning Play, Magento to Moodle, Selenium to OpenLayers, Maya
Programming to Linux Shell Scripting, Redmine to BackTrack - be sure
to take this opportunity to try something new.
All customers
have to do is simply click on the day’s free eBook and it will
instantly be added to their account. New customers are also
encouraged to take advantage, with the offer being a great
opportunity to get to know Packt a little better – all that’s
required is a Packt account.
Find out more:
<bit.ly/1ECubjf >
#freelearning
Sunday, January 18, 2015
CMetronome
Geek and nerd musicians do not need GUI, do they? You can obtain the release from here. It is already available in AUR for Archlinux. It requires the pulseaudio sound server. It does not depend on any of Qt, just C++. Do not forget about voting in AUR if you like the software. ;-)
Friday, October 4, 2013
Release: cutepaste
You can obtain the release from here. It is already available in AUR for Archlinux (do not forget to vote if you like ;).
 |
| Cutepaste in action |
Thanks go to Sayak for providing this service!
 |
| KDE Paste web client |
Wednesday, July 24, 2013
Yocto: mature or not?
This is a bit of fun spoiling post, but sometimes we need to become constructively critical in order to improve the situation. As you may already know, Yocto has been advertised as the relatively new technology for creating custom distributions for you. Although, people commonly use Poky, Arago, and so forth ready-made distributions on top of Open Embedded.
 |
| Yocto Project |
Cross-compilation
So, here is the critical issue for embedded developers using the cross-toolchain provided by Code Sourcery why I personally think that Yocto might not be usable for the moment for commercial projects where reliability is a main concern.
In short: it does not work if you would like to build the distribution (for instance stock Poky) for your embedded board, like ARM with the sourcery toolchain.
What makes me worry a bit more, this cross-toolchain environment was working in the first half of 2012 yielding some regression in here. That opens up new concerns about QA, right? It is fundamentally broken and can be reproduced easily as acknowledged in the bug report above, yet the changes got in.
One could suggest to revert back to the very old and unsupported version. Well, it is unsupported first of all, so you cannot reliable base a commercial product on top of it. More importantly, that version has a lot more issues. I have tried to back port fixes to that release from master, but I have not had so much fun. I experienced many merge conflicts and so forth.
 |
| Cross compilation |
Unsupported Archlinux
It is a bit disappointing that such a common distribution as Arch is not supported. Please do not write me that they do not enough manpower. I fully understand and appreciate that. Yet, it means Archlinux developers are in trouble.
 |
| Archlinux |
Unsupported releases
They, kinda, support two releases back. They have a time based release cycle. One new release comes in every half a year. This brings us to the point that they only support your selected software version up to maximum one year. That is not so comfortable when you need a reliable product. I just faced the issue yesterday that there are fixes in old release branches, but no one has cared to release them for more than half a year. They will probably not be released either. I am now referring to the denzil version coming from April in 2012. So, it is not quite like the Linux kernel or Ubuntu LTS.
 |
| Long Term Support (LTS) |
Error reporting
I think this is also a hard sell in Yocto as of now. There are issues that I could not simply figure out on my own as a newcomer without quite a bit of time with analyzing, especially when the public documentation is not up to the task either. There are several issues which made me spend a few days just to understand them, and that what is going on underneath.
The first bogus error reporting is about bblayers.conf file mismatch based on the generated file and the sample available. It was even hard for others to provide some help on IRC who have been experienced with the project. Here you can read the details about it.
Then, there is the issue of mismatching cross-compilation toolchain and MACHINE configuration. In my case, I would like to use the arm gnueabi toolchain from gcc for my omap board, particularly for the arm core. All fine, the external sourcery toolchain is setup, but the default config file generated for the build comes with "qemux86". When you try to generate the distribution, you will get weird toolchain issues about x86. I have been surprised because I explicitly specified the toolchain what to build with. Having spent 1-2 days with trying to understand the situation, it boils down to that the default MACHINE config generated, screwed this up. It would have been so much easier if it is reported up front with a warning that the toolchain and machine configurations are mismatching. Here you can find the bugreport about that one.
There are more to it, albeit the last, but not least I would like to mention here is the one when you get tab/space issues when migrating from an older poky version, or you just get those for some reason. Reporting those issues should be easy, shouldn't it? Theoretically yes, but in practice, all you will get a file having issues tab and space issues. I did not quite get the point what the issue is after checking the offending file for quite a while. It turned out that the real problem is in the include file which it was requiring. Again, a newbie would spend a lot of time with it without external and professional support. I would even go further than reporting the right file as in: it would be nice to get a report for the location as close as possible. That is, a function name, perhaps a list of offending line numbers, and so forth. Here you can find the relevant bugreport for this.
Please note that, I have been told for some of these that it is not an easy fix as the parser design is not prepared for such use cases. It unfortunately means, it is not just about adding a minor feature, but basically revamping the parser.
Then, there is the issue of mismatching cross-compilation toolchain and MACHINE configuration. In my case, I would like to use the arm gnueabi toolchain from gcc for my omap board, particularly for the arm core. All fine, the external sourcery toolchain is setup, but the default config file generated for the build comes with "qemux86". When you try to generate the distribution, you will get weird toolchain issues about x86. I have been surprised because I explicitly specified the toolchain what to build with. Having spent 1-2 days with trying to understand the situation, it boils down to that the default MACHINE config generated, screwed this up. It would have been so much easier if it is reported up front with a warning that the toolchain and machine configurations are mismatching. Here you can find the bugreport about that one.
There are more to it, albeit the last, but not least I would like to mention here is the one when you get tab/space issues when migrating from an older poky version, or you just get those for some reason. Reporting those issues should be easy, shouldn't it? Theoretically yes, but in practice, all you will get a file having issues tab and space issues. I did not quite get the point what the issue is after checking the offending file for quite a while. It turned out that the real problem is in the include file which it was requiring. Again, a newbie would spend a lot of time with it without external and professional support. I would even go further than reporting the right file as in: it would be nice to get a report for the location as close as possible. That is, a function name, perhaps a list of offending line numbers, and so forth. Here you can find the relevant bugreport for this.
Please note that, I have been told for some of these that it is not an easy fix as the parser design is not prepared for such use cases. It unfortunately means, it is not just about adding a minor feature, but basically revamping the parser.
 |
| Error messages |
Documentation
There are some issues here as well I hit. I had a DISTRO_FEATURE entry "--disable-zlib" that I inherited. I was looking into it, but I have not seen anything like that in the reference manual. I guessed respestively that, it is not a proper syntax, so I can remove it. Right, you would imagine it could be as simply as that?
The problem is that, yes, theoretically, but in practice: I have seen other undocumented DISTRO_FEATURES like "opengl". I opened up a bugreport for that, but the problem is that, once you find a feature not documented, how will you know what to do with another not represented. Is that a mistake, undocumented, or what exactly? :)
I would not like to bore the reader, so I will only give one more example in here. I have been told that external toolchains should work, yet, it is not documented in the released documentation properly. Even in the development version of the next generation documentation, it is a bit of sloppy. You get the documentation of 2-3 variables, but you do not have any concrete example at hand. Then, I have been told to use the meta-toolchain/sourcery layer. As for the latter, I do not even find any documentation that could be useful for me on github from Mentor Graphics. I created a bugreport for that one, too.
I would not like to bore the reader, so I will only give one more example in here. I have been told that external toolchains should work, yet, it is not documented in the released documentation properly. Even in the development version of the next generation documentation, it is a bit of sloppy. You get the documentation of 2-3 variables, but you do not have any concrete example at hand. Then, I have been told to use the meta-toolchain/sourcery layer. As for the latter, I do not even find any documentation that could be useful for me on github from Mentor Graphics. I created a bugreport for that one, too.
 |
| Dr. Documentation |
Conclusion
I am objectively pessimistic with the current state as an Arch user who is looking for a reliable product in an embedded environment with cross-compilation. I have spent a couple of days to experiment with all this, and I just wanted to let you the limitations so that you do not need to go through the same issues. Oh, and please do not write that "It works for me" because yes, I heard people using git master or not even that with supported distributions, and very simple setups where cross-toolchain is not necessary, et cetera. I am now referring to Arch, embedded, and so forth scenarios. I of course appreciate the Yocto people's work a lot, and I hope they can put more effort into this project to address those issues in the, hopefully near, future.
 |
| Conclusion |
Saturday, July 20, 2013
aKademy mola (i.e. rocks)
Back in the UK!
While having a short discussion with David Edmundson at the Stansted airport in London, we realized that this has been one of the best annual KDE summits we attended to. We made a note that the organization team always kept us busy with awesome social programs.
I think Milian summarizes it in his blog post well: "The reason why I didn’t write a single blog post in between is just that I never had a spare minute for that. "
Many thanks go to the sponsors, organizers and participants who made this vacation in Spain an unforgettable success. ;-)
Photos, blog posts and other information can be found on the official web page.
While having a short discussion with David Edmundson at the Stansted airport in London, we realized that this has been one of the best annual KDE summits we attended to. We made a note that the organization team always kept us busy with awesome social programs.
 |
| One of those funny pictures |
I think Milian summarizes it in his blog post well: "The reason why I didn’t write a single blog post in between is just that I never had a spare minute for that. "
Many thanks go to the sponsors, organizers and participants who made this vacation in Spain an unforgettable success. ;-)
Photos, blog posts and other information can be found on the official web page.
Friday, July 19, 2013
Tuesday, July 16, 2013
C++ and compile-time guaranteed pointer safety?
Personally, I would find this feature useful, but I am not a C++ expert by any means. ;-)
Do you think this would be a useful feature to add to the TR, and then later the standard after C++14? Let me know if you have any alternative suggestions within the currently available or already planned feature set to address this issue.
Oh, and if you do not know what this all means, here you can find the explanation of a good reference design: http://static.rust-lang.org/doc/tutorial.html#borrowed-pointers
Sunday, July 14, 2013
C++ and header files
Just got into a conversation with my dear room mate, Ivan, here in Bilbao at aKademy about this.
My personal opinion seems to have leaned towards preferring to not have to write them myself. Rather, I am happy to have them generated by a util, for instance during the build process.
A real life example could be rustdoc, most probably. I also realize that it is a bit of an unrealistic wish at the moment, but as I am on vacation now I am entitled to dream a lot. ;-)
My personal opinion seems to have leaned towards preferring to not have to write them myself. Rather, I am happy to have them generated by a util, for instance during the build process.
A real life example could be rustdoc, most probably. I also realize that it is a bit of an unrealistic wish at the moment, but as I am on vacation now I am entitled to dream a lot. ;-)
Friday, March 8, 2013
Mobile hotspot connection on Linux
Hi,
I always wanted to write a short blog post about connecting to a mobile hotspot like joikuspot on my N9 phone. The application uses ad-hoc mode, but it can be easily adapted to managed mode like on the Blackberry DevAlpha, Z10 and Q10 devices. Just replace the "ad-hoc" mode with "managed". Unfortunately, joikuspot does not support wpa and wpa2, so this command will be primarily useful for wep. If you leave the key option out, it is also useful for open (i.e. brief sanity checks, et cetera).
Here you can find a reference command which works fine across distributions and even without GUI:
iwconfig wlan0 mode ad-hoc essid Test key s:TestTestTests && dhclient wlan0
It is admittedly not a big thing. However, I lost this command several times in the past. Now, I would know what to do by heart, but what about this in half a year or later? :)
Also, netcfg and similar distribution specific utils kept being broken for some reason. This was always the fallback for me which worked off-hand. Hope it helps. :-)
I always wanted to write a short blog post about connecting to a mobile hotspot like joikuspot on my N9 phone. The application uses ad-hoc mode, but it can be easily adapted to managed mode like on the Blackberry DevAlpha, Z10 and Q10 devices. Just replace the "ad-hoc" mode with "managed". Unfortunately, joikuspot does not support wpa and wpa2, so this command will be primarily useful for wep. If you leave the key option out, it is also useful for open (i.e. brief sanity checks, et cetera).
Here you can find a reference command which works fine across distributions and even without GUI:
iwconfig wlan0 mode ad-hoc essid Test key s:TestTestTests && dhclient wlan0
It is admittedly not a big thing. However, I lost this command several times in the past. Now, I would know what to do by heart, but what about this in half a year or later? :)
Also, netcfg and similar distribution specific utils kept being broken for some reason. This was always the fallback for me which worked off-hand. Hope it helps. :-)
Thursday, February 14, 2013
QtSerialPort in Qt 5.1
Hi everyone,
I would like to introduce you to a project I have been working on lately under the Qt Project umbrella. Hope, you find it useful. :)
About a year ago, I was looking for a library for my project to handle the serial port communication with the modems I needed. As I had been about to make a touch friendly UI with QML, I thought it would have been nice to have a Qt solution. It would have been phantastic to communicate with the modem on my Windows, or Linux host.
There has been an old library around for a while, called QExtSerialPort. Unfortunately, its API looked weird and the project had been abandoned for a while without people contributing to it. Then, a chinese person began to fix certain issues, but still: the design had been carried for long from the old ages.
The Qt Project established a nice opportunity for contributors to start a new project, or move an existing to the Playground area. There was a discussion on the development mailing list to figure out the rules for handling this. Around the time, when I requested the QtAudio3D project into the Playground area of the Qt Project, there was a russian person, Denis, who initiated a community project into Playground in his own pastime to make a great developer experience for serial port based projects across platforms.
The library was supporting only Qt5 back then, and my project was based on Qt4. This is understandable as Qt5 was not realeased for the time, so we were unable to take the risks of the moving target. I decided to give the project a go and make support for Qt4. Not much later (i.e. 1-2 weeks), I got the first changes into the Qt Project, following the Gerrit workflow. By that time, it was more or less possible to use QtSerialPort with Qt4.
Our work has been achieved by using the Qt instance of the awesome Gerrit codereview tool. Almost every commit got at least one review, but many times two, or sometimes even more. I think that is nice, and helped to guarantee the quality of the work even without having a Continous Integration (CI) in place for the time.
As time time had flied, I had more and more feature requests and own changes for those to implement. That is how the library kept rolling, getting new features and bugfixes. The API was also a bit too low-level, and I began to send patchs to refactor the API to be more Qt style'ish. As I am a geek, I instantly wrote a command line based example to enumerate the devices. It was necessary for me to get the project tested on my pandaboard where the UI was not available. There were also important features added like support for gadget serial driver on Linux and so forth.
The initial plan was to make QtSerialPort available as an add-on module for Qt 5.0. This had been proposed on the development mailing list last year. You can read the platforms and environment supported in that threa. Unfortunately, the Qt Project did not have enough capacity for this integration. Likely, it was also good for us because we were able to clean up the remaining uncertain bits of the API. I am not claiming it is now perfect, but it looks much better than it used to be. :-)
The main short term plan is to get the integration right in terms of Jira and Gerrit to move out of the Playground scope. As the CI integration has happened lately, the project is now also covered for build tests, so we cannot end up in situations like having regressions as before. It is not so simple to maintain such a project like this without proper CI integration because we experienced many regressions on one platform when we tried to fix issues or add new features.
As you may already know, it is not simple to test the serial port projects automatically. There had been an initiation for a Qt Mock project from me last April, but it did not yet manage to reach any progress. Nevertheless, we are working on making tests available as much as possible.
My personal plan is to write a KDE frontend for the library, preferrably also a terminal emulator. We already have a terminal emulator example in place to represent the developer and user experience for the project. It is not full-fledged, but it has been working nice for the basic needs. You can set the baudrate, parity and stop bits, flow control et cetera. Something like that would be nice in the KDE project, or perhaps even a plasmoid. There has been a CuteCom around for a while, but when I briefly discussed the project with Alexander Neundorf last summer at aKademy in Tallin, it did not support all the platforms we need.
As you may already know, the QNX platform is also getting closer to a Tier 1 stage in the Qt Project. Blackberry, formerly known as Research In Motion, and KDAB made an excellent job in that area. I have been considering to add a QNX backend support for the project at some point.
Secondly, many thanks to all the contributors to QtSerialPort!
The reviewer statistic is generated by the following command: git log --grep '^ *Reviewed-by:' | sed -n 's/^ *Reviewed-by: *//p' | sed 's/ *<.*>//' | sort | uniq -c -i | sort -n -r
I would like to introduce you to a project I have been working on lately under the Qt Project umbrella. Hope, you find it useful. :)
History
The serial port technology is quite old, but still in active use today. It is mostly used for communicating with modems, sending control commands and so forth where the universal serial bus is not necessary. I am sure many of you recall the time when soldering the pins and cable manually to get it right for the embedded boards. :-)
About a year ago, I was looking for a library for my project to handle the serial port communication with the modems I needed. As I had been about to make a touch friendly UI with QML, I thought it would have been nice to have a Qt solution. It would have been phantastic to communicate with the modem on my Windows, or Linux host.
There has been an old library around for a while, called QExtSerialPort. Unfortunately, its API looked weird and the project had been abandoned for a while without people contributing to it. Then, a chinese person began to fix certain issues, but still: the design had been carried for long from the old ages.
 |
| Serial Port Cable |
Qt Project Playground
The Qt Project established a nice opportunity for contributors to start a new project, or move an existing to the Playground area. There was a discussion on the development mailing list to figure out the rules for handling this. Around the time, when I requested the QtAudio3D project into the Playground area of the Qt Project, there was a russian person, Denis, who initiated a community project into Playground in his own pastime to make a great developer experience for serial port based projects across platforms.
The library was supporting only Qt5 back then, and my project was based on Qt4. This is understandable as Qt5 was not realeased for the time, so we were unable to take the risks of the moving target. I decided to give the project a go and make support for Qt4. Not much later (i.e. 1-2 weeks), I got the first changes into the Qt Project, following the Gerrit workflow. By that time, it was more or less possible to use QtSerialPort with Qt4.
 |
| Gerrit - Code Review Tool |
Our work has been achieved by using the Qt instance of the awesome Gerrit codereview tool. Almost every commit got at least one review, but many times two, or sometimes even more. I think that is nice, and helped to guarantee the quality of the work even without having a Continous Integration (CI) in place for the time.
As time time had flied, I had more and more feature requests and own changes for those to implement. That is how the library kept rolling, getting new features and bugfixes. The API was also a bit too low-level, and I began to send patchs to refactor the API to be more Qt style'ish. As I am a geek, I instantly wrote a command line based example to enumerate the devices. It was necessary for me to get the project tested on my pandaboard where the UI was not available. There were also important features added like support for gadget serial driver on Linux and so forth.
 |
| The command line enumerator example |
The initial plan was to make QtSerialPort available as an add-on module for Qt 5.0. This had been proposed on the development mailing list last year. You can read the platforms and environment supported in that threa. Unfortunately, the Qt Project did not have enough capacity for this integration. Likely, it was also good for us because we were able to clean up the remaining uncertain bits of the API. I am not claiming it is now perfect, but it looks much better than it used to be. :-)
Future plans
As you can read in the topic of this post, QtSerialPort makes it for Qt 5.1. This has been approved by Lars, the Qt Project Chief Maintainer, in the aforementioned thread. This is a really great and exciting news for us. It is also a very good prove for the Qt Project that the idea actually works. Community people can contribute with new modules under the same umbrella with the companies behind the Qt Project.
The main short term plan is to get the integration right in terms of Jira and Gerrit to move out of the Playground scope. As the CI integration has happened lately, the project is now also covered for build tests, so we cannot end up in situations like having regressions as before. It is not so simple to maintain such a project like this without proper CI integration because we experienced many regressions on one platform when we tried to fix issues or add new features.
 |
| FTDI USB-Serial adapter |
As you may already know, it is not simple to test the serial port projects automatically. There had been an initiation for a Qt Mock project from me last April, but it did not yet manage to reach any progress. Nevertheless, we are working on making tests available as much as possible.
My personal plan is to write a KDE frontend for the library, preferrably also a terminal emulator. We already have a terminal emulator example in place to represent the developer and user experience for the project. It is not full-fledged, but it has been working nice for the basic needs. You can set the baudrate, parity and stop bits, flow control et cetera. Something like that would be nice in the KDE project, or perhaps even a plasmoid. There has been a CuteCom around for a while, but when I briefly discussed the project with Alexander Neundorf last summer at aKademy in Tallin, it did not support all the platforms we need.
 |
| Terminal example |
As you may already know, the QNX platform is also getting closer to a Tier 1 stage in the Qt Project. Blackberry, formerly known as Research In Motion, and KDAB made an excellent job in that area. I have been considering to add a QNX backend support for the project at some point.
Kudos
First of all, many thanks to the Qt Project!
Secondly, many thanks to all the contributors to QtSerialPort!
 |
| Authors |
The reviewer statistic is generated by the following command: git log --grep '^ *Reviewed-by:' | sed -n 's/^ *Reviewed-by: *//p' | sed 's/ *<.*>//' | sort | uniq -c -i | sort -n -r
 |
| Reviewers |
Sunday, February 10, 2013
Geek'ish application development for Blackberry 10
Hi there again,
As indicated in my previous post, I am now about to summarize my developer experience for the platform Blackberry 10. As written before, the regular way of developing applications for this platform is to use the Momentics IDE or QtCreator.
Those environment usually generate the necessary qmake build system files, bar files for you to a certain extent I guess. Admittedly, I have never used them for this purpose, so this is just a gut feeling. Anyway, this is not so important for the scope of this post.
When I had started to develop my first application, I made some research if it had ben possible to develop applications the way I like: command line and cmake. For those of you, who are not familiar with cmake, it is a nice cross-platform Makefile generator thoroughly used in many projects. One open source reference is KDE for this.
Interestingly enough, I got some messages in private after my cmake based projects that people found those files and used in a similar fashion one by one. This is nice, but some explanation is necessary for newcomers. So, let us dig into more details about this.
In order to make cross-platform development with cmake, usually one has to produce a correct toolchain file. I looked around on the internet, and there was some examples available for QNX. I took one of those essentially to start off with. That is also one reason why it is a bit bloated, and a much simpler would be enough for achieving what we wish to.
If you are not interested in the underlying operation, you can skip the explanation below, and you can just use my toolchain file right away.
The important changes I made were the followings:
Use the 'qcc' build wrapper. It is essentially a wrapper around the compiler, linker, and so forth. You can find more complete documentation about it here.
This is a very important change because I started with the "ntoarmv7-g++" which is a link to the "arm-unknown-nto-qnx8.0.0eabi-g++-4.6.3" toolchain file. I also tried the latter directly, but I encountered crash for my applications even for a very simple test case without cmake. The program crashed even before entering the main function. It took me two nights at least to track the problem down.
Once I figured out I would have to use 'qcc', there were still some problems that I encountered, albeit slightly different. I had to realize the usage of certain flags is necessary. Once I made it work with the proper flags without any build system, I had to figure out the proper way of setting that for the toolchain file. Now, we have all the information necessary so here it goes the statement:
-> -DCMAKE_TOOLCHAIN_FILE=/path/to/the/toolchain/file.cmake
This is only my personal opinion, but I found it simpler to put the toolchain file into the project because then I did not have to carry that on to other machines I worked on. It is also simpler to ask other non-cmake developers to test my application if I pass a command to them. It is not a huge file, so it probably does not take up much space in the repository either. It does not clutter the project that much either in my opinion.
This is also a very important step to find the Cascades libraries for your application. This was not a big deal, albeit I have not had time to solve this issue nicely either. So, there are rooms for improvements. :)
I have created separate cmake find modules for each library for the time being, but perhaps it should be handled more like Qt4 with a joint find module, and one can request anything out of that. So, there would be a macro with a few parameters. It would not be then necessary to copy and paste the code. If you are not up to that contribution, you probably better go with the files I created. You can find them below.
I wrote a primitive python script for this after gathering all the information what flags to use. Here you can the result. This one is more or less just a hint as it cannot be used that directly. I chose python because then I can also use this on Windows and elsewhere as python is a nice cross-platform scripting language.
Essentially, there are several tools that have to be used for installing and then launching the application on the device from your host system:
I personally made an alias for this, but here you can find the comment:
-> source /opt/bbndk/bbndk-env.sh
-> ifconfig usb0 169.254.0.2
-> blackberry-connect 169.254.0.1 -password devicepassword -sshPublicKey ~/.ssh/id_rsa_rim.pub
Here you can find an example how to use it:
-> blackberry-nativepackager -package -target bar test.bar /path/to/the/bar/descriptor/xml/file.xml -devMode
-> blackberry-deploy -installApp -device 169.254.0.1 -launchApp -password devicepassword -package test.bar
A simple ssh connection can be used for logging into the device once the development mode is switched on in the settings. It has to be done after each boot as of now on my devalpha, at least. Make sure the connection is established properly and the blackberry-connect process is still up. Here you can find the command for that:
-> ssh -i ~/.ssh/id_rsa_rim devuser@169.254.0.1
Once this is done, there are some tricks to get information about QML syntax issues, C++ crashes, reading your intended log file, and so forth:
-> slog2info -w
or/and
-> cd /accounts/1000/appdata/${id_from_the_bar_descriptor_file}/logs && cat log
You can also get the screenshots created on the device by pressing the two volume buttons simultaneously:
-> scp -i ~/.ssh/id_rsa_rim devuser@169.254.0.1:/accounts/1000/shared/camera/IMG_*.png /path/to/the/directory/to/store/the/screenhots
Here you can find the command I used:
-> blackberry-nativepackager -package -target bar test.bar /path/to/the/bar/descriptor/file.xml -sign -cskpass devicepassword -buildId 1
Note: Do not forget that you have to increase the -buildId value for each new signing.
This is also a common request that someone would like to get feedback about the application before even getting approved in the AppWorld. In such cases, you may request your friends and acquaintances to test it. This could also happen vice versa so that you are asked for testing an application and provide feedback. Hence, it is useful to know how you can do that. Here is the command I used.
-> blackberry-deploy -installApp -device 169.254.0.1 -launchApp -password devicepassword -package test.bar
Like many things in the life, this is also possible. I do not find any issues with this workflow for application development, but I am a bit strange developer. I am glad to have found the way I like spending my time. Many thanks go to Bill Hoffman from Kitware for patiently helping me with cmake issues on the cmake mailing list.
Hope, it helps some people out there.
Happy Blackberry 10 hacking! :-)
As indicated in my previous post, I am now about to summarize my developer experience for the platform Blackberry 10. As written before, the regular way of developing applications for this platform is to use the Momentics IDE or QtCreator.
Those environment usually generate the necessary qmake build system files, bar files for you to a certain extent I guess. Admittedly, I have never used them for this purpose, so this is just a gut feeling. Anyway, this is not so important for the scope of this post.
Goal
When I had started to develop my first application, I made some research if it had ben possible to develop applications the way I like: command line and cmake. For those of you, who are not familiar with cmake, it is a nice cross-platform Makefile generator thoroughly used in many projects. One open source reference is KDE for this.
Interestingly enough, I got some messages in private after my cmake based projects that people found those files and used in a similar fashion one by one. This is nice, but some explanation is necessary for newcomers. So, let us dig into more details about this.
CMake Toolchain file
In order to make cross-platform development with cmake, usually one has to produce a correct toolchain file. I looked around on the internet, and there was some examples available for QNX. I took one of those essentially to start off with. That is also one reason why it is a bit bloated, and a much simpler would be enough for achieving what we wish to.
If you are not interested in the underlying operation, you can skip the explanation below, and you can just use my toolchain file right away.
The important changes I made were the followings:
- Use the proper toolchain binary
Use the 'qcc' build wrapper. It is essentially a wrapper around the compiler, linker, and so forth. You can find more complete documentation about it here.
This is a very important change because I started with the "ntoarmv7-g++" which is a link to the "arm-unknown-nto-qnx8.0.0eabi-g++-4.6.3" toolchain file. I also tried the latter directly, but I encountered crash for my applications even for a very simple test case without cmake. The program crashed even before entering the main function. It took me two nights at least to track the problem down.
- Use the proper toolchain binary flags
Once I figured out I would have to use 'qcc', there were still some problems that I encountered, albeit slightly different. I had to realize the usage of certain flags is necessary. Once I made it work with the proper flags without any build system, I had to figure out the proper way of setting that for the toolchain file. Now, we have all the information necessary so here it goes the statement:
| -> SET(CMAKE_CXX_COMPILER_ARG1 "-Vgcc_ntoarmv7le -lang-c++) |
|---|
- Instruct cmake to use the toolchain file created
- The location of the toolchain file
So this is the entire command I use from the build folder: -> cmake -DCMAKE_TOOLCHAIN_FILE="../frontends/blackberry/cmake/Toolchain-QNX-8.0.0.cmake" .. && make VERBOSE =1 |
Find modules for Cascades libraries
This is also a very important step to find the Cascades libraries for your application. This was not a big deal, albeit I have not had time to solve this issue nicely either. So, there are rooms for improvements. :)
I have created separate cmake find modules for each library for the time being, but perhaps it should be handled more like Qt4 with a joint find module, and one can request anything out of that. So, there would be a macro with a few parameters. It would not be then necessary to copy and paste the code. If you are not up to that contribution, you probably better go with the files I created. You can find them below.
Deploying the application to the device
I wrote a primitive python script for this after gathering all the information what flags to use. Here you can the result. This one is more or less just a hint as it cannot be used that directly. I chose python because then I can also use this on Windows and elsewhere as python is a nice cross-platform scripting language.
Essentially, there are several tools that have to be used for installing and then launching the application on the device from your host system:
- Set up the Blackberry NDK environment
I personally made an alias for this, but here you can find the comment:
-> source /opt/bbndk/bbndk-env.sh
- blackberry-connect
-> ifconfig usb0 169.254.0.2
-> blackberry-connect 169.254.0.1 -password devicepassword -sshPublicKey ~/.ssh/id_rsa_rim.pub
- blackberry-nativepackager
Here you can find an example how to use it:
-> blackberry-nativepackager -package -target bar test.bar /path/to/the/bar/descriptor/xml/file.xml -devMode
- blackberry-deploy
-> blackberry-deploy -installApp -device 169.254.0.1 -launchApp -password devicepassword -package test.bar
Debugging from command line
A simple ssh connection can be used for logging into the device once the development mode is switched on in the settings. It has to be done after each boot as of now on my devalpha, at least. Make sure the connection is established properly and the blackberry-connect process is still up. Here you can find the command for that:
-> ssh -i ~/.ssh/id_rsa_rim devuser@169.254.0.1
Once this is done, there are some tricks to get information about QML syntax issues, C++ crashes, reading your intended log file, and so forth:
-> slog2info -w
or/and
-> cd /accounts/1000/appdata/${id_from_the_bar_descriptor_file}/logs && cat log
You can also get the screenshots created on the device by pressing the two volume buttons simultaneously:
-> scp -i ~/.ssh/id_rsa_rim devuser@169.254.0.1:/accounts/1000/shared/camera/IMG_*.png /path/to/the/directory/to/store/the/screenhots
Application signing for AppWorld
Here you can find the command I used:
-> blackberry-nativepackager -package -target bar test.bar /path/to/the/bar/descriptor/file.xml -sign -cskpass devicepassword -buildId 1
Note: Do not forget that you have to increase the -buildId value for each new signing.
Testing someone else's application
This is also a common request that someone would like to get feedback about the application before even getting approved in the AppWorld. In such cases, you may request your friends and acquaintances to test it. This could also happen vice versa so that you are asked for testing an application and provide feedback. Hence, it is useful to know how you can do that. Here is the command I used.
-> blackberry-deploy -installApp -device 169.254.0.1 -launchApp -password devicepassword -package test.bar
Conclusion
Like many things in the life, this is also possible. I do not find any issues with this workflow for application development, but I am a bit strange developer. I am glad to have found the way I like spending my time. Many thanks go to Bill Hoffman from Kitware for patiently helping me with cmake issues on the cmake mailing list.
Hope, it helps some people out there.
Happy Blackberry 10 hacking! :-)
Subscribe to:
Posts (Atom)