Submitted by Ars Technica has an article about recent proposals to evolve the GTK+ toolkit: “The developers of GTK are preparing for a major overhaul that aims to resolve many of the framework’s most significant deficiencies and add next-generation features that will increase flexibility and simplify development. This effort is still in the earliest planning stage, but several intriguing proposals provide valuable insight into some of the changes envisioned by prominent developers.”
I would like to see GTK+ as a serious competitor to QT4, not only as a graphical toolkit, but as a complete toolkit including XML, Database, Networking, OpenGL, WebKit, etc. I also think it should have better theming possibilities like QT4s CSS styling.
I am completly aware that GTK+ got some of this functionality through other projects (like libxml), but I feel it should be more tightly integrated with eachother utilizing the glib mainloop system and have a uniform API style throughout the different modules.
Btw, I am not sure about this so I ask anyway: does GTK+ have any widget like the QT4 dock widget? If not, I think they should include that as well.
Edited 2008-04-10 13:51 UTC
I don’t think that would be a good idea. It would probably result in bloat and a lof of maintenance effort that could be avoided.
Keep it simple.
Perhaps that is why many are drawn towards Mono since that is basically GTK+ with loads of extra stuff like networking, xml, etc…
No, Mono is a completely different beast that happens to be able to use GTK.
Yes. Plus, I would dispute that “many are drawn to Mono”. It is my impression that a few very vocal people are drawn to Mono. Which is a very different statement.
F-spot, Tomboy, Beagle. Am I missing anything significant? Judging from my Fedora 9 beta installation, I don’t think so. And it does not come with Beagle.
Probably more OSS devs are “drawn to” Java. But I don’t think that is a particularly large group, either.
F-spot, Tomboy, Beagle. Am I missing anything significant? Judging from my Fedora 9 beta installation, I don’t think so. And it does not come with Beagle.
What about MonoDevelop and Banshee?
What about them? Are they included in a default intall by some distro? OpenSuse, maybe? Five apps != “many people are drawn to Mono”. (And should MonoDevelop really count as an app?)
From current rawhide:
$ yum list | grep -i perl | wc -l
920
$ yum list | grep -i python | wc -l
332
$ yum list | grep -i java | wc -l
238
$ yum list | grep -i ruby | wc -l
113
$ yum list | grep -i mono | wc -l
43
Edited 2008-04-11 00:21 UTC
Yum list and grep can only find packages have a particular word in them. As you can see a lot of packages have perl in their name because of CPAN naming conventions and Fedora packaging guidelines on perl.
What works much better to actually find which ones are dependent on a particular programming language is to use repoquery that is part of yum-utils package. As a example,
# repoquery –whatrequires python | wc -l
134
Thanks. I was unaware of repoquery but had been looking for something like it.
What about them? Are they included in a default intall by some distro? OpenSuse, maybe? Five apps != “many people are drawn to Mono”. (And should MonoDevelop really count as an app?)
You asked if you missed anything significant. MonoDevelop is certainly significant considering it is arguably the best IDE for Linux. Banshee is also a very good application. All of the Mono applications listed are very polished and were developed much faster than equivalent applications developed in C. Look how long Anjuta has been developed, then compare it to MonoDevelop. This is the real advantage of Mono.
I don’t really know why you wouldn’t consider MonoDevelop an application. It’s an IDE and a very good one at that as I mentioned previously. As for default installs, who cares. I run all of them on Gentoo and they all seem to be best of breed for what they do. I think that says something.
I think you missed the point.
When you install Gnome, or any Gnome or GTK application at all, you bring in a veritable panoply of dependencies that sometimes defies belief. What’s worse is that each application might depend on a slightly different version of each package (binary compatibility only gets you so far – it’s expected behaviour that really counts). Each application might then depend on its own version of libegg or something similar.
Application developers should never be put into a situation where they are depending on GTK, Cairo, libXML and all the others directly. With Mono, what you have is a framework that is universal, consistent and learnable for developers, and where they’re not depending on low-level components directly.
Vala is more like what you are talking about. Vala is specifically GObject based, but C# like in syntax.
An updated GTK will be good for the developer community. I’ll evaluate it again when that happens.
It shows that the GTK devs are much more pragmatic than the users (isn’t that always the case?). Sometimes advances require big breaks. Not everything is achievable with incremental updates. If you incrementally update forever, you end up stuck with millions of lines of compatibility code and cruft that must be maintained in perpetuity.
That situation might be manageable for microsoft, which can throw billions at the problem, but for open source or smaller companies it’s not an option. The code base needs to remain well designed, with as few hacks as possible. Developers are limited and a lot of them do it for fun, so if the framework is no longer fun, you’re going to lose developers.
It shows that the GTK devs are much more pragmatic than the users (isn’t that always the case?). Sometimes advances require big breaks. Not everything is achievable with incremental updates. If you incrementally update forever, you end up stuck with millions of lines of compatibility code and cruft that must be maintained in perpetuity.
That’s why I like Imendio’s suggestion to break API/ABI compatibility every 5 years (or whatever GTK devs decide) to allow removing any code which has become redundant and to allow for refreshing the code a little. And if it is done always done in a controlled manner on a regular basis it will allow developers to anticipate the breakage too and prepare for any possible changes.
GTK does indeed require some work to be done to allow new interesting stuff to be implemented and as many GTK devs have stated it does seem more and more so that an API/ABI breakage is the way forward.
Well from the plan described elsewhere, anything coded for version 2.999999 of Gtk+ that follows certain guidelines should be source level compatible with Gtk+ 3.0. This should allow a smoother migration path than either Gtk+ 1.0 to Gtk+ 2.0 or Qt 3.0 to Qt 4.0.
From memory, the guidelines would include:
* not using libraries that have been obsoleted and instead use the “new and improved” widgets (e.g. GIO instead of GNOMEVFS)
* instead of coding GObject in raw C, write an IDL file that generates the GObject (this will allow GObjects to be dramatically rearranged without breaking things)
The “don’t break conforming Gtk+ 2.9999” code plan acctually seems doable, albeit, the Gtk+ 2.9999
release may have a few duplicate functions
(e.g. if we need to add another parameter in Gtk+ 3.0, we may have two versions of the same function/method, one with the parameter which gets ignored and the other without)
I suggest that GTK create a standard set of media controls such as knobs, sliders, and some type of VU meter. That way multimedia applications can have some standardization. While these controls could be handy, and as a standard, they could be groundbreaking, they probably won’t get made because they are not needed in the GIMP. Perhaps GTK+ will never have any functionality other than what is needed to create a 2D bitmap program.
Dude, GIMP has been a second-class citizen in GTK+ development for a long while. GNOME is the primary consumer of GTK+ and GNOME’s needs have a far greater weight to GTK+ than the GIMP does.
The real reason controls like that aren’t in GTK+ is because in general only 1 or 2 apps are going to actually need it, and thus they make more sense in an add-on library than the core toolkit.
You are wrong.
Nice comeback, any links to back that up or a less blanket statement to backup what I’m guessing is just your opinion? I’m not saying the guy you are responding to is right. But just saying “You’re wrong” and then leaving it at that kind of defeats the purpose of a DISCUSSION board.
I hate to break it to you Brenda, but your original claim that GTK development is still driven by GIMP is so seriously misinformed that, at first , I thought you were joking.
A long, long time ago, back in 1997, GTK was written to facilitate the GIMP. And briefly, what you claim was probably true. But by late 1997, Gnome had already eclipsed Gimp as the prime mover for GTK development. It’s probably time to rename it to “Gnome Tool Kit” to avoid any confusion.
I personally think that it should be called the “General Tool Kit.” This would reflect the fact that it and the technologies based on it are used by many projects outside of just GNOME, such as Xfce and Firefox. I feel like they need a company or non-profit to help monetize the development of GTK better. This would be similar to the relationship between Trolltech and Qt. I would go the non-profit route and try and establish a relationship with the major GTK usage companies such as Red Hat and Novell to help finance its development. I work in the non-profit sector though so I may just be biased.
Also, I am not a programmer but what would seem to be important to me from what little I understand it for future proofing would be easy portability in its build process, making GTK easily maintained across all major platforms, emphasizing applications be developed with screen resolution independence in mind (please I want my high resolution screens and software
, and ensuring processes and governance that keeps developers interested. Perhaps if they do implement a plan of major API/ABI breakage every 5/6 years then they could open up a GTK 4.0 concept/experimental code branch after say GTK 3.2 is completed in order to maximize developer interest. It’s just some ideas and you are more than welcome to shoot it full of holes.
How about an even simpilar reason – those who want those control’s shouldn’t simply just sit around expecting it to be done for them. GTK is a community based project, if one wishes for that particular feature then one should make a project proposal and write the necessary code. Sitting around demanding others do it for them is a pretty pathetic way of doing things.
Take Evolution, for example; it used to rely on a huge laundry list of widgets, they have now been merged with GTK. Same can occur with these media controls; now sure, there will be applications in future that will need those widgets, and for the sake of uniformity across the platform, it would be nice for there to be a standardised set – but to complain without doing anything is just plain stupid.
GTK has sliders… obviously, almost every GTK App uses them including GIMP.
I only know two Toolkits that have knobs and knobs are generally not a metaphor that works well with a non tactile 2d screen, so those are hardly used even in music apps.
I don’t know any GUI Toolkit that comes with a VU meter Widget. You are either clueless about programming or the laziest Programmer ever if you expect one. And why would an Toolkit ever include one. If you want to make an media player you will likely want to create one yourself that suits your very specific needs.
You know, there is also no “Doom 3 level editor Widget” existing. Programming isn’t about leaving all work to the Toolkit guys.
Just imagine what this will do for the Gimp and Gnome. Funny, how the GTK was made for the Gimp, but became the toolkit for a lot of other projects also.
I lot of the stuff that is proposed is exactly what GTK needs. Sure it may take a long time, but the pay off will be huge.
This will greatly help me in my project.
I’m the author of florence (an on-screen keyboard for disabled people):
http://florence.sourceforge.net
I have to use libgnomecanvas so the user can see the progress of the timer for auto-click.
No need to say dealing with libgnomecanvas is a pain and it’s not portable. If gtk could handle that kind of stuff, it would make my life so much easier.
Nice app! I will take a better look at it in the next couple of days.
I was wondering — can’t you use cairo for drawing?
Perhaps.
libgnomecanvas gives me some limited event handling though (mouse enters, mouse leaves and mouse clicks). This would be better with real gtk widgets.
I will investigate if I can use cairo, thanks for the advice.
For basic things such as handling events and good-quality 2d drawing, GtkDrawingArea and cairo is the perfect combination. You don’t have to write a new widget, just use GtkDrawingArea and connect to the GDK events for mouse control etc, use the expose handler with cairo to draw.
Thanks for the info. What I need is a canvas library that keeps track of what is drawn.
I’ll investigate goocanvas which uses cairo.
I don’t know if cairo is better or worse than libart and if libgnomecanvas is better or worse than goocanvas, but I’ll investigate. It looks like gcompris is moving avay from libgnomecanvas to goocanvas, so there must be good reasons to do this.
I hope you don’t mind me asking you, but have you tried Qt/KDE? It’s certainly much more fit for your use and would save you a lot of time and effort…
The problem is that it pulls down too much dependancies. You have to install all the kdelibs to use QT. And KDE doesn”t support at-spi yet. I’ve heard they’re going to support at-spi when it has moved to dbus. I’ll consider KDE when it’s done. I know there are alternatives to at-spi but it’s a lot of work to support every single assistive technology. I better wait for KDE to support at-spi. GNOME is ready and most other DE or WM do use gtk.
I might be mis-understanding you, but – Qt needs KDElibs?!? It sure is the other way around, but Qt certainly doesn’t need KDE libs. It’s an independent toolkit.
Secondly, Qt has supported at-spi for years already: http://doc.trolltech.com/4.0/qt4-accessibility.html
Third, Qt already supports D-Bus (has done so for years) and so do the stable KDElibs (the fact that some parts of the desktop applications aren’t stable doesn’t mean the libraries aren’t – KDElibs was released over 6 months ago with the guarantee to stay binary compatible until the next major KDE release which won’t be in the next 4 or 5 years – we’d sooner see a GTK 3.0 release).
So if it’s the KDElibs dependency or lack of at-spi stuff keeping you of off Qt, think about it again. As I said, it sure will save you lots and lots of efforts as it’s much more complete, documented and efficient to program with than any other toolkit ‘out there’. And fully GPL 2 or 3.
Thanks for the informations.
There is indeed accessibility support in QT, but it’s not at-spi though.
Well, the trolltech documentation specifically mentions it:
“Qt 3 already supports Microsoft Active Accessibility (MSAA) and Mac OS X Accessibility. Qt 4 closes the gap in Trolltech’s accessibility offering by introducing support for AT-SPI on Unix/X11 systems.”
http://doc.trolltech.com/4.0/qt4-accessibility.html
You have convinced me. QT4 seems to be the answer to my problems. I will most probably move my project to QT4. It looks like it has everything I need.
LOL, well, I didn’t want to convince you, but it seemed the info you and I had wasn’t congruent so I tried to rectify that. It could just as easily have been me who has learned something…
Anyway, I would like to ask you something. I’m often a speaker at conferences, but I’m no developer. So when people ask me about the relative merits of Qt and GTK, I can only tell them what I’ve heard from others. And as I’m mostly around KDE hackers, that information is biased. It seems you are rather openminded and unbiased, and you’ll soon have experience with both GTK and Qt, and writing a rather complex application. Would you be willing to give me your opinion on the two toolkits? You can contact me at jospoortvliet on the lovely gmail DOTcom servers 😉
I would really appreciate it, but of course feel free to ignore my request 😉
But do they have the manpower to implement them? It’s well known that GTK+ has suffered from a shortage of developers / maintainers in recent times. GTK+ needs fertility treatment, otherwise it will remain sterile. There’s no reason why a barren person couldn’t improve themselves, but there are limits. The future belongs to successive generations.
I hope that the scene graph stuff will be considered and implemented. Having technology on the level of WPF (and it’s upcoming native code variant in Windows 7) would be great. If they manage to get an usable version out before Windows 7 hits the market, even better.
Instead of adding animations and other crap, how about fixing the file selector so it doesn’t take so much space, has thumbnails and allows the user to rename, copy and paste files without opening a separate Nautilus window and navigating the folder hierarchy one more time?
And while we’re at it, make GTK+ use native file and print dialogs on Windows by default (without having to specifically code for this in the app), and fix the pane redraw bug that plagues for example Sylpheed.
All this doesn’t require huge rewrites, but will be appreciated by many users.
Edited 2008-04-10 20:45 UTC
This is a good move by the GTK devs.
It’s good that every so often, devs think about how a toolkit or application could be improved, starting with a “clean slate” (or close to it). Python is doing it with Python 3, and KDE have too.
– obsidian
I find this stuff interesting, but I wonder if it would be better to get the clutter team on-board since they seem to already have the experience with scene graphs and a robust toolkit. I know clutter isn’t made for anythign really complex that would be necessary for apps like gimp or DE’s like gnome and xfce, but some of the ideas and code can be used and the developers of that project if so inclined can be a huge help to a better m,ore modern gtk.
I say that its about time that gtk got out from under gnome’s skirt and step out on its own as its own project and let the gnome devs deal with the details of finally bringing gnome to the 21st century. i like the ideals behind gnome, but the system just feels old and in desperate need of updates.
Knowing how innovate the gnome project is I suggest that people review .net 3.5, the latest QT, the latest Java GUI librariese, and the latest Apple GUI work to see what will be in the next few versions of GTK.
Think I am incorrect? Then list 5 major innovations that GTK has made.
And so what?
Apple shamelessly uses open source project and it doesn’t provide any useful code back. Their MacOS X is almost UNIX. And don’t get me started with Microsoft and their ‘inovations’.
If they do things better, copy them, reap them, reverse engeneer the code if needed. I have no problem with that and if they have one, they had it coming.
You don’t think IBM should be the only company building PC computers do you? Or do you think the USSR should be the only entity launching satelites?
If GTK is a perfect copy of COCOA, it is still better because it is free (in all senses of the world). And if they steal ideas from several sources, it is even better. We just want the best, so let’s take the best.
Edited 2008-04-11 05:40 UTC
Webkit? GCC? To name but a few.
So much vitriol. What Open Source project is Apple “ripping” off now?
They use BSD.
Anyway, they provide some code for GCC or Webkit, big deal. Sun gives away a complete office suite, the full code of the most advanced kernel in function today, provides the code for java and numerous projects including at-spi and I can’t name everything. Red Hat gives everything they do. Novell provides Mono, compiz, and a ton of code.
And Apple provides some adjustment to webkit and GCC (And they are obligated by law to do so because GCC is GPL). Still, they use BSD and how many lines of codes provided to them for free, they modify it and lock it down to make sure nobody can modify the code or provide better apps for it than them. And they make multi-billion dollars profit from it.
I’m sorry, but as much as you like Apple, they give far less than what they take.
Anyway, I have no problem with that. They use BSD, fine. And I have no problem taking what can be taken from Apple and copying COCOA when I need to do so.
People are confortable with COCOA? Fine, let’s do that in GTK and make people confortable with FOSS.
Right, this will be the BSD core they inherited from NEXT Computer, the one NEXT licensed from the BSD bods before BSD was opened up like it is today? So, you want to penalize them for licensing code 20 years ago? And, that they’ve integrated FreeBSD code – how would returning the twaeks they used to get it to work with their kernel, NEXT inherited internals and IO Kit benefit FreeBSD? Most things make their way in to Darwin.
If you are talking about drivers – not relevant. They use a completely different Driver model.
If you mean WebKit (which they based on KDE HTML rendering technologies, but as an entity originated, at least in part, IIRC), a load of it is in Objective-C.. no use to anyone really, outside of MacOS X.
There isn’t a single OS in existence that was developed in the last 10 – 20 years and didn’t borrow or license code from elsewhere. Some even stomp all over the GPL on the sly (BeOS did internally for example.)
Besides, as stated ad infinum, OS X can do what ever it likes with BSD code – the BSD license allows for this. You may not like it, but the code licensing is up to the developers, not the wingers who sit on the fence bitching about everything and nothing all at once (OMG, am I breaking in to Green Day lyrics.. too much coffee..)
You get my drift?
Do whatever the hell OS X Cocoa APIs can do.
I get counted down for giving GTK a compliment. I’d love to see both toolkits interoperate and boy it would be nice to have a common bindings between GNUstep and GTK+.
Well look at it, it really doesn’t read like a compliment. At best, it’s just really unhelpful. Why do you think it makes sense to hold up the OS X APIs as the epitome of what GTK should aspire to? Why do you just assume that the needs of OS X developers and GTK developers overlap so completely?
Having read the article, I can say that the proposed plans make sense: listen to what GTK users are asking for, and give it to them, integrating and extending exisiting external solutions where appropriate. At no point is a desire for GNUstep integration expressed, so why are you suggesting that developers should use their precious time implementing something for which there is no major demand?
Bloody hell… I was quite happy to just read this article, nod in satisfaction at the ongoing GTK progress and move on, but your comment was just so outlandish I felt compelled to respond.
Hmmm yes. GNUstep always impressed me, mostly because it could be used to do awesome things even on slow x86 machines. But sadly, that’s where “old” GTK is useful, but GTK+ isn’t. Sure, from a developer’s standpoint, the increasing functionalities within the toolkit do help you to concentrate on the main work, the “functionality”, not the “how to implement it in detail” or “how to delegate operations to other toolkits” (e. g. database access). But have you noticed? When applications changed the toolkit from GTK to its successors, you nearly ended up in installing half of GNOME when installing something simple as a mail user agent. Okay okay, today’s applications aren’t that simple, I know. Oh oh… where’s the philosophy of having simple applications doing simple jobs gone? Today’s applications tend to develop into “one app does it all” monsters. That’s fine if your DE already brings all the dependencies (and that’s what’s happening on most users’ systems), but if you havent… good luck. 🙂
Additionally, I’d like to mention that GTK is still my favourite toolkit, followd by the mentioned GNUstep. So common bindings would be an excellent idea.
Copy my favourite toolkit and bow down to the greatness of its creators! (bonus points for bowing to its users as well)
I have coded for qt and gtk, and for both I started from scratch by reading documents and example code.
After already having coded UI with qt for one of my own projects, I wanted to give a hand for an open source project, which was using gtk.
For gtk drawing I first tried cairo, but that was a major turn down because of the lack of proper documentation for some of the cairo features. I guess that’s not gtk to blaim, but gdk was not much better experience. The learning curve was just too steep compared to the time/effort I had prepared to spend.
For qt docs, I don’t have much to complain and the whole framework was easier to adapt. Maybe partly because I had experience on C++ before I started qt, but not much experience on C when I started tinkering with gtk.