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 > > > _______________________________________________ Glade-devel maillist - [email protected] http://lists.ximian.com/mailman/listinfo/glade-devel
