Dublin, ich komme!

Wenn alles klappt, dann sollte genau dann, wenn dieser Blogpost veröffentlicht wird, mein Flieger nach Dublin starten.

Aber was mache ich denn da nun eigentlich? Alberto hat das in seinem Blogpost wunderbar zusammengefasst. Hier aber nochmal eine kurze Zusammenfassung auf Deutsch.

Ziel der Veranstaltung ist es, das Theming von Gtk+ zu verbessern. Themes beschreiben die Erscheinung, also das Aussehen einer Benutzeroberfläche. In der einen Woche sollen gleich mehrere Probleme dazu gelöst bzw. Lösungsansätze entwickelt werden. Für eine Zusammenfassung dazu verweise ich auf Alberto’s Blogpost. Da die Veranstaltung auch ein Logo hat, möchte ich das an dieser Stelle niemanden vorenthalten.

Nun habe ich noch gar nicht gesagt, was ich damit zu tun habe. Also Carlos meinte, dass meine Anwesenheit ganz nützlich sein könnte, da ich mich ja mit Animation beschäftige und das eben auch etwas ist, was man dann gerne zukünftig in Gtk+ unterstützen möchte. Tja, wer sagt schon Nein, wenn er so nett gefragt wird?

So, na dann bleibt uns nur noch hart zu arbeiten, damit der erwartete Erfolg sich auch einstellt.

Bis denne!!! Hej då!!!

PS.: Zuerst wollte ich ja schreiben, dass ich zur europäischen Fleischertagung, dem sogenannten Hackfest, nach Dublin fahre und dort Hackepeter treffen werde. Aber das habe ich dann doch lieber gelassen, um keinen zu verwirren… .

Animation for GtkWidgets – some experiences and thoughts

Disclaimer: This blog post is going to summarise the experiences I made while implementing animation for the GtkVBox< widget and my thoughts about widget animation in Gtk+ so far. This blog post is not going to be about animation in themes because this is another issue. Of course there are intersections, I’ll point to them when they arise.
 

By the way, this is one of the longer posts. If you’re interested in this topic you should bring a bit of time with you.
 

The question is how can we support the application developer to create dynamic user interfaces and at the same time increase the user experience while preserving the advantages of Gtk+’s box model? Let’s have a look on this short video to motivate this idea with a working example of how animation for widgets in Gtk+ can look like.

What have I done? First I derived from so the original implementation is not touched directly. Then I slightly modified the size_alloc function by saving the computed GtkAllocations and removing direct calls of gtk_widget_size_allocate. I modified add and remove so I can start the animation at the right time. I also added a function called my_vbox_pack_start_n which inserts a widget at a given position so one is able to preserve the original packaging order. You trigger the animation by simply adding or removing widgets to the vertical box as usual.
 

You find to code here: http://github.com/troja84/af/tree/master/

• tests/myvbox_a.h

• tests/myvbox_a.c

• tests/test-vbox-animated.c

Let me talk about some points in regard to the main topic.
 

Implementation

In the example I derived my animated version of GtkVBox from the original one. The advantage is that the animation code is well separated so when an application developer wants an animated widget she has to explicitly select that version. On the other hand you increase the amount of redundant code because you have to slightly modify some functions in order to implement animations. The question is if an additional gtkvbox_animation.[h|c] would be more suitable in case of maintainability. Personally, I like the current implementation very much and I would prefer to add the slight modifications to the original class because these are not so harmful.

May you have noticed the problems when the widgets overlaped each other. At the moment I don’t know how to influence the, let’s call it z-position (the code draws the animated widget first but as you can see this doesn’t help…). That is why I’ve implemented the second animation which is more Gtk+ like (in the way that the widgets do not overlap each other while the animation is running) but this doesn’t work well with widgets which have a minimum size like the buttons in the example.

A further issue is artistic freedom. Should we provide standard animations or do we have to provide an API which enables artists to modify the animations in a significant way? The current implementation is following the first approach. I’m not sure if other widget toolkits or OSs offer more freedom so references are very welcome.

 

Infrastructure

Animations are not suitable at any place at any time be it by computing power, battery power or personal taste. That is why a discussion about the infrastructure is important. Furthermore, this is something which also affects the discussion about animation in themes.

Infrastructure in this case means an API which offers functions to influence the state of animation on the system level in a way that is transparent for the application and application developer. At least one should be able to turn animations on/off. There is already a property called gtk-enable-animations in GtkSettings which might be useful for the beginning.

 

That’s it for now. Remarks are very welcome!

 

Cheers!!!

Some moving pictures are not enough

There has been at least one comment who stated that only sliding pictures around is not so exciting. Indeed, it isn’t when we want to talk about animation in GTK+ and don’t want to miss the point which is that GTK+ handles widgets and not images!

So I started to create a second application which does nearly the same like the picture slider but with mature GTK+ widgets (at least for the widgets I used ).

I’m sorry for the bad text quality! Google video applies some aggressive algorithm on my videos… .

Anyway, have fun!

Repository: http://github.com/troja84/af/tree/master

A new proposal for GTK+ theming

Today I started my work on a new GTK+ theme engine. The main idea is to use SVG to attract designers who actually are not interested in hacking their own theme engine. The main advantages of SVG are the standardized format and foremost the availability of sophisticated graphics tools. Unlike the current way designers should be enabled to design entire widgets, e.g. buttons, textboxes, slides. Because this way would brake a lot of applications the designer has to provide themes for the old primitives (e.g. box, shadow, hline, vline), too.

For that purpose I’m going to provide a high level primitive via the RcStyleClass which can be used to draw an entire widget. On the other side the old capabilities stay untouched and can be used as expected.

At the moment I’m working on the basis that every GTK+ theme engine has to provide. I hope to get thinks done in about a week as I still have to learn a lot.