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
