Entries by Dan Leinir Turthra Jensen

Starting the day with a hearty breakfast is very important, and for the people at the Gluon developers' sprint this is of course no different - anything but, in fact, as the sprint is quite intensive. And so, the day started out with having breakfast in the hostel's cafeteria, which served a quite straight forward continental style breakfast service with cereal, bread, cheese, meats and all that's included. Oh yes, and cocoa milk.

After the breakfast, Harald Fernengel picked us up. For those of you who don't know, this is the guy who made sure that we had hacking space at the Nokia offices in Munich. He is, as his name implies, an angel. Well, technically he's a troll, but you get the idea. But we already knew that trolls are, in essense, just angels without wings So, he picked us up, and had even been so good as to buy us tickets for the duration of the sprint. We then got on the tram, and en ruite Harald informed us of the interesting points - one of the best beer gardens in Munich is right next door to us, there are beautiful churches, and the shopping street was where we changed to the U-bahn.

Finally we got to the office, which is in the business area - a surprisingly green area all things considered - on the fifth floor of an office building. Very nicely laid out offices, where had been arranged coffee and soft drinks for us - news of course received by the team with sounds of glee and much joy. After setting up the laptops and checking our mail and news and such after a couple of days, it was time to start the first topics which, as it turns out, ended up taking most of the day.

Just before the first point, Knut Yrvin (for those who don't know, he's the community managet for Qt Nokia) showed up to hang out with us. In the tradition of such things, he brought along a toy for us to play with, namely an N900. Now, of course, everybody wants one (even more than they already did ).

Kim then started his presentation, in which he described what Unity3D's workflow is like, and some of the base concepts in it. One thing that i personally got out of this refresher is how scripted Components are handled. They are not handled in any magical way, like i thought i remembered. In stead, they are handled very simply by a Script Handling Component, which has a script Asset attached. The component then analyses the script, and exposes the public fields in the script as properties. This means that the concept is much cleaner as well - scripts are no longer a special case, they are simply assets. Furthermore, it meant that everybody in the team now has an at least superficial understanding of how Unity3D works, and what sort of workflows we are working towards supporting.

Afterwards, Sacha requested i describe the GameObject hierachy in some more deep detail by describing what you would do to create Pong using this method. After a bit of talking about the GameObjects and how you add Components to them, and the fact that a Prefab is really just an instance of a GameObject that you can change a few values in, but which stay the same as the prefab, we eventually came up with a layout with two instances of a Paddle Prefab (which is just a GameObject with a sprite renderer, a box collider, a mouse input component and a small scripted component which reacts to the mouse input), one GameObject named ball with most of the actual game logic inside it (a motion handler which simply moves the ball in a set direction at a set speed per frame, and a collission handler which simply checks whether the ball has collided with something, and reacts accordingly (hit one of the end walls the person owning that wall looses one point, hit one of the paddles or one of the side walls the ball bounces), and a sound emitter which the collission handler tells to make a sound at appropriate times) and four bits of wall with a box collider (made of by a sprite renderer and a box collider). The end result of this is visible in the picture to the right. Coding on your feet is fun!

Around two in the afternoon, a little later than originally planned, and after people had spent some time hacking around, working on the different parts of Gluon, it was decided that it was time to grab something to eat. So, we all got ready to go out, and as we gathered in the social area of the office, Harald handed out meal tickets to everybody and we went down to the mall next to the offices. The problem with this plan, as it turned out, was that in Munich, a lot of places are closed on Saturday. So, we ended up going to the super market, where Harald bought lots of food type things (bread, toppings and the like), and instructed the rest of us to buy random other things (i.e. snacks). So, we all ended up buying all kinds of silly things, like bisquits, crisps and so on. This mishap ended up turning out quite well, since what happened when we got back to the office was that we all gathered around the social area, where we talked much about open source in general.

After lunch was completed it was time for the final run of presentations. So, after poking around with remote desktop a lot (since Rune had also forgotten his VGA converter, and had a laptop which was not compatible with the other converter) we ended up able to see him showing off the Blender Game Engine. Two important things came out of this: We saw how not to design user interfaces -around half way in, Rune mentioned that what people couldn't see too easily was that on his netbook's screen, sitting beside his laptop, he had the keyboard reference open - basically every key makes Blender do something, and they have decided to focus so much on effectiveness that learnability has gone completely out the window. As such, they have created the 3D modelling equivalent of the Vi editor. Extremely effective, but with a learning curve greatly resembling a mirrored version of the Debian logo. The other important thing which came out of this presentation was an introduction to the interaction management system in the Blender Gane Engine. Short short version is that in Blender, any object in the game world can have three types of game related data added to them: Sensors, Controllers and Actuators. A Sensor is something such as for example mouse input, a keyboard button or a magic 'always' sensor which is simply always true. A Controller is a piece of logic which can define a number of outputs associated with the sensor's values, and an Actuator acts on the game world (for example moving an object around, setting colour values and so on). So, most things can be scripted in this manner without writing any code. Afterwards Virtools was discussed, which has a similar graphical scripting system, which was described by someone as "Horrible for programmers, but amazing for game designers and graphics people".

After this Kim, Morten and i gave a short introduction to our university project about Behavior Trees, which will be implemented as a component for Gluon. A short explanation was given of what a behavior tree is, something i won't bother you the reader with (if you are interested, keep an eye on this blog as you can be sure there'll be something about it at a later date, when we're closer to project end), but the really interesting part here was the properties editor that is found inside the behavior tree editing tool. For those interested in the code to this thing, it can be found on gitorious: http://gitorious.org/gluon-bt/gluon-bt/blobs/master/src/gluon-bt-editor/btpropertywidget.h and http://gitorious.org/gluon-bt/gluon-bt/blobs/master/src/gluon-bt-editor/btpropertywidgetitem.h (plus their accompanying cpp files, of course). What this allows us is to basically just grab this code, do very few changes to it and have it work on GluonObjects, which are the generic objects that make up a GameObject hierarchy (GameObjects, Assets, Prefabs and Components are all GluonObjects). Much more on this later - when we've actually got something to say properly on Gluon Creator (hopefully tomorrow).

The final large-scale discussion that happened was regarding the Gluon Project concept described on the wiki. What came out of that discussion was a more or less straight forward resolution that building Gluon Creator on top of KDevPlatform might well make sense - the reasoning behind this being that this already has functionality for version control and handling projects, and that what we would need would be to implement a project management plugin for it, and then create a UI based around it. Whether or not we will be using Sublime is entirely up in the air, and it may be overkill for what we need, but KDevPlatform does seem like the logical choice. It would also mean that any scripting languages we would support needs some simple coding assistance. To implement this we could either do something simple ourselves, or we can create language support for it in KDevPlatform. The KDE way, it seems to us, would be the second option. Any help with this endeavour would be greatly appreciated! (as, of course, any help with any part of Gluon ).

At six, the larger discussions finally ended and people started to work on coding more heavily. People all started playing around with their respective parts - much pair-programming or group-programming happened, with a number of small teams gathering around one or two machines, working hard on getting this or that piece working (especially KCL on MacOS X and KGL in general is getting much love, as is the Definition Language handler, plus its assisting classes).

Finally at eight it was time for dinner... But people were so busy that we ended up working way past that, not leaving the office until an hour and a half later, when Knut stood up and exclaimed that we had to leave now or face the possibility of having nowhere to eat. This meant that when we got to a restaurant which was open, we went in there and were instructed that the kitchen was almost closed. However, a quick decision later, and everybody has beer on the table, and a few minutes later food starts getting served. Fastest service ever for twelve people, i'm sure! Kudos to the kitchen team at Weisses Brauhaus for providing us with such brilliant service - especially considering the waitress didn't understand a word of English, and still seemed very happy (stressed out though she was by the sudden influx). After dinner, which of course included the mandatory discussions of open source politics and general life stories, we decided that it was time for ice cream. In the words of the ice cream gurus: Pleasure is the path to joy!. We managed to find our way home at around 0100, and all went straight to bed.

All in all, a really nice day!

Game Concept of the day: Hungry Hungry Hakcers - keep your hackers fed, or they get angry and you lose the game!

Final point: We can do better!

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!

Just as a small aside, a sort of response to Nikolaj's latest entry, he and i have already discussed the usability problems in the Ampache configuration dialog, and the suggested solution was the mockup you can find below. The problem is, of course, as it is in so many of these occurrences that this particular type of dialogue requires more work than the current implementation. Since the current one exists and so much other work needs doing to get Amarok 2 ready, we decided to postpone this work until later on. However, it would not be fair on you guys that we should keep this to ourselves, so here you go, our idea of what a configuration page for Ampache might look like:

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: