leinir

Friday, everybody's arriving. After driving for 12 hours, the 4 person Danish contingent arrived in Munich safe and sound, and found two people already at the hostel, Arjen Hiemstra and Dirk Leifeld, both sitting in the lobby, where we joined them.

As most people were slowly trickling into the hostel, we all hung around the lobby while the rooms were made ready for us. Much random talking happened, and around four the room keys were finally handed to us, and everybody put their stuff in the rooms and such.

After this we all went out for a meal at a nice little restaurant down in town, where we were introduced to a mix of beer and soda named Radler - since only one person in the group is German (Dirk Leifeld), he was our interpreter. However, as it turned out, this was not really needed - everybody at the restaurant spoke English, so we could all order. One of the guys, of course, forgot to tell us that he is a vegetarian before we actually started ordering, so much fun ensued attempting to find a vegetarian dish in a place whose specialty is grilled foods

However, everybody was fed, and again much talking happened. One thing which was discussed around the table was the sound systems available to us for creating games. As we know already, Phonon is not really geared for such things as it is currently, and we do not know of QtMM is useful for it either. However, in Gluon there exists a library named KAL, which currently knows of two things: Playing sound effects and playing music.

Furthermore was quickly discussed input systems. Qt currently lacks an input handling system powerful enough for use in games - there's keyboard, but it is not entirely fast enough, there is mouse support, which is fine for point-and-click things, but not so good for e.g. first person shooters, however there is no handling of joysticks and the like. In Gluon we're working around this by having KCL, which is already extremely powerful - the problem it has is that it needs a new backend for each new operating system. The backend on Linux is the very powerful evdev, but on MacOS X we have one person who through the last couple of weeks has been ripping his hair out trying to get input out of the system itself, and on Windows there's nothing so far (though the idea of using DirectInput has been tossed around).

So, discussion points for Saturday now also include sound and input, on top of scripting and showing off Blender Game Engine and Unity3D which was already on the agenda. So, much to be done!

After the meal, we went back to the hostel - which has really nice rooms, with en-suite bathrooms and plenty of room for the four people sleeping in each room - and people went straight to sleep. Personally, i went to sleep after sitting in the lobby for a while, not managing to stay awake. As i later find out, around half an hour later, two more of our team scheduled to show up Friday showed up (saw the texts on my phone this morning, telling me they had luckily found their way into their room), but at time of writing i have yet to hear from the final member (Sanro Andrade) coming in from Brazil. Hopefully he will be ok - i will find out when we meet up for breakfast in a few minutes.

So, the first day went quite well, all things considered - people were tired after a long day of travelling (for most anyway, Leifeld only had three hours in a train, and others a couple of hours in a plane, bah! ) - a really good day, with much talking both shop-talk and non-shop talk, which of course is at least as important at this type of thing. Getting to know how people work is just one of those things that's difficult to pick up through email only. So, good stuff all 'round! Looking forward to this sprint

P.S.: Yeah, i know - this entry isn't tl;dr compliant, and contains no pictures. Sorry, i shall endeavour to do better tomorrow when i'm not tired!

Do you want to go to Qt Developer Days in Munich, October 12th to 14th? If so, read on!

Traditionally, game development in KDE has happened much like how you would develop any other application: You start out with an idea, then you boot up your vi/emacs/kdevelop or whichever other coding tool you use, and you start hacking together your game logic. Later on, or during this, you team up with a graphics artist, and maybe a sound artist, and you all work together to create a pretty, well sounding game. Now, we have seen in KDE 4 that this actually works.

However, there is a fly in the ointment. One of those big, blue ones that just won't go away when you swat at it.

First, of course, the graphics people and the sound people at some point have to start pestering the programmer to change their code so that their work can fit into the game better. Unless they know a little code, they have to rely on the coder to change which pieces of graphic and sound are loaded and played when and where. This makes it difficult for the sound guy to time his sounds so they fire at the right time, and for the graphics guy to time his animations so they play at the right time.

But more than that, however, you have the problem that every time you start writing a game, you as a programmer end up rewriting the same code again and again. You write an input handler, you write a simple (or not) playing field, you write your gameloop, you write a structure to manage each of the objects in your game... Why is it that this needs to happen? Why can you not simply start up a tool, and start writing your game immediately?

In other worlds, you have a number of tools to assist you in your task when you want to create a game. In the Windows and MacOS worlds you have tools like Game Maker and Unity 3D, and in our own world we have... Not a single thing. The closest thing we have is KDevelop 4 which makes some things easy for us, but even that is just a generic IDE, it is not something really geared to making games, and most importantly: You could never give a graphics artist or a sound artist KDevelop 4 without risking them curling up in a small ball and making unpleasant squeaky noises, something which is not particularly conducive to getting a game made.

So, today i offer you the potential for a brand new scene, a new world: A world in which KDE ends up taking the indie games scene with a storm.

Today, i announce: Gluon Creator.

Based on the Gluon project's heavy legwork, the powerful systems inside KDevelop 4 and an investigation into workflows, Gluon Creator is a project which will aim at creating a tool designed specifically for creating games, which is useable by all the artists that make up the team behind them: Graphics, sound, level designers, game designers, coders and all others involved in the process.

The connection this has with DevDays? Simple: Nokia has gracioucly offered to sponsor up to 15 people attending Qt Developer Days in Munich*, and in connection with this it was suggested that a developer's sprint should happen the weekend leading up to DevDays, in the style of those held for the KOffice, Amarok, KDevelop and other teams. The topic of this sprint would then, is my suggestion, be the initial creation and investigation into what would be needed for Gluon Creator to happen.

So: To attend Qt Developer Days 2009 in Munich and the sprint leading up to it, get in touch with me, either by commenting on this entry, or by emailing me directly at admin@leinir.dk - please don't hesitate! And remember, just because you are not a coder does not mean you won't be useful here!

*: Yup, there's one in San Francisco as well, however the sprint there will have a different focus, and i'm only sporadically involved with that one anyway and will not be going

This is going to be my shortest entry yet, mainly to say that this absolutely rocks in so many different ways! Nokia has released Qt under the LGPL - Ryan at ars talks about it some more here

Yes, i know this sounds contradictory to what markey said in his recent blog, but i felt the need to elaborate somewhat on his statement regarding the old-style playlist being gone. While yes, this is entirely true, and good riddance (as it says), this is mainly because it is far too inflexible. The new playlist is vastly superior in all ways, and i shall spend a few moments describing to the doubters just why this is so.

The most often mentioned dislike with the new playlist is, well, the new playlist - or to be more exact, the default layout used in the new playlist. In my original post of mockups of the new playlist layout, i failed to touch on the topic of the layouting system needed for it. This is really where the whole thing comes together and enables those who dislike the new fanciness to get back to using the old, 90s style playlist view.

A bit of graphics always helps with understanding such things, of course, so here you go - description of the essential parts of this below



What you can see in this mockup right at the bottom is a section reading "Available items for header". What this really means is that this is where you design the layout of your playlist. The header is what is shown in the playlist, and while the default set contains two rows of data and a piece of art spanning two rows, what is not so clear in the mockup is that you are able to add new rows and items, splitting the entire layout up in any way you want to. What this means is that if you really want to, you are able to put all the items on a single line, and the album art gets scaled accordingly.

This all depends on someone actually implementing this layouting system/manager

N.B.: This mockup also shows how sorting will eventually work in the new playlist

In the beginning, the benevolent Ceiling Cat saw that Amarok 2 required tagging abilities, and He saw that it was sorely lacking in both quality and scope. And lo! a solution was presented, in the form of our very own Summer of KDE student Teo, who will be joining the Amarok squad and create the tagging solutions for Amarok 2!

My name is Teo Mrnjavac and I study computer science at the University of Trieste, Italy. My initial proposal was to implement mass tagging in Amarok 2, but givent the current state of things I will have to do a bit of porting to implement basic tagging support as well. While keeping as much as possible of Amarok's existing interface intact, the goal is to implement an unobtrusive and simple, yet powerful interface with the underlying algorithms to mass process the tags and file names consistently on top of the collection browser and to download track information from a remote database.

The key to simplifying the usually clunky rename-from-tags or extract-tags-from-filenames functionality would be a visual layout bar with movable items representing the elements of the filename's syntax. Ultimately, every user, regardless of his tech savvy, should be able to have a consistently and cleanly tagged collection with only a few clicks.

Greetings

Teo

In short, Teo: Welcome!

Some people might be aware of one of our competitors attempts at making something which looks all swish with all those high quality CD covers that people have for the albums in their collections. Now, we long ago decided that while eyecandy is all good and stuff, we really don't want eyecandy without a reason behind it. So when people started asking repeatedly "Hai, I can has coverflow?" on #amarok, we started thinking how something like that could be kicked into some form of usefulness.

And, so, when Summer of Code came around, we decided that it would make good sense to throw up an idea on the page for exactly that - our thoughts on what might make a useful bling. Many came forward with proposals for taking up this idea, but unfortunately, though in fact several of them were really good, in the end we had to not accept them as there were some that were more important for Amarok 2's release. However, luckily, one student came forward with a refined proposal for the CD Stack after the accepted projects had been presented. In stead of talking more here, i will let nottheones tell it himself:

My name is Nicholas Lovell, and I study computer engineering at the University of Notre Dame in South Bend, IN. This summer I will be providing a new collection view. My idea is to provide a 3D list of albums that can be browsed much like a physical CD collection. Think of it as how CoverFlow should have originally been implemented. Rather than simply allowing selection of an album (or simply displaying the album currently playing), it will also allow selection of individual tracks from a selected album. Selecting a CD from the stack will display the front of the CD and the tracks from the album underneath it.

So, ladies, gentlemen and everybody else - forget the CoverBling widget from early Amarok 2 code - real niftiness is coming up!

As you might have noticed, Plasma now has control handles on each plasmoid. This has been a long way under way, and i am very happy to see them arrive Being a non-codey type person, though, i was then reminded that at Akademy this year, i did a sketch of what handles might look like for Plasma. And well... they look very different to the ones in Plasma right now, and i have a feeling that they would feel more natural to the user. So here, with no further ado, the mockup: