GNOME.org
 

Re: gtk3 + python : lookup_widget


On Mon, August 20, 2012 9:16 am, Tristan Van Berkom wrote:

On Mon, Aug 20, 2012 at 2:32 PM, Patrick Shirkey
<pshirkey 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
<pshirkey 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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]