[Glade-users] Autoglade



On Wed, 2007-10-10 at 11:26 +0200, Diego Torres Milano wrote:
I've been working on a tool named autoglade that could be of help to
simplify application development using glade as the interface designer.
You can download autoglade from http://sourceforge.net/projects/autoglade.
A basic tutorial can be found in the wiki:
http://autoglade.wiki.sourceforge.net/autoglade+tutorial+-+first+steps
More to come.

This sounds really cool I think :)

I didn't take the time to go through the whole tutorial but
I think I get the idea, one little problem I see is that you
are using the widget's name property, I think with a little
collaboration we can setup the widget's name, auto, init and
optional parameters separately from the widget name.

Another thing, have you considered writing this code somehow
as a plugin to glade ? or maybe a plugin to anjuta that can
interface with the glade core ?

Excuse me here I'm going to run off on a tangent but you
might want to indulge with me ;-) ...

I wonder if this task could be done simply by defining objects 
that control what to do with entries and inputs, this way 
the objects could be added to the xml output of glade, the
resulting program would remain language independent and
you'd just need to have your library of "input controlling
objects" installed on the target system for it to run
(those object's parameters would replace the auto/init/extra
params you outlined and would contain the needed code
to do the appropriate things in the resulting runtime).

A simple similar idea thats been floating around that would be
useful and might also integrate well with your work is a
state machine plugin, basically you would have your GObject
based "state" objects with callbacks for state initializers,
cleanups and transitions and predefined links from one state
to another or from state back to superstate, or to substate
(all of these links interestingly could be setup using a GUI
that could be part of the state machine plugin and work seemlessly
with glade as if the state objects were actually widgets)

ofcourse, state transitions could also be triggered by widget
events or GtkAction activations, a simple state_machine_run_action()
could be setup as a callback for any GtkAction, the GtkAction
itself could have an attribute telling the state machine in which
state it should transition to.

Anyway, these are just a couple ideas that I think could
go a long way, I'm glad to see that people are doing work
towards really automating the application writing procedure :)

Cheers,
                         -Tristan






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