Calligra Spring 2013 Sprint started

The Calligra contributor community finally is meeting again for a sprint weekend, both virtually and in real life: There are 6 people at the ThoughtWorks Bangalore office in India, sitting and hacking on stuff already since the morning. And 11 people are gathering at the Linuxhotel in Europe until the evening, to follow and join them the next two days. Other people are popping up in the random Google Hangout sessions, and of course in the IRC channel #calligra.

Today was arrival day, so more or less dynamically structured. Still the Krita people had already their BoF, as most of them arrived early. Tomorrow then there will be great discussion day, topics will be e.g. a new document/view-architecture and improving QML-support.

With doing a few more 2.x releases in the futures, Calligra is slowly approaching the 3.0 version, as a milestone where the individual programs not only are useful as serious viewers, with e.g. excellent import filters for MS formats, but finally also as reliable, easy to use and well integrated editors (which most still need to become).

Krita, as the current flagship, is already making waves in the world of movie and GFX studios, also Intel having used a special version (Krita Sketch) at their CES booth!
Author is going to find a so far unclaimed niche, while Kexi is getting closer to occupy its targetted one. Words, Stage, Sheets are offering alternative UX to what AOO | LO | MS have. Plan quietly evolves into a serious project planner. And more.
While these are all exciting developments, there are also new challenges in the future: KF5 & Qt5 & QML2 & Plasma Active.
Also some old challenges are still around: while now only more Kexi has Qt3Support dependencies, the started big refactoring of the central Calligra libraries waits to be finished.

There are lots of reasons to keep on pushing Calligra programs and libraries: built on Qt/kdelibs and with a quite modular architecture, it’s quite easy to adapt to new platforms out there, which e.g. can be seen with Calligra Active or the plugins for Okular, which have been done with only little effort in comparison. And Qt5 brings even more hope and options.

This sprint would not be possible without the supporters of KDE e.V., thanks to them to make it financially possible for us to meet up to develop plans for the future roadmaps. So if you, dear reader, want to do your little contribution to the future of KDE software as well, consider to Join The Game as a supporter of the KDE e.V. !

Thanks also to KO GmbH for supporting the sprint, to ThoughtWorks Bangalore for hosting the Indian part of the sprint and for the Linuxhotel for the community-friendly offering in their great setting for the European part. And thanks to Claudia, the KDE e.V.s business manager, for her quick and uncomplicated handling of any issues.

Next here in Linuxhotel: Pasta self-cooking for dinner (that’s why there are pasta sauce recipes on the sprint planning page ). Oh, got ready while writing this post, actually next is Pasta self-eating

Sculpting Marble in Prague

The Golden October should be a matching time to go to the City of Gold, Prague. That, it seems, thought the organizers of the OpenSUSE Conference 2012. And that also thought the developers of Marble, the virtual globe and map program/lib, who happily used the possibility to be hosted there.

And golden it was, the October, at least on friday, when the air was clear, the leaves mostly still at the trees, in all colors, and the pairs of shoes still on the line, off all kinds:

Saturday and Sunday then Prague turned into the City of Fog, especially dense at nights, perfect to stay inside to talk about how to make Marble even more awesome.

I initially went there to mainly talk and learn about how to use the Marble lib to resurrect in a proper way the Map shape for Calligra, the office, graphics and management suite. Like how to get the data used for the current view exported from the Marble lib to store it into the document, to be able to display the map without being connected to the internet, e.g. in a presentation. Or how to get rendering done in case of printing, where there is no way to simply update the view when the missing data arrives from the server and where all time-based layers (think satellites) should render for the exact same time setting. The latter might also be needed for a possible plugin for Kdenlive, the video editor, where you could render transitions between places with Marble lib, like e.g. for a short movie about your last vacation trip.

These needs were discussed to some detail, and it turned out that there is quite some work still needed to satisfy them. But any efforts in this direction are very welcome by the Marble developers, as they are in general pretty open to support all kind of usages of the Marble libs. Which for other use-cases is quite easy, as can be seen in the impressive presentation by Marble routing master Dennis Nienhüser showing how his students use the Marble libs in research projects.

Being a little bit disappointed I picked up some other little tasks that turned up in the discussions, like registering Marble as handler for OSM data files, ESRI shapefiles and GPX files, as otherwise most people might miss that Marble can read and display them. This also meant making these file types known to the mimetype database at all, so both a proper name for the file type and a nice icon are shown in the file manager/dialog (shapefiles being a little troublesome here, as they are split into multiple files, where some are hard to catch by magic rules, but at least the main file .shp is):

Opening these files in Marble is now just a single click away.

Next step is to finish the thumbnail plugin, so one can also have nice previews of the content of these filetypes. And then some more things. One day even the Map shape for Calligra hopefully

It was a very good weekend, I am glad I could be there and meet almost all of the Marble developers (which to some degree I am now one as well, if only by my own copy of the Marble t-shirts Torsten handed out as present to his fellow developers).
And Prague is still an extremely beautiful city, also when with a foggy dress.

Thanks to OpenSUSE for hosting us there, and thanks to the supporters of KDE e.V. to enabling them to sponsor the Marble Weekend 2012!

All new Okteta features for KDE Apps 4.9 in a picture

KDE Apps 4.9 is out, providing also the version 0.9 of the hex editor Okteta.

So like done for 0.7, 0.4, 0.3, and 0.2, here another entry in the series of all-new-features-in-a-picture, take a quick glance what is new since 0.7:

Which background to use for text style previews?

So I thought I am smart and made a patch to have the text style selector in the text shape configuration of Calligra always with a white background.
Because in the text style selector the names of all styles are rendered as a preview, incl. the color. Which is nice, but is flawed with dark UI color schemes, as typically text styles have dark colors, so the name is hardly seen. And as the preview in the style manager is already done on a white background, and the sheet of a new blank document is white… well, I thought it is smart to just fix the text style selectors to always have a white background.

Just… I already saw it before because one of the testing documents had a, exactly, white text style, as that was for a colored header. And since then there is more and more of that kind jumping into my eyes… e.g. here in Calligra Stage:

Sigh…

What could be done about this?
The initial idea was to always use the background of the currently selected shape/page. But what if that is a gradient, then use the color under the cursor? That could result in an ever changing UI, not sure that is preferred. And would not work for the style manager, where one background color has to work for all text styles, both in the listview as in the big preview area.
Faking a transparent background, the usual way with a check pattern? That looks ugly, no?

KDESDK module planning the move to git

So while quite some KDE modules have pioneered the move/migration from subversion to git as SCM, others modules have been resisting that move, for various reasons. Just, seeing the pioneers to settle successfully and to have a better life, the home-stayers get jealous and start to plan to follow in the land of better living. After all, the road and the traps to avoid are known now.

And so does now the KDESDK module. There is a page on the Community wiki as central place to coordinate things for the migration, go there if you are interested to see what is happening and how.

All known maintainers of things in KDESDK have been tried to reach. If you feel responsible for something in the module and were left out, please act now and join the new mailinglist for kdesdk. Anyone else interested is of course also invited to join

The unmaintained things in KDESDK have been removed already (kspy, GUI for kunittest, scheck), no need to migrate that (for now, can be done later if picked up).

Comments on this post are disabled. If you want to comment, please simply subscribe to the mailinglist for kdesdk and join the discussion there, so it’s in one place!

Maintainer wanted: port the “scheck” style to Qt4/KDE4

In KDE3 times the “scheck” style from kdesdk/scheck could be used by developers and testers to “highlight accel and style guide conflicts”, like this (from the README):

• Orange shows accel conflicts.
• Green proposed accels.
• Dotted red lines show nested groupboxes (not prohibited, but not favored ).
• Potential style guide violations are marked with yellow, likely ones with red.
• Missing colons are drawn with two small red squares.
• Errors in window titles are marked with “foo|b|ar”.
• Violet background show untranslated string.

Just, the scheck style has never been completely ported to Qt4/KDE4! Since the begin of the KDE4 era it has stayed in kdesdk but excluded from any build. And now in the preparation of the migration of kdesdk module to git-based repositories any unported submodules will be moved to tags/unmaintained/4, already next sunday, May 20th.

So take a look at the current sources (Link updated to new location in tags/unmaintained/4) and consider giving it some Qt4/KDE4 love

If you are interested, please subscribe to the new mailinglist for kdesdk.

Herding your program’s icons, how?

The last weeks I have been doing my small share of bit-flipping to contribute to the polishing of that big, big rough diamond which there is called Calligra, doing some pixel pushing here and there (e.g. on the line-end-style selectors and the rulers) and fixing a few bugs.

Now I wanted to give all icons used in Calligra a check, to see both if there is an icon for the given icon-id as well as if there are icon files installed which are no longer used. After all Calligra is a quite large codebase, coming over a long and winding road (some files have up to 13 and more authors, the first one usually in 1998 ), so a few icon usages got broken during the trip.

Problem
But how to get all icon-ids in your codebase?

I have used a simple approach to get at least most of them, doing a grep for lines with “KIcon(“. That gave me more than 1000 lines for Calligra, and almost all also directly used an icon-id, so there was chance to do a check and create a report for these.

Now this is quite unsatisfying to not be able to easily get a list of all the icon resources used in your codebase. How do you deal with this in your project?

Proposal
Ideally icon-ids would be kind-of tagged when used, so like gettext is able to extract all strings which need a translation, some geticon would be able to extract all icon-ids. The result could then be used to check the icon-ids against the icons available from the icon themes and the icons installed from the project itself, ideally automatically (as doing that manually is… pretty boring, time-consuming and error-prone).

I could imagine that there could be some macros

kicon("some-icon")

and

kiconid("some-icon")

which would resolve to

KIcon(QLatin1String("some-icon"))

and

"some-icon"

and would enable to automatically extract these icon-ids.

What do you think? Comments, other/better proposals welcome!

Upcoming: Barcode shape for Calligra

More and more signs and papers seem to get covered with QR code pictures these days, to allow people with camera-equipped devices to copy some text by taking a picture, helping around the error-prone and cumbersome copying by typing letter by letter. Those code tags are not really aesthetically pleasing (yet), but if you ask your search engine for “QR” and “art” you will see that people are trying to do something about that.

Trying to do something about any support for 2D and 1D bar codes in Calligra, now I have been doing that the last days. With the prison library around there is some code already to do the encoding of text data into the code pictures, and with Inge Wallin having added up-to-date template code for a shape last week, doing a shape for barcodes was to a large degree simply filling in template code and wiring things up.

So for Calligra 2.5, the release after the next, you will hopefully be able to e.g. add a QR code to the last of your slides, if the code passes review and testing. So people can get your contact data as vcard or a link to a website with more info, by you dropping a barcode shape and entering the text like this:

This could also be a useful for someone wanting to write a program for mass-production of labels, similar to KBarcode, but based on Calligra modules, to be more powerful e.g. thanks to all the shapes.

Calligra is really getting somewhere finally. Check out the sources and see yourself. Those people have done amazing work. Time for everyone to start and join polishing, to help on the breakthrough from a dream to reality, which has never been closer.

Reading other files from the past…

While being stuck in text layouting problems during my work on writing an import filter for CDRv4 files for Calligra, I discovered that the import filter for the xfig format is currently disabled from built and needed some porting.

So for some change and a break and the old files I have around in the xfig format I gave it a try, should be just a few hours… Well, of course that became a few days, but now the import filter works at least somehow comparable good as it might have done before.

E.g. this old file

is now imported as

You see that text and arrows still need some work, and so do pattern fills, but otherwise it looks good. Except for:

??? How to translate x-splines to quadratic/cubic Bézier curves ???
XFig was used to be the reference implementation for that special type of splines. But so far I have not seen an explanation how to translate those to the kind of curves which are supported in ODG/SVG. Any help welcome! Currently those curves are imported as simple polylines.

If you want to give the filter a look, it currently lives only in an own branch in the Calligra repo, named filters-karbon-xfig-recreate2012.

Progress on CDRv4 import

It might be these magic moments which keep one returning to sit in front of the computer: you once again change a few lines here and there, like done before, and out-of-a-sudden something consistent appears on the screen, instead of random lines and dots.

This has now happened a few times since I started to try to import my old Corel Draw v4 files in Calligra. Just, one quickly gets used to what one has achieved, on the week-end I was happy to see this (cmp. the initial picture):

But that picture is still not exactly the one I remember, no wonder, there is quite some data which is not yet interpreted on reading the CDR file. For example in the transformation data so far only the x and y translation information was used, the other values did not yet make sense to me.

But after starring for some time at the corresponding bytes from my files today I finally seem to have found out how those floating values are stored:

• the first two bytes give the fraction part, by an unsigned 16-bit integer value to be divided by 65535
• the second two bytes give the integral part, by a signed 16-bit integer.

Never seen that storing approach before Just wondering how a negative value < 0.0 would be stored that way, maybe such a value is not to be expected here?

Using this interpretation gives me something which is quite close to what I remember:

But there are other files which still render awfully. So not yet done here. Also, with some v5 files around I need to look into that format version as well, and also see how all this code work could be integrated with libcdr, so it lives on.