Comments on: My take on GTK+ 3.0

By: Quim Gil: This is not a GTK+ 3.0 blog post | Christian eBuddy Blog

Quim Gil: This is not a GTK+ 3.0 blog post | Christian eBuddy Blog — Tue, 22 Jul 2008 20:14:02 +0000

[...] been trying to follow the intense debate tagged GTK+ 3.0 and actually covering a lot more, from the longest post to the shortest. If I was into film criticism I would say that the story is evolving from [...]

By: kalikiana

kalikiana — Mon, 21 Jul 2008 12:02:25 +0000

That’s a nice visional post. I particularly like the points mentioned in the User Interface paragraph, and this is what I’d like to see coming in the near future. I would add revamped sizing algorithms of interface elements there, and we have great goals for a great toolkit.

By: Karl Lattimer

Karl Lattimer — Mon, 21 Jul 2008 07:09:17 +0000

@knipknap: Sounds like deprecating like that would cause problems along the way, I understand your point however it would be necessary to have specific dates which were publicised where the deprecation occurs. These would of course be release dates but they would have to be publicised before the fact.

@Juri Pakaste: You kinda jumped the shark a little there, but I understand what you mean, although I believe these kinds of animations should be a part of the theme engine.

@megatux: I think what you want for your 3D widgets is maybe another library, it shouldn’t really be in GTK+ but I believe you have a good point regarding simple OpenGL primitives, or even loading meshes and uvw projections onto those meshes with simple API framework for event processing… Not really a GTK+ issue but a good idea for a new library, would be even nicer if it could somehow be integrated with clutter.

By: megatux

megatux — Mon, 21 Jul 2008 06:48:16 +0000

Excellent post. I must say, you have one of the few GTK+ 3 opinions I almost entirely agree with. (especially on the animation and resolution independence parts)

The one other thing I’ll add as a “necessary wishlist” item is 3D objects as widgets (both simple primitives and meshes). I’m not talking about the power to create intense games or full-power GL apps, just “basic” things like 3D globes for geo-browsers or 3D navigation widgets that work well with multi-touch. There should be enough power that developers don’t have to break into using GL in a frame to do the simple things. Most of these sorts of things would perform adequately with software GL renderers, for those worried about old/low-end hardware. Of course, it won’t be long before every device, phones included, have reasonable 3D acceleration.. 2 years perhaps? It’ll take that long to develop GTK3.

By: hells_dark

hells_dark — Fri, 18 Jul 2008 19:11:07 +0000

Some interesting points here

By: Peter

Peter — Fri, 18 Jul 2008 09:06:37 +0000

I agree with this, some people that have said that MS don’t ever break the API/ABI on windows are also wrong. When windows XP was release a huge amount of things were removed that were marked obsolete with when Windows 2000 was released. I remember as an IT consultant at the time having 100s of proprietary business applications break and having to wait for vendors to release new versions. The same thing happened when Windows Vista was released. Apple has done exactly the same thing with their OS

The other thing that I believe is the case is that gtk3 (or at least gnome 3) isn’t due for nearly 2 years and I would guess that for a lot of the cruft that is being removed alot of it has already been replaced with better stuff and just can’t be removed. 2 years is a long time to migrate where alot of apps may well already be along way there.

By: Juri Pakaste

Juri Pakaste — Fri, 18 Jul 2008 06:44:44 +0000

On animation: Animation is generally speaking a good idea when anything changes the user interface. Folding a window into a paper plane is admittedly silly, but subtle animations where things slide into visibility etc make things clearer.

Using Cocoa as an example, because it’s something I used just a few days ago: I needed to optionally display an information text below a list view, depending on what was in the list view.

So I added a label that’s usually outside the window and when necessary, resized the list view to not take up all the vertical space and moved the label into view. Not too hard, just [listView setFrameOrigin:foo]; [listView setFrameSize:bar]; [infoView setFrameOrigin:baz];. All fine and good, but it’s sort of clunky how it suddenly just appears out of nowhere. It’s the same way it would work with GTK+ 2.x. What to do to make it smoothly animated? Change those calls to [[listView animator] setFrameOrigin:foo]; [[listView animator] setFrameSize:bar]; [[infoView animator] setFrameOrigin:baz];. The result: the info view slides out smoothly at the same time as the list view resizes itself.

That’s the sort of thing I’d love to be able to do with GTK+ and animations. Of course you can tweak the Cocoa animation to your heart’s content, but the basics should be really, really easy.

By: nona

nona — Thu, 17 Jul 2008 22:51:39 +0000

How right you are, on many points. Device/resolution independence is something that’s quite long overdue. It would be nice if the icons I’ve put in the middle of my panel or desktop, stay in the middle even after changing resolutions back and forth.

Also, it’s probably not a bad moment to make sure the APIs are multi-pointer (multi-user) and multitouch aware.

By: alex

alex — Thu, 17 Jul 2008 22:29:54 +0000

I think that this is probably the most sane thing written on the topic so far.

By: knipknap

knipknap — Thu, 17 Jul 2008 21:11:47 +0000

Everybody seems to think that the only way to allow for API/ABI breakage is to have a fixed date at which Gtk will overhaul it’s entire interface. Why not have a general rule instead that says “we may at any time remove any API that was deprecated at least n years ago”. Then the only applications who need changes are the ones that haven’t removed deprecated API for a really long time. This allows ISVs to slowly and iteratively update their applications.