The first unstable major version of GTK+ are out and about: Pango 1.5.1, GTK+ 2.5.0 and GLib 2.5.0. Among the new features are some visual ehancements on the way windows draw/resize.
GTK+ 2.5 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
Eugenia I searched those keywords in the links provided and I can’t find any reference to “windows draw/resize”
How do you know of these improvements.
I didn’t read the whole thing, but I noticed this:
* Performance improvements
– predict exposes for override-redirect windows [SÃ?¸ren Sandmann]
– unset the background when mapping or unmapping windows [SÃ?¸ren]
– support the update counter spec for smoother resizing [SÃ?¸ren]
Thanks, I guess I don’t know what to look for.
At this rate, hopefully GTK and crew will hit v3.0 at the same
time as GNOME. I have always like version numbers coinciding.
It makes things so… sexy ;]
GTK could do with some speedups, I hope it achives some faster load times and less clunky.
Like someone else said it would be nice to have both on the two on the same dev path. Though I do realize that to keep them on track on the at the same path is hard to do because one will always prevent the other from being released if they are not on the same page in terms of development speed.
>> Support for ellipsization in PangoLayout
Finally! Hope to see this implemented in most Gtk+ and Nautilus widgets as soon as possible.
The current way of using capped texts without any further notice (or even worse: not capping texts) just sucks.
>> GtkComboBox, GtkComboBoxEntry: improve placement and
>> sizing of popups
Hm, does this mean that combo box popups will be finally shown in ‘Windows-style’ below or above the combo box (which is used in Qt as well) instead of that useless way of popping it up on top of the combo box itself? (making it much harder to keep the thing popped up after clicking)
>> support the update counter spec for smoother resizing
Great, if this is what I think it is, resizing is going to be much nicer (smoother) compared to how it used to be, especially in combination with Linux (kernel) 2.6
Is it possible to get the old style to define shortcuts? In GTK1 it was possible to select a menu item and press a key combination. I liked this, but in GTK2 it was removed (as default) because it is to complicated for newbies (I don’t like this argument). Is there an option to activate it or is this feature completely removed?
Great, if this is what I think it is, resizing is going to be much nicer (smoother) compared to how it used to be, especially in combination with Linux (kernel) 2.6
It is what you think it is
Basically, the update counter makes the window frame and the client redraw in lock-step, so one can’t get way ahead of the other. I think it’s the same way OS X does things, except OS X has double-buffering on top of that. I haven’t tried the GTK+ patches, but in KDE, doing this makes resizing look a whole lot nicer for complicated applications (eg: Konqueror browsing Slashdot). It also get’s rid of a lot of the redraw lag that happens when you resize windows when there are other ones underneath.
Open gconf-editor. Set /desktop/gnome/interface/can_change_accels to true.
RE: my subject By my name (IP: —.quicknet.nl)
>> Support for ellipsization in PangoLayout
Finally! Hope to see this implemented in most Gtk+ and Nautilus widgets as soon as possible.
The current way of using capped texts without any further notice (or even worse: not capping texts) just sucks.
Nautilus, and so forth, used an Eel (a place where nautilus holds a bunch of extra widgets) widget that did the same. The code was just put into Gtk instead of living in a different module.
>> GtkComboBox, GtkComboBoxEntry: improve placement and
>> sizing of popups
Hm, does this mean that combo box popups will be finally shown in ‘Windows-style’ below or above the combo box (which is used in Qt as well) instead of that useless way of popping it up on top of the combo box itself? (making it much harder to keep the thing popped up after clicking)
This is already supported. It just depends on the theme to decide how to do it. Take a look here (notice it is a style property):
http://developer.gnome.org/doc/API/2.0/gtk/GtkComboBox.html#GtkComb…
What I am much more exited about is the development of some of the new widgets, like GtkIconView (really cool!), GtkCellView, GtkCellRenderProgress and GtkCellRenderCombo. Though many of these were already possible before hand (look at epiphany for example) it is nice to have them integrated into gtk.
A lot of GTK+ widgets waste
a lot of whitespace.
For example in menus, there
are a few pixels above and below the text
that are empty. Compare this with windows or mac
menus, the GTK ones look clunky because of this.
Toolbars have the same problem, there’s
too much space above the icons,
between icon and text, below icons and in between consecutive icons.
Many other widgets have the same problems,
and have had it for years.
It would be great if this would be fixed.
i don’t see that — on the contrary i think there is too little padding on the right side of a menu without accelerator keys.
the menu item text ends just at the border but on the left side there is usually some padding because some of the options have icons and some have not (example: context menu of gnome desktop where “change desktop background” is displayed this way.
at least i think the arrow that indicates an item has a submenu should go in its own column on the right just like the icons on the left. perhaps i am just to much of a perfectionist?
>>> GtkComboBox, GtkComboBoxEntry: improve placement and
>>> sizing of popups
>Hm, does this mean that combo box popups will be finally shown in >’Windows-style’ below or above the combo box (which is used in Qt as well) >instead of that useless way of popping it up on top of the combo box itself? >(making it much harder to keep the thing popped up after clicking)
Window’s style popups are actually inferior to the way gtk currently does it’s popups (but the same as gtk’s combo-box popups). In gtk’s current system (and Mac OS’s for that matter), the menu pops up such that the mouse appears over the current item. It is quite common for the user to want to select something near the current item, so this behavior can save said user a lot of time.
you can just add the line
gtk-can-change-accels = 1
to your .gtkrc-2.0 file. hope that helps… it is a nice feature.
This, like many other concerns in this thread, is theme-centric. Some themes, like Ximian Industrial, contain a lot of this wasted menu space, while others, like Simple or the XFce-engine themes, contain virtually no wasted space at all. If your theme has too much wasted space, contact the theme’s developer and voice your opinion about it!
Or just rework it yourself
fixing the amount of CPU usage it takes to move a window? If you look at the system monitor while moving a window you’ll see it spikes to 100% sometimes.
Ignoring SMP here…
CPU usage is always either 0% or 100%, unless you
average it over time. Instantaneous CPU usage is
always 100% for the viewer tool and 0% for everything
else. Every app that runs will spike to 100%.
The “top” program with default settings will give
you an average over 3 seconds. The “ps” program will
give you an average over the whole life of the process,
though it really should give a decaying average.
I suppose this “system monitor” thing will average
over a very short time. Perhaps it is 1 second.
> * GtkTreeView
> – hover-selection mode [Matthias]
If this is what I think it is
then it’s something I’ve always missed in GTK, though it’s strange it comes in GtkTreeView (which also includes listview, I think). Or does the new GtkIconView also support hover select ?
You guys could have at least replied to my request after moderating down my comments. Truly disappointing.
-magg
Button space isn’t wasted:
Fitts’ Law
The time(ms) it takes to move the cursor to a target is
a + b * log2(D/S +1)
D = Distance to target
S = Size of target.
Note that the pixels around the screen edge can be seen as infinite in size.