Re: [pygtk] PyGTK in the standard Library
On Friday 18 June 2004 8:59 am, Skip Montanaro wrote: > Matt> There have been several discussions on the list in the last few > Matt> months about trying to get PyGTK into the standard library, ... I would like to see PyGtk become part of the core Python distribution, however, this is an unrealistic goal in the short term. There is no way that PyGtk will be added to the next Python release. The alpha is going to be out in about a month and PyGtk would be much to big of an addition at this late date. It isn't clear that PyGtk is the "best" choice for replacing Tkinter. Unless PyGtk takes a substantial lead over PyQt and wxPython it is unlikely that Guido will approve the selection of one GUI toolkit over the others. Also, the core developers would not want such a big addition to the code that must be maintained in the official release. They will argue that PyGtk should evolve separately. There is a second approach that is realistic and probably also more workable. At PyCon we had a "Fat Python" BoF session. The goal was to build a super distribution of Python that would include many Python based pieces of software. I'd like to see PyGtk become a foundation piece for this distribution. The distribution will most likely also include wxPython and PyQt, but we should try to make PyGtk the preferred GUI platform for the future of Python. (A few months ago I saw a reference to a hack that allowed Qt and Gtk mainloops to be run in the same process. If it can be done, then I would expect Python to be the language with the best chance of making it possible to build apps that used widgets from both toolkits.) Discussion of the Fat Python distribution is on the python-grants mailing list at: http://starship.python.net/cgi-bin/mailman/listinfo/python-grants There are a also a couple wiki pages on python.org that are being used to organize the Fat Python distribution: http://www.python.org/cgi-bin/moinmoin/EducationalCd http://www.python.org/cgi-bin/moinmoin/EducationalCdLinux > > Matt> there where however a few buts... > > Matt> 1. Documentation - As a separate distribution from the core language the documentation shouldn't be a problem. We distribute the PyGtk FAQ, API and Tutorials as part of the Fat Python distribution. It doesn't need to be integrated into the core Python manual. > Matt> 2. Windows - The Fat Python distribution is KNOPPIX based release. We will be picking software that generally also is available on Windows, but for the first release the Fat Python will use Linux as the target platform. There are other distributions of Python that is targeting Windows. > Matt> 3.Idle - One of the other posts to this thread included someone volunteering to re-target Idle to PyGtk. I think this is a grand idea. I hope others will join this effort. > 4. Mac OSX - Is GTK available on Mac OSX without X11? Tkinter does have > the advantage that TkAqua is available for non-X environments. For now the Gtk 2.0 release is only available on the Mac using the X11 API. This is included with the latest OSX distribution, so it isn't a show-stopper. I talked with Tamer Fahmy at PyCon about getting Gtk 2.0 ported to Aqua. He was considering this as a summer project. I haven't talked with him since the conference to see if anything has happened on this task. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] PyGtk usage question
Kevin, I'm forwarding your message to the PythonGtk mailing list for an answer. James has been busy with work or school for the last several months and other PyGtk developers have stepped in to move the ball forward. Does anyone on the list know the stats for the number of downloads? I could be wrong, but I suspect this is not known because the downloads are from mirrored ftp sites. Also, are Please chime in with any information on applications written in Python or PyGtk that have widespread use. -- Forwarded Message -- Subject: Re: [marketing-python] most popular Python projects Date: Friday 12 March 2004 11:43 am From: "Kevin Altis" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: "Michael McLay" <[EMAIL PROTECTED]> Hi James, I'm trying to figure out the most popular Python projects and Michael McLay brought up PyGtk, which I had missed since it isn't hosted at SourceForge, where I did my initial data mining. Based on the number of subscribers to the mailing list, I would say it is quite popular. Do you have any download stats or other info that would help us gauge its popularity? I'm assuming the majority of users are on Linux. Do you have any evidence that people are adopting PyGTK because it is easier to build GUI apps on Linux than using C/C++? Thanks for the info, ka On Mar 12, 2004, at 8:31 AM, Michael McLay wrote: > On Wednesday 10 March 2004 5:58 pm, Kevin Altis wrote: >> This is a long message, if you reply, you'll probably want to >> the >> parts that don't pertain to your reply... >> >> If you can think of projects that qualify that would be great. It >> would >> probably be useful to track open source and commercial projects where >> Python is used as a scripting or glue language, even if the primary >> app is >> written in another language (e.g. CVSGui projects, Blender, Paint >> Shop Pro >> 8, etc.). >> >> wxPython >> >> http://sourceforge.net/project/stats/index.php? >> report=months&group_id=10718 >> >> Downloads are now consistently over 20K per month. There are 639 >> regular >> subscribers to wxPython-users, and around 275 digest subscribers. >> Robin >> Dunn is the only real developer of wxPython, though there are more on >> the >> wxWidgets side of things and many people like myself that don't do >> much on >> the core, but help out on the Python bits. Boa Constructor, the >> wxPython >> GUI builder gets a few thousand downloads per month. > > PyGtk > == > > PyGtk is available through ftp and mirrors which makes it difficult to > count > downloads. Also, since PyGtk is included with the Redhat and Mandrake > distributions, the count would not represent the size of the user > base. The > GUI toolkit is used extensively by Redhat for building the system > administration tools, so counting Redhat installations might be a good > starting number for the userbase. There are 503 regular subscribers > and 75 > digest subscribers. --- ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] IDLE-Gtk / Should PyGtk be proposed for the Python 2.4 release?
On Wednesday 03 March 2004 02:45 pm, Andy Sy wrote: > Michael McLay wrote: > > On Tuesday 02 March 2004 11:24 pm, Andy Sy wrote: > > AS> Michael McLay wrote almost a year ago: > >MM>The Tkinter library in the standard Linux distribution is getting > long in MM>the tooth. It is in the standard distribution because it > provides MM>cross-platform portability and has a rich text widget. The rate > of MM>improvement in the Tk toolkit has slowed to a trickle and the > marketshare MM>of Tk continues to shrink. Is it time to look for a > replacement that MM>would be a comfortable fit within the standard Python > library? MM> >MM> > > AS> Due to its maturity under Win32 and superbly friendly learning curve, > I am AS> also convinced that PyGtk is the way to go (over Tkinter, > wxPython, and AS> PyQt). > > > I'm glad to hear you agree with my thoughts on the subject. It won't be > > easy to convince the skeptical gatekeepers who control the standard > > library. The case for selecting PyGtk instead of wxPython will be > > particularly tough, given the large user base that GUI toolkit has > > attracted. This will require showing that PyGtk does everything wxPython > > can do and that PyGtk is a better fit in general. Your thoughts on how to > > do this would be appreciated. > > I've only had a cursory introduction to wxPython and admittedly it, > together with Qt, is more mature in both cross-platform support and > functionality than Gtk. However, I consider PyGtk's API be far more > elegant. I find Gtk code cleaner and easier to understand and as someone > who's tried to learn PyQt, PyGtk, Tkinter and wxPython, I got the furthest > with PyGtk (Tkinter is my second choice). This fact should help encourage > more newbies to try out GUI programming under Python. > > Furthermore, I feel that Gtk has the most easily understood and > well-factored codebase. Gtk sits on top of GDK, a small platform-dependent > core. Theoretically it is the only thing that needs to be reimplemented on > a new platform to get Gtk running on it. In fact, they have already have > Gtk running on DirectFB, meaning Gtk apps will not need X to run under > Linux. I agree. They have a minimal GDK layer and a minimal Gtk layer. That puts very little between Python and the bare metal. > > I've lost track of a very good email that described the characteristics > > of the PyGtk GUI library and why it looks like a natural component for > > the Python core library. I'd love to have that reference available. That > > email gave specific example of how Gtk fits with Python. From what I > > recall it contained some of the following observations: Gtk is a widely > > used, high quality GUI widget set. The implementation has been ported to > > a wide set of platforms. Gtk has a rich set of widgets. Gtk uses C as the > > implementation language. While Guido will not let GPL code into the > > Python core distribution, the LGPL is probably acceptable in the Python > > core library. While Tk, wxWindows, and Qt all have strengths, none of > > them are as good a fit to the Python core library as Gtk. At a technical > > level, the naming techniques used in Gtk seem to be very complementary to > > the hash table basis of the Python language. James' wrapping of Gtk 2.0 > > is a first class example of how to merge a large external library into a > > Python package. And finally, the combining PyGtk with the libglade module > > makes it very easy to get started building GUI based applications with > > Python. Eric Raymond's concern over the lack of good documentation for > > PyGtk is being addressed, but it would be much better if a good book on > > GUI programming with PyGtk and Python were available. > >AS> I just remembered something though. How are you going to unbundle >AS> Tkinter from the Python distribution without also dropping IDLE > (which AS> I'm sure most of us would not want to do without)? I'm not suggesting this be done quickly. I know it is code bloat to have two GUI toolkits in the library, but only one would be used per process, so there would be minimal memory consumption at run time. Also, for many situations, the GTk libraries would already be loaded in as libraries, so the overhead of the Python importing of the library would probably be minimal. Tkinter is the odd man out in this situation. It isn't used for the Gnome window manager, the Mozilla browser, or any other major application. > > I'm not proposing dropping Tkinter. I'm suggesting that PyGtk be added as > > a second, and preferred, GUI for the standard Pytho
Re: [pygtk] TreeView column expanding
On Tuesday 30 September 2003 01:05 pm, Theodore A. Roth wrote:
> Hi,
>
> I have built up an app using glade-2 and it loads and runs fine using
> gtk.glade. One of my widgets is a TreeView using a ListStore and I'm
> having a bit of trouble figuring out how to make all the columns
> # the model and the BOOLEAN in column 1.
> col = gtk.TreeViewColumn (hdrs[i], renderers[i],
> text=i+2, editable=1)
> # This is obviously wrong.
> col.pack_start (renderers[i], expand=gtk.TRUE)
You are inserting the renderer and several properties into the column using
the column constructor. Later you are using pack_start to reinsert the same
renderer into the column. The pack_start method is to be used to insert
multiple renderers into the same column, for instance, if you want to insert
an icon and some text into the same cell.
The following works as a replacment for what you are trying to do
col = gtk.TreeViewColumn (hdrs[i])
col.pack_start (r, expand=gtk.FALSE)
col.add_attribute(r, 'text', i)
renderers[i].set_property ('editable', 1)
The attached example is a works.
import gtk, gtk.glade, gobject
class ListView:
def __init__ (self, view, model, hdrs, renderers, sel_cb):
self.view = view
view.set_model (model)
view.set_headers_visible (gtk.TRUE)
for i in xrange (len (hdrs)):
# Set text to i+2 to skip over the PYOBJECT in column 0 of
# the model and the BOOLEAN in column 1.
col = gtk.TreeViewColumn (hdrs[i],)# renderers[i],text=i)
#text=i+2, editable=1)
col.set_resizable (gtk.TRUE)
col.set_alignment (0.50)
view.append_column (col)
# This is obviously wrong.
r = renderers[i]
col.pack_start (r, expand=gtk.FALSE)
col.add_attribute(r, 'text', i)
renderers[i].set_property ('editable', 1)
renderers[i].set_property ('xalign', 0.50)
#renderers[i].set_property ('font-desc', font_fixed)
view.show()
sel = view.get_selection ()
sel.set_mode ('single')
sel.connect ('changed', sel_cb)
types = [ gobject.TYPE_STRING ] * 10
renderers = [ gtk.CellRendererText () ] * 10
hdrs = [ 'Address', 'Name',
'Bit 7', 'Bit 6', 'Bit 5', 'Bit 4',
'Bit 3', 'Bit 2', 'Bit 1', 'Bit 0' ]
class App:
def __init__(self):
self.gui = gtk.glade.XML("project8.glade")
dic = {"on_treeview1_select_cursor_row":
self.on_treeview1_select_cursor_row
}
self.gui.signal_autoconnect(dic)
def setup_treeview (self, widget_name, types, hdrs, renderers, sel_cb):
self.model = model = gtk.ListStore (*types)
view2 = self.gui.get_widget (widget_name)
view = ListView (view2, model, hdrs, renderers, sel_cb)
return view
def insert_row (self, data):
"""Also adds the python object, 'data' to the store in the first
column. Set the value of the boolean to TRUE so we can edit the
cells later.
"""
iter = self.model.append()
self.model.set(iter,0,'a',1,'b',2,'c')
##args = [0, data, 1, gtk.TRUE]
##for i in range (len (data)):
##args.extend ([i+2, data[i]])
## print "args", args
##self.model.set (iter, *args)
def on_treeview1_select_cursor_row(self, *obj):
print "selected", obj
a = App()
print a.setup_treeview('treeview1',types,hdrs,renderers,
a.on_treeview1_select_cursor_row)
a.insert_row(['a','b','c'])
a.insert_row(['a','b','c'])
gtk.main()
project8.glade
Description: application/glade
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] check button callbacks
On Monday 29 September 2003 08:51 am, liquid wrote:
> Hi guys
> I'm really a newbie of python and pygtk, so sorry if my question is... too
> dumb (o:
Welcome to Python. No question is too dumb from a newbie:-) There mailing
lists specifically for these types of questions. As was mentioned earlier,
reviewing the Python tutorial is a very helpful first step.
http://www.python.org/doc/current/tut/tut.html
Also, the http://www.python.org/topics/learn/ page on the Python website has
lots of good references for beginners. You might also direct basic Python
questions to the Tutor mailing list.
http://mail.python.org/mailman/listinfo/tutor
Please browse through the archives to see if the questions have already been
asked. Also remember the PyGtk FAQ. It answers many basic questions.
http://www.async.com.br/faq/pygtk/
> I'm tring to understand how to set a value to a variable, with check
> buttons. I will post here what I'm doing...or better...tring to do.
> when I check the button I would like that the variable a will be set as 3
> and when is unchecked to 4, this of course doesn't work, when I press the
> other button to see the results I will get as output always the number 2,
> as set at the beginning.
> #!/usr/bin/env python
> import gtk
> a=2
> class try:
The example as written should generate a SyntaxError because the class name
'try' is a reserved keyword.
[EMAIL PROTECTED] src]$ python
Python 2.3 (#2, Aug 15 2003, 16:34:02)
[GCC 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class try:
File "", line 1
class try:
^
SyntaxError: invalid syntax
>>>
The following corrections to your example fix the problem with 'a' not being
updated
#!/usr/bin/env python
import gtk
class foo:
def __init__(self):
#As was suggested, move 'a' to inside the class as an instance variable.
self.a=2
#Python searches the instance namespace first, then the class namespace, and
#finally the global namespace to resolve a name.
self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
self.window.set_title("Check Button")
self.window.connect("delete_event", self.delete_event)
self.window.set_border_width(20)
table = gtk.Table(2, 2, gtk.TRUE)
self.window.add(table)
button = gtk.CheckButton("check button 1")
button.connect("toggled", self.callback, "check button 1")
table.attach(button, 1, 2, 0, 1)
button.show()
button=gtk.Button("press to try")
button.connect("clicked", self.call1, "cool button")
table.attach(button, 0, 1, 0, 1)
button.show()
table.show()
self.window.show()
def callback(self, widget, data=None):
# in you example the value 'a' was a local variable to the 'callback' method.
# Local variables are only in scope inside the method. The name
# local name and it's value disapears when the method returns.
# The following assignment converts the number to a string. This
# means that when you are printing out the initial value of 'a' it is
# printing a number and subsequent statements are printing a string
self.a = "%s" % ((3, 4)[widget.get_active()])
#Use the following statement to always assign an integer to self.a
#self.a = (3, 4)[widget.get_active()]
def call1(self, widget, data=None):
# The 'a' referenced in the print statement of your example was resolving to
# the global 'a', which had been assigned the value of 2. The reference to
# 'a' could not see the use of 'a' in the 'callback' method because that name
# went out of scope when the program returned from the method.
# The following print statement show what type of value is being printed
print "The value is:", self.a,'but it really is:', repr(self.a), type(self.a)
def delete_event(self, widget, event, data=None):
gtk.main_quit()
return gtk.FALSE
def main():
gtk.main()
return 0
if __name__ =="__main__":
foo()
main()
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] check button callbacks
On Monday 29 September 2003 08:51 am, liquid wrote:
> Hi guys
> I'm really a newbie of python and pygtk, so sorry if my question is... too
> dumb (o:
Welcome to Python. No question is too dumb from a newbie:-) There mailing
lists specifically for these types of questions. As was mentioned earlier,
reviewing the Python tutorial is a very helpful first step.
http://www.python.org/doc/current/tut/tut.html
Also, the http://www.python.org/topics/learn/ page on the Python website has
lots of good references for beginners. You might also direct basic Python
questions to the Tutor mailing list.
http://mail.python.org/mailman/listinfo/tutor
Please browse through the archives to see if the questions have already been
asked. Also remember the PyGtk FAQ. It answers many basic questions.
http://www.async.com.br/faq/pygtk/
> I'm tring to understand how to set a value to a variable, with check
> buttons. I will post here what I'm doing...or better...tring to do.
> when I check the button I would like that the variable a will be set as 3
> and when is unchecked to 4, this of course doesn't work, when I press the
> other button to see the results I will get as output always the number 2,
> as set at the beginning.
> #!/usr/bin/env python
> import gtk
> a=2
> class try:
The example as written should generate a SyntaxError because the class name
'try' is a reserved keyword.
[EMAIL PROTECTED] src]$ python
Python 2.3 (#2, Aug 15 2003, 16:34:02)
[GCC 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class try:
File "", line 1
class try:
^
SyntaxError: invalid syntax
>>>
The following corrections to your example fix the problem with 'a' not being
updated
#!/usr/bin/env python
import gtk
class foo:
def __init__(self):
#As was suggested, move 'a' to inside the class as an instance variable.
self.a=2
#Python searches the instance namespace first, then the class namespace, and
#finally the global namespace to resolve a name.
self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
self.window.set_title("Check Button")
self.window.connect("delete_event", self.delete_event)
self.window.set_border_width(20)
table = gtk.Table(2, 2, gtk.TRUE)
self.window.add(table)
button = gtk.CheckButton("check button 1")
button.connect("toggled", self.callback, "check button 1")
table.attach(button, 1, 2, 0, 1)
button.show()
button=gtk.Button("press to try")
button.connect("clicked", self.call1, "cool button")
table.attach(button, 0, 1, 0, 1)
button.show()
table.show()
self.window.show()
def callback(self, widget, data=None):
# in you example the value 'a' was a local variable to the 'callback' method.
# Local variables are only in scope inside the method. The name
# local name and it's value disapears when the method returns.
# The following assignment converts the number to a string. This
# means that when you are printing out the initial value of 'a' it is
# printing a number and subsequent statements are printing a string
self.a = "%s" % ((3, 4)[widget.get_active()])
#Use the following statement to always assign an integer to self.a
#self.a = (3, 4)[widget.get_active()]
def call1(self, widget, data=None):
# The 'a' referenced in the print statement of your example was resolving to
# the global 'a', which had been assigned the value of 2. The reference to
# 'a' could not see the use of 'a' in the 'callback' method because that name
# went out of scope when the program returned from the method.
# The following print statement show what type of value is being printed
print "The value is:", self.a,'but it really is:', repr(self.a), type(self.a)
def delete_event(self, widget, event, data=None):
gtk.main_quit()
return gtk.FALSE
def main():
gtk.main()
return 0
if __name__ =="__main__":
foo()
main()
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] TreeView column expanding
On Tuesday 30 September 2003 01:05 pm, Theodore A. Roth wrote:
> Hi,
>
> I have built up an app using glade-2 and it loads and runs fine using
> gtk.glade. One of my widgets is a TreeView using a ListStore and I'm
> having a bit of trouble figuring out how to make all the columns
> # the model and the BOOLEAN in column 1.
> col = gtk.TreeViewColumn (hdrs[i], renderers[i],
> text=i+2, editable=1)
> # This is obviously wrong.
> col.pack_start (renderers[i], expand=gtk.TRUE)
You are inserting the renderer and several properties into the column using
the column constructor. Later you are using pack_start to reinsert the same
renderer into the column. The pack_start method is to be used to insert
multiple renderers into the same column, for instance, if you want to insert
an icon and some text into the same cell.
The following works as a replacment for what you are trying to do
col = gtk.TreeViewColumn (hdrs[i])
col.pack_start (r, expand=gtk.FALSE)
col.add_attribute(r, 'text', i)
renderers[i].set_property ('editable', 1)
The attached example is a works.
import gtk, gtk.glade, gobject
class ListView:
def __init__ (self, view, model, hdrs, renderers, sel_cb):
self.view = view
view.set_model (model)
view.set_headers_visible (gtk.TRUE)
for i in xrange (len (hdrs)):
# Set text to i+2 to skip over the PYOBJECT in column 0 of
# the model and the BOOLEAN in column 1.
col = gtk.TreeViewColumn (hdrs[i],)# renderers[i],text=i)
#text=i+2, editable=1)
col.set_resizable (gtk.TRUE)
col.set_alignment (0.50)
view.append_column (col)
# This is obviously wrong.
r = renderers[i]
col.pack_start (r, expand=gtk.FALSE)
col.add_attribute(r, 'text', i)
renderers[i].set_property ('editable', 1)
renderers[i].set_property ('xalign', 0.50)
#renderers[i].set_property ('font-desc', font_fixed)
view.show()
sel = view.get_selection ()
sel.set_mode ('single')
sel.connect ('changed', sel_cb)
types = [ gobject.TYPE_STRING ] * 10
renderers = [ gtk.CellRendererText () ] * 10
hdrs = [ 'Address', 'Name',
'Bit 7', 'Bit 6', 'Bit 5', 'Bit 4',
'Bit 3', 'Bit 2', 'Bit 1', 'Bit 0' ]
class App:
def __init__(self):
self.gui = gtk.glade.XML("project8.glade")
dic = {"on_treeview1_select_cursor_row":
self.on_treeview1_select_cursor_row
}
self.gui.signal_autoconnect(dic)
def setup_treeview (self, widget_name, types, hdrs, renderers, sel_cb):
self.model = model = gtk.ListStore (*types)
view2 = self.gui.get_widget (widget_name)
view = ListView (view2, model, hdrs, renderers, sel_cb)
return view
def insert_row (self, data):
"""Also adds the python object, 'data' to the store in the first
column. Set the value of the boolean to TRUE so we can edit the
cells later.
"""
iter = self.model.append()
self.model.set(iter,0,'a',1,'b',2,'c')
##args = [0, data, 1, gtk.TRUE]
##for i in range (len (data)):
##args.extend ([i+2, data[i]])
## print "args", args
##self.model.set (iter, *args)
def on_treeview1_select_cursor_row(self, *obj):
print "selected", obj
a = App()
print a.setup_treeview('treeview1',types,hdrs,renderers,
a.on_treeview1_select_cursor_row)
a.insert_row(['a','b','c'])
a.insert_row(['a','b','c'])
gtk.main()
project8.glade
Description: application/glade
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Warnings issued by get_property
On Monday 08 September 2003 06:55 pm, Christian Reis wrote:
> On Fri, Sep 05, 2003 at 11:57:22AM +0800, James Henstridge wrote:
> > On 4/09/2003 8:00 AM, Michael McLay wrote:
> > >I received an odd warning when testing the use of get_property.
> > > Accessing the 'child' property for a button returns the message:
> > >
> > >(:2640): Gtk-WARNING **: ../../gtk/gtkcontainer.c:874: invalid property
> > > id 3 for "child" of type `GParamObject' in `GtkButton'
> > >
> > >>>>c.get_property('child')
> > >
> > >(:2640): Gtk-WARNING **: ../../gtk/gtkcontainer.c:874: invalid property
> > > id 3 for "child" of type `GParamObject' in `GtkButton'
> > >
> > >Here's the code that caused this to happen.
> >
> > the GtkContainer::child property is write-only, which is why you get
> > weird results when trying to read it. The other cases are most likely
> > similar.
>
> Would it be possible to raise a proper exception in this case explaining
> it is write-only?
I'm curious, what is the purpose of a write-only property? Under what
circumstances would it be advantagous to not be able to do introspection on a
property? Even if this does raise a special "Write-Only" exception, it still
requires a special work around for code that is looking to probe the state of
the object.
Thanks
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Warnings issued by get_property
I received an odd warning when testing the use of get_property. Accessing the
'child' property for a button returns the message:
(:2640): Gtk-WARNING **: ../../gtk/gtkcontainer.c:874: invalid property id 3
for "child" of type `GParamObject' in `GtkButton'
>>> c.get_property('child')
(:2640): Gtk-WARNING **: ../../gtk/gtkcontainer.c:874: invalid property id 3
for "child" of type `GParamObject' in `GtkButton'
Here's the code that caused this to happen.
>>> b = gtk.Button()
>>> for x in gobject.list_properties(b):
... print x.name, c.get_property(x.name)
...
user-data None
name sxx
parent None
width-request -1
height-request -1
visible False
sensitive True
app-paintable False
can-focus True
has-focus False
is-focus False
can-default False
has-default False
receives-default True
composite-child False
style
events 0
extension-events 0
border-width 0
resize-mode 0
(:2640): Gtk-WARNING **: ../../gtk/gtkcontainer.c:874: invalid property id 3
for "child" of type `GParamObject' in `GtkButton'
child None
label None
relief 0
use-underline False
use-stock False
I tried adding a child object, which changed the return value for c.child to
the value of the label that was added to the button.
>>> c.add(l)
>>> c.child
But this didn't fix the complaint about accessing 'child' using get_property
>>> c.get_property('child')
(:2640): Gtk-WARNING **: ../../gtk/gtkcontainer.c:874: invalid property id 3
for "child" of type `GParamObject' in `GtkButton'
A warning also occurs when trying to access the 'pattern' property for a
gtk.Label:
>>> for x in gobject.list_properties(l):
... print x.name, l.get_property(x.name)
...
user-data None
name
parent None
width-request -1
height-request -1
visible False
sensitive True
app-paintable False
can-focus False
has-focus False
is-focus False
can-default False
has-default False
receives-default False
composite-child False
style
events 0
extension-events 0
xalign 0.5
yalign 0.5
xpad 0
ypad 0
label
attributes None
use-markup False
use-underline False
justify 0
(:2640): Gtk-WARNING **: ../../gtk/gtklabel.c:569: invalid property id 6 for
"pattern" of type `GParamString' in `GtkLabel'
pattern None
wrap False
selectable False
mnemonic-keyval 16777215
mnemonic-widget None
cursor-position 0
selection-bound 0
>>>
Setting l.pattern to a string value did not make the message go away
>>> l.pattern = "xxx"
>>> l.pattern
'xxx'
>>> l.set_property('pattern',"foo")
>>> l.pattern
'xxx'
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Should PyGtk be proposed for the Python 2.4 release?
On Tuesday 25 March 2003 11:25 pm, Rob Brown-Bayliss wrote: > > shrink. Is it time to look for a replacement that would be a comfortable > > fit within the standard Python library? > > Is it really a good idea? Python is already distributed with Tkinter, and it gets used as the standard cross platform GUI toolkit. The addition of PyGtk will give the standard distribution a more viable cross platform capability. > It makes everything larger, and for what benefit? Having looked at the > wxWindows and gtk+ for windows web sites I dont see a benefit. any app > written on windows using either toolkit will probably follow the windows > look and feel, menus and icons etc, one written in linux will probably > follow the gnome look (based on wx and pygtk using gtk+) Using the cross platform GUI is optional it will still be possible to use the platform specific toolkits. Authors of reusable GUI components that canl run on any platform will benefit from having a standard GUI API. > These are great if your looking specifically for a cross platform app, > but if you are not then why not just use the toolkit for your chosen > platform? It's more likely to "fit in" that way. The proposal is to pick one of the three candidates for the task of being the new standard cross platform toolkit. If you are not writing a cross platform application the availability of PyGtk will have no effect on your application. > Leave python as it is and let distributors choose to add one or more gui > kits to it. Why leave it to the distributors? That will result in one distribution inclluding PyGtk, another using wxPython, and a third using PyQt. The point of selecting a new standard for cross platform interoperability is to make it easier to use Python. The applications targeted to proprietary platforms probably won't use any of these choices and they are free to use any alternative package in their applications. Is it bloat in the standard library that is of concern? A --without-pygtk flag could be added to the command line when building Python for a platform, or you could simply delete the package. Perhaps there should be another flag that can declare --no-GUI-packages. Of course it is always possible to simply to delete modules and packages that are not needed. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Should PyGtk be proposed for the Python 2.4 release?
On Monday 24 March 2003 09:34 pm, Greg Ward wrote:
> On 23 March 2003, Michael McLay said:
> > Of the big three; PyGtk, wxPython, and PyQT; I believe the PyGtk package
> > is probably the closest match to the Python coding philosophy and style.
>
> If I had to pick one of those, right now I'd pick PyGtk. (Although
> first I should spend a weekend immersed in (Py)Qt, because I've never
> used it and I keep hearing good things about it.) I played with
> wxPython for a few days recently, and I think I was expecting something
> a little higher-level. Since wxWindows and GTK seem to have pretty much
> the same level of abstraction, then so do wxPython and PyGtk. And I had
> an easier time getting things to work with PyGtk than with wxPython, so
> that's what I'm using now.
>
> wx{Windows,Python}'s similarity to MFC would probably be as much a point
> against it in certain circles (ie. Unix/Linux geeks) as it is a point in
> favour in other circles. Personally, I think Gtk's model is just
> insanely sensible, and PyGtk reflects it very well. wxWindows seemed a
> bit more awkward, and wxPython inherits some of that awkwardness.
>
> As for documentation, wxPython and PyGtk both, well, err, umm, suck.
> Let's not mince words. wxPython is a tad better, but not enough.
> However, Gtk has really quite good docs -- much better than wxWindows
> IHMO -- and translating on-the-fly to Python is not too much work.
>
> Disclaimer: all of the above is based on about two days' playing with
> wxPython, and 3-4 days playing with PyGtk. I am by no means an expert
> here, just a competent hacker dipping his toes in the GUI pool for the
> first time in many years. (Last time I did this was with Perl/Tk 6-7
> years ago.)
Thanks for your impressions of the candidate GUIs. I think your observations
are apt, despite the minimal time spent with each GUI. I say this because the
initial impression of working with the GUI API is important to attracting new
users. The interface needs to be intuitive and practical from day one. If
you, as an experienced Python programmer, find PyGtk "insanely sensible" then
I'd say that is a good reason for it to be selected to be part of the Python
distribution. Python is all about being sensible and PyGtk seems to be a good
fit in this regard.
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Should PyGtk be proposed for the Python 2.4 release?
On Monday 24 March 2003 10:43 am, James Henstridge wrote: > I don't know. PyGTK is a fairly large extension compared to most other > extensions distributed with Python (mostly due to the size of the GTK > API). I don't know what the Python developers would think of something > of its size. > > The other reservation I have is release frequency. PyGTK is still being > improved with each release, and those releases are much closer together > than Python releases. PyGtk would continue to be develop independent of Python, like PyXML and IDLE have parallel development tracks. The point would be do declare an endorsed winner in the standard GUI for Python and bundle the GUI with the standard distribution. > From a quick look at the anygui documentation, it doesn't seem to be a > very interesting GUI programming API. It looks like it uses absolute > positioning for pretty much everything, which is a big step backwards > compared to the geometry management of GTK, Qt and Tk, etc. Fair enough. I only brought up anygui because it is an interesting attempt to unify the GUI across by supporting all possible GUI interfaces. It was mentioned more to acknowledge the effort than to endorse the API. I'd primarily interested in having a single tight API become the Python standard GUI. Of the big three, I think PyGtk is most Pythonic, which is what I stated in the following paragraph. > >Of the big three; PyGtk, wxPython, and PyQT; I believe the PyGtk package > > is probably the closest match to the Python coding philosophy and style. > > It is also closer to the Tkinter programming model. PyGtk is written in C > > and the widget library seems to be a superset of Tkinter. I also think > > James has done an excellent job of making use of the Python 2.2 API for > > creating classes. The library has a very natural Python feel to it. Would > > others on this list care to comment on this assertion? The case for > > adding a new GUI to the standard library will need to address the sticky > > point of why the GUI toolkit is appropriate for the standard Python > > library. > > The gtk-osx project you mention here is not really relevant to PyGTK in > its current form. Since the developers main aim was to have a toolkit > to run filmgimp on OS X, they decided to port GTK 1.2. This means that > the port is can not be used to port any modern GTK application to OS X > (remember that GTK 1.2 has now been obsoleted by two stable series > now). It also means that gtk-osx can't take advantage of the backend > separation work that was done during GTK 2.0 and 2.2 development in > order to make ports easier. This is my opinion, of course. > > As far as the gtk-wimp theme engine, it would be pretty easy to do a GTK > distribution for windows that had it set as the default theme engine. > It is really just a packaging issue. Thanks for clearing this up for me. My point was to identify some process in which PyGtk could be made available with a native theme for all three of the major platforms: X Windows, Windows, and Mac OS X. As I said in an earlier posting, it will be a requirement to identify maintainer for the three platforms before standardizing on PyGtk would even be considered in the standard Python distribution. I think it is important to establish a robust standard GUI API for Python. I don't really care which one is selected. PyGtk seems to be the best candidate. We need to pick one and move on with it. Back at the Python Conference in Menlo Park in 1995 we had a BOF to discuss standardizing the GUI for Python. Guido said something to the effect of "Let many flowers grow in the garden". That was 8 years ago. It's time to weed the garden. Python is being hurt by not having a stronger default GUI included in the standard distribution. > >I'd like to get some feedback from this list before brining this idea up > > in the general python mailing list. If it is shot down here, where I > > would expect some support for selecting PyGtk, there is no need to take > > up the bandwidth of the larger forum. > > My main concern would be linking of the release schedules. It isn't > clear that linked release schedules would benefit either pygtk or python. The releases do not have to be linked, but each Python release should include the most up to date PyGtk release so the end users have something better than Tkinter to count on being included in the distribution. To make this happen we need better documentation and designated maintainers for the three major platforms. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Should PyGtk be proposed for the Python 2.4 release?
On Monday 24 March 2003 09:34 pm, Greg Ward wrote:
> On 23 March 2003, Michael McLay said:
> > Of the big three; PyGtk, wxPython, and PyQT; I believe the PyGtk package
> > is probably the closest match to the Python coding philosophy and style.
>
> If I had to pick one of those, right now I'd pick PyGtk. (Although
> first I should spend a weekend immersed in (Py)Qt, because I've never
> used it and I keep hearing good things about it.) I played with
> wxPython for a few days recently, and I think I was expecting something
> a little higher-level. Since wxWindows and GTK seem to have pretty much
> the same level of abstraction, then so do wxPython and PyGtk. And I had
> an easier time getting things to work with PyGtk than with wxPython, so
> that's what I'm using now.
>
> wx{Windows,Python}'s similarity to MFC would probably be as much a point
> against it in certain circles (ie. Unix/Linux geeks) as it is a point in
> favour in other circles. Personally, I think Gtk's model is just
> insanely sensible, and PyGtk reflects it very well. wxWindows seemed a
> bit more awkward, and wxPython inherits some of that awkwardness.
>
> As for documentation, wxPython and PyGtk both, well, err, umm, suck.
> Let's not mince words. wxPython is a tad better, but not enough.
> However, Gtk has really quite good docs -- much better than wxWindows
> IHMO -- and translating on-the-fly to Python is not too much work.
>
> Disclaimer: all of the above is based on about two days' playing with
> wxPython, and 3-4 days playing with PyGtk. I am by no means an expert
> here, just a competent hacker dipping his toes in the GUI pool for the
> first time in many years. (Last time I did this was with Perl/Tk 6-7
> years ago.)
Thanks for your impressions of the candidate GUIs. I think your observations
are apt, despite the minimal time spent with each GUI. I say this because the
initial impression of working with the GUI API is important to attracting new
users. The interface needs to be intuitive and practical from day one. If
you, as an experienced Python programmer, find PyGtk "insanely sensible" then
I'd say that is a good reason for it to be selected to be part of the Python
distribution. Python is all about being sensible and PyGtk seems to be a good
fit in this regard.
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Should PyGtk be proposed for the Python 2.4 release?
On Monday 24 March 2003 10:43 am, James Henstridge wrote: > I don't know. PyGTK is a fairly large extension compared to most other > extensions distributed with Python (mostly due to the size of the GTK > API). I don't know what the Python developers would think of something > of its size. > > The other reservation I have is release frequency. PyGTK is still being > improved with each release, and those releases are much closer together > than Python releases. I envision having PyGtk continue to develop independent of Python, like PyXML and IDLE have parallel development tracks. The point would be do declare an enndorsed winner in the standard GUI for Python and bundle the GUI with the standard distribution. > From a quick look at the anygui documentation, it doesn't seem to be a > very interesting GUI programming API. It looks like it uses absolute > positioning for pretty much everything, which is a big step backwards > compared to the geometry management of GTK, Qt and Tk, etc. Fair enough. I only brought up anygui because it is an interesting attempt to unify the GUI across by supporting all possible GUI interfaces. It was mentioned more to acknowledge the effort than to endorse the API. I'd primarily interested in having a single tight API become the Python standard GUI. Of the big three, I think PyGtk is most Pythonic, which is what I stated in the following paragraph. > >Of the big three; PyGtk, wxPython, and PyQT; I believe the PyGtk package > > is probably the closest match to the Python coding philosophy and style. > > It is also closer to the Tkinter programming model. PyGtk is written in C > > and the widget library seems to be a superset of Tkinter. I also think > > James has done an excellent job of making use of the Python 2.2 API for > > creating classes. The library has a very natural Python feel to it. Would > > others on this list care to comment on this assertion? The case for > > adding a new GUI to the standard library will need to address the sticky > > point of why the GUI toolkit is appropriate for the standard Python > > library. > The gtk-osx project you mention here is not really relevant to PyGTK in > its current form. Since the developers main aim was to have a toolkit > to run filmgimp on OS X, they decided to port GTK 1.2. This means that > the port is can not be used to port any modern GTK application to OS X > (remember that GTK 1.2 has now been obsoleted by two stable series > now). It also means that gtk-osx can't take advantage of the backend > separation work that was done during GTK 2.0 and 2.2 development in > order to make ports easier. This is my opinion, of course. > > As far as the gtk-wimp theme engine, it would be pretty easy to do a GTK > distribution for windows that had it set as the default theme engine. > It is really just a packaging issue. Thanks for clearing this up for me. My point was to identify some process in which PyGtk could be made available with a native theme for all three of the major platforms: X Windows, Windows, and Mac OS X. As I said in an earlier posting, it will be a requirement to identify maintainer for the three platforms before standardizing on PyGtk would even be considered in the standard Python distribution. I think it is important to establish a robust standard GUI API for Python. I don't really care which one is selected. PyGtk seems to be the best candidate. We need to pick one and move on with it. Back at the Python Conference in Menlo Park in 1995 we had a BOF to discuss standardizing the GUI for Python. Guido said something to the effect of "Let many flowers grow in the garden". That was 8 years ago. It's time to weed the garden. Python is being hurt by not having a stronger default GUI included in the standard distribution. > >I'd like to get some feedback from this list before brining this idea up > > in the general python mailing list. If it is shot down here, where I > > would expect some support for selecting PyGtk, there is no need to take > > up the bandwidth of the larger forum. > > My main concern would be linking of the release schedules. It isn't > clear that linked release schedules would benefit either pygtk or python. The releases do not have to be linked, but each Python release should include the most up to date PyGtk release so the end users have something better than Tkinter to count on being included in the distribution. To make this happen we need better documentation and designated maintainers for the three major platforms. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Should PyGtk be proposed for the Python 2.4 release?
On Monday 24 March 2003 02:52 am, Eric S. Raymond wrote: > Michael McLay <[EMAIL PROTECTED]>: > > Of the big three; PyGtk, wxPython, and PyQT; I believe the PyGtk > > package is probably the closest match to the Python coding > > philosophy and style. It is also closer to the Tkinter programming > > model. PyGtk is written in C and the widget library seems to be a > > superset of Tkinter. I also think James has done an excellent job of > > making use of the Python 2.2 API for creating classes. The library > > has a very natural Python feel to it. Would others on this list care > > to comment on this assertion? > > I largely agree. But... > > The biggest weakness of PyGTK at this moment is woefully inadequate > documentation. The API documentation is simply not up to the standard of > detail and clarity expected in a Python standard library. > > The most useful thing anyone could do towards this proposal would > be to fix that. I agree it will be very helpful to have documentation on PyGtk included in the standard Python distribution documentation. Having books available for PyGtk will also improve the utility of the new package. I would expect book publishers would start working on a PyGtk book if they knew it was going to become part of the standard Python distribution, so a commitment to add PyGtk to the 2.4 release would help prime the pump. There is documentation from the Gtk project. This is analagous to the Tk documentation that is referenced from the Tkinter documentation. Tkinter was listed as an undocumented module in the standard distribution for years and the early documentation simply explained how to map the Tk documentation to the Python equivolent syntax. I suspect that many people who were using Tkinter before it was documented in the Python docs either used Mark's book, read the source code, or cribbed from the demo code examples. Do you think it would be harmful to put the PyGtk package into the standard distribution prior to it being documented? A show stopper requirement for getting packages included into the Python distribution is the identification of volunteers to maintain the package for X Windows, the Mac, and Windows. Do we have volunteers who can maintain the code for the three platforms? ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Should PyGtk be proposed for the Python 2.4 release?
The Tkinter library in the standard Linux distribution is getting long in the tooth. It is in the standard distribution because it provides cross-platform portability and has a rich text widget. The rate of improvement in the Tk toolkit has slowed to a trickle and the marketshare of Tk continues to shrink. Is it time to look for a replacement that would be a comfortable fit within the standard Python library? There are three major contenders in the cross-platform GUI race, PyGtk, wxPython and PyQT. Each of these options have strong Python support and a mature code base. Less mature technologies that could be considered include the anygui project and the IBM Eclipse library and IDE. The anygui project is very much in the early research stage, with a minimal set of widgets defined. It would be great as the standard GUI API because it would allow the user to select the underlying GUI toolkit at execution time. When anygui eventually matures it could be added to the standard library, alongside the Tkinter and whatever other GUI APIs find their way into the standard distribution. The IBM Eclipse GUI was written for Java, but the C language interface, which is a thin layer over native toolkit widgets, could be wrapped into a Python GUI package. The design goals described in the design methodology provide a well balanced tradeoff in Eclipse is to use the native widgets when they are available and build widgets that are missing from native components. This fixes the problems with the Java awt (lowest common denominator widgets) and Swing (draws all widgets using Java). While Eclipse looks attractive, it is not as mature as the other options and it has not gathered a strong following of Python users. In addition to the GUI, I think it is important to have a GUI Builder available for the GUI toolkit. This has always been a weakness of Tkinter and I think it has hurt the growth of Python that we did not have a visual basic like GUI interface for building applications. By selecting PyGtk, and including the libglade library, it would be easy to create an integrated development environment based on Glade and the XML glade files that it generates. Quality tools such as these need to be part of the standard distribution. If they are not then they cannot be counted on to be part of a Python installation. I have seen numerous programs written in Tkinter simply because the author did not want to impose the requirement of installing an alternative GUI library. Of the big three; PyGtk, wxPython, and PyQT; I believe the PyGtk package is probably the closest match to the Python coding philosophy and style. It is also closer to the Tkinter programming model. PyGtk is written in C and the widget library seems to be a superset of Tkinter. I also think James has done an excellent job of making use of the Python 2.2 API for creating classes. The library has a very natural Python feel to it. Would others on this list care to comment on this assertion? The case for adding a new GUI to the standard library will need to address the sticky point of why the GUI toolkit is appropriate for the standard Python library. An argument often posed for using wxPython instead of PyGtk has been that wxPython used native widgets to render applications on platforms. This allows the GUI themes of the native toolkit to be transparently used in the application. This helps make the application look closer to the users expectations for the GUI. There is merit to this argument, but the tradeoff is a more bloated GUI toolkit that places abstraction layers inbetween a native toolkit and the GUI API. It looks like some work has been done on making the native themes for Windows and Mac OS X [1] work under Gtk+ [2]. Is anyone on this list experienced with using these capabilities? Do they mitigate the theme problems of Gtk+, or will applications still need to manually adjust the themes to match the theme of their desktop? I'd like to get some feedback from this list before brining this idea up in the general python mailing list. If it is shot down here, where I would expect some support for selecting PyGtk, there is no need to take up the bandwidth of the larger forum. If Guido rejects adding a new GUI package into the standard distribution, then I would suggest that we use PyGtk as one of the foundation packages in a Fat Python distribution. The purpose of developing Fat Python is to provide users with a "No Assembly Required" distribution of Python. It would be a release of a set of Python packages and applications that run cross-platform. The goal would be to create binary installations for major platforms. [1] http://www.osxfaq.com/Press/12-31-02/gtk-12-31-02.ws [2] http://gtk-wimp.sourceforge.net/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Curves, splines and libart
On Wednesday 05 March 2003 10:32 am, "Gustavo J. A. M. " Carneiro wrote: > On Ter, 2003-03-04 at 15:16, [EMAIL PROTECTED] wrote: > > Does anyone know how to draw an spline-curve? > > Or any other fancy type of curve that the user can drag and tweak? > > Is using art (libart) an option? > > libart in python? no, sorry. > Maybe you should try gnomeprint. If you want interactivity, you should > use gnome.canvas. They are both in the gnome-python package. The DiaCanvas [1] project might be what you need. It uses libart and has python wrappers. [1] http://diacanvas.sourceforge.net/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] TreeModel mystery
On Wednesday 21 August 2002 04:20 am, Michele Campeotto wrote: > DISCLAIMER: HORRIBLE code ahead! > > Michael McLay wrote: > > My goal is to populate a TreeModel with an XML tree. So far I've had no > > luck in getting started. I suspect that others on this list would really > > love to see an example that shows how to tie a XML DOM tree to the > > TreeModel. (An > >I don't have the specific example you're asking for, but I've done > some experimentation with TreeModel and come up with an example that > maps a filesystem to a TreeModel: > http://www.micampe.it/software/explorer/files/explorermodel.py >Note that I am nowhere near to understand how and why this code works > (I know, I've written it, so? ;), but I hope it can help you... Thanks for the example. I think I can crib from it to make a DOM viewer. >Btw, have considered using TreeStore instead? I've thrown away that > code and used the simple TreeStore and it fits quite fine... Please, if it's not too much trouble, send an example of how this is done with TreeStore. I suspect TreeStore is a better solution for connecting data from the DOM to the viewer. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] TreeModel mystery
I've figured out how to use many of the widgets in the 2.0.0 release of pygtk, but I've spent the last several hours trying to make sense of the TreeModel. Call me thick, but I don't see where some of the methods are originating, or why they are being called. Why did I have to define the 20 some methods in the class that inherited from GenericTreeModel? I've studied treemodel.py, but I still don't get it. If I delete on_iter_children I get the following error. AttributeError: on_iter_children None Some experimenting found that the following code will call on_iter_children: def f(a,b,c): print " nodes: ", b,c p = MyModel() p.foreach(f) Why this is happening isn't clear. I found no references to on_iter_children in the pygtk source code. It shows up in a couple binary files that are built, but that, and in the example are the only references. My goal is to populate a TreeModel with an XML tree. So far I've had no luck in getting started. I suspect that others on this list would really love to see an example that shows how to tie a XML DOM tree to the TreeModel. (An example that displayed a .glade file would be most helpful.) The example treemode.py is confusing because the path is also the content that is displayed in the tree. Does the path have to be a tuple? It isn't clear how the tree is initially populated. BTW, thanks for all the great work on pyGtk. Now if I could only figure out how to use it:-) ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Python, GNOME, Locale, and Dates
On Thursday 13 December 2001 03:59 pm, Michael P JasonSmith wrote: > James Henstridge wrote: > > Michael P JasonSmith wrote: > > >The GnomeDateEdit widget insists in displaying the dates in mm/dd/ The ISO [1], the IETF[2] , the W3C [3], and the U.S. government [4] recomend formating a date using -mm-dd. Unfortunately traditions prevales and dates written in the 09/01/01 format continue to be used. (So will they be delivering the new furniture on September 1, 2001 or January 9, 2001.) Hopefully the Gnome project will change the default date to the ISO recommendation. Perhaps the use of the broken/obsolete date formats can be discouraged by making it painful to use the option. (Perhaps selecting one of the older ambiguous options should emmit shocks through the mouse or the keyboard:-) Whoever created the GnomeDateEdit widget may find the following references helpful: [1]http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=26780 [2] http://www.ietf.org/internet-drafts/draft-ietf-impp-datetime-05.txt [3]http://www.w3.org/TR/NOTE-datetime [4] NIST FIPS 4.2 - http://www.itl.nist.gov/fipspubs/fip4-2.pdf > > >format. > > [snip] > > > This is not a pygtk bug, and most likely won't be fixed in > > gnome-libs-1.x. > > > > In the 2.0 tree, it uses the strftime "%x" format string, so it > > internationalises correctly (ie. doesn't use silly date order in en_AU). > > Thanks for that, James. After discussing it with my boss we decided to > document the bug, and switch to Gnome 2.x this time next year, rather > than hack the libs :). ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
[pygtk] Usign libglade and Glade to write PyGlade
On Sunday 25 February 2001 03:20, James Henstridge wrote: > On Sun, 25 Feb 2001, Russell Nelson wrote: > > 3) Is there a program which can take a .glade file, and modify a .py > > file so that it matches the signal definitions with a > > GladeSignalHelper class? It would be even cooler if I could just > > click on a signal in glade, and have a text editor bring up the > > associated code. Of course, you'd need glade to print events to > > stdout, and a text editor to read them. > > I have considered writing such a program to help use libglade with C, but > never got around to doing it. I don't believe there is such a program for > python though. Perhaps a slightly more radical change would yield bigger dividends. The Glade tool is written in C using the gtk library as a monolithic application. If it were rewritten in Python and used the libglade library to manage the GUI layout the reorganized application would be transformed into a modularized GUI framework. The primary goal of the re-engineering of Glade is to create an architecture for Glade that facilitate the contribution of plugins by mere Python programmers. A side effect of the redesign would be the creation of an core application that is considerably smaller in size. All of the code that generates the language interfaces would be moved out of the core GUI implementation and into plugin modules. The plugins would generate alternative language APIs by post-processing the XML definitions of the GUI from the .glade file. The new Python based architecture would encourage the addition of capabilities as described in "3)" by Glade users. In Glade's current monolithic form the barrier to contributing to the coding starts with task of understanding the complexity the Glade C code. This first step in adding capabilities to Glade is too high of a barrier so most end users. The task of trying to do "3)" is dead before they even start. The rewrite would not be a huge task for the right person. The current implementation of glade has about 75k lines of C code. Based on most C to Python comparisons it is reasonable to expect a 6 to 1 reduction by using Python in combination with Glade and libglade. So it will probably require writing about 13k lines of Python code to create pyglade. Some added shrinkage might be possible if the PyXML library was used for the in-memory representation of the GUI prototypes. Since XML is the target format for the .glade files it would simply data management to use the capabilities of PyXML. There are some indirect benefits to using Glade to develop a new implementation of Glade. The resulting application would provide a self documenting example for Glade users to examine and it would demonstrate that libglade can be used to implement real applications. A potentially larger indirect benefit would be the creation of an embeddable GUI development architecture. A pure Python based Glade implementation simplify the work involved in adding a GUI builder to any gtk or gnome application. All that would be required would be the integration of Python interpreter and the python libglade module into the application. All of the Glade capabilities would be loaded into the application by reading Python and .glade modules. This architecture for adding a GUI builder to an application has secondary benefits. All the code (with the exception of libglade) would be written in Python so it would be possible for end users to customize the GUI development environment within the application in which it was embedded. The GUI builder can also be upgraded without recompiling or reinstalling the application. The possibilities are endless:-) ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
[pygtk] Python-gnome documentation help
Daniel Kornhauser writes:
> Hi after not understandig several things I decided I needed to understand
> the way python works in order to persue my documentation effort . And I
> mean REALLY works:
> How it initializes, how does it's stack works, etc
>
> For example in C I have read several documents and books of how C works:
> You have a memory arrangement where you find diferent segments:
> text, initialized data, uninitalized data, heap, stack, stack frames and
> these components interact in other to make a program works, blah, blah,
> blah
> Sorry if this is a offtopic and dum question (I studied electronics not
> computer science ) but I've just lost 45 mins searching for
> such a doc of "how does python work" in the python site and I've remained
> empty handed...
>
> I would understand if there isn't such a doc and that I would have to take
> a plunge in python source code but a nice document would be very helpfull.
It's all done with mirrors, magic, and dictionaries.
Just use dir() and XX.__dict__ to understand the magic. The following
examples should help to illustrate how a definition of a class stores
the class members and class methods in a dictionary and that instances
of a class are stored in dictionaries.
Python 1.5.2 (#1, Sep 17 1999, 20:15:36) [GCC egcs-2.91.66 19990314/Linux (egcs- on
linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> a = 3
>>> def f(p=1, p2="string"):
... print p2
...
>>> class C:
... a = 1
... def __init__(self, b, c):
... self.b_is = b
... self.c_is = c
...
>>> c = C(1,"a string")
>>> dir()
['C', '__builtins__', '__doc__', '__name__', 'a', 'c', 'f', 'readline', 'rlcompleter']
So where did these global names come from?
>>> a
3
The name a is the global variable with the value 3
>>> f
This is the function that was declared.
The readline and rlcompleter methods are inserted into the global
namespace by my ~/.pythonrc initialization file. This file just has
two lines:
import rlcompleter, readline
readline.parse_and_bind('tab: complete')
The ~/.pythonrc file is imported whenever python is run in interactive
mode and the readline.parse_and_bind() sets up 'tab' to call a
name completion function.
>>> __builtins__.__dict__.keys()
['OverflowError', 'AttributeError', 'NotImplementedError', 'range', 'filter',
'KeyboardInterrupt', 'TypeError', 'AssertionError', 'apply', '_', '__debug__', 'ord',
'__name__', 'eval', 'ZeroDivisionError', 'callable', 'len', 'max', 'buffer', 'hash',
'None', 'map', 'ValueError', 'slice', 'exit', 'abs', 'getattr', 'reduce', 'complex',
'execfile', 'FloatingPointError', 'min', 'OSError', 'RuntimeError', 'locals', 'id',
'quit', 'EnvironmentError', 'issubclass', 'intern', 'coerce', 'KeyError', 'EOFError',
'__import__', 'ImportError', 'oct', 'MemoryError', 'cmp', 'dir', 'round', 'str',
'reload', 'compile', 'list', 'raw_input', 'setattr', 'IndexError', 'delattr',
'hasattr', 'ArithmeticError', 'xrange', 'repr', 'tuple', 'StandardError',
'isinstance', 'Exception', 'SystemExit', '__doc__', 'type', 'input', 'IOError', 'chr',
'NameError', 'long', 'hex', 'SystemError', 'open', 'LookupError', 'Ellipsis',
'divmod', 'globals', 'int', 'float', 'SyntaxError', 'pow', 'vars']
The '__builtins__' dictionary contains all of the builtin function
definitions, such as dir(), map(), and str().
The '__doc__' is the doc string for the namespace. All modules
classes and functions contain a '__doc__'. If it isn't defined by
then Python returns None as the value.
>>> `__doc__`
'None'
Finally '__name__' is the name of the module. The toplevel module is
named '__main__'.
>>> __name__
'__main__'
>>>
The test for the value of '__name__' is an idiom often found at the
end of a module. This test:
if __name__ == '__main__':
do_test()
This will only pass if the module is called as the top level script to be
executed. If the module is imported then the test fails and the
function do_test() would not be called. The idiom provides an easy
mechanism for including test code directly in a module.
>>> locals()
{'__doc__': None, 'rlcompleter': , 'readline': , '__name__': '__main__', '__builtins__':
, 'f': , 'c': <__main__.C
instance at 80c7a20>, 'C': , 'a': 3}
The locals() command uncovers the secret of Python. It's dictionaries
all the way down. The global namespace is a dictionary. Every module
is a dictionary. A package is created by nesting dictionaries.
>>> c
<__main__.C instance at 80d5eb0>
>>> dir(c)
['c_is', 'b_is']
>>> c.__dict__
{'b_is': 1, 'c_is': 'a string'}
The instance 'c' is a dictionary. The instance is the first parameter
passed into the methods defined in a class. This parameter is traditionally
called 'self', but this is not a requirement. Note that the class
variable 'a' does not appear in this dictionary. It was not assigned
to the 'self' dictionary. The value of 'a' requires looking in the class
dictionary.
>>> C
>>> d
[pygtk] ignore - Archives not being updated
Michael McLay writes: > > It looks like the email archives for the pygtk list stopped being > updated on 2000/02/10. Looks like it is a problem with the http://www.mail-archive.com/ service. They had a system crash and they are running in degradation mode. To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
[pygtk] Archives not being updated?
It looks like the email archives for the pygtk list stopped being updated on 2000/02/10. http://www.mail-archive.com/pygtk@daa.com.au/maillist.html To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] rotation and scaling of canvas items
James Henstridge writes: > Yes you are right. I had forgotten about the gnome_canvas_*_affine > functions. I will probably be putting out a new version of pygtk and > gnome-python soon. > > Here is the list of things I will be adding: > - gtk_ctree_new (I had gtk_ctree_new_with_titles but forgot this one) > - gnome_canvas_item_affine_relative > - gnome_canvas_item_affine_absolute > - Adding code so you can make exceptions cause the mainloop to exit (this > will be a runtime option). This way it should be easier to debug python > programs with pdb. The behaviour will probably be turned on by setting > PYGTK_FATAL_EXCEPTIONS to a non null value. > - fix up code so builddir != srcdir builds work properly. > > If you think I have missed anything on this list, please tell me. Excellent. I look forward to the additions. Would it be possible to have some convenience functions added on top of the affine code to do a couple common operations. In particular, translation (which is already available), rotation (specified in degrees), and symmetrical scaling. Things like skew and scaling in one direction are probably rare enough to be done using the affine matrix directly. To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
[pygtk] rotation and scaling of canvas items
The gnome-canvas looks like a good candidate for developing a simple viewer for printed circuit board graphics. The Python API is missing two important methods. It is possible to translate groups and nested groups, but it is not possible to scale or to rotate the groups. The code in the definitions file that is suppose to generate a scale and rotate funtion were commented out. The underlying gnome code had defined functions for rotate and scale, but they were not implemented. The gnome-canvas authors sent the following response to a query about what will be done with this code and what should be used to rotate and scale objects: Raph Levien writes: > Michael McLay wrote: > > > > In gnome-canvas.h gnome_canvas_item_rotate and gnome_canvas_item_scale > > are defined, but they are not implemented. It looks like the required > > art_affine_scale and art_affine_rotate functions have been defined in > > art_affine.c. Will they be implemented in a future release or is this > > a deprecated feature? > > > > This is a key feature of the canvas which I need for my application. > > You want to do a gnome_canvas_item_affine_relative (or maybe absolute, > depending on what you're trying to do), using the appropriate art_affine > functions to generate the affine transform. > > The g_c_i_rotate and _scale methods shouldn't be in the .h file. > Federico is planning to clean that stuff up soon. > > Good luck with your canvas app! > > Raph It looks like it won't be possible to simply generate a wrapper for an existing library call. Some additional code will be required to implement the rotate and scale functions. Or, perhaps the affine functions should be exposed in the Python API. To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
