Re: gtk3 + python : lookup_widget
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.
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
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
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
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 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
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 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. --
Re: gtk3 + python : lookup_widget
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.
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 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.
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
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk3 + python : lookup_widget
On Mon, Aug 20, 2012 at 1:59 PM, Tristan Van Berkom t...@gnome.org 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).
Correction, that didnt sound the way I intended, The original Glade was a great
tool for its time... what I mean to say is that back then our coding
practices were
very poor and we've made much improvements since then.
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.
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 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.
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
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk3 + python : lookup_widget
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.
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
