GTK 3.0: an app developer's view
- From: Allin Cottrell <cottrell wfu edu>
- To: gtk-devel-list gnome org
- Cc: gtk-app-devel-list gnome org
- Subject: GTK 3.0: an app developer's view
- Date: Mon, 16 Jun 2008 22:39:40 -0400 (EDT)
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]