On Mon, August 20, 2012 9:16 am, Tristan Van Berkom wrote: > On Mon, Aug 20, 2012 at 2:32 PM, Patrick Shirkey > <pshir...@boosthardware.com> wrote: >> >> On Mon, August 20, 2012 6:59 am, Tristan Van Berkom wrote: >>> The "lookup_widget()" paradigm comes from a very old time when we >>> had very poor >>> tools and actually it originates from people using generated code from >>> the original Glade >>> tool (Glade versions 1 and 2). >>> >>> Ideally, as specially as you are using python, your application should >>> be modular. >>> >>> Perhaps you have an Application object which owns the main widgetry >>> created >>> by GtkBuilder after having parsed a Glade file initially, this is >>> different from a global >>> variable. >>> >>> Ideally you can use you object constructor as an entry point to load >>> your GtkBuilder >>> and assign the pointers you need later on to the members you define on >>> your >>> Application object. >>> >> >> In this case I am programatically creating the widget. >> >>> After that you simply have to pass your Application object to all the >>> callbacks >>> which originate from the user interface, giving you access to >>> everything >>> you >>> need when you need it. >>> >> >> This is the part I am having trouble with. >> >>> This concept can be further extended to be more modular, for instance >>> if >>> you have a preferences dialog/window... it can be defined by a separate >>> python class/GtkBuilder file and reused at will throughout your >>> program. >>> >> >> Thanks for your advice. I am planning to make this app as modular as >> possible but I am finding it hard to find a simple example that deals >> with >> my use case. > > Look at GTK+ sources: gtkdialog.c for example, or gtkmessagedialog.c even. > > Many composite widgets exist in GTK+, all of them follow the same > construct: > > o Create child widgets at initialization time and assign them to your > private data structure members which you have declared for them > (in other words, of course you hold a private instance member for > any composite children you need, like dialog->entry or dialog->label > or dialog->button etc). > > o Connect signals to, for example the button, when doing so.. > supply the dialog (self) instance as user data for the callback > > When the callback runs, it receives the dialog as user data, so > all of the internal composite children are always available in > those callbacks. > > In theory, in this 'dialog' example, normally all composite children > are private to the dialog and the dialog has some kind of output > or modifies your program state in some way, so no user of the > dialog should ever have to access those internal widget members > and the dialog can change internally without breaking any API. > > So in the context where "the dialog" handles a callback for any > signal originating from one of it's instance members, it always > has the dialog in context so it can always access any member > of the dialog. >
Do you know of a python example of this concept? I have the signals part under control and I am ok with python classes but I'm a bit murky on how to pass the commands back to the object. I have seen an examples where the class exposed a function that pulled in the dynamic variable which is updated when the signal is sent/received. i.e from gi.repository import Gtk, Gdk import cairo class MyWidget(Gtk.DrawingArea): def __init__(self, parent): self.par = parent super(MyWidget, self).__init__() self.connect("draw", self.expose) def expose(self, widget, event): self.variable = self.par.get_cur_value() label.text = variable class PyApp(Gtk.Window): def __init__(self): super(PyApp, self).__init__() mywidget = MyWidget self.cur_value = 0 def on_changed(self, widget): self.cur_value = widget.get_value() self.mywidget.queue_draw() def get_cur_value(self): return self.cur_value PyApp() Gtk.main() > How that translates to python script, I'm not exactly sure, but > I'm sure that it does indeed translate to python script ;-) > > In any case it's the coding practice which is relevant, not > the language binding which you use to achieve it > Thanks Tristan, I appreciate your detailed explanation. It seems to me that gtk3 and python3.2 hasn't yet received much love in terms of documentation efforts. I am happy to release the stripped down version of this code as an example project if anyone feels like helping me with the thinking part. FYI, I am currently building an almost complete rewrite of an application which is being migrated away from another platform so I have quite a lot to get through and getting my head around this part will be a major milestone :-) > > Cheers, > -Tristan > >> >> Basically I want to be able to modify the text in a label widget from a >> Entry or EventBox signal. >> >> I haven't found an example of that but if anyone knows of one that would >> be very helpful. >> >> >> -- >> Patrick Shirkey >> Boost Hardware Ltd >> >> >> >>> Cheers, >>> -Tristan >>> >>> On Mon, Aug 20, 2012 at 1:10 PM, Patrick Shirkey >>> <pshir...@boosthardware.com> wrote: >>>> Hi, >>>> >>>> I'm having a little trouble finding examples online of using the >>>> equivalent of lookup_widget() with gtk3 + python. >>>> >>>> For example in the following code what is the best way to modify the >>>> "message" label after the "commandline" callback is sent? >>>> >>>> Should I be using globals or a glade file or is there a way to >>>> dynamically >>>> lookup the "message" widget ? >>>> >>>> >>>> >>>> def create_gtkEntry(): >>>> >>>> commandline = Gtk.Entry() >>>> commandline.connect("activate", command_entered, 1) >>>> >>>> messages = Gtk.Label('TEST') >>>> >>>> >>>> >>>> def command_entered(self, *args): >>>> >>>> cmi_command = self.get_text() >>>> messages.set_text(cmi_command) >>>> print "command entered: ", args[0] >>>> >>>> >>>> >>>> -- >>>> Patrick Shirkey >>>> Boost Hardware Ltd >>>> _______________________________________________ >>>> gtk-app-devel-list mailing list >>>> gtk-app-devel-list@gnome.org >>>> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list >>> >> >> >> -- >> Patrick Shirkey >> Boost Hardware Ltd >> _______________________________________________ >> gtk-app-devel-list mailing list >> gtk-app-devel-list@gnome.org >> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > -- Patrick Shirkey Boost Hardware Ltd _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list