So it seems my…

summer of 2011 will come in a distinct 2009 flavor. Can’t wait to get started ;)

I’ll probably blog my progress here. What do you guys think; OK for me to have it aggregated on p.k.o? Scribus KDE-ish enough for you?


PS. For those of you who didn’t understand or can’t be bothered to click the links; I’ve been accepted into GSoC this year to improve the tables support of Scribus. You might remember me doing the same for KWord as part of GSoC back in 2009. DS.

Call for Help — Styles Widget for Calligra Words

Background

Some of us in the Calligra team recently got together and held an IRC meeting to discuss a redesign of the text styles dock widget in Calligra Words. The meeting was attended by both coders and usability people. A full summary of the meeting is available on the wiki, but some of the conclusions were:

  1. We need two dock widgets: one compact for people who value screen real-estate and one big dock widget for the styles junkies out there who always wants to have the list of text styles available on-screen.
  2. Applying styles should be a one-click operation.
  3. As the styles dock widgets are mostly used to apply styles, styles should be presented in the dock widgets as a simple list, not as a tree showing the inheritance between styles.
  4. Previewing of styles should as much as possible be done in-list. That is, items in the styles lists are previews of themselves.

Apart from that, most of what was decided at the meeting were details regarding the implementation.

Below are some preliminary mock-ups of how we envision the new styles widget to be used in the two dock widgets. Note that the same styles widget will be used in both these dock widgets, so the two dockers will probably share 99% of their code.

Compact Dock Widget Mock-up. Click to enlarge.
Compact Docker Mock-up. Click to enlarge.
Big Dock Widget Mock-up. Click to enlarge.
Big Dock Widget Mock-up. Click to enlarge.

Call for Help!

Some preliminary coding of the styles widget to be used in the two new dockers has been started by Casper, but now we’re looking for someone to finish the work. The task involves implementing the actual list view used in these two new dock widgets. If you feel that you

  • want to help out with making Calligra Words a lot more usable
  • have some experience with the Qt model/view framework
  • want to work with a motivated and friendly team of developers
  • like to have your work shine at a very prominent place in Calligra Words

then you’re the one we’re looking for! If you’re interested in helping out, you’re welcome to contact us in the Calligra Team either in #calligra on irc.freenode.net or on our mailing list.

Spotify Links in Chrome on Linux/KDE

Short tip on how to get this to work:

Create a script /path/to/spotify_open.sh with the following in it:

#!/bin/bash
wine "$HOME/.wine/drive_c/Program Files/Spotify/spotify.exe" /uri "$1"

Create $HOME/.kde4/share/kde4/services/spotify.protocol with the following in it:

[Protocol]
exec=/path/to/spotify_open.sh "%u"
protocol=spotify
input=none
output=none
helper=true
listing=false
reading=false
writing=false
makedir=false
deleting=false

That’s it, spotify:blah style URLs will now open in Spotify launched through Wine. Chrome just uses xdg-open for launching external apps.

HDD fail :/

*From the annoying-like-h**ll department*

After a nice weekend at my parents and hanging out with some old friends, one of which recently came back from a stay in Kunshan, China, I was greeted this morning when coming back home by a crashed hard drive on my laptop :/

It started out with things beginning to act irregular, and then after a reboot I was told the computer had been uncleanly shut down and was dropped into an fsck run that failed in flames with I/O errors and whatnot. I ran a manual fsck and actually got it to a state where I could boot it again, the kernel kept spewing I/O error messages and failing ioctl commands though. I managed to get some of the more important files off the drive and onto my USB stick. They were actually surprisingly few compared to last time I had a hard drive crash, which is a small consolation.

Having been through several hard drive crashes in the past, what pisses me off most about this one is not the loss of data but the fact that it’s just a 1 year old drive that is now failing, which I really think is crappy. But more importantly the annoyance of loosing time having to go hunt for a new drive and set up the system again; I really don’t have time for this right now. What’s also annoying is that for many many years I always had at least two computers at home, but since just a few months ago, the laptop has been all I have. And of course the Kubuntu CD I had laying around was scratched so I had to go to a friend to burn a new one.

Anyway, the machine is back to normal now and sounding like a cat from the make -j4 getting a dev env up again. Lessons learned; as always, keep a backup; make sure you have a working installation media for your OS of choice around, and consider having at least two computers in your home.

At the store, getting the replacement drive, I didn’t really care that much what I was getting and just picked something. On the way back I realize that it’s a 320 GB Wester Digital… I think it might actually be the exact same model that I had.. Stupid? ;)

Tables GSoC Update

Here’s a little update on my GSoC progress. Time really flies and we have less than two weeks left until pencils down!

Some of the things that has happened in KOffice tables land since last time is:

  • Fixed a bug in relative table width loading.
  • Further improved KoTextDebug to work with the new styles for tables, rows, columns and cells.
  • Added support for column width and relative column width. Up until now all columns were hard coded to equal widths.
  • A KoTableAndRowStyleManager has been added for managing column and row styles.
  • Fixed a bug where two subsequent tables were painted on top of each other.
  • Added support for minimum row height.
  • I began to re-factor the table layout to use a list of rectangles that describes the table instead of a simple rectangle, and started thinking about table breaking. Pretty soon though I realized that I was probably in over my head, and passed the torch to Casper, who has been hard at work trying to get the first pieces in the breaking puzzle, hard row breaks, to work. I just got word on IRC that he may just have it working (!).
  • Finally fixed the issue with an empty line above tables. This text block is there by necessity; it’s mandated by Qt Scribe. Me, Thomas and Casper discussed a bit on how to best handle this. And at least for now, we’ve chosen to solve it like Qt does in its own layout engine, which is putting the empty block to the left of the table. We might do some improvements to the user interaction here though.
  • Added three new classes; KoTableFormat and its subclasses KoTableColumnFormat and KoTableRowFormat. These are very much like the QTextFormat classes in Qt in that they’re simple implicitly shared classes that hold a set of properties. They are not used yet, but will be soon.
  • Fixed bug in justify aligned tables when an explicit width is also specified.
  • Fixed up the table layout code to handle nested tables, as it was totally oblivious to them up until now.

In addition to these things there were some other small fixes, and I’ve also worked a bit on the tests, which all needed fixing after Casper’s re-factor. More work to be done on testing though and right now I’m looking at adding some loading tests to the test suite that Girish created.

On Tuesday last week I fell terribly ill, with high fever, and was mostly in bed or on the couch for a good two days. I’m back to full health now though. I think it might have been food poisoning.

The future of the column and row style manager I mentioned above is unsure though. At the moment it’s just a container for pointers to the styles, and the loading code tosses them in there and decorates the QTextTable with a property containing a pointer to the manager. Not really the prettiest of setups, and we need to find a better solution. The format classes I added are a part of this puzzle, but the question is; where do we store these formats?

I’m sure we’ll work it out though, and now I need to get back to coding. Sorry if this post was a little duller than my previous ones, but to cheer you up, here’s a screencast in which I save a set of nested tables in OpenOffice.org Writer and open them in KWord to edit them a bit :)

Nested Tables from OO.o to KWord
Nested Tables from OO.o to KWord

Direct link (15 MB, Ogg/Theora)