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 a class exposed a function that pulled in
the dynamic variable which is updated when the signal is sent/received.
But I can't figure out how to adjust widgets that are defined outside of
the class. For example in the code below how would the label be accessed
by the "MyWidget" class if it is defined in the PyApp class?
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__()
self.cur_value = 0
mywidget = MyWidget
label = Gtk.Label()
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 received much love in terms
of documentation efforts. Google is suprisingly sparse and I am running up
against quite a lot of gaps in terms of general tips and knowledge
compared to what I am used to.
Is it safe to say that there are not many people/projects who have adopted
gtk3 and python3.2 at the moment?
Patrick
>
> 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
