At FOSDEM 2014 I had a short presentation about how the text gets drawn in Writer. It is mostly an explanation of the backtrace you get when you stop the drawing at the right time; hopefully it is helpful in case you want to know more about LibreOffice Writer.

Click to see the entire presentation

Once I announced MimeKit, I knew it would only be a matter of time before I started getting asked about SMTP, IMAP, and/or POP3 support.

Let's just say,

Challenge... ACCEPTED!

I started off back in early December writing an SmtpClient so that developers using MimeKit wouldn't have to convert a MimeMessage to a System.Net.Mail.MailMessage in order to send it using System.Net.Mail.SmtpClient. This went pretty quickly because I've implemented several SMTP clients in the past. Implementing the various SASL authentication mechanisms probably took as much or more time than implementing the SMTP protocol.

The following weekend, I ended up implementing a Pop3Client. Originally, I had planned on more-or-less cloning the API we had used in Evolution, but I decided that I would take a different approach. I designed a simple IMessageSpool interface which more closely follows the limited functionality of POP3 and mbox spools instead of trying to map the Pop3Client to a Store/Folder paradigm like JavaMail and Evolution do (Evolution's mail library was loosely based on JavaMail). Mapping mbox and POP3 spools to Stores and Folders in Evolution was, to my recollection, rather awkward and I wanted to avoid that with MailKit.

At first I was loathe to do it, but over the past 2 weeks I ended up writing an ImapClient as well. I'm sure Philip van Hoof will be pleased to note that I have a very nice BODYSTRUCTURE parser, although that API is not publicly exported.

Unlike the SmtpClient and Pop3Client, the ImapClient does not have all of its functionality on a single public class. Instead, ImapClient implements an IMessageStore which has a limited API, mostly meant for getting IFolders. I imagine that those who are familiar with the JavaMail and/or Evolution (Camel) APIs will recognize this design.

The IFolder interface isn't designed to be exactly like the JavaMail Folder API, though. I've been designing the interface incrementally as I implement the various IMAP extensions (I've found at least 37 of them at the time of this blog post, although I don't think I'll bother with ACL, MAILBOX-REFERRAL, or LOGIN-REFERRAL), so the API may continue to evolve as I go, but I think what I've got now will likely remain - I'll probably just be including additional APIs for the new stuff.

So far, I've implemented the following IMAP extensions: LITERAL+, NAMESPACE, CHILDREN, LOGIN-DISABLED, STARTTLS, MULTIAPPEND, UNSELECT, UIDPLUS, CONDSTORE, ESEARCH, SASL-IR, SORT, THREAD, SPECIAL-USE, MOVE, XLIST, and X-GM-EXT1. Phew, that was exhausting listing all of those!

Also news-worthy is that MimeKit is now equally as fast as GMime, which is pretty impressive considering that it is fully managed C# code.

Download MailKit 0.2 now and let the hacking begin!

LibreOffice 4.2 has been released - have you tried it? If yes, you might have experienced the new start center that looks about like this:
Many people have contributed to it, and this is going to be a "Thank you" blog post. I hope I remember everyone who has helped; if not, please let me know in the comment - would be a shame to miss anyone.

Original idea

It all started as a Google Summer of Code idea that I have filed, and later mentored. Basically, I wanted a student to reuse the Caolan McNamara's awesome dynamic dialogs to provide modern and easy way to create a beautiful dialog, and GSoC 2012 project that introduced a new template manager in LibreOffice 4.0 - done by Rafael Dominguez and Cédric Bosdonnat.

The work itself

The main part of the work was done by Krisztian Pinter, who was working on it as a GSoC project too. His first task was to convert the old start center to the dynamic layout, so that the start center could much more easily adapt when the user resizes the screen.

But that was not all - his next task was to plug the template manager code in, and extend it so that it was able to show recent files instead of the templates. He  made the needed changes, adapted the look to the preliminary design made by the LibreOffice Design / UX team, and the GSoC period was over :-)

We have integrated it into the LibreOffice master, and I was patiently waiting when we get the final look blueprint from the design guys.

The final look

And it came! The code was in the master and in the daily builds, so everyone could play with it. For some time, nobody reacted on my call for the final look, but finally, Mateusz Zasuwik sent a design proposal of Krzysztof Ponikiewski to the LibreOffice Design mailing list which lead to discussion, and in the end to the start center we have now in 4.2.

The the ultimate version of the design was done mostly by Stefan Knorr, and Mirek Mazel, but others contributed to that too. I've adapted the code accordingly, Rodolfo Ribeiro Gomes helped me with some changes, and Tamas Zolnai fixed many bugs to give it the final, polished look & feel.

Thank you!

As you can see, the new start center couldn't have happened without shared work of many people - I want to thank you all. And of course, thank you Google for the Google for Summer of Code, I hope we will be able to participate as an organization this year again.

At the very moment, the LibreOffice UX Hackfest is taking place in Brussels, and I am working on few more improvements in the start center - like previews of even other filetypes than just ODF. But that will be for LibreOffice 4.3...

Lately there was some confusion regarding our communication. We, at the openSUSE Team@SUSE are deeply aware that our communication needs to be improved. So in the hope to make everything clear again, here is the summary to clear up what is really going on and what was not happening.

Long story short:

• There WILL be openSUSE 13.2 in November 2014
• 13.2 WILL have security and maintenance support provided by SUSE
• We WILL have coolo as release manager for 13.2
• SUSE is NOT decreasing manpower put into openSUSE
• Everybody from the community is welcome and encouraged to be involved with, and if they want to, take over some parts of the release process and we will support you the best we can in doing that

Now for the long story.

Our team and only our team – openSUSE@SUSE – is going to work on improving ‘tooling’ side of the openSUSE project until August. These changes will benefit openSUSE by making it easier to produce better releases in the future.

Nothing changes for the rest of SUSE. SUSE is not abandoning openSUSE. The rest of SUSE will still do the same things they were doing until now and continue to keep openSUSE awesome. This includes Maintenance, Security, Infrastructure, and many other teams besides the openSUSE Team at SUSE who actively support the openSUSE project.

What is our plan?

Our plan is to make sure that future openSUSE releases are easier for everyone to produce. As we grow we could keep putting in more and more full-time release managers (if we find them somewhere), but this approach is probably unsustainable and, more importantly, goes against our desire to empower the community to do more as part of openSUSE.

Therefore, we decided to improve our tools to ensure that making a release is much more straightforward and reliable and we can reduce and distribute the workload needed for integration and release. To make this happen we need time and everyone from the team to work on adapting the tooling side. We also would welcome volunteers to help us with tools and with the following release(s).

With the release date now set in November (mirroring roadmap for 13.1), first milestone should be released in May. That is a perfect oportunity to go to openSUSE Conference in Croatia where we can meet up, gather volunteers to help and discuss how to work. Remember that openSUSE Travel Support is in place to sponsor everyone who needs financial help to get to the event.

Hopefully now we cleared things up a little and we are really sorry again for our poor communication – We’re going to work on it.

Your truely confused openSUSE Team

As we stated in our communication over the time, our team’s main focus for foreseeable future is Factory and how to manage all those contributions. Goal is not to increase the number of SRs that is coming to Factory, but to make sure we can process more and to make sure we see even well hidden consequences to make sure that Factory is “stable” and “usable”.

Not really part of our current sprints, but something that will hopefully help us is spec-cleaner that Tomáš Chvátal and Tomáš Čech were working on lately during their free time/hackweek. What is it trying to address? Currently, there are some packaging guidelines, but when you write a spec file for your software, you still have plenty of choices. How do you order all the information in the header? Do you use curly brackets around macros? Do you use macros? Which ones do you use and which not? Do you use binaries in dependencies? Package config? Perl symbols? Package names? There is format_spec_file obs service that tries to unify a little bit the coding style but leaves quite some of the stuff up to you. Not necessarily a bad thing, but if you have to compare changes and review packages that are using completely different coding styles the process becomes harder and slower.

spec-cleaner is format_spec_file taken to another level. It tries to unify coding style as much as it can. It uses consistent conventions, makes most of the decisions mentioned previously for you and if you already decided for one way in the past, it will try to convert your spec file to follow the conventions that it specifies. It’s not enforcing anything, it’s standalone script and therefore you don’t have to be worried that you spec file will be out of your control. You can run it, verify the result (actually, you should verify the results as there might still be some bugs) and commit it to OBS. If we all do it, our packages will all look more alike and it will be easier to read and review them.

How to try it? How to help? Well, code is on GitHub and packages are in OBS. You may have a version of it in your distribution, but that one is heavily outdated (even the 13.1 version), so add openSUSE:Tools repo and try the version from there.

zypper ar -f obs://openSUSE:Tools/openSUSE_13.1 openSUSE-Tools
zypper in spec-cleaner

You can then go to some local checkout and try what changes does it propose for your spec file. Easiest way is to just let it do stuff by calling it and taking a look at changes afterwards.

spec-cleaner -p -i *.spec
osc diff

If it works, great, we will have more unified spec files. If it doesn’t, file a bug

Its a new year (belated) and 13.1 has been out for quite a while now.  I had it running in a VM as an evaluation and did not really move my desktop setup from 12.3 up to 13.1 until last weekend.

In the meantime, a few readers has corresponded with me via comments in my previous post about getting IBM Lotus Notes 9 Social Edition to work on 13.1.  My initial favourable responses were based purely on a very quick install and startup tests (it all looked good).  Unfortunately, there appears to be a little bug with the combination of openSUSE 13.1 and IBM Notes 9.0.1 but it is a very small one and the resolution is ridiculously simple (but not immediately apparent).

I hope to blog more on 13.1 at a later date but will only focus on getting IBM Notes 9.0.1 working on 13.1 in this entry.  I have been having some difficulties in my personal health lately and that only takes time away from pursuing my hobbies (blogging here being one of them).

First, I would like to acknowledge Craig for bringing to my attention the challenge and so proactively providing the links to his discussions in the Lotus forum (here).  I would also like to Thank Ashu for his encouraging comments left on my previous blog entry and hope this entry will be just as useful to those out there who share the same fascination of using openSUSE and IBM Notes.

Installation - Easy as pie

As documented in previous blog entries, installation of IBM Notes 9.0.1 is really a piece of cake.  You download the binaries (NOTES_9.0.1_LINUX_RPM_EN.tar), untar it into an empty directory and you will find 5 RPMs (i586 - 32-bit) and a few other files.

As root, execute the following in the same directory:

zypper in *.rpm

Done!  You will find the IBM Notes icon in the Recently Installed Apps folder in KDE4.  Alternatively, the launch icon can also be found in the KDE::Applications::Office::More Programs::IBM Notes.  Right-click and Add to Favourites to easily find it the next time.

First sign of trouble

First sign of trouble, at least for me, only occurred after successfully launching IBM Notes and when I get into my mailbox, view calendar or log into SameTime.  The GUI would freeze and then IBM Notes would terminate and NSD runs.

Read more »

In presentations I like to use colourful graphics. Some of those graphics are generated automatically by the Cairo based oyranos-profile-graph 2D grapher tool. In git that tool obtained a option to show black body spectra based on kelvin. The spectra are scaled for better illustration.

 

Some other work in Oyranos went on with the device mapping to JSON serialisation, as is useful to store device configurations using the Oyranos API. Through JSON files it is possible to support new device classes without to worry about creating a native Oyranos device module. The basic idea is to let users bring in a OpenICC device description and a weighting description. Oyranos is then able to find matches inside its DB and weight the resulting properties according to the provided weighting file. The example code is inside oyranos-test-device and needs still some polishing to become a stable tool. For instance more integration with the frontends and UI parts is needed, to make sure everything gives a nice user experience. Raw images can now be rendered better in image_display and do not show the artefacts from table based conversion of linear camera space to gamma encoded monitor spaces.

During spring 2013 I decided to abstain from public activities and paused coding completely. After some months I was mentally able to enjoy work on self contained stuff. That was first without any community involvement. Months later I contacted some people to explain that situation and want to thank here all those friendly souls who directly encouraged me. After what happened in the last years, I learned, that it can be pretty healthy to not to stay in public light and become involved in highly controversial discussions. Especially the later can become easily burning. As a result of that personal lesson, I skipped 2013 LGM and other meetings and outside activities. Now after around 9 months I feel really better and hope to become slowly more involved. Still I am learning how to keep others opinions at arms length. And that lesson appears key for me to stay welcoming and focused. Well, time will show how well .

Oyranos supports Elektra-0.8.4 in git as a result of friendly behind the scene discussions later in 2013. A new image filter, called “scale“, is currently used inside the image-display example viewer. It does so far no interpolation, but it might become useful for other applications as well, in order to select only a subset of unaltered image pixels. ICC named colour list reading was added. More changes happened around documentation, building external modules and use of threading inside the image-display application.

It all started by an innocent (?) question on 28th of November 2013. The inimitable Caolán asked whether anybody considered writing an import filter for AbiWord document format. And the distinguished readership of this blog knows well what makes your servant tick. So, the very evening, a skeleton was written and libabw, a library to read AbiWord file-format, started. It was pretty exciting to write -- after a host of libraries for file-formats that are not documented anywhere -- a filter for a file-format of our cousin. There was a hope that existence of a reference implementation whose source code is widely accessible would make the endavour easy. It is undeniable that grepping for values of different enums made the work a bit easier. Nonetheless, a huge part of the work was still figuring out what is permitted in AbiWord and how a change of one parameter affects the rendering of a document. Other thing to find out was how to map the concepts in the ABW files into the libwpd API that is heavily influenced by ODF concepts.

But the date of the start meant that soon came the Christmas and with it a possibility to spend some free time on the library. Eventually it became very usable and the import filter made it -- as a late feature -- into the LibreOffice 4.2 line and users of the upcoming LibreOffice 4.2.0 release.

The library currently supports both the plain xml ABW files as well as the gzipped ZABW files. The converted features include:

• Tables, including nested tables
• Headers and footers, including different left, right and first page headers/footers
• Footnotes and endnotes
• Multi-column sections
• Embedded images

And since a picture speaks louder then hundred words, here are some screenshots:

	&nbsp
A sample ABW file openedin AbiWord	&nbsp	The same ABW file openedin the upcoming LibreOffice 4.2.0

	&nbsp
A sample (zlib compressed) ZABWfile opened in AbiWord	&nbsp	The same ZABW file openedin the upcoming LibreOffice 4.2.0

As you can see from the screenshots, the world domination that we are actively seeking is having several contenders. But if you believe that we are the closest to its realization, please join the filter-writing fun! Show up on #libreoffice-dev channel at irc.freenode.net. You are also encouraged to follow my twitter and Google+ accounts. And stay tuned for more exciting news in the near future. We can promise you that you will have a lot of fun in the growing community of LibreOffice filter writers.

Scenario: I have a KVM virtualization server with a number of VMs defined. Suddenly, I cannot log in as root to one of the VMs. I will need to reset the root password. The "normal" methods like adding single or init=/bin/bash to the kernel boot line in GRUB do not work. The only option left is to boot from a rescue disc, but this is a virtual machine -- there is no DVD drive. Oh, no -- what to do?

NEWS FLASH: I just learned from a colleague that there is a much easier method. It is possible to chroot directly into the VM from the virtualization host. Will post detailed instructions as soon as I get them. Until then, there is always the "long route" described below.
Read more »