soc idea: gconf-gtk tools

[Sam Thursfield <ssssam list googlemail com>]

Hello everyone! I'd appreciate a couple of moments of your time to
give me some feedback on my summer of code idea, before I spend too
long on a proposal for something nobody likes. It's a package which
would save everyone some time and effort, and hopefully remove some
redundant code from all over GNOME while reinforcing UI and behavior
consistency.

Basically using GConf in a standard GNOME application is a lot harder
than it could be, and although there have been various localised
solutions to the problem I think gconf integration needs a few months
of love. I don't want to waffle on for hours about what I want to
propose, but it's a little tricky to explain; hopefully an example is
the best way. Let's say Joe starts work on a revolutionary new GNOME
application. Before long he has some things he'd like to make
configurable and expose to the user. He then has to:

* Hand-write a gconf .schemas file, which is a little annoying
* Perhaps make a header with #define KEY_FOO_BAR
"/apps/my-app-with-a-long-name/foo/bar" etc.
* Write gconf notify hooks to update his application's state.
* Make a dialog with widgets to control these settings, neatly aligned
and indented to match other GNOME apps - it's annoying wrestling with
vbox padding etc. in Glade, or having to modify an existing apps
dialog, when these things normally follow the same pattern.
* Connect all the widgets to the gconf properties - which each project
solves in a different way, some writing a special callback for each
widget, some writing their own code to do so automatically, and it
seems none of them using the 'gconf-bridge' library which I only
discovered this afternoon.

When I'm done, this workflow should hopefully change to:
* Define the keys he wants to use, in format nicer than XML
* Define the dialogs he wants to use, in a simple heirarchical way.
* Write gconf notify hooks to update the application's state.
* Add a macro to his autoconf file, or wscript or whatever he likes to
use, and link to the correct library.

In a nutshell that's what I would like to do. Please let me know if
you think it's a good, bad or pointless idea, and if you're interested
to hear more I have had a kind of preemptive question and anwser
session with myself which will tell you a bit more about what I am
thinking of doing ..


Q. How do you know this is a good idea?
A. A preliminary version of the tool already exists, written poorly in
LISP, and using the gconf-peditor code from gnome-control-centre to
connect widgets to keys. I certainly will never go back to doing
things by hand now I have a tool to it myself - but as you can
probably tell, the current version really needs rewriting from scratch
before it's useable by many people, and there's lots of work to do on
integration etc.

You can find the tool here:
http://calliope.svn.sourceforge.net/viewvc/calliope/trunk/conftool?view=markup
And the input file here:
http://calliope.svn.sourceforge.net/viewvc/calliope/trunk/settings.conftool?view=markup


Q. Writing XML schemas isn't hard, why add another layer of complexity?
A. It's not my primary aim to replace XML schemas with another
slightly simpler language. In fact, I might decide to ignore that part
and just have a dialog generation tool which reads from the XML
schemas. It's nice being able to define simple keys easily though, compare this:

(key "import/file-name-parsing/enable" bool     :default true
:blurb "Enable file name parsing")

With the 10 lines of XML the .schemas file requires. There are other
bonuses too - for example, you can say a certain key has an enum type
and the tool can generate a long description listing all the valid
values automatically.


Q. Can't I use existing code to do this?
A. Code is out there for the gconf bridging. There's no complete
solution though. The contenders really are libgconf-bridge, which can
connect keys to window geometry, listbox rows or arbitrary properties
- useful, but needs work before it can connect to most GtkWidgets, and
gconf-peditor, which connects to lots of GTK widgets but not arbitrary
properties, and isn't (yet) a library. Also, I'd like to make the
connections GtkBuildable to save the dialogs tool having to generate C
code, which nobody seems to do at the moment.

As for dialog generation, there doesn't seem to be any program to do
this at the moment.


Q.  Don't you think this is too much work for SOC?
A. Well, there's there's not a huge amount of work to do before the
project becomes useful. I already have a working prototype of the
dialog & schema generator, and existing code for the gtk/gconf
bridging.


Q. That sounds like too little work for SOC.
A. I could keep going all year. An well as the coding there is
documention, unit tests, integration with build systems, a GLADE
plugin for people who'd like to make their dialogs by hand but would
still like to connect the widgets to gconf automatically, and then I
could get started converting any existing GNOME programs that would
like to use the new tool and library. There's plenty to do.



Q. How much effort does this actually save?
A. I had a look through some existing applications, and there's a lot
of wasted energy. There are a couple of places (libeel and
libgames-support) that gconf_client_* gets wrapped, but using a global
gconf client istead of passing a parameter. That's something a new
library could do instead. I had a look at 5 existing apps to see if
this idea would do them any good: 3 of them (Rhythmbox, Gnometris and
Gedit) each have hand-coded callbacks bridging every widget to its
key. The other two (Gnome-terminal and Gnome-control-center) are
cleverer and each use their own generic callback code. All of them
would something from this project, even if it's just a slightly
smaller codebase in the case of the last two. Introducing new
configuration properties in the other apps seems like a real pain at
the moment, without even considering dialogs!


Q. Why must you introduce yet another dependency for GNOME?
A. There's no reason this couldn't become part of gconf, or GTK, or
both. The bridging library should be seperate from gconf because gconf
only depends on glib, not gtk+, and there's no reason it shouldn't
stay that way, but it could be distributed with it potentially.


Q. What language are you writing this in?
A. I don't know. The prototype is in LISP, mainly because that made
parsing the input so easy, but no other part of GNOME depends on LISP
so that seems like a no-go. C for the library, C or Python for the
tool I suppose.


Q. What do you see the input format looking like?
A. I don't know. In my prototype of course it's LISP syntax, and I
like it but I don't know how 'gnome-y' that's considered. It certainly
needs to be simple, but expressive enough to be able to specify
settings dialogs in this sort of fashion:

  (header "File name parsing"
      (radio file-name-parse-mode "import/file-name-parsing/mode"
          (item "auto" "Guess information from filename")
          (item "filter" "Parse filename based on filter")
              (entry "import/file-name-parsing/filter")))

I'm sure it won't be too hard to come up with a nice syntax for the
input - please tell me if you have any thoughts.


Well thanks for reading if you got this far. Please share any opinions
you have about any part of this - the whole idea is to make life
easier for GNOME's army of application programmers, after all. I hope
I did the write thing by writing a big email to this list to discuss
my idea; I remember reading that it's good to discuss with the
organisation before formally proposing something, and there are still
lots of details to this that need fleshing out.

Thanks for any feedback
Sam Thursfield