GNOME Bugzilla – Bug 359661
Command line interface for glade
Last modified: 2018-03-26 15:00:31 UTC
Because of glade's undo/redo architechture for user actions in
the UI, it becomes stunningly easy to add a command line interface
this could be implemented in two ways simultainiously:
a.) As an embedded "command shell" optionally available
in the UI proper
b.) As the command line interface of the glade exec itself
(could be used to modify glade files without ever using
the glade designer UI)
Pseudo-idea of what the commands might look like:
$ project dialog.glade
$ table1 add new(GtkButton)
$ table1 add clipboard(vscale3)
$ vscale3 set left-attach 2
This would be advantagous not only by providing a more flexable tool
in general - it would also (I think) force glade3 development to be strict
about commands, resulting in a better defined/less buggy end product overall.
Created attachment 74373 [details] [review]
Python Console example
This patch adds a python console to glade with a couple of commands
(undo, redo, project_new, project_open and project_save) and it just a test case.
My intention is to kill two bird in one shot being http://bugzilla.gnome.org/show_bug.cgi?id=359765 the other bird :)
The idea is to have a general interface in glade to load interpreters plugins,
so this interpreter plugin will take care to provide a console for glade and support for widgets written in that language :)
of course, this will only work for interpreted languages that provides a way to embed it's interpreter from C.
for compiled languages..... well i am clueless :D
Created attachment 74883 [details] [review]
A more complete patch, the infrastructure (GladeBinding) its almost finished but the python plugin is not.
Created attachment 76170 [details] [review]
GladeBinding + glade_widget_adaptor_action_*
Created attachment 76727 [details] [review]
Bindings + Actions
<?xml version="1.0" encoding="UTF-8"?>
<glade-catalog name="pythontest" library="pythontest" domain="glade-3" depends="gtk+" language="python">
<glade-widget-class title="TextView" name="TextView" generic-name="textview" adaptor="GladeTextViewAdaptor"/>
<glade-widget-group name="python" title="Python">
class GladeTextViewAdaptor(glade.get_adaptor_for_type ('GtkHBox')):
__gtype_name__ = 'GladeTextViewAdaptor'
def do_post_create(self, obj, reason):
def do_child_set_property(self, container, child, property_name, value):
glade.GladeGtkHBoxAdaptor.do_child_set_property(self,container, child, property_name, value);
print "hola do_child_set_property\n";
def do_child_get_property(self, container, child, property_name):
a = glade.GladeGtkHBoxAdaptor.do_child_get_property(self,container, child, property_name);
print "hola do_child_get_property\n";
def do_get_children(self, container):
a = glade.GladeGtkHBoxAdaptor.do_get_children(self, container);
print "hola do_get_children\n";
__gtype_name__ = 'TextView'
Just a note while I'm here, I think we are yanking the console
from 3.1 for now, doesnt make sence to combine this with the bindings
thing (command console should be a simplified language, something
proper to glade I guess).
Now that we are removing the console for the time being, it would be a good time to discuss the vision and goals of this console/command-line feature.
I don't see how this console would benefit users, even experienced ones. if they have to go to the console to do something, it means our graphical user interface is not doing it's job.
So, if users don't need the console, I don't see why it should be listed in the "View" menu, or available for users at all. Otherwise, to state clearly, it is just clutter.
If you guys really want to go ahead with this feature, that's alright. I just think it would be best that this feature is hidden or disabled by default, so that it is not available to users.
Just to clarify a bit...
In the above comment, I was speaking from a user's point of view. As a developer, I think a python console would be useful addition, at least as a debugging/testing tool.
Maybe we can set an environment variable, say 'GLADE_DEBUG_MODE', or a command-line option '--debug-mode'. When glade-3 is executed, it will determine whether to go into debug mode, and if so, then all our debugging tools will magically become available.
As for the language syntax for this console/command-line, how about simply using Python? Of course, we could create a few convenience Python classes to abstract over the complexity of the glade core api.
-- GitLab Migration Automatic Message --
This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glade/issues/7.