GTK+ 2.4.14 was released among stable and unstable versions of atk, glib, pango. This version includes some major speedups on the GtkUIManager code. You can rate the toolkit here. Update: GTK+ widget update in the documentation.
GTK+ 2.4.14 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Also Glib 2.4.8 and 2.5.7 and Pango 1.7 were released.
Any idea when we’re gonna see a break to GTK 3.x? is it in development/discussion? are we waiting on developments in the core OS to take place before such planning/coding?
GTK has really come a long way… the file selector has made all the difference to me…. and now, XFCE 4.2, coupled w/ a nautilus makes for a powerful, but streamlined DE….
The one thing i found amusing by the post…was that gnomefiles has GTK rated lower than apps based on it….
Its probably the same reason people would rate say “Romeo and Juliet” higher than the english language. Words are pretty cool in their own right, but I would rather read a book. A toolkit is nothing without great applications that use it. The same can be said about many other things including (off the top of my head) video game consoles.
That said I am more of a QT/KDE guy myself but I am always keeping up with GTK/GNOME development to see what cool stuff they can cook up. Congrats to all.
What exactly is the “GtkUIManager code” responsible for?
Define “major speedups”.
if you opened an image in pre 2.2 versions of The Gimp, it took a while after the dialog disappered and the image actually appeared.
GtkUIManager: Constructing menus and toolbars from an XML description. See also http://developer.gnome.org/doc/API/2.0/gtk/GtkUIManager.html
This is an important code to speedup. For example, all GIMP menus are constructed with it: see http://cvs.gnome.org/viewcvs/gimp/menus/
hello
Does programs well be run faster ?
> GtkUIManager: Constructing menus and toolbars from an XML description. This is an important code
> to speedup. For example, all GIMP menus are constructed with it.
This is still no alternative to BonoboUI if you want to embedd other components such as “GtkEntryBox” or an other customized widgets into the Toolbar at least not with GtkUIManager. I recall around one year ago when this was announced as the successor to BonoboUI (and I still believe it to be the right path to go) but somehow these bits needs to be much more worked on. Right now to add a different component into the Toolbar using GtkUIManager you need to subclass the entire thing and add your own custom Widgets to it which ends up in more work than initially thought. There are also no informations whether you add the newly created Toolbar into a vbox, into a ButtonBar, if you should add a Toolbar handle to it or not (e.g. to deatach the Toolbar from the app). This ends up in a lot of customizied own solutions as I have seen in plenty of GNOME and GTK+ applications. Some prefer using a vbox to stuff all this in, some prefer using it into a ButtonBar box, some add a deatach handle and some not. Which makes the applications look all differently again.
This is a known issue for GIMP 2.2. The GIMP-Team waited for at least two things before releasing GIMP 2.2.0:
1.) The new splashscreen. It will be choosen on Dec 5 2004
2.) The new Gtk-Release where the speed-issues are fixed. This happened with this release.
GtkUIManager is also going to be the engine for the next major release of Nautilus. Even before the speedups were comitted to GTK, the de-bonoboized Nautilus felt a little quicker than the previous BonoboUI version.
And it also supports GTK’s keyboard shortcut redefining!
The biggest problem with gtk+, in my opinion, is lack of a good grid widget for database development. GtkTreeView can be used but it is not suitable for in place data entry especially using just the keyboard.
I’ve been asking for just one thing.
An option to show buttons w/o glyp.
Holey in next versions.
The biggest problem with gtk+, in my opinion, is lack of a good grid widget for database development. GtkTreeView can be used but it is not suitable for in place data entry especially using just the keyboard.
What about libgnomedb? From the website:
libgnomedb: Database Widget Library. These widgets are integrated with the latest versions of glade.
http://www.gnome-db.org
Now that free QT is not really an option on windows and gtk+ has made big improvements on windows, gtk+ is a decent crossplatform toolkit (don’t know about Mac but don’t really care).
Pygtk is a nice crossplatform development tool.
Someone mentioned that a new version of Pango was released. Anybody know if the fastpath rendering code for western languages is in there?
For me i implemented something like you said,
using GtkTree and ODBC and it didnot took a lot
of time(1 day maybe) and it was quite generic.
So when are the GTK fellows going to begin the arduous transition to Cairo? Once that happens, everything is going to change for the better.
To clarify, data bounding to a GtkTreeView can be done easily, my problem is the in place data entry of the tree view especially using only keyboard. Also, there is no easy way to have combo fields in the current widget, which is very handy for database apps.
Please see http://www.sicem.biz/personal/lgs/projects/gtkgrid/view_project
for what I am looking for.
Probably more like will be in 2.8…
http://www.gtk.org/plan/2.8/
sorry, wrong article
No fast rendering path.
Here’s the NEWS:
Overview of changes between 1.6.x and 1.7.0
===========================================
* Add PangoRenderer, a subclassable driver object holding the
logic for rendering PangoLayout.
* Support transformed rendering for the Xft backend
* Add Lao support in Thai Module [Theppitak Karoonboonyanan]
* Support Thai OpenType fonts [Theppitak]
* Add Syriac module [Emil Soleyman-Zomalan]
* Add underline-color and strikethrough-color attributes
[Morten Welinder]
* Add pango_win32_render_transformed() [Hans Breuer]
* Misc fixes [Hans Breuer, Matthias Clasen, Manish Singh,
Morten Welinder]
* Documentation improvements
You mean there already is a patch to implement that fast rendering path?
Speedissues should be fixed, IMHO, with evas. Yes this would require some rewrite of the underlaying GTK structure, I guess. And probably cut some of the Systemindependencys.
just my .2¢
kindest regards,
Moritz Angermann
Is EVAS also being used by Gnome?
Isn’t Evas an Enlightenment project? That would require fairly substantial rewrite, not just “some rewrite”.
Evas: http://enlightenment.org/pages/evas.html
?
Hi,
Well, I’ve already taken a look at some Evas demos (this was a few months ago), and I have to say it totally rocked =). E17 the window-manager is in CVS now, and Rasterman did a comparison between Evas and Render a while ago
I’ve been running Gnome 2.8 (Ubuntu) for a while now, and I have to say I really like it, except for the (perceived) lagginess. XFCE is much smoother, at least to me, and enlightenment is just lightning.
Bye,
Victor
EVAS wouldn’t be a great fit for GTK+. GTK+ has an immediate-mode rendering API, while EVAS has a scene graph. EVAS would be more appropriate for a compositing, scene-graph toolkit like Fresco.