I'm going to start work on a new program, and I'm just wondering, should I use gtk+-2.0 or gtk+-3.0? I've worked with gtk2 before, but 3 is pretty much the same, only better ( so it seems to be to me, with things like running applications talking to each other ).

Here's what I think:

• gtk2 would be unmaintained (soon).
• but users would probably have gtk2 already installed (and maybe not 3)
• however gtk3 would have newer features
• still, gtk2 and gtk3 can be installed side by side, so even if a user doesn't have 3, they can install it easily without any issues

So, what do you think? In my opinion, gtk3 is the way to go. I'd like to hear some comments, though. What do you use?

I use native C, if that's relevant. I'd use Vala, but I'm going to use other C libraries too, so it's best to keep it simple, right?

Simple is (almost) always better, methinks.

You're right that most of the world is GTK+2 rather than 3 (today, anyway), and it might be better to go for 2... with embedded 3 while you're at it? An #ifdef or two might not be a bad idea.

There's a GNOME paper worth a look-see at http://developer.gnome.org/gtk3/3.5/...ng-2-to-3.html. Might find that useful.

Hope this helps some.

1 members found this post helpful.

I've read it, actually, and I think most changes in gtk3 are very welcome additions. I do really want to use gtk3, but the thing is that most people including me have gtk2 installed as the default toolkit, meaning that gtk2 applications will use themes and icons as per their default set up, and will blend in perfectly.

While I was initially leaning towards gtk3 at first, I think you're right: simple is the way to go. People still have (atleast easy access to) gtk1, so I think gtk2 will still stick around for quite a while.

I think the best thing to do is to keep the UI code separate from the core application and if a time comes when I have to switch from gtk2 to gtk3 (or something else entirely, maybe), it'll just be easier to do.

Well, this would be the way to go in every non-trivial application

Yep, I agree. Initially, when I started coding, my aim was to get it to compile, using the shortest route possible. My first program was a hack of the GtkIconView tutorial into a file manager. Initially I just wanted to make it work, and so it turned out that everything was #included in main.c and a global GtkWindow* was used everywhere. But when it grew (e.g a xine media player was embedded, it had its own device management system) it became simply unmanageable. Ultimately it got to the point where the code was 13000+ lines all compiled at the same time, so that every time I changed it even a tiniest bit, it took over a minute to compile. Then I found out that to open a second window, a whole new instance had to be run. Then I decided that the thing had to be completely rewritten, which I tried to do for a while but then just gave up.

Now, for one, I've learnt the importance of system design. For example, this project would have a plugin architecture, so I'm going to try to keep the public and private api separate, keep the application core as generic as possible and let the individual modules do the rest. Plus, since most open source libraries are now cross platform, I'll try to keep the code cross compilable as well. I'm thinking that maybe I should write the basic structure of the program first, and then put it on sourceforge. Hopefully I will find some more help there.