“To make the desktop look really nice, you want the ability to theme a window (or sub-component thereof) as a whole. This could mean graphics that span multiple widgets, it could mean moving widgets around, it could mean changing the spacing between widgets, etc. To address this, I believe we’d need to rework GTK+ a fair bit” says Red Hat’s Havoc Pennington.
Extending GTK+’s Visual Flexibility
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
This idea of making every line/square a widget is remarkably similar to our idea of having each elementary shape receive events as described in http://www.purevoid.org/os/progress/
It’s a nice idea, just hard to implement. Too bad GTK people thought of this before we finished implementing ours
Man, some of these guys forget that themers aren’t necessarily hackers. Half of what dude is saying is over my head, and I make themes for GTK+ and GNOME.
The ideal theming paradigm for real themers (i.e. artists and designers) is to have something like a pixmap engine, where themers can design custom made widgets in gimp or their favorite construction kit, map those widgets in a resource file (like gtkrc, oh we need a better easier syntax folks), and allow the theme engine to do it’s work.
That’s right, that’s exactly what the pixmap engine does today. I was expecting they’ll take that concept to the next level e.g optimizing, or redesigning, a pixmap-like engine from the scratch, giving themers to wealth of animation resources, opengling and cairoizing the engine etc.
We don’t even need any of the theme engines we have today, except for pixmap, because every look of every other engine can be effectively recreated with pixmaps. Yet we have a dozen engines, all with their own quirks and idiosyncrasies.
What are themers yelling for?
1).More expressive and syntactically sweet resource file. (i.e gtkrc without its horrible syntax)
2).Pixmap-like engine with mad optimizations that is cairo/opengl ready.
3).Ability to produce and direct creative animations, transparency, shadows, etc.
4).Make theming more artist oriented and less code oriented. Programmers that write themes are far and few between.
5).We want to be able to create and recreate every single widget in gimp/inkscape. The pixmap engine gives us that today, we love it, please follow that path.
6).A theming kit?
7).SVG capable theme engine, again make it pixmap-like.
8).Let artists, themers and graphic designers be at the helm of the decision making process, not hackers!
I guess what themers are looking for is a combination of the freedom the pixmap engine gives you in designing widgets, and the freedom the smooth engine gives you in controlling the engine and aspects of widgets. I think the existence of too many engines is a curse not a blessing. Today we only need two engines, pixmap and smooth. Pixmap is slow and I doubt it has been looked at or optimized in ages. Smooth gives me all the control I need but I can’t design custom widgets for it.
I rambling again, but I can’t see the light in the way Havoc intends to do the next generation theming for GNOME. Maybe I am just short-sighted. Can someone explain what he is trying to do in layman terms?
I largely agree with this comment, but I’d like to add another point, that doesn’t have something to do with theming, but more with the overall direction of GTK+
I’d like to see more focus on optimization and making GTK a “lightwight” Toolkit, like for example fltk.
GTK+ is in my Opinion a very, very cool toolkit, lets make it a lean, mean fighting machine too
An interesting read, but maybe one shouldn’t need to micromanage one’s layout so? Just as with Latex, one doesn’t have to micromanage the Page.
I think Havoc’s point is to make micromanagement possible, but not required. People will still be able to make buttons and textboxes with ease, but one will no longer have to reimplement controls in order to achive something like a triangualar button or an oddly shapped textbox.
GTK+ can’t be lightweight. It provides so much functionality, it is impractical to expect a lightweight toolkit out of it. If you want a lightweight toolkit then use Tcl/Tk, or like you mentioned, fltk. GTK+ has a lot more functionality and features over those. A compromise has to be made between being lightweight and being full featured. GTK+ is a full featured toolkit and we all just have to live with that.
Sorry pal, but Qt is faster than GTK and it offers the same, if not more, functionality. I am a gnome user, not a KDE one. But true things must be said: GTK/Pango are largerly unoptimized. It crawls on slower machines, where other toolkits don’t feel a hitch.
That’s all bull until you provide valid evidence in the form of benchmarks, or testing. Tell me, how does your wild statement help developers “optimize” “slow” GTK?
GTK apps *feel* too slow compared to other X apps (e.g. fox, qt, fltk). We don’t need benchmarks to tell us just that. I just know that I am not happy with the gtk/gnome performance no matter what PC or distro I am using. The immediate response that I get from BeOS or other toolkits on X is NOT there for gtk/gnome. Even XP apps feel faster on the same machine.
Besides, at least for Pango, the gtk devs know about the problem, just read their mailing list and blogs and how the Mozilla guys are not happy about Pango being so dog slow. I think Red Hat’s Blizzard was writing about this the other day.
Well, I don’t share your *feelings*.
I do share her feelings, GTK is Slow to respond slow to redraw etc, QT feels much faster, Windows XP does too. This is sad since I prefer Gnome/GTK over both QT/KDE and Windows
If you have an old machine around, just install gnome and watch the machine going dog slow. Your “feelings” will get in toutch with the “feelings” of the others.
I for sure hope, and wait, they will fix the issues, whatever they are.
> Sorry pal, but Qt is faster than GTK and it offers the same, if not more, functionality. I am a gnome user, not a KDE one. But true things must be said: GTK/Pango are largerly unoptimized. It crawls on slower machines, where other toolkits don’t feel a hitch.
I confirm this. I’m running a Duron 800 with 512Mb of RAM and a modern NVidia graphic card : Qt is faster that GTK+ on redraw. In fact, when moving, resizing, maximizing, reducing windows, GTK+ sucks on redraw , probably like never a toolkit sucked before. And I’m a GNOME/XFCE user, both based on GTK+ as all applications I use are written in GTK+. I hope GTK+ will improve if slowness, be it in pango or whatever subsystem.
@Anonymous: That’s all bull until you provide valid evidence in the form of benchmarks, or testing. Tell me, how does your wild statement help developers “optimize” “slow” GTK?
There is not need of benchmark to see that GTK+ is slower that QT on redraw : we are talking about user feel. Moreover, even GTK developers confirmed that GTK+ (or pango) has redraw slowness problem and need to be optimized. If you means that to give a advice a user should come from St Cyr or Harvard, you are putting you a finger in the eye (polite version).
The fact is that developer are probably running very powerfull computer and don’t have the same UI feedback (an feel) that user running less powerfull computer. And users running over-powered computer do probably not see the redraw problem.
Oh and surely, my comment don’t help developer in optimizing GTK+, but if only such comment where allowed, this new will probably get 0 comment, included yours.
No feelings, but if I can see *how* app like xchat2 redraws itself and do not react instantiously to scrolling and resizing for example… its SLOW. xchat 1.8x (on gtk1.2) was lightning fast at the same time.
It was best visible on old P200, but is still noticable on athlon.
Another example – zapping 0.7 where I have to often wait about half a second for menus to open on athlon 2000+ system!
Zapping 0.6.7 (which used gtk1.2) didn’t have that “feature”.
I have had almost never to wait for redraws and menus on Qt/gtk1.2 applications. With gtk2 this is usual.
These days I just mostly avoid gtk2 apps because of that (haven’t time yet to find out how to make lirc work with xawtv/motiftv).
This may be seen as rant… but I’m actually just frustrated with good apps turning slow after moving to gtk2.
GTK feels slow to me as well (on my 3200+ amd machine). Benchmarks don’t mean anything.. if the benchmarks tell you that it is faster but it still feels slow, then its slow.
OSX is a decent example of that, its actually pretty slow but it generally *feels* fast (until u try to resize a Safari window, anyway
)
Haha, that’s a new one. “OSX is slow but it feels fast.” Hmmm…these feelings are getting interesting.
I have a 1.4Ghz Athlon with 256 MB of RAM. I’m running the GTK-2.6.2 and the GNOME-2.9 series. It’s bloody snappy. On windows, when I right click on icons on the desktop, it takes a couple of seconds for context menu to draw. In gnome, it’s instanteneous. When I click on the programs menu in Window XP, takes forever for the menus to draw. In gnome the apps menu is instantenous.
Right now, I”m scrolling up and down xchat, I’m resizing epiphany, I’m minimizing and maximing nautilus, I’m moving the gossip window around in circles and I can’t for the love of God figure out where this so called “slowness” *feelings* are coming from. Maybe I have eye problems. And it’s not as if I have monster rig either.
Someone is talking about menus taking half a second to respond, another one is talking about running apps on a P200, and the rest are talking about feelings. Can you even run OS X or Windows on a P200? I think your expectations are weird.
> Someone is talking about menus taking half a second to respond, another one is talking about
> running apps on a P200, and the rest are talking about feelings.
Even I can confirm that GTK+ is kinda slow and together with GNOME even slower. Well If one person would say GTK+ is slow then you can still excuse it as Troll but if many people (and over the time it’s quite a damn lot) then something must be true in this.
This isn’t controversial anymore. It’s just a fact that Pango needs a fast path for western languages. Gtk+ is even a little sluggish on my p4 3.2ghz 1 gig ram. It’s totally usable, but it could be optimized.
That is what i expect to see on linux desktop in 2004-2005 when install my first distro (Mandrake 7) near 2000. What is so complex to do full 3D model of window decorations with some light cute vector drawing editor (inkscape-like) or even Blender, store in xml, and pass it to POW/yafray/whatever with 3x resolution in LCD subpixel dimention( most common horizontal), make pixmap cache. Then rasterize caches with respect to output gamma and (oh no, it is impossible) HDR glowing.
Yes, i know that it is dream but i read someware that Longhorn need hardware pixel shader support exactly for hi-speed subpixel rasterizer, why Linux not to do better ?
Such design have one big plus – it is motion-blur ready. If we do not micromanage “let put picture A to coord X Y now” and do hi – level command “start from current position move (fade) to next” it is completely decouple content and layout.
I am for example very interested in rasterizer part ( gamma-aware dithering/AA/subpixel), somebody interest with tracer, etc. 3D atrists can do extremely fine icons. That is the future!
Havoc is a really smart guy, but this time he just sounds like being on crack. Maybe he worked too much. Let’s ignore this idea of him: Guess we have other problems to solve, than turning GTK+ into a crack widget set.
Why do we need a theme engine that can make triangular buttons?! Is this really a requirement for a pleasing user experience? Or in the long term it will cause confusion and a visual mess?
What GNOME/KDE and other free Desktops need rigth now is to standartize their interfaces. Make better configuration interfaces, and make shure everything works!!
Wanna make something better? Work on X11… make it have a plugabble driver interface, so I can try to make my wacom tablet work without having to restart X on every configuration change.
I really hope that they DONT try to implement this, I love GTK the way it is now.
Its substantially slower than KDE/Qt. Just Selecting Gnome Menu or Alt F2 takes around 1½ sec on this machine while on KDE it happens instantly. Even though i prefer KDE over Gnome i like Gnome and the developers epic strugle to keep up with KDE. Gnome 1.x and i think early 2.x series didnt have this problem.
And as others have pointet out if it is perceived as slow then its slow. Before something can be done about it there must be recognition of the problem – fortunattely those that code seem to be aware, contrary to a few ganboys 🙂
I just wanted to say that with Cairo and opengl glitz back end GTK drawing will be around 400x faster on an Nvidia card. On other cards expect 10-100x improvements.
As regards Havoc’s idea, I fully support having a scene graph layout for the compositer. This is really cool cause the compositer can then add window wide lighting and shading effects to create a slick blended look rather than the discrete widget rendered look we have today. Individual widgets simply need properties to specify how reflective they are, how much shadow they produce etc so that the compositer gets the effects right. This only needs modest changes to GTK and is certainly doable.
I’m not sure we need to use subwidgets for every line – that seems a lot of work for very little gain.
Try again pal, Alt-F2 launches the run command dialog.
I really hate applications that have their own themes. Everyone should be using the standard widgets and system HCI guidelines for a consistent user experience and let the user decide how they look. We don’t need all our applications crying out “Hey, look at me! I’m different!”. People want to get on with tasks, they don’t care about individual applications and want their computer to act as a whole.
Take a look a Windows at the moment. People love to say we should have a standard interface like Windows but even Microsoft themselves cannot stick to one interface style. Compare MSN messenger, Windows Media Player, IE and Microsoft Office. They just seem to add in random themes on the widgets and Windows to make it stand out as different. Add in third party applications like iTunes and any Norton application and you just have a mess of different interface themes which detract from a consistent HCI. We do not want this.
Agreed!
Yeah, I was reading the article with interest but also not without a feeling of fear.
That said, I acknowledge that GTK+ is quite slow, but I prefer it to QT anyway for API reasons; I think that the dynamic widget placing system (as opposite to a fixed-position) in GTK+ is perfect. I also like that it’s C and not C++. And I pretty much dislike thisNamingConvention, which is a setback for QT, but that’s too personal perhaps ;> Oh, and I haven’t been able to use themes for QT without using KDE, and I don’t want any KDE libs on my system. So it looks just plain ugly.
OK, I know this isn’t about GTK vs QT. It’s just that… well… nevermind. Sorry ;-p
Yes, i know that it is dream but i read someware that
Longhorn need hardware pixel shader support exactly for
hi-speed subpixel rasterizer, why Linux not to do better ?
Why is this ”better” ? Where are the papers leading to that conclution ?
Personally I’d flush these features down the dreain if the come available.
Sure It might look cool for the first 3 minutes. I want usability.
The current interface we have to interacting with computers is already rotten enough, series studying should be performed. (and I don’t trust MS on such studies, they already have broken just about all deadly sins regarding usability)
//Longhorn need hardware pixel shader support exactly for
//hi-speed subpixel rasterizer
uhm, interesting: that’d be a function i’d implement if i were to design a completely new gui engine: a server doing the job of managing and compositing the window and widget hierarchy, WITH embedded widget kit in two forms: a SW fallback one, and one in the form of pixel/vertex shaders, to have the GPU directly render widgets and scroll inside them (with vector widgets, this is an heavy task that can be relieved from the cpu, with an order of magnitude efficiency increase)
of course, that is my concept, but its not soo far from a “Enlightened DOpE V2.0” thing…
//I really hate applications that have their own themes. Everyone should be using the standard widgets and system HCI guidelines for a consistent user experience and let the user decide how they look. […]
I Agree 😉 sometimes i’m tempted to take some otherwise good (according to the common opinion) program, and redesign the UI …
Because subpixel AA for all not only text provide much better signal/noise ratio for real image and image that programmer want to see, less stress eyes and allow talanted designers do better “weight” for different GUI elements, it is like i promote stereo 44KHz audio but you say – why i need this XXX if i can recognize 3KHz voice.
Another question: what to do with all that hand writen pixel themes in next gen hi-res displays that i guess be very cheap and popular after HDTV come to every house. Why not utilize all effort to 3D NURBS objects and matherials instead handwriting small pictures?
People want to get on with tasks, they don’t care about individual applications and want their computer to act as a whole.
Pal, you have absolutely no idea what people want.
This is something YOU want, so please dont try to speak for “the people” just to make your claim sound more important.
>> And I pretty much dislike thisNamingConvention
..and the rest of the world dislikes this_naming_convention_which_is_much_worse
Instead of demanding benchmarks that we’ll then dispute until the cows come home, lets address the perception of the problem. Whether or not gtk/gnome/pango are actually faster or slower than anything else nobody gets hurt if the system runs faster. The linux-desktop community has a tendency to dispute and argue instead of rolling up their sleeves and making things better.
p.s. I am the Lorax I speak for the trees and triangular buttons are what everyone needs. </suess>
Well that pretty much what I’m getting at. In Latex I design at the “purpose” level. e.g. paragraph, chapter, etc. And then let the software worry about the small details. Most of the HCI stuff can be embedded in both the widget kit, and the layout tools (asthetics is almost an AI problem. e.g. what exactly is “looks good”?)
[drynwhyl (IP: —.heim8.tu-clausthal.de)]
“Pal, you have absolutely no idea what people want.”
Now, now the situation with HCI’s has a middle ground. The extremes are “a totally unique interface for each person on the planet”, and “one interface to rule them all”. As I’ve pointed out, before as unique as everyone is, there is enough commonality amoungst us to base a viable HCI upon. A designer doesn’t have to make a complete guessing game out of it.
The primary question is where do the toolkit designers draw the lines between the common, and the variable?
It sounds to me like Havoc is just starting to reflect on what ‘theming’ means in the context of a fully composited window management system. As functionaility, which once was the domain of the individual Desktop Environments, gets pushed down the stack and into the common base of the FLOSS desktop, the role and the dominion of the Desktop Environment begins to change.
On the surface I see more than a little similarity between what he discussed here and that which is now being developed as part of E17. Rasterman, with E17, decided to go ahead and try to create the ‘next generation of Desktop Environments independently of the latest developments which are happeing at freedesktop.org and xorg.org. E17 is capable of leveraging complete composition, vectorization and opengl acceleration -the scope of what E17 graphically does is to a large extent determined by the resources available to it(compostion,opengl etc.).
As xorg begins to offer these same ressources to all Desktop Environments(Cairo/glitz/COMPOSITE/DAMAGES/FIXES/DMX) the roll of the toolkits starts to change-with these resources available a whole new range of possibilites has opened up and the toolkit developers need to think about how to best integrate-not only with the new technologies, but also how to utilize these new technologies to realize the new range of possibilites. I am quite sure that all of the toolkit devs are in a position of having to re-think a lot, questioning architecture decisions, due to the changes in underlying assumptions made as regards the scale of the doable.
GTK apps *feel* too slow compared to other X apps (e.g. fox, qt, fltk). We don’t need benchmarks to tell us just that. I just know that I am not happy with the gtk/gnome performance no matter what PC or distro I am using. The immediate response that I get from BeOS or other toolkits on X is NOT there for gtk/gnome. Even XP apps feel faster on the same machine.
Agreed. I think it is something that many people don’t want to readily admit, but it’s true. I think it will certainly be a real problem when people start porting everything to Cairo and the new 3D promised land everyone talks about.
I’m not sure the problem is all GTK though. X is certainly going to need further investigation and optimisation and with GTK in Gnome I’m convinced that some of the Gnome libraries need to be looked at. GTK on other desktops isn’t perfect, but the effect always seems to be worse in Gnome for some reason. I don’t know why.
I think people should be looking at the problem as within the context of a whole system rather than just with GTK, as Qt applications themselves aren’t perfect. However, GTK is obviously a part of where the problems lie.
I just wanted to say that with Cairo and opengl glitz back end GTK drawing will be around 400x faster on an Nvidia card. On other cards expect 10-100x improvements.
I’m afraid you’re smoking a large amount of crack there.
Cairo and Glitz will add a great deal more complexity to the system as a whole, and to get the most out of them users and developers will need confidence that what they’ve got now isn’t going to give them problems. You’re basically saying that people should throw hardware at an obvious problem and somehow it will go away. There’s a certain company from Seattle that advocates that approach.
Nat Friedman had some stuff about about Xgl, the 3D X server, and in his interview talked about how it was an awful lot faster in font rendering and window redrawing, basically because it was all handled in hardware. I got the impression he thought this was a solution also. I’ve tried Xgl, and it is indeed extremely cool, but you absolutely have to have a fully working and reliable OpenGL hardware-accelerated implementation. nVidia is the only one that cuts it, so for many it just isn’t going to happen. You’re also relying on non-open source software there that is critical to your system, but provided OpenGL remains a standard I don’t see it as a massive problem. I’m sure we will see graphics cards emerge with open source drivers that will really give nVidia and ATI a run for their money if people start using them.
However, in the open source world you can’t just ask people to throw hardware, complexity and more layers of software at the problem. There isn’t the resources.
“However, in the open source world you can’t just ask people to throw hardware, complexity and more layers of software at the problem. There isn’t the resources.”
That’s more a “keeping up with the Jones” problem. But throwing hardware at the problem is nothing new. That’s what brought us from the 4004 to the present Athlon 64 FX. Sort of a “We would like this” .e.g. better graphics, more horsepower. And the hardware meets up with the desires, and then people come back and realize that “Oh yeah you can do this with that additional horsepower too”.
Cairo and Glitz will add a great deal more complexity to the system as a whole, and to get the most out of them users and developers will need confidence that what they’ve got now isn’t going to give them problems. You’re basically saying that people should throw hardware at an obvious problem and somehow it will go away. There’s a certain company from Seattle that advocates that approach.
the “obvious problem” is still the good old stuff of moving windows, layering them, painting and scrolling inside them, right?
imho, that’s not throwing hardware at the problem
it’s more like exploiting hardware that many people have (with at least directx7-like capabilities, that is, even cheap cards in most pc’s for the last few years) by making it do some useful work that was entirely on the cpu’s shoulders until now
I haven’t realized GTK slowness until I tried GNUTSTEP live CD. Before I tought that sluggish behaviour was due to X11 but gnustep runs on X11 too and gnustep is as feature rich as GTK as far as I can tell.
As a side note, programming with GTK is not easy, especially TreeModel interface needs a lot of time to master.
Ok GTK+ 2.x is slow, we all know that, now tell me something I don’t know?
When will the Windows version of GTK+ 2.6 finally be released? After all this time since the GTK+ 2.6.0 release, there is still no accesible Windows port of it. GIMP, GAIM etc. are all still using 2.4.
If they call it a cross platform toolkit, why is there no Windows version of the latest release after 2 months!!? And why is it always buggy and half baked when it is released
(((((((((.
GIMP 2.2.3 is just too slow on GTK 2.4, I heard 2.6 makes ita bit faster, so this is really annoying me.
If GTK feels slow and you have a NVIDIA card, I was experiencing that too, but you can make GTK feel faster the nany other toolkit in my experience. On my laptop with a NVIDIA GeForce 2 Go I was able to notice the redrawing affect a little bit while scrolling/resizing windows. There is a VERY simple solution to this problem though: Add Option “RenderAccel” to your xorg.conf file, and all the problems are gone from my experience.
Offtopic, but myzz wondered how to get lirc working with xawtv. Well, I have that working here just fine. Just put something like this into your ~/.lircrc:
begin
remote = SBC-RU-520
button = TV_1
prog = irexec
config = xawtv-remote -d :0.0 setstation ARD
end
…
begin
remote = SBC-RU-520
button = VCR_1
prog = irexec
config = xawtv-remote -d :0.0 — contrast +=10%
end
“man xawtv-remote” is your friend
>As a side note, programming with GTK is not easy, especially TreeModel interface needs a lot of time to master.
I agree, totally. It took me some time to actually realize, we’re _supposed_ to work that way. That there was no easier way.
My reasoning is, this is due to GTK+ being designed mainly for scripting languages, not so much for native C usage. However, I haven’t checked if current scripting wrappers make trees any easier.
>However, I haven’t checked if current scripting wrappers make trees any easier.
Well, atleast in Ruby-GTK2 it’s still really hard, but i can’t compare it to the C-interface becease i have never coded GUI in C.
>> And I pretty much dislike thisNamingConvention
>..and the rest of the world dislikes >this_naming_convention_which_is_much_worse
I can’t help but notice you chose to seperate the words in your sentence spatially rather than withSomeCapitalLettersToDiscernWhereOneWordEndsAndAnotherBegins.
Theres a reason that some of us still stick with _’s; I tend to follow whatever coding style that the languages libraries use, or else my code inevitably becomes un-readable.
I’m afraid you’re smoking a large amount of crack there.
Why do we need to use strong words just to show our disagreement with other’s opinion? And this is common here. This is not a matter about life or death. His comment was not to insult or embarrass someone.
Please we all are educated people. And this is just about software. No need to act like this.
So, did anyone else find themselves appending “… like Avalon” or “…like XAML” to every other sentence of this article?
Yes, the TreeView interface can be hard to understand, but that’s because it’s using the MVC design pattern. A little bit of complexity adds a huge amount of flexibility.
> Yes, the TreeView interface can be hard to understand, but that’s because it’s using the MVC design pattern. A little bit of complexity adds a huge amount of flexibility.
I agree with this : the huge amount of flexibility is here at the cost of more complexity. But now the facts : how many programs really need such flexibility/complexity ? How many programs really use this flexibility ? Perharps 2% (ok, this is probably over-estimated). But now, how many programers using the GtkTreeView MUST face this complexity ? 100%. I wonder if it really worth it …
I’m a GTK/Gnome user and use lightweight managers like icewm, fluxbox, openbox (all based on gtk). I’d really like to see if there is a speed improvement using QT. Does anyone know of a lightweight window manager based on QT? It has to be lightweight because this is going on old hardware.
TreeView is a pain in the ass because the GTK developers haven’t wrapped a simplier way to do basic stuff around the MVC architecture of TreeView.
Its not that TreeView’s API is not flexable; it iss just that not a lot of people need to use it that way, and instead of wrapping the API into something simplier that most people would use (listbox, combobox, etc) all using the TreeView API behind the scenes (for when its time to start extending things), they have opted to not wrap it at all, and so everyone has to face the same mountainous challenge.
Its not better in the wrappers for ruby-gtk or Gtk#.
In my opinion, TreeView is not fexible. If it is flexible, one should able to use any gtk widget as a field in TreeView.
“If it is flexible, one should able to use any gtk widget as a field in TreeView.”
You are able to do that.
So, did anyone else find themselves appending “… like Avalon” or “…like XAML” to every other sentence of this article?
I certainly did
. The question is if the right tools are available to make it happen.
// creating some tree model
. . GtkListStore *store =gtk_list_store_new(3,
. . . . GDK_TYPE_PIXBUF, G_TYPE_STRING, G_TYPE_POINTER);
// filling the model
. . for_all_data(item) {
. . . . GtkTreeIter iter;
. . . . gtk_list_store_append(store, &iter);
. . . . gtk_list_store_set(store, &iter,
. . . . . . 0, item->pixbuf, 1, item->caption,
. . . . . . 2, item, -1);
. . }
// setting up some view
. . GtkTreeView *view = gtk_tree_view_new_with_model(store);
. . GtkCellRenderer *renderer;
. . gtk_tree_view_append_column(view,
. . . . gtk_tree_view_column_new_with_attributes(NULL,
. . . . gtk_cell_renderer_pixbuf_new(),
. . . . “pixbuf”, 0, NULL));
. . gtk_tree_view_append_column(view,
. . . . gtk_tree_view_column_new_with_attributes(NULL,
. . . . renderer = gtk_cell_renderer_text_new(),
. . . . “markup”, 1, NULL));
. . g_object_set(renderer,
. . . . “color”, “red”,
. . . . “editable”, TRUE,
. . . . “ellipsis”, PANGO_ELLIPSIZE_END,
. . . . “weight”, PANGO_FONT_WEIGHT_BOLD,
. . . . NULL);
C’mon guys, this minimal set of code is too complicated for your minds? Don’t put your light under the shelf! Cannot imagine to get along with significantly less C instructions, to setup and fill some two-column list-view. Would like to see you ideas how to simplify this, without introducing simplexity.
Btw: Did someone ever mention, that the comment-interface of osnews sucks? No auto-quoting, no indenting…
You mean “like Interviews” don’t you? Because as far as I can tell, the model of building up widgets in this manner was first implemented in Interviews’ glyph system. In interviews, everything is a glyph, and those glyphs can be composed into more complex glyphs. So character glyphs could be composed to make a label glyph, which could be composed with a rectangle to form a button glyph. Very nifty stuff, and done more than a decade ago
I hope so. I’m a KDE guy however there are times I do use a GTK app. on windows I use Gaim and fight with it’s sluggishness with every click. took me 5 mins to drag 1 contact to another metacontact once due to this.
Mozilla’s slowness is a HUGE! reason why I use Konqueror.
about a year ago I tried to seriously use Gnome.. but that lasted 2hours Not even looked at it since.. 15 crashes, 10 System crashes/lockups (yes I was using stable).
So yes I seriously hope they improve GTK to be ALOT faster and better! I really like mozilla, and gimp. seems really sad that such good apps use this toolkit.
I’m an electrical engineer working on a particle accelerator (www.sns.gov) for the US Department of Energy.
We run the particle accelerator control system on redhat enterprise linux machines, the control system is called epics (http://aps.anl.gov/epics/). This control system is used by many large projects.
The control system allows one to launch a multitude of separate display windows, many of which are graphically intensive with realtime waveforms, etc.
If I log in to a RHEL workstation, start a KDE session, and launch several control system windows I find the system performance to be adequate. However, if instead I start a Gnome session and launch the same control system windows the system becomes so slow as to be unusable.
This comparison is on fairly fast hardware. Please note also that I generally prefer Gnome, and run fedora/ubuntu on my personal machines.
I would really like to see Gnome/GTK focus on efficiency, simplicity, “just works”, and high performance rather than all the bells, whistles, buzzwords, and bloat.
Don’t want to be off topic, but why does the government fund a particle accelerator?
You don’t need to show a little bit of code to explain how a GtkTreeView works : to discuss about its flexibility/complexity, most people here have used it. What do you believe ? That people find pleasure to critisize things they don’t know ? People here don’t tell you they don’t know how it works : it’s more or less explained in the half-written GTK+ dcumentation. They just tell you it’s more complex than it should be and that it probably doesn’t really worth the trouble for most program !
Adam:
The US government funds research activities at several US particle accelerators (SLAC, Fermilab, LANL, …) for the same reasons that other nations fund programs such as CERN, or for that matter that the US funds the NASA space program.
The primary reason for this research is purely academic, to learn more about what makes up the world around us. The secondary motivation is economic, the research produces jobs and technology. Particle accelerator research/technology touches a wide range of fields, including electronics, medicine, and materials.
I run an old 1 ghz amd athlon with 384 mb of ram, and I don’t find that I have any problems with the speed of my desktop until I have OO.org, The GIMP, and Eclipse open at the same time. With the version of OO.org that I have (1.1.2 I think, FC3 default) if I right-click a misspelled word to fix it, it takes up massive amounts of ram, which has the same effect as having the other apps open as stated before.
Anyway, I think that GTK/GNOME has room for improvement. I’m confident that improvements will be made, and I’m excited for the time when they are made.
Yeah, and while at it please change the name. That plus make people go “GET What?”.
I like the name scheme QT guys works with.
Wow! RenderAccel *really* *really* fasters GNOME!
It becomes 5 times faster visually, all its sluggishnesses gone.
Try it, it is really saver.
“I would really like to see Gnome/GTK focus on efficiency, simplicity, “just works”, and high performance rather than all the bells, whistles, buzzwords, and bloat. ”
Not to pick on Chip or anything. But I just thought this was amusing. Especially in the context of all the complaints heard during the KDE vs Gnome wars.
>> “I would really like to see Gnome/GTK focus
>> on efficiency, simplicity, “just works”, and high
>> performance rather than all the bells, whistles,
>> buzzwords, and bloat. ”
> Not to pick on Chip or anything. But I just thought
> this was amusing. Especially in the context of all
> the complaints heard during the KDE vs Gnome wars.
So true. Nothing to add.
Well, so just show me some more compact API for implementing multi-column list-views. Don’t know one.
Some of the problems with speed in gtk is related to what theme you are using. Some themes feel sluggish, while others again feel pretty good. And I am not talking about using crappy simple themes, some themes look very good and feel fast while others again feel comparably slow. Test a bit around with different themes from art.gnome.org .
Don’t remember what kind of theme I am using now (sitting on os x right now
So character glyphs could be composed to make a label glyph, which could be composed with a rectangle to form a button glyph. Very nifty stuff, and done more than a decade ago
It certainly was. Unfortunately this is quite obviously being talked about now in response to stuff like Longhorn and Avalon – that’s the sad part about it.
It certainly was. Unfortunately this is quite obviously being talked about now in response to stuff like Longhorn and Avalon – that’s the sad part about it.
I don’t think that’s sad. In Linux we’re moving to compositing in Xorg as OsX did before us and Longhorn will also do. We will have to make changes and address problems similar to what other desktop engines have to address. Nobody said that we’re getting the same answers, but asking similar questions comes natural. And as a theme creator for both GTK and Metacity I really crave a way to extend graphical elements across widgets and across the window borders, or to alter the layout theme-wise.
And yes, it’s the ultimate window dressing, and there are other more important issues with gtk. Still, it would be nice if someone started to look into it…
I think the “sad” part refers to the fact that this sort of technology has been ripe for the picking for years now, but only know are people getting around to looking at it, and only then because they are following Microsoft’s lead. Interviews, and its successor, Fresco, have always belonged to the “free” camp, unlike competitors like Motif. Yet, the modern Open Source projects have catagorically refused to look at the technology until Microsoft pointed it out to them.
The Java-GNOME project (http://java-gnome.sourceforge.net/) is currently working on providing simplified APIs for TreeViews. Just wait for the next release (not the 2.10, but the 2.12).
The hardware to really do stuff like this hasn’t been out for terribly long; in order to really apply your windows as textures, you want non power of two texture dimensions, which (AFAIK) have only been out since the GF3 (not sure what the ATI equivalent of that is). Also, large amounts of gfx card memory are somewhat new, and that really is nice when each window on your screen is taking up its own chunk on the card.
Aside from the technical considerations, we really should give credit where it’s due: apple. Microsoft, as always, is following in Apple’s lead. We are too, like normal.
And I guess Apple is following Amiga’s lead.
Well, the toolkit model espoused in the article has been doable on stock hardware for quite awhile now. Fresco was usable on machines dating to 1995, it would fly on today’s machines, even without hardware acceleration. Beyond that, I’m curious to see how Apple is to credit for this particular set of innovations. Apple has nothing like this up their sleeve. Cocoa doesn’t use a canvas compositing model for its widgets, like Avalon will and like Fresco did. If such a plan was in the cards for Tiger, we would have heard about it by now.
I’m a GTK/Gnome user and use lightweight managers like icewm, fluxbox, openbox (all based on gtk).
Icewm is not based on gtk and blackbox derirvatives wasn’t eighter (although I’m not sure about newer openbox versions).
Any GUI application (gtk, qt, fltk, xlib) running in GNOME with Metacity as the window manager redraws extremely slow. Try running the same application in a fast window manager such as icewm — the redraw resulting from expose events is much faster. Try moving one window over another window containing some AA text and you will notice a big difference between the two environments. I noticed this when writing a simple hello world program with just xlib calls and xft calls for the AA text.
Although I will agree with you that there have been other projects, which have already addressed these capabilities, I cannot agree with you that the steps now being taken is due to Microsoft. As far as I know, and you may correct me if I am wrong- none of the competing graphics projects supported the holy-grail of backwards compatibility with X. Many may lament X being the standard-but in the Linux/FLOSS world backwards compatibility has been the alpha and omega in terms of whether or not something ever gets any significant amount of support-technical superiotirty is irrelevant if one has to throw away all of the GUI apps that have been written.
Firstly, as I noted before, E17 has been on the drawing board since before the hype broke about Microsofts plans for the future and at least superficially there is a quite a bit of similarity between what was discussed about GTK+ and the ongoing developments in E17. Secondly someone mentioned the the relatively recent availability of mass-consumer 3d graphics capable graphic cards-certainly this also played a role. But, perhaps more importantly, the ongoing changes to X represent a new positioning strategy- the proposed changes to xorg seem to be leading to a complete rewrite of the entire graphic card driver subsystem-nad in so doing xorg is positioning itself to demand, with a much greater degree of likelihood of success, that the hardware manufactures support the new emerging standards.
The old X contained lots and lots of code which didn’t really belong there in the first place- things which logically should have been implemented at a lower level, ie. in the OS(kernel) itself. Most of this code was in the form of hacks-making X do work which it should not have to do. With the move to modular xorg it appears as if the driver infrastructure is undergoing a massive change-work is now ongoing to coordinate and synthesize much of the stuff done in fbdev, DRI and mesa. At the end of the day xorg appears to be heading for a situation where manaufacture drivers have a very clear subset of functionailty which they must provide and where only the parts which apply to how a particular graphics card implements a opengl interface need remain cosed source. In all likelihood the opensource nvidia driver with a glx module will end up replacing the propietary driver plus glx. Is this perfect no-but it means that a much smaller part of the code base remains closed source. With a clear delineation of the functionality needed and clear implementation of that functionality, seperating out those things which belong to the underlying OS from xorg, it should be possible for the manufacturers to more easily supply opengl support for their hardware under xorg.
Although one still hears much in the way of confusing reports about ATI’s commitment- it is clear that NVIDIA has dedicated staff to working together with the xorg development people to implement the next generation of X. The reality of the situation is that X has to a large extent been held hostage by the hardware manufactures in terms of what they were willing to support. Making the decision to move to opengl has been a very hard decision to make-most computers running FLOSS do not currently have a good opengl implementation. If there was no conviction that the changes to xorg driver subsystem would lead to better opengl support this move would simply not be feasible. Ultimately only if the hardware manufactures choose to support the new driver subsystem will the opengl accelerated desktop have a real chance of succeeding.
None of these developments have anything driectly to do with Microsoft and their plans. Of course the xorg developers are aware of what Microsoft has announced-they do not live in utter isolation. But I think a whole slew of pragamatical concerns are the real underlying issues at work here.
I for one really appreciate the tenacity with which Keith Packard et al made the push to move to opengl. The difference between what Keith Packard has done and what all the other competing projects have done is that Keith Packard has been working on a way to guarantee backwards compatibility.
For those of you who are not aware of the most recent changes- if you are running >=GTK+-2.6 along with xorg-6.8.2 on a card with good opengl support(NVIDIA) you can now use xcompmgr for a fully composited desktop-I run it now full time- it is almost completely stable and it is ultra-smooth.
“xcompmgr -cCfF -r7 -o.65 -l-10 -t-8 -D7 &”
When I first tried this out, almost a year ago, it was slow, buggy and unstable. But a whole lot of work has been done-it is now much, much faster, and quite stable-opengl apps work fine as well as xv video. I now get ‘zero’ visibile redraws and my CPU usage is a fraction of what it was without using compositing…..
As far as I know, and you may correct me if I am wrong- none of the competing graphics projects supported the holy-grail of backwards compatibility with X.
Fresco was an X toolkit, developed for a time by the X Consortium itself.
Firstly, as I noted before, E17 has been on the drawing board since before the hype broke about Microsofts plans for the future and at least superficially there is a quite a bit of similarity between what was discussed about GTK+ and the ongoing developments in E17.
Most OSS folks summarily ignored E17 until the Avalon hype hit.
In all likelihood the opensource nvidia driver with a glx module will end up replacing the propietary driver plus glx.
Unlikely. There are no specs for NVIDIA’s hardware, and even if there were, the OSS driver would likely be inferior to the closed version, just as the OSS ATI drivers are.
None of these developments have anything driectly to do with Microsoft and their plans.
Sure it does. Directly or indirectly, all this OpenGL X business is in direct response to Longhorn and OS X. The X folks are faced with the possibility of missing a very big boat, and being left without a 3D-accelerated GUI, just as they were left without anti-aliased text for a time. That’s what’s driving this particular push.
More generally, the X on OpenGL stuff is orthogonal to the GTK+ ideas discussed in this article. You can usefully implement either of the two in isolation. However, I think it’s safe to say that the ideas in this article are at least inspired by Avalon’s canvas model. The concept of building up the GUI using a tree of canvas primitives has been ignored in far too many other systems for this particular iteration to be spurred by anything other than Microsoft’s interest in the idea.