GTK 3.0: an app developer's view

[Allin Cottrell <cottrell wfu edu>]

Sorry for cross-posting, but I think this does cross gtk-devel and 
gtk-app-devel: it's the thoughts of a common-or-garden app 
developer following the dicussions on gtk-devel about what's 
coming with GTK 3.0.

As a starting point, on June 5, in the thread "Steps to get to 
GTK+ 3.0", Martyn Russell (name_obscured imendio com) wrote:

"Many applications didn't make the change [from GTK 1.2 to GTK 2] 
because it meant rewriting a lot of code. Unless my applications 
are using some evil voodoo they shouldn't be using, I don't expect 
the transition from GTK+ 2.x to 3.x to take much time at all."

As an app developer who did take the trouble to re-write a lot of 
code in the transition 1.2 -> 2.0, I wonder about this statement. 
(Note: In my understanding, one key difference between GTK 2.0 and 
3.0 is that all the APIs deprecated in 2.0 will be removed in 3.0; 
If I'm wrong about that, please tell me!)

What's the status of the portion of the GTK API that was not 
deprecated from the get-go with GTK 2.0, but joined the deprecated 
list later, after 2.4?  I'm thinking in particular of 
GtkItemFactory: if I'm remembering right, that was still kosher 
when GTK 2.0 appeared.

My app has a large number of menus, across several classes of 
windows, and, after checking my code in the wake of the recent 
discussion of GTK 3.0, I find I'm very heavily invested in 
GtkItemFactory.

I don't want to be a stick-in-the-mud, and I spent most of today 
working on a "trial port" to the GtkUIManager API of some of my 
GtkItemFactory code, to get a sense of the work that would be 
involved in eliminating all dependency on the older API.

Results so far: On the one hand, I can certainly see the 
attraction in the newer API.  Being able to define an "action" 
just once and then have it instantiated in various different UI 
constructions (regular menus, buttons, popups) is very nice.  But 
from my point of view the attraction is largely counterfactual: 
_If_ I had originally composed my app's UIs in this way, I could 
have saved myself some trouble.  But I didn't, and now I'd have to 
go to very considerable trouble to redo them.

I considered the possibility of writing some sort of script or 
program to translate from GtkItemFactory to GtkUIManager, but 
fairly quickly convinced myself this was not feasible in a 
reasonable amount of time: the APIs are just too different.

One key difference relates to the situation where you have several 
GUI actions that are basically similar but differ in some detail.  
In the GtkItemFactory API you can map all such actions to a common 
callback, but assign different values to the guint parameter to 
the callback. So far as I can tell, the callback signature for a 
GtkAction does not support any such (gu)int parameter.  So either 
you have to use different callbacks for each specific action, or 
you have to construct a mapping from string action names to 
specific int action values.

This is perhaps not terribly onerous if you're starting from 
scratch, but it's definitely inconvenient, and represents quite a 
major porting burden: not only would I have to rewrite all the 
menu code, but I'd also have to rewrite all the top-level callback 
code other than for simple cases where there's a one-to-one 
mapping from GUI action to callback function.  Moreover, the new 
code would be less efficient than the old (lots of strcmp as 
opposed to just looking at integer values from an enumeration).

In addition, I'm not 100% convinced of the virtues of defining a 
UI in XML as opposed to via an array of C structs (having both 
options would be nice).  Gtk-demo has an example where the UI is 
defined via a chunk of XML inlined as a C string.  This really 
sucks, and would be a maintenence nightmare in any real app.  
Reading the XML from file is preferable, but even then I'm a bit 
skeptical about offloading core stuff to separate files to be read 
at runtime.

OK, I don't want to be too negative about GtkUIManager; it surely 
has its advantages.  But I am concerned about the possibility that 
GtkItemFactory will disappear: this API is not "evil voodoo", IMO, 
and I don't suppose that mine is the only GTK 2 app that uses it 
rather extensively.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC