support for hand-editing .glade files (was Re: [Glade-devel] XUL and Glade - Some more ideas and links)



Hi list,

I have been experimenting with glade for a few months and I really like
what I see. I am particularly interested in experimenting with some
ideas I have about the use of glade, particularly given the desired move
away from generated code and towards run-time calls to the glade library
for apps. I hope to post some interesting ideas and proof-of-concept
code snippets in the near future (finals in a a few weeks)

This is my first post to the list and I'd like to make a quick point
about hand-editing .glade files, and why it shouldn't be an unsupported
operation.

On Thu, Apr 08, 2004 at 10:49:40AM -0400, Dan Winship wrote:
 
But there's no reason to hand code a glade file. If you want to code the
UI by hand, you can just write out the Gtk calls in C (or python or
whatever). The point of glade is just to be a graphical way of
generating a description of the layout of a bunch of Gtk widgets. If you
want it to be something other than that, then you're basically talking
about a completely new app/file format.

I can think of one very good reason for supporting hand-editing glade
files, and that is for overriding the UI of an application at
user-level.

For example, take Gaim. When I start a new conversation window with
someone, there's a row of formatting buttons just below the conversation
text area. I don't ever use it and wish I could turn it off.

If the UI was defined in a glade file, then there's the potential for a
user to take a copy of that file, comment out or rearrange the
components and have their copy used for the interface.

 From a user's perspective I would greatly appreciate such an ability. I
plan on writing a quick proof-of-concept app. Of course until more
mainstream apps use glade it won't prove very useful :)

Supporting hand-editing .glade files doesn't mean explicitly coding
anything - it simply means being aware that some people would have a
genuine use for hand-editing the XML and so its
verbosity/signal-to-noise ratio etc. are considerations.

-- 
Jonathan Dowland
http://jon.dowland.name/




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]