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.

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?

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

Lots of stuff has happened since my last blog. It’s Monday afternoon when I’m writing this and I’m on the train back from the sprint that Casper Boemann and I had at his place outside Copenhagen this weekend.

Since Casper is now working on tables support as part of his employment with KO GmbH, we both agreed that it would be a good idea to have a meeting to make plans for our cooperation during the rest of my GSoC, but also do get some hacking done.

The weekend has been intense to say the least, and we’ve added support for several essential features of tables, such as:

• 
  

  Row and Column Spanning

  Cells can span multiple rows or columns. The row height calculations have been updated to handle the case where a cell that spans multiple rows grows vertically from a text insertion; the last row that is spanned into will grow in height along with the spanned cell.

• Table and Cell Styles

  Thanks to hard work from Casper, we now have KoTableStyle and KoTableCellStyle, which are proper styles for tables and cells, respectively. Work is underway for row and column styles.

• 
  

  Loading

  Casper also took the plunge on loading and quite quickly got stuff up and working, and with the commit he did right before I left his apartment, most of the features here should now be loading correctly from ODF.

• 
  

  Table Alignment and Margins

  Tables should now support all the alignment options in ODF; right, left, center and margins (justified), and they can have a left, right, top and bottom margin.

• 
  

  Table Background

  Tables can have a global background color set.

• 
  

  Relative Table Width

  Tables can now have a percentual width that is relative to the page width.

• 
  

  Cell Background

  Individual cells can have a background color set.

• 
  

  Cell Borders

  Cells can have borders, including double borders with a spacing between them.

• 
  

  Cell Padding

  Individual cells can have a left, right, top and bottom padding.

During our sprint, Casper focused on loading, styles and drawing, and also sat with me for some pair programming when we implemented spanning, while I worked mostly on the layout part and unit testing of the features.

All in all it’s been a great weekend. Of course there are bugs to be worked out, but the basics of these features are all there and working. Casper is a very friendly host and a great programmer. I have a lot to learn He also did all the cooking and made me feel right at home. Thanks Casper!

The weekend ended with a couple of hours of planning, and we made a detailed list of ODF table features that we want for 2.1.

It’s quite pleasing to see that the approach to tables in KOffice that we’ve chosen seems to be holding up, and I’m pretty sure it will work out for all the remaining features that we need to implement, of which proper table breaking across pages is perhaps the most tricky one, from a layout point of view. But that’s for later; right now I’m going home for some resting up, and I think Casper is doing the same back at his place.

Anyway, kids are screaming like crazy here on the train, so I think I’ll end this blog with a little screencast showing off some of the new features, and then put on my headphones and doze off.

So long!

Copenhagen Sprint Features Screencast

Direct link (2:40 min, 15.2 MB Ogg/Theora)

Right now I’m on the train down to Copenhagen for a little sprint/coordination meeting with Casper. As it turns out, he’ll be working on tables too and therefore we thought it would be good to get together and coordinate a little. And code like crazy of course.

I’ll be going home Monday afternoon, and hopefully there will be something blog worthy coming out of this. *yAwn*. Got up at 5 AM, so a little tired, but no rest for the wicked right?

Later, Elvis.

As you may remember from my last post, I was cheating in my screencast; the table height was hard-coded and the cell heights were not adjusted to content height. What I needed to do was to handle the following case:

Cell Heights Adjustment

I have just commited the beginnings of this in r997173. TableLayout now has an updateCellContentHeight(QTextTableCell&) API, which is called once the content of a cell has been laid out in Layout::nextParag().

There are a lot of rough edges, and my tests of course broke left and right, but it principally works, fingers crossed Here’s a video demonstration:

Cell Heights Calculations

Direct link (1:30 min, 7.6 MB Ogg/Theora).

I skipped uploading to Vimeo this time, as it’s so clunky. I don’t think anyone will miss Flash right?

Anyway, my dear mom just appeared and is taking me out to eat, then I need to start fixing/extending those tests, so bye for now!

I hope everyone had a nice time on Gran Canaria. It seems like it’s been a really successful event from all the posts I’ve read.

I’m not one of the frequent GSoC bloggers here on p.k.o, but as we are in mid-term now I thought I’d make a little summary of my thoughts around the project so far and give a little status report.

Initially my idea was to divide this post into two sections; “The Good” and “The Bad”, with a summary at the end. But then I realized that for almost every bad thing I could think of, I could find a good side to it, and vice versa. There’s always two sides to a coin. So instead I’ve decided to make a table. How appropriate

(The table is styled and probably looks better at my blog page)

GSoC experiences so far
-	+
Table layout is hard. There are just so many things to consider, and a lot of side cases to take care of. Just look at Qt Scribe’s implementation. Lord knows I have	But extremely fun and a very rewarding thing to work on. The feedback is quite immediate, which is very gratifying.
Unit testing is an art. You have to be very careful what you test for and how you go about it. Just writing the tests is not enough, you have to put a lot of thought into it.	But it’s an invaluable tool when starting out and trying to focus on a specific aspect of a complex thing such as table layout. By the way, anyone who can recommend a short little book on unit testing? Preferably something as concise and “hands-on” as e.g. Meyers’ Effective C++.
I have probably over-estimated my abilities as a programmer. I tend to try to consider all the consequences of the changes I do at once and look into the future, instead of focusing on the actual problem at hand, and this tend to be a real show stopper for productivity. As my good mentor Thomas put it; perfection is the enemy of productivity.	But I’ve learnt a lot about my abilities and limitations, and I feel that I’m improving. I’m confident that by the end of this summer, I will have grown as a programmer.
Git can be confusing. Coming from centralized VCSs like SVN and CVS, wrapping your head around this new-fangled distributed VCS can be quite daunting, especially as the user interface is a veritable swiss army knife of funky names and idioms. A text that really helped me understand how Git works was The Git Parable. And for the more technically inclined I’ve heard good things about Git for Computer Scientists	But it is a God-send after all, and I can’t wait until all of KOffice (and KDE) is on Git. Things like cherrypicking, interactive rebasing and extremely easy branching/merging is just too good to say no to. I’d like to make a parallel to when I first learned Vim. No pain no gain right? Recent posts here on the planet, if I understand them correctly, indicates that there are talks about hosting KDE Git repos at Gitorious, which sounds like a good idea to me.
The payment schedule of Summer of Code is kind of unfortunate. At least if you have high fixed expenses every month, as you’ll have to go all through June without any money. This is something to think about if you’re considering participating. I was lucky to be able to loan money for my rent/Internet/electricity/phone bill.	But this is definitely understandable. Having monthly payments would mean having monthly evaluations and a lot more work for both mentors and Google staff members. I guess a lot of students in the program live with their parents and don’t have a lot of expenses. But I’m (almost) an old fart as far as students go Just bringing this up, as it can become an extra stress factor.

All in all, I’m having a great GSoC so far, and I think it can only get better.

Progress

Now on to some information about my progress. What I’ve been working on is getting some first basic table layout working. The design is quite simple so far, and looks very roughly something like this:

Table Layout Design Overview

The Layout class is the innermost class of the text layout engine in KOffice, and is the one responsible for most of the nitty gritty details of text layout. It is declared as an inner class of KoTextDocumentLayout, which has an instance of this class called m_state.

KoTextDocumentLayout in turn is a higher level class that derives from Qt’s abstract document layout class QAbstractTextDocumentLayout. Qt’s own document layout engine, QTextDocumentLayout, which is not shown in the diagram above, derives from this same ABC. I’ve also included KWTextDocumentLayout, which is a specialized KoTextDocumentLayout used in KWord. It adds support for letting text flow around other shapes, among other things.

What this all means is that KOffice’s layout engine, while still working with an underlying QTextDocument, is completely separate from Qt’s. Now, because of poor research on my part in the weeks leading up to the GSoC start, I actually thought I’d be able to leverage at least some of the built-in support for table layout in Qt. But I have only myself to blame for that, and it’s nothing to cry over now. What I do get is QTextTable, which can be considered a blueprint for a table, and my task is to lay out this table according to its properties, which I’ll later have to extend to support ODF features that don’t have a 1:1 equivalent in QTextTable and its associate classes.

I’ve modified Layout to have an instance of the new class TableLayout, which is responsible for doing layout and drawing of tables. It takes a QTextTable and lays it out, storing the layout information, such as table and cell geometries in an associated TableData instance. It actually caches TableData instances per-table internally. TableLayout offers an API to be used from Layout to obtain cell content rectangles to direct the layout engine into, as well as an API for adjusting cell heights based on the cell contents.

It’s a simple design, but one that I think will work out fine for all the requirements that will come later, and I already have ideas on how e.g. cell spanning should be implemented. Things on my TODO are too many to even enumerate, but what I’m working on right this minute is row heights calculations and finding a good way to let the layout process in Layout notify the TableLayout of cell content height changes. After that comes, among other things:

• Margins/paddings/borders.
• Variable column widths.
• Tests, tests and more tests.

Now let’s see, this post has had a table, a diagram and a list. What’s missing? A video of course Take 50 seconds and marvel at me pasting a basic table from Firefox into KWord and editing the cell contents:

Direct link (5.7 MB Ogg/Theora).

Actually I’m cheating in the above video, as the table height is hard coded, but don’t tell anyone!

Finally, I’d like to be honest and admit that progress really haven’t been as fast as I thought it would be, but I do feel that I’m on the right track. And even though the road ahead is longer than what I would have wanted, at least it seems pretty straight, all things considered.

Now if you’ll excuse me, I really need to get back to coding!

Bye ’til next time!

The good news is: Yes! My proposal was accepted and I’ll be working this summer with implementing basic support for tables in KOffice’s text shape. Of course I’m very excited about this and I just wish school was over so I can start hacking.

I’ve been aggregated on the planet for a while now, so maybe some of you have an idea of who I am, though my very infrequent posting surely hasn’t helped. My name is Elvis Stansvik and I’m a 25 year old student from Sweden. A little more about me in my original proposal. I’ve followed the KOffice project with great interest for the past 4 years or so, and when time has allowed I’ve done some bug fixing et.c. I’m looking forward to finally be able to put my heart into the project this summer.

Since support for tables is quite an ambitious task and one that is important to get right, I’m very honored by the confidence put in me by the KOffice mentors and I’ll make sure to work closely with my assigned mentor Thomas and other senior devs within KOffice to bring it to fruition. Don’t be fooled by the word “basic” in my proposal title, tables are a complex thing to implement and although my goals for this summer does not include support for every single detail of the ODF specification of tables, all the requirements of the spec must still be kept in mind in order for my implementation to be able to grow in the future.

As I said, at the moment I’m kind of swamped by school work, but during the little free moments that I actually have, I’m putting my nose in the text layout and loading code of KOffice, and I think that I already have quite a good grasp of how it fits together. School work should ease up a bit in the coming week or two, and during this initial “Community Bonding” period, my plan is to:

• Read all the relevant portions of the ODF specification and keep my eye out for things that I need to keep in mind that I haven’t thought of already, and maybe create a short list of “requirements” to get a better overview of what ODF demands when it comes to tables.
• Spend more time reading and maybe even poking at some at the text layout code in plugins/textshape and loading code in libs/kotext/opendocument. No better way to learn than to break stuff.
• Ask my good’ol mentor quite some questions!

In the beginning of June, I’ll also be attending the KOffice meeting in Berlin, where I’ll be able to meet Thomas and the other KOffice devs.

All in all, I think this summer will be a lot of hard work, but a great opportunity, both for me to grow as a programmer and learn more about the KOffice code, but also for KOffice who will finally be getting a proper implementation of tables for the 2.x series, and I’m very much looking forward to it.

Just posting this in case it helps anyone else who like me was unsure about their eligibility.

My previous work experiences are quite varied and include running my own book shop and eventually a book café, working as an IT-technician for a small book publishing company and also being leased out as a programming consultant to other Swedish publishing companies. At the moment I’m studying and doing some part time work as a translator of technical manuals and user interfaces for a Spanish localization company.

I’m an agile worker and good at keeping deadlines and delivering on spec, as well as quickly getting up to speed in large existing code bases in a multitude of programming languages.

If you need an extra hand for your project, or just need an additional part time worker on your staff, please don’t hesitate to contact me! Here’s my CV. I’m not picky about which tools or technologies you want me to work with, or afraid of mundane tasks. And the pay just have to be reasonable, not more

Looking forward to hearing from you!

Phone: +46763091545
E-mail/Skype: elvstone [[at]] gmail.com