[Glade-users] Autoglade



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


  




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