[Glade-users] Autoglade

[Diego Torres Milano]

Tristan Van Berkom wrote:
> This sounds really cool I think :)
>   
Thanks for your comments.
> 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.
>   
Widget name is used because the file continues to be a valid glade file
and can be edited through glade.
It would be nice to have somewhere to enter arbitrary properties and
values. Then it would be added as
<property name="myprop">myval</property>
in the glade XML file.
> 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 ?
>   
Yes, this is an alternative. But don't forget that autoglade "is" the
application (or the module imported in some cases), not to be run as
part of the designer.
i.e: $ autoglade myapp.glade
Am I missing something ?
> 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).
>   
Yep, would be nice, but much harder to implement I think.
Currently, autoglade can invoke any method almost with any arbitrary
list of parameters (widget:auto:method:params).
> 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.
>   
Very interesting idea indeed.
> 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 :)
>   
autoglade target, at this stage, is to simplify (or to eliminate in some
cases) the development of simple applications, mainly to give a command
line tool a GUI.
One of the most representative examples is described in the tutorial
(rdc, a GUI for rdesktop).
In about 100 lines of bash scripting, plus the glade definition plus
autoglade you have a "real" application comparable in functionality with
Microsoft's client or tsclient (~ 5K lines of C code).
Any ideas are welcome.


Again, thanks for your comments.
> Cheers,
>                          -Tristan
>
>
>