QCryptographicHash: code snippet

  When the guys developing Qt applications find themselves in such a case when they need to obtain MD5 hash of a string or an array of bytes, the first thing most of them do is try to use the already implemented 3rd-party libraries like libxcrypt, OpenSSL and others. The talented ones try to get the output of 'md5sum' command.
  But the 'true' way is to use built-in tools: not everyone knows that Qt already has QCryptographicHash class which can help us. Let's see how:


QString password("our super secret password");
QByteArray hashed_password_ba(
     QCryptographicHash::hash(password.toAscii(),
                              QCryptographicHash::Md5));
/* Now 'md5_password' var contains
*  md5-hashed our super secret password 
*/
QString md5_password(hashed_password_ba.toHex().constData());

Very easy, isn't it? Apart from MD5, the class allows to generate MD4 and Sha1 hashes which may also be very helpful in some special cases.

GMail Buzz: I do not like when it forced

Only a lazy one doesn't write about Google Buzz. So here are my five cents. When I was fighting for GMail Invite several years ago to get the best e-mail service ever, I really wanted to get the convenient instrument to work with e-mail correspondence. And finally I got it, what really made my day. For all the time I've been using GMail I haven't had anything bad to say about it. Now I have.

If I say that something is not what I currently want, I really mean it. I decided not to transform my e-mail account into the social network account when Google asked me about that. But when I got logged in, the first thing I saw was that Google ignored my decision and enabled it (Buzz). I did not like the way it was.

Thanks to the advice of GMail Help I managed to turn it off:

If Buzz isn't for you, you can turn it off it by clicking the turn off buzz link at the bottom of your Gmail (it's near the basic HTML link).

After doing this simple thing I enjoy e-mail service I really like as earlier.

Serna accepted to Debian!

Thanks to amazing work of Joachim Breitner Serna finally is officially accepted to the one of my favorite Linux distros -- Debian GNU/Linux! Hope it will be in Ubuntu soon as well.

Of course, some things may work not as expected or may not work at all :), but it is just a beginning. Please feel free to contribute your patches and bug-reports directly to serna-developers mailing list or to http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=serna.

Sandbox`ed (AppArmor) Skype 2.1 in Linux

To be able to stay in touch with my contacts and speak for free with people through Skype I agree that my workstation becomes P2P-node. But I do not agree that Skype scans my private files (browser cookies and history). What to do? As far as I am Linux user the solution is simple: to use AppArmor. According to this approach Skype is launched in some kind of sandbox, i.e. in the invironment where not everything is allowed You can read more about sandbox`ing Skype with AppArmor here.

But the problem is that all AppArmor profiles I found for Skype do not work for the latest version 2.1 -- they cause a termination of the application. Because they seem to be just a bit outdated. So I have managed to write (after hours of experiments) a new one, which definitely works well for me (Ubuntu 8.10 + latest Skype 2.1b). Here is a draft version of usr.bin.skype:

Serna XML editor goes Open Source!

Amazing news! Accordingly to the Syntext's announce Serna goes Open Source!

What exactly is known about:

• It is going to happen in the course of month;
• License: vanilla GNU GPL with FLOSS exceptions

Official announce is here: http://syntext.com/about/news/open-source/

What this means for the OSS community?

• There will be an extensible and powerful Open Source XML platform to write and maintain various types of XML based documents;
• Document formats such DocBook and DITA will become more popular due to availability of the excellent tool to maintain them; and other XML formats may grow -- depends on the community aims only;
  
• There might be a dramatic growth of open documents formats to interchange. ODF is a good one, but not perfect and not so applicable in the all fields of the human specialization;
• ... and have you ever dreamed about Open Source application for .fb2 (FictionBook) authoring? This and a lot of other things may come true one day.

Syntext, thank you for the surprise :).

Serna OSSO Help plugin announce

This post can be considered as a logical continue of the previous one.

I am pleased to announce my implemented vision of solution to make life easier for Maemo help/documentation authors. Since Syntext Serna WYSIWYG xml editor is free (free as beer!) and it is really crossplatform (written using Nokia/Trolltech Qt framework; currently it is avaialble for Linux, MacOS X, Windows, and even Sun Solaris), I decided to use it as a platform to create such solution.

What has been done:

1. Schema files

   I've researched sources of OSSO Help framework to get more knowledge about all available elements. Also distribution help files placed in /usr/share/osso-help/en_GB were researched to get more information about elements order. The result: DTD file was written from the scratch which allow to make elements validation and completion.

2. Stylesheets

   All visual appearance for Serna is made using XSLT Stylesheets. So, special XSLT stylesheets have been written which allow to represent OSSO help files "as is".

3. Documentation

   As it was mentioned in the previous post, there is no really good documentation about help authoring for Maemo, so some intros were written. Actually they are not so good as I want and imagine, but it is just a first step, is not it?

Plugin's homepage is http://thekondor.net/osso-help-plugin where documentation, tutorial and download links can be found. Of course, plugin is free of charge; licensed in terms of GNU Lesser GPL v3.


Some screenshots

There is how help file looks like being opened in Serna:



There is a final representation being viewed in Maemo. Impressing, right?
I hope this beta will be useful and there are ideas to improve it in the following ways:

1. Schema files
2. Visual representation (XSLT stylesheets)
3. Usability (want to use a power Serna customization to make help authoring for Maemo more easier)
4. Publishing. Make a possibility to generate PDF/HTML files directly from Serna.
   

Feedback about OSSO Help Plugin is welcome.

Stay tuned!

Why help writing for Maemo applications sucks?

Why help writing for Maemo applications sucks?

We like good applications. We can spend a lot of time telling our friends about fantastic applications we met. But application will be more better if one small thing can be improved.

Beside a cool functionality, a program must have well-designed User Interface (UI).

Good UI can help users not to get lost in the set of buttons and checkboxes, can help to do his task more efficiently and more quickly, and make all work with application intuitive. Despite on GUI is a key to success, it is not everything: even the world's better UI cannot tell the user about all allowable tricks and hints. The solution is: to write a documentation or/and write quick help available from the main menu. I suppose lot of users firstly looks to help to find answer to the question, and then, if nothing, go to the documentation/google. So, this is why having application help is a so important case.

Maemo applications don't differ lot from desktop applications. But why help writing for Maemo applications sucks? I suppose that not only I ran into the following problems when I firstly
met Maemo help subsystem when started writing help for Conler.

1. Awful OSSO Help format description

(for who not familiar with the idea: help system in Maemo is implemented using OSSO Help framework. This framework requires that all help files must conform to the special XML-based format).

When you were reading Maemo_*_Reference_Manual_for_maemo_*.pdf you surely had read a section dedicated to the help writing. It is very "comprehensive", is not it? It has a list of available elements and short descriptions for them, some examples, and nothing more. What is the hierarchy of the elements? When I should use "element-1" and when I don't have to use "element-2"? Unfortunately answers to these questions can be found only in researching already written help files located in /usr/share/osso-help.

2. No abilities to validate written help.

The good practice in working with XML files is when it is done, the result must be checked for correctness. It can be done using XML Schema, DTD, or RelaxNG, whatever. But there is no schema files for our case!

The only way to check that the help will be shown correctly is:

1. Make XML non-schema validation, using, for example, 'xmllint': we will be sure that the document conforms to XML.
2. Try to browse it in Maemo: if it is shown as expected, the work can be supposed done.

I really was trying to find such files. But I did not manage: because they ain't exist, even on the framework's homepage.

3. No good tool/solution for non-technical people to write help documentation.

Help for applications might be written by non-technical people, not developers only. But how can they do it if they even don't have any idea how to do this -- this is a result because of points 1 and 2 above.

The usual steps for novice to write a help:

1. Read Maemo_*_Reference_Manual_for_maemo_*.pdf
2. Try to find more information
3. Research files in /usr/share/osso-help to get real-life examples
4. Write a first version of the document using simple constructions only
5. Validate it
6. Improve document using more advanced constructions
7. Deploy to the application package.

Too complicated, is not it? Have to say that I did these steps too when I first was writing help for Conler. The next iteration of the process might be short. But it could be:

1. Read intro about writing OSSO help documents
2. Run editor and write following the tips about document structure. And not being worried about its correctness.
3. Deploy newly created help to the application package.

There is an obvious profit: if there were such a good tool/solution, non-technical people could be involved to Maemo development.

Lot of criticism without nothing useful? Actually not at all. Important step in problem solving -- is to find and describe it. Hope, being inspired by this text and having some experience in XML, I to release soon my implemented vision of the solution.