I have seen the truth and it doesn't make sense
There are here on Igalia a lot of people working on Vagalume, a last.fm client started by Berto, another Igalian.
So, I realize that one missing feature (not a real priority) was the i18n support. So I start to add this, and today, I have finished the support, as you can read on the vagalume developer lists.
I didn’t made a full translation, only the support (I let the translation for the translators 😉 ) , but you can get something like that:
This weekend I was present at the FOSDEM 2008.
This is my first “normal day” here at home, as we take advantage of the Monday to visit Bruges
There was several talks, about several themes, Gnome, KDE, Crossdesktop, etc. Some of them interesting other less. Some of the interesting ones:
These past weeks I have spent some time taking a look to GAIL, the Gnome Accessibility Implementation Library, taking a look at the gnome accessibility guides, and to an interesting framework related to that, dogtail ( it will be cool to make GUI testing for fisterra, eh? :P).
I took a litle to the code and play a little with it. One of the things you can see is that almost all the interfaces are private (the headers are not installed with the library). So if you make a custom subclass of any gtk widget you haven’t got access to his accessibility object to extent. But you don’t don’t have to reinvent the wheel, as there are a way to workaround it, as you can do an anonymous (run-time) inheritance from GAIL.
Ok, so, no problem no? Well, I don’t think so (IMHO). With this solution you can obtain the parent type, and extend it using g_type_register_static. But, what happens if you have an abstract class, with any virtual abstract functions? In theory, the concrete subclasess requires to implement this functions. But how can do that if you haven’t got the parent definition (on the header)?
You can think: but it is unlikely to happen. Well, this is not very common, but it happens: GailRendererCell define two virtual elements: property_list and update_cache. This add the accessibility for GtkCellRenderer. This has some subclasses, that defines it: GailTextCell, GailBooleanCell and GailImageCell.
IMHO it is really common to make a GtkCellRenderer subclass, as you could want a custom cell rendering. So, what happens if you want to create a custom library with widgets (or something similar), and some try to extent it? How do you redefine this virtual elements?
You could do some hacks, like use directy the gail source to access to the libraries (it is free software, you know? 😉 ), or create a custom header with the structures you require to redefine it. But this last is a really dirty hack, in fact, a copy&&paste hack, with all problems of sync, and others related with the anti-pattern copy and paste.
Conclusion: in my opinion, the gail interfaces, or at least some of them, should be exposed
Well, I have found other “particularities” on gail code, but this can be exposed on the next post
The other day, looking at planet Gnome, I found one more interesting that the others. This was writen by MDK, and its titled Vector drawing: OpenGL shaders and cairo.
This post continues, in some way, a post written by Tim Janick on his blog, about OpenGL for Gdk/Gtk+, that summarizes some of problems about using OpenGL with Gdk/Gtk+.
MDK made some tests to compare one an another, I had a little curiosity and check the code. The shader version was written in Cg, and as there are a lot of time that I doesn’t write nothing related to shaders, I decided to waste the little free time I have making the GLSL version of this test this afternoon.
I same the sames tests, except by environment:
And the visual results:
But the most curious was about the times (sorry, not chart this time);
GLSL better than cg? I suppose that this is the easy answer but:
Conclusion: it is good to revive some time GLSL, I need to do this more often, thanks to MDK to give us some code to play !
At the end, the Guadec 2007 has finished.
This is my first “normal day” here at home, as we spent all Sunday trying to return from Birmingham to Coruña. This was a little more difficult than expected, including a two-step landing on Coruña (seems that the “typical english weather” that we see these day on Birmingham reach to Coruña).
After this I can see one phrase: I’m tired. Guadec ES + Guadec sums 12 days flying, living in a hotel, wake up early in the morning, etc. Although I’m sure that people from South America like Germán or Claudio must be very very tired.
On the Guadec I see a lot of interesting things, a random group of this can be:
I have been these last days on the Guadec-ES at Granada. The city was great (although it was really hot).
The thursday we visit the Alhambra, that, although it didn’t get to be one of the “new seven wonders of the world” it is really great. At the guadec dinner this night, the organization take us to a restaurant on the mount where we see the whole Alhambra. This was great (I’m sorry, I have no photos).
The friday I had a talk, shared with Juanjo. Here we made a presentation about the Gnome Build Brigade. Iago Toral will have another one, more complete, on the Guadec 2007.
Another Igalians had presentations too, Juan and Xabier about Webkit and Epiphany, Juanjo and JavierF about TinyMail and a really interesting talk about ringschart made by Alex.
But, as the song says, “all have his end“, and as we need something to waste our time, after Guadec-es we travel to Birminghan to assist to the Guadec (in a flight with more than a hour of delay, strange no?).
Today was the first Guadec day, with some interesting talks, how “Latest evolutions in Hildon Desktop”, by Luis Rocha.
To be continued ….
Recently I have joined with Iago to make efforts on the work of the build brigade development, the continuous integration system for gnome.
The first task was install an work enviroment on my local machine, using the work of Iago and Dape on use the buildbot integration system on jhbuild, the tool to compile gnome modules.
At first I use the buildbot from cvs, but then I switch with the 0.7.5 version, as is the one the build brigade production page is using. But this work let me enter on the buildbot code, to make the neccesary changes to work with it, and start to see how is the python code, as I have no previous experience with it.
But python is an dynamic object-oriented programming language very intuitive, so I understand almost all.
Then, I started with a real useful task. The idea is add RSS support to this buildbot. To do that I start first using the Dape changes on buildbot to add feeds to the failed builds, but then I start to use the Lieven Govaerts work (based on Dape’s works). The advantage of Lieven work is that this adds new classes, creating a new file with this new classes, without modifying the buildbot code. This is more “clean” as we don’t need to add patches to the buildbot, or wait to apply these, and makes it easier to keep in sync with buildbot releases.
One of the buildbot advantages is that is really easy extend it. So view this more easily this is an summary class diagram:
On the diagram the white classes are the original buildbot classes, gray classes came from Twisted module, red classes are the ones which adds Lieven Govaerts and the green one is that we define in our custom buidbot.tac.
Well, one you reach this, review the code etc., you can think, “well nothing more to do!”. But we have a weird problem. This feeds takes the failed log builds and create a rss/atom element. In this case the build log are the jhbuild logs. And we have a problem with this. At first the rss failed, getting a crash on this line:
*** error during stage configure of cairo: ########## Error running ./configure –prefix /home/gnomeslave/devel/gnome/work/prefix –disable-static –disable-gtk-doc –enable-coverage *** [1/1]
So we go to the log, and we see some strange symbols on this line (and realize that the line appear two times):
*** Configuring cairo *** [1/1]
jhbuild: Configuring cairo [1/1]
Looking after this I have found the problem. jhbuild show his log in a pretty print way, showing some phases in bold and add the title to the current terminal. To do that it adds some special symbols. In the case of the bold, it uses “tput bold” to get the special symbol (as it can be different on each terminal). To the title it checks if it is and xtem or rxvt, and uses the special symbols 33] 07. But in our case we don’t need this, we only want the log as a plain text, as this will be used to be showed on the web browser. The log with strange symbols on the web page is only a annoying problem, but the crash on the rss feed is a real problem.
So I started to work on the jhbuild code, as the first idea was avoid to print this ones from the jhbuild. jhbuild has a configuration parameter called “pretty_print”, used to allow to print the output on the terminal in a enhanced visual way (colors, etc.) So my initial idea was include the bold and the title in the “pretty print concept”.
But this has a problem. It is easy to do, but I need to create a patch, add a bug on jhbuild bugzilla page, and wait this to be applied. Meanwhile, to use it we’ll be using and “custom jhbuild” and everyone who wants to install the jhbuild-buildbot scripts, need to take it into account, applying this patch. And, in my personal opinion, I don’t think that a patch that is only a enhancement required for an concrete project could be a high priority task for jhbuild guys. If I were an jhbuild maintainer I will ignore this patch for a long time 😉
At first I realize that the title is only set when an xterm is detected. So I tried to change the environment variable TERM to another terminal (vt100) and this works. Using this idea, I start to search a terminal with no bold support. Reading a little the terminfo manpage, and another related, I used the adm3, and this works!! 😛
So, to solve this problem, instead of modify the jhbuild code, you only need to modify it on your slave .bashrc file:
export TERM=adm3
Simple, no?
Well, this work is done, I hope that this will be released soon on the buildbrigade production page, enjoy it! 🙂
PS: on the lines which appears the strange symbols, I have removed this ones. This is because the planet.igalia.com feed started when I added this 😉
I’m currently working on Igalia in order to get Fisterra better.
My firsts tasks was about obtain a good debian package for Fisterra, and then add documentation to the page. A good amount of developer manuals, installation manuals, and examples are important to understand a huge project, and Fisterra is a really huge one. This is important too to get a good comunity of people working on it (we are searching help, join us! 🙂 )
But recently, in a conversation with Alex, another Igalo, introduce me one technology: Internet Communications Engine, or sortly, Ice. Ice pretends to be a middleware similar to CORBA or COM. This was developed by ZeroC, a company founded by experienced CORBA developers. The idea is get a better middleware than CORBA. As ZeroC says, “we neither wish to start a “CORBA vs. Ice” flame war nor do we want to discredit CORBA. On the contrary, we believe that CORBA was a great achievement for its time, and obviously Ice borrows many good ideas from CORBA”. They only want to go to the next step.
I see the page and the features only a bit, but this looks great! And this was implemented by them himself, are complete, and are free (libre), using a GPL license.
Fisterra initially uses CORBA as the middleware for his communication layer, using the ORBit implementation. Then, adds support to SOAP, due some needs in a concrete project. And, what about uses Ice in Fisterra? This is a very interesting technology, and Fisterra was designed in a way that the comunication layer could be replace (this is a hard work, but not an IMPOSIBLE work), although the first task should be “it worth the effort?”. The next could be “we can use the three simultaneously?”.
This task could be called “Freeze Fisterra” … a good name 😉
Meanwhile some igalians (*) was making a very useful view of the baobab, I was spending my time creating a 3D of this widget. To do that I used the great library gtkglext , which allows to add OpenGL drawing to any widget gtk.
While the base 2D view are very intuitive, and allow you a visual track to your directorioes, with tooltips, etc, my 3D view is a very beatiful 🙂 view of a widget, but it is almost useless, as is hard to manage and select the directories. But, as I’d said, this look greats, and its funny create this, although I became a leech of the igalians laptops. For example, the Mario’s one, forcing him to work in this widget, when I kidnapped his laptop … 😉
At the end of the post you can see a screenshoot of an alpha release of this widget. The next step is create the blocks more consistently, as at this moment has some visual “leaks”, and integrate with the original base.
This is a headache problem, as to avoid to add a new dependence with the baobab, I was working in a “parallel experimental” branch. “One day” its possible a total integration, but for this moment, we have two work groups.
