hi! Please also have a look at http://live.gnome.org/dconf. I think it could be more useful to work on this system as I am not sure we will have gconf in GNOME 3.0. It has the very nice feature to bind GObject-properties to dconf-keys which might make your work much easier. Regards, Johannes Am Donnerstag, den 19.03.2009, 01:16 +0000 schrieb Sam Thursfield: > 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 > _______________________________________________ > gnome-soc-list mailing list > gnome-soc-list gnome org > http://mail.gnome.org/mailman/listinfo/gnome-soc-list
Attachment:
signature.asc
Description: This is a digitally signed message part