Developing GNOME is going to rock even more very soon!

When I started to getting involved with GNOME, I missed some features and got frustrated on how many details I needed to know to solve simple problems. However, the magic of opensource makes every problem a matter of time.

It seems that Gtk 2.12 is going to include the GtkBuilder API that Johan has been developing for a while, this is going to allow to abtract a lot of details, it not only replace libglade and UIManager, but also, it will be possible to define treeview columns and even populate data on it from a ui designer, such designer doesn't exist yet, this ui is yet to be created, but again, time will fix this.

Alexander Larsson is working on GVFS, a new API for accessing files and perform IO operations, that whips gnome-vfs' ass in terms of simplicity and portability. Kudos to Alex for this work.

On the other hand I realized today via FootNotes, that Anjuta 2.2, the first stable release of the 2.x series has been released, congratulations to the developers. I hope they can include it for the development suite for 2.22, this is a must have.

We have the wider and best maintained set of bindings for a graphical toolkit, just take a look at the development activity in PyGTK, ruby-gnome, java-gnome, gtkmm.. (the list goes on). This is a core asset of the GNOME platform since it encourage our so beloved freedom of choice. C haters, you have no excuse to become a GNOME developer :-)

GNOME is getting simpler, easier to develop and more usable every day, and we are not even braking backwards compatibility! Kudos to all the GNOME community.

The personal side

Work keeps me busy enough to being unable to accomplish the promise I made myself to release a Gtk+ msi installer before GUADEC. Hope is not lost yet, but I still need to focus on other things yet.

Working on Sun is being great so far, at last I have the opportunity to learn some things that I've been delaying for too long. Some of them funny, others  just mandatory, but I'm enjoying my time here as I've never did in the past, I couldn't have thought in any better first full-time job in my life.

Comments

[will_in_wi]

What frustrates me about gnome is the lousy gobject system. I think Gtk3 should be all about porting to C++ and gaining true OO. My other problem with it is the tendency to have incomplete or outdated documentation. I am a programmer on the side and when I write a program I want to be able to write the program, not try and figure out quirky infrastructure. I have been trying to replicate the speed of development of VB.net in a free environment. Example, I was doing math homework and got frustrated with having to re-solve the quadratic formula for each of my problems. So I opened vb.net and wrote a program that allowed you to enter a, b, and c and it would spit out the values of x. This program took me 3 minutes to write and debug. I added a form added three textboxes, a label, and a command button, and double clicked on the command button. There were only three lines of code involved. In Gtk/C it would have takem me much longer, to the point of taking me longer to code and debug then it would have to just do the problems manually. I later rewrote the program in Qt/Ruby. It did not take me long at all and could have been sped up even more with a good ide (I wrote it in nano). This was in large part due to the incredible documentation Qt has. I was able to work with the Qt4 Canvas stuff easily from their docs, while I have never been able to figure out cairo (where are the docs and tutorials for rcairo?). Gtk was originally written in response to a non-free Qt. Qt is now GPL. Even on windows and mac on which platforms it looks and behaves vastly better then Gtk. The only remaining problem I see to adopting Qt for Gnome is the perception of not having as many language bindings. And this is no longer really true. Off the top of my head Qt supports ruby, python, php, cobal, C++ (duh), C#, and javascript. This is in large part due to the smoke bindings. This library autogenerates the other language bindings making the amount of work required to use them minimal. I really don't see a problem with having two desktops, but I think that our two main toolkits should be consolidated. The current has an immense duplication of effort. Gtk maintainers keep on mentioning new tasks and projects, but complain about lack of manpower. A recent example being rewriting the theming engine. It is somewhat silly to duplicate core infrastructure. This is what killed unix in the first place. Life as been much better since printing was consolidated with cups. I get frustrated when I look at the incredible efforts of the Anjunta team and then look at Kdevelop which has already done all that.

I am attempting to keep a non-troll discussion here. I just think that we are replicating a lot of stuff that shouldn't be replicated by having two toolkits. And hurting the user and developer experience in the process.

[Emmanuele]

you forgot the perl/gtk bindings, which have been part of the bindings suite for long, and are probably the most thoroughly tested bindings in the suite. ;-P

[Alberto Ruiz]

@will_in_wi:

First, thank you for your comment! :)

Porting Gtk+ to C++ is a non sense. There are very strong reasons to keep Gtk+ in C.

The first one is there is already a great opensource C++ toolkit, Qt, so C++ lovers already have that.

The second one is portability. Not only among platforms, but among compilers. That's why Gtk+ is so interesting for mobile computing, lots of vendors has their own optimized C compilers for their hardware, and maintaining ports of Gtk+ is way far easier.

And the third one, keeping the core in C, allow us to have better binding suites, more maintainable and more flexible, as an example, PyGTK feels way much pythonic than PyQT. You can also check the number of Python/QT or Ruby/QT releases and community compare them to their equivalents in Gtk+ as a proof of this.

The OO thing is a common complaint about people. However, then you say that you used RubyQT to compare it to Gtk+/C, that's not fair comparaison.

C is for the core of the platform, not for applications, you can use Python, in the Python way, to develop Gtk+ applications, and you wouldn't never realize that there is a C api below that.

However, if Qt fits better your needs, that's the beauty of opensource, diversity allows this kind of things. Making Gtk+ more Qt like would be killing the project itself, because people choose it because its difference. For the other needs, there's always another rocking toolkit out there :)

[Janne]

You're comparing a C api and a C++ api; of course they're different, and of course C is a mess by comparison. Why did you use the C api to begin with, as GTK and Gnome has API bindings for C++, ruby, python and so on?

You write a small application in GTK/python or GTK/C++ in no more complicated code than you do in Qt. As far as features and ease of use, Qt and GTK are pretty much in feature parity (I've used both quite a bit), and in the areas where they still differ in ability - the accessibility issues in Qt for example - they are gradually converging.

[Alberto Ruiz]

@Emmanuele:

Sorry for that, I've also forgot to mention the haskell and the php ones too... and the clipper ones... and the Ada ones...

[Marco]

QTDesigner has the ability to populate treeview afair.

[Alberto Ruiz]

@Marco:

There are a lot of developer toolkits and tools that have that kind of features years ago. Borland and MS developer tools for example.

That's why I'm excited to have this on Gtk+ after waiting for it all this time.

Qt is a great toolkit, but I love the GNOME project and the GNOME community, so I will keep using their platform and pushing for improvements on it :)

[Marco]

Sorry I misunderstood you
I think you say that there isn't any feature like it in other designers sorry :P

[Juan Colino]

I bet java its one of the mandatory things...
I <3 Python
fu*k Java!
=)

[Alberto Ruiz]

@Juan:

More or less ;-) But I don't like to say fuck Java, since it's a good tool for a lot of purposes.

[will_in_wi]

Is there any way to get gtk and qt apps to use the same theming and dialogs? Or is there a compatibility library that would allow you to compile for example rhythmbox against qt so it would blend. I don't care tremendously about having both gtk and qt, I just dislike seeing ubuntu write an app and then the interface is ported to qt. I think that if I like qt or gtk better I should be able to program in whichever one I want and just have it look and behave right in either gnome or kde.

[Alberto Ruiz]

will_in_wi:

Yes there is.
http://gentoo-wiki.com/HOWTO_Same_look_for_QT,_GTK_2_and_GTK_1_apps
and
http://www.metatheme.org/

Next time you might want to express your real worries first :-)

[will_in_wi]

Those help, but it still doesn't fix the underlying problem. Dialogs are still not common, Icons are still not common, basic design decisions (HIG) are not similar, VFS is a mess.

I think you get the idea. I want to be able to write a Qt app and have it work seamlessly in Gnome, or write a Gtk app and have it work seamlessly in KDE. This includes if I have a gnome-vfs mount of a samba music share, it should show up and be accessible in both Qt and Gtk apps.

[Alberto Ruiz]

@will_in_wi:

join to the freedesktop.org community to help both KDE and GNOME communities to find this common ground.

Both are working together to blur those lines, but lots of work needs to be done yet.

Still, everytime I give you an answer of your complaints, you came up with another new one. :)

[will_in_wi]

Thanks for all of the answers!

Sorry to seem to be complaining. I love using Linux and all of the stuff that comes with. The Gnome and KDE devs are incredible and are really refining the idea of a UI.

I just have had a lot of trouble developing for Linux. Now, my first programming language was VB6, so I never learned pointers and the C stuff that is so important. This is probably one of my problems. I also loved MSs extensive documentation. I will have to just start trying to do some more contributing on the dev front.

Thanks again!!!