After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 359661 - Command line interface for glade
Command line interface for glade
Status: RESOLVED OBSOLETE
Product: glade
Classification: Applications
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Glade 3 Maintainers
Glade 3 Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-10-04 18:15 UTC by Tristan Van Berkom
Modified: 2018-03-26 15:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Python Console example (15.05 KB, patch)
2006-10-09 21:16 UTC, Juan Pablo Ugarte
none Details | Review
GladeBinding patch (38.30 KB, patch)
2006-10-17 17:31 UTC, Juan Pablo Ugarte
none Details | Review
GladeBinding + glade_widget_adaptor_action_* (64.43 KB, patch)
2006-11-07 20:02 UTC, Juan Pablo Ugarte
none Details | Review
Bindings + Actions (86.70 KB, patch)
2006-11-16 20:06 UTC, Juan Pablo Ugarte
committed Details | Review

Description Tristan Van Berkom 2006-10-04 18:15:34 UTC
Because of glade's undo/redo architechture for user actions in 
the UI, it becomes stunningly easy to add a command line interface
to glade.

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
etc etc.

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.
Comment 1 Juan Pablo Ugarte 2006-10-09 21:16:01 UTC
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
Comment 2 Juan Pablo Ugarte 2006-10-17 17:31:56 UTC
Created attachment 74883 [details] [review]
GladeBinding patch

A more complete patch, the infrastructure (GladeBinding) its almost finished but the python plugin is not.
Comment 3 Juan Pablo Ugarte 2006-11-07 20:02:58 UTC
Created attachment 76170 [details] [review]
GladeBinding + glade_widget_adaptor_action_*
Comment 4 Juan Pablo Ugarte 2006-11-16 20:06:37 UTC
Created attachment 76727 [details] [review]
Bindings + Actions

pythontest.xml
<?xml version="1.0" encoding="UTF-8"?>
<glade-catalog name="pythontest" library="pythontest" domain="glade-3" depends="gtk+" language="python">
  <glade-widget-classes>
    <glade-widget-class title="TextView" name="TextView" generic-name="textview" adaptor="GladeTextViewAdaptor"/>
  </glade-widget-classes>
<glade-widget-group name="python" title="Python">
    <glade-widget-class-ref name="TextView"/>
</glade-widget-group>
</glade-catalog>

pythontest.py
import gtk
import gobject
import glade

class GladeTextViewAdaptor(glade.get_adaptor_for_type ('GtkHBox')):
	__gtype_name__ = 'GladeTextViewAdaptor'
	def __init__(self):
        	glade.GladeGtkHBoxAdaptor.__init__(self)
	def do_post_create(self, obj, reason):
		print "hola\n";
	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";
		return a;
	def do_get_children(self, container):
		a = glade.GladeGtkHBoxAdaptor.do_get_children(self, container);
		print "hola do_get_children\n";
		return a;

class TextView(gtk.HBox):
	__gtype_name__ = 'TextView'
	def __init__(self):
        	gtk.HBox.__init__(self)
Comment 5 Tristan Van Berkom 2006-12-05 17:59:59 UTC
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).
Comment 6 Vincent Geddes 2007-01-18 20:16:19 UTC
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.
Comment 7 Vincent Geddes 2007-01-18 23:49:10 UTC
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.
Comment 8 GNOME Infrastructure Team 2018-03-26 15:00:31 UTC
-- 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.