Re: [pygtk] Lost in Gtk3 height-for-width geometry

[Pietro Battiston]

OK, last update on this issue: the problem lies in the fact that the X
server doesn't know anything about trading width for height, and so
determining a (minimum) allocation to ask for the toplevel window is not
a trivial thing to do for the layouting engine.

See this reply:
https://mail.gnome.org/archives/gtk-devel-list/2013-June/msg00053.html

and this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=681937#c12

for more info.

Pietro


Il giorno mar, 18/06/2013 alle 17.10 +0200, Pietro Battiston ha scritto:
> I have found an explanation... in the official documentation.
> 
> "The minimum height for the minimum width is normally used to set the
> minimum size constraint on the toplevel (unless
> gtk_window_set_geometry_hints() is explicitly used instead)."
> 
> But the real answer to my problem is not in that sentence, but in its
> non-obvious (to me) consequence: Gtk.Widget.do_get_preferred_width()
> should _not_ return the minimal width the widget will ever be able to
> cope with, but rather its width in some reasonable form factor, though
> as compressed as possible.
> 
> (still, I don't see the rational for this design choice, since the
> layout algorithm will not be able to know the _real_ minimum width of my
> widget)
> 
> Pietro
> 
> Il giorno lun, 17/06/2013 alle 20.20 +0200, Pietro Battiston ha scritto:
> > Hello,
> > 
> > I'm designing a widget. Its "do_get_request_mode(self)" returns
> > Gtk.SizeRequestMode.HEIGHT_FOR_WIDTH.
> > 
> > 
> > Now, in a testcase, the widget does the following:
> > 1) do_get_preferred_width() is called: it returns 53 (minimum), 212
> > (natural)
> > 2) do_get_preferred_height_for_width() is called with width 53: it
> > returns 170, 170
> > 3) do_get_preferred_height_for_width() is called with width 212: it
> > returns 51, 51
> > 
> > So far, so good: the widget has received all the calls I expected, and
> > returned what I wanted it to. But now, what I would expect (at least in
> > a test case in which no other widgets are reclaiming anything) would be
> > that the widget is offered (212, 51). Instead, not only it is offered
> > (212, 170), but the 170 is considered as minimum - I'm unable to resize
> > the widget to something smaller. Now, I did declare 170 as a minimum...
> > but only in the case in which the width is 53!
> > 
> > To reproduce, you can do:
> > git clone git://pietrobattiston.it/quack
> > cd quack
> > git checkout wrapbox_error
> > cd plugins/tags
> > python test_wrapbox.py
> > 
> > to understand what I would like, just replace the "if nat:" at line 93
> > with "if True:", and rerun.
> > 
> > Thank you in advance for any enlightenment, or pointer to a good
> > discussion of such issues.
> > 
> > Pietro
> > 
> > ___
> > pygtk mailing list   pygtk@daa.com.au
> > http://www.daa.com.au/mailman/listinfo/pygtk
> > Read the PyGTK FAQ: http://faq.pygtk.org/
> 
> 
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Gtk.Grid and checkButton

[Pietro Battiston]

Hi Petr,

this can certainly be done by nesting each checkbutton in a
Gtk.Alignment.

That said, are you sure gtk.CheckButton.new_with_label() is not what
you're looking for?

Pietro



Il giorno mer, 19/06/2013 alle 10.37 +0200, Petr Hracek ha scritto:
> Hi folks,
> 
> I have question regarding Gtk.Grid and Gtk.CheckButton.
> 
> I have a grid which is like
> - first column contains checkbuttons
> - second column contains label with help text for that checkbuttons
> 
> label are align to the top and left but checkbutton are always centered.
> 
> Do you have any idea how to align checkbuttons to the top and left?
> 
> Thank you in advance
> 


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Gtk.Grid and checkButton

[Pietro Battiston]

Hi Petr,

this can certainly be done by nesting each checkbutton in a
Gtk.Alignment.

However, 

Il giorno mer, 19/06/2013 alle 10.37 +0200, Petr Hracek ha scritto:
> Hi folks,
> 
> I have question regarding Gtk.Grid and Gtk.CheckButton.
> 
> I have a grid which is like
> - first column contains checkbuttons
> - second column contains label with help text for that checkbuttons
> 
> label are align to the top and left but checkbutton are always centered.
> 
> Do you have any idea how to align checkbuttons to the top and left?
> 
> Thank you in advance
> 


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Lost in Gtk3 height-for-width geometry

[Pietro Battiston]

I have found an explanation... in the official documentation.

"The minimum height for the minimum width is normally used to set the
minimum size constraint on the toplevel (unless
gtk_window_set_geometry_hints() is explicitly used instead)."

But the real answer to my problem is not in that sentence, but in its
non-obvious (to me) consequence: Gtk.Widget.do_get_preferred_width()
should _not_ return the minimal width the widget will ever be able to
cope with, but rather its width in some reasonable form factor, though
as compressed as possible.

(still, I don't see the rational for this design choice, since the
layout algorithm will not be able to know the _real_ minimum width of my
widget)

Pietro

Il giorno lun, 17/06/2013 alle 20.20 +0200, Pietro Battiston ha scritto:
> Hello,
> 
> I'm designing a widget. Its "do_get_request_mode(self)" returns
> Gtk.SizeRequestMode.HEIGHT_FOR_WIDTH.
> 
> 
> Now, in a testcase, the widget does the following:
> 1) do_get_preferred_width() is called: it returns 53 (minimum), 212
> (natural)
> 2) do_get_preferred_height_for_width() is called with width 53: it
> returns 170, 170
> 3) do_get_preferred_height_for_width() is called with width 212: it
> returns 51, 51
> 
> So far, so good: the widget has received all the calls I expected, and
> returned what I wanted it to. But now, what I would expect (at least in
> a test case in which no other widgets are reclaiming anything) would be
> that the widget is offered (212, 51). Instead, not only it is offered
> (212, 170), but the 170 is considered as minimum - I'm unable to resize
> the widget to something smaller. Now, I did declare 170 as a minimum...
> but only in the case in which the width is 53!
> 
> To reproduce, you can do:
> git clone git://pietrobattiston.it/quack
> cd quack
> git checkout wrapbox_error
> cd plugins/tags
> python test_wrapbox.py
> 
> to understand what I would like, just replace the "if nat:" at line 93
> with "if True:", and rerun.
> 
> Thank you in advance for any enlightenment, or pointer to a good
> discussion of such issues.
> 
> Pietro
> 
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

[pygtk] Lost in Gtk3 height-for-width geometry

[Pietro Battiston]

Hello,

I'm designing a widget. Its "do_get_request_mode(self)" returns
Gtk.SizeRequestMode.HEIGHT_FOR_WIDTH.


Now, in a testcase, the widget does the following:
1) do_get_preferred_width() is called: it returns 53 (minimum), 212
(natural)
2) do_get_preferred_height_for_width() is called with width 53: it
returns 170, 170
3) do_get_preferred_height_for_width() is called with width 212: it
returns 51, 51

So far, so good: the widget has received all the calls I expected, and
returned what I wanted it to. But now, what I would expect (at least in
a test case in which no other widgets are reclaiming anything) would be
that the widget is offered (212, 51). Instead, not only it is offered
(212, 170), but the 170 is considered as minimum - I'm unable to resize
the widget to something smaller. Now, I did declare 170 as a minimum...
but only in the case in which the width is 53!

To reproduce, you can do:
git clone git://pietrobattiston.it/quack
cd quack
git checkout wrapbox_error
cd plugins/tags
python test_wrapbox.py

to understand what I would like, just replace the "if nat:" at line 93
with "if True:", and rerun.

Thank you in advance for any enlightenment, or pointer to a good
discussion of such issues.

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] "gtk.Window.get_size()" returns wrong dimesntions after "resize()"?

[Pietro Battiston]

Il giorno gio, 24/01/2013 alle 12.56 +0530, Ajay Garg ha scritto:
> 
> 
> On Wed, Jan 23, 2013 at 9:58 PM, Guan Xin  wrote:
> Hi Ajay,
> 
> According to
> 
> 
> http://www.pygtk.org/docs/pygtk/class-gtkwindow.html#method-gtkwindow--get-size
> 
> "As a result, if you call the resize() method then immediately
> call the get_size() method, the size won't have taken effect
> yet. After the window manager processes the resize request,
> PyGTK receives notification that the size has changed via a
> configure event, and the size of the window gets updated."
> 
> 
> So, perhaps it is expected.
> 
> 
> Ahh.. Thanks Guan.. !
> 
> So, is there a workaround, whereby one get the correct, updated
> dimensions (preferably in a synchronous manner), after "resize" is
> done?


I honestly doubt it's an elegant solution, but years ago I followed this
approach:
http://www.pietrobattiston.it/wiki/pygtk:resizing

best,

Pietro





>  
> 
> 
> Regards,
> 
> Guan
> 
> 
> 
> On Wed, Jan 23, 2013 at 5:18 PM, Ajay Garg
>  wrote:
> 
> Hi all.
> 
> 
> First I would like to paste the simplistic example,
> highlighting the issue :
> 
> 
> #
> import gtk
> import gobject
> 
> win = gtk.Window()
> win.show()
> 
> print win.get_size()# prints (200, 200)
> 
> win.resize(100, 346)
> print win.get_size()# still prints (200, 200) :-(
> 
> gobject.MainLoop().run()
> 
> #
> 
> 
> 
> 
> As can be seen, the "get_size()" continues printing
> the older dimensions, even after a  "resize()" has
> been done?
> 
> 
> Is it expected? Is there a way I can get "(100, 346)"
> to be printed in the second call to "print
> win.get_size()" ?
> (note that the resizing graphical-effect takes place
> without any issues)
> 
> 
> 
> 
> Regards,
> Ajay
> 
> 
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/
> 
> 
> 
> 
> 
> -- 
> Regards,
> Ajay
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] How to use g_timeout_add () function?

[Pietro Battiston]

Il giorno sab, 07/04/2012 alle 00.24 +0800, Lion Chen ha scritto:
> many thanks. so import glib is also right?

sure

import glib
glib.timeout_add(...)

but notice you answered to me instead than to the list

Pietro

> 
> Lion
> > Il giorno ven, 06/04/2012 alle 17.09 +0200, Petr Kubánek ha scritto:
> >> What about this:
> >>
> >> import gobject
> >>
> >> self.color_cycle_timeout_id = 
> >> gobject.timeout_add(500,self.color_cycle_timeout())
> >>
> >> Does it helps?
> > Petr's solution indeed should work indeed. A couple of notes:
> >
> > - gtk_timeout_add translated to Python as gtk.timeout_add. Similarly,
> > g_timeout_add translates to glib.timeout_add. That said, as Petr pointed
> > out, gobject.timeout_add will work too (assuming it isn't or doesn't
> > become deprecated too)
> >
> > - I may be wrong (don't know what you're trying to do exactly), but I
> > guess the second argument should probably be self.color_cycle_timeout
> > (without the brackets)
> >
> > Pietro
> >
> >
> >
> >> Petr
> >>
> >> Lion Chen píše v Pá 06. 04. 2012 v 23:03 +0800:
> >>> Hello all,  i have a question:
> >>>
> >>> when i check gtk_time_out in the gtk+2 reference, it said " 
> >>> gtk_timeout_add has been deprecated since version 2.4 and should not be 
> >>> used in newly-written code. Use g_timeout_add() instead."
> >>>
> >>> but i don't know how to use the g_timout_add() function. if i use the 
> >>> function, i would get an error message:
> >>>
> >>> self.color_cycle_timeout_id = g_timeout_add(500, 
> >>> self.color_cycle_timeout())
> >>>
> >>> Traceback (most recent call last):
> >>>File "/home/lionchen/workspace/testtext/testtext_bak.py", line 296, in 
> >>> set_colors
> >>>  self.color_cycle_timeout_id = g_timeout_add(500, 
> >>> self.color_cycle_timeout())
> >>> NameError: global name 'g_timeout_add' is not defined
> >>>
> >>> or:
> >>>
> >>> self.color_cycle_timeout_id = gtk.g_timeout_add(500, 
> >>> self.color_cycle_timeout())
> >>>
> >>> Traceback (most recent call last):
> >>>File "/home/lionchen/workspace/testtext/testtext_bak.py", line 296, in 
> >>> set_colors
> >>>  self.color_cycle_timeout_id = gtk.g_timeout_add(500, 
> >>> self.color_cycle_timeout())
> >>> AttributeError: 'module' object has no attribute 'g_timeout_add'
> >>>
> >>> when i use the gtk.timeout_add(), no error message occurse.
> >>>
> >>> can i use g_timeout_add() in pygtk?
> >>>
> >>> ___
> >>> pygtk mailing list   pygtk@daa.com.au
> >>> http://www.daa.com.au/mailman/listinfo/pygtk
> >>> Read the PyGTK FAQ: http://faq.pygtk.org/
> >>
> >> ___
> >> pygtk mailing list   pygtk@daa.com.au
> >> http://www.daa.com.au/mailman/listinfo/pygtk
> >> Read the PyGTK FAQ: http://faq.pygtk.org/
> >
> > ___
> > pygtk mailing list   pygtk@daa.com.au
> > http://www.daa.com.au/mailman/listinfo/pygtk
> > Read the PyGTK FAQ: http://faq.pygtk.org/



___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] How to use g_timeout_add () function?

[Pietro Battiston]

Il giorno ven, 06/04/2012 alle 17.09 +0200, Petr Kubánek ha scritto:
> What about this:
> 
> import gobject
> 
> self.color_cycle_timeout_id = 
> gobject.timeout_add(500,self.color_cycle_timeout())
> 
> Does it helps?

Petr's solution indeed should work indeed. A couple of notes:

- gtk_timeout_add translated to Python as gtk.timeout_add. Similarly,
g_timeout_add translates to glib.timeout_add. That said, as Petr pointed
out, gobject.timeout_add will work too (assuming it isn't or doesn't
become deprecated too)

- I may be wrong (don't know what you're trying to do exactly), but I
guess the second argument should probably be self.color_cycle_timeout
(without the brackets)

Pietro



> 
> Petr
> 
> Lion Chen píše v Pá 06. 04. 2012 v 23:03 +0800:
> > Hello all,  i have a question:
> > 
> > when i check gtk_time_out in the gtk+2 reference, it said " gtk_timeout_add 
> > has been deprecated since version 2.4 and should not be used in 
> > newly-written code. Use g_timeout_add() instead."
> > 
> > but i don't know how to use the g_timout_add() function. if i use the 
> > function, i would get an error message:
> > 
> > self.color_cycle_timeout_id = g_timeout_add(500, self.color_cycle_timeout())
> > 
> > Traceback (most recent call last):
> >   File "/home/lionchen/workspace/testtext/testtext_bak.py", line 296, in 
> > set_colors
> > self.color_cycle_timeout_id = g_timeout_add(500, 
> > self.color_cycle_timeout())
> > NameError: global name 'g_timeout_add' is not defined
> >  
> > or:
> > 
> > self.color_cycle_timeout_id = gtk.g_timeout_add(500, 
> > self.color_cycle_timeout())
> > 
> > Traceback (most recent call last):
> >   File "/home/lionchen/workspace/testtext/testtext_bak.py", line 296, in 
> > set_colors
> > self.color_cycle_timeout_id = gtk.g_timeout_add(500, 
> > self.color_cycle_timeout())
> > AttributeError: 'module' object has no attribute 'g_timeout_add'
> > 
> > when i use the gtk.timeout_add(), no error message occurse.
> > 
> > can i use g_timeout_add() in pygtk?
> > 
> > ___
> > pygtk mailing list   pygtk@daa.com.au
> > http://www.daa.com.au/mailman/listinfo/pygtk
> > Read the PyGTK FAQ: http://faq.pygtk.org/
> 
> 
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] mouse-on information widget?

[Pietro Battiston]

Il giorno mar, 20/03/2012 alle 14.53 -0500, Zhenjiang Lan ha scritto:
> Is there any way to show some messages when mouse move onto a button
> or something else?

Maybe a stupid question, but: do you mean tooltips?!

http://developer.gnome.org/gtk/2.24/GtkTooltips.html

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] pygobject documentation ?

[Pietro Battiston]

Il giorno mar, 10/01/2012 alle 18.54 +0100, Timo ha scritto:
> Op 10-01-12 15:42, Jérôme schreef:
> > Hi all.
> >
> > I started python and pygtk recently (a few weeks).
> >
> > For that I used
> >
> > Python 2.7 documentation
> > http://docs.python.org/
> >
> > python GTK2.0 tutorial
> > http://pygtk.org/pygtk2tutorial/index.html
> >
> > Then, I decided to switch to pygobject. Two reasons for that :
> >
> > * The advice on pygtk.org : "New users wishing to develop Python 
> > applications
> >using GTK+ are recommended to use the GObject-Introspection features
> >available in PyGObject."
> >
> > * The fact that glade, that I wanted to use as well, now (from version 3.10)
> >only supports GTK3 (or so I understand).
> >
> > The resources I use are now referenced here : 
> > https://live.gnome.org/PyGObject
> >
> > * The tutorial :
> >http://readthedocs.org/docs/python-gtk-3-tutorial/en/latest/index.html
> >
> > * A partial doc I don't really use :
> >http://people.gnome.org/~johnp/girdocsalpha/Gtk/
> >
> > * Examples I just discovered :
> >http://developer.gnome.org/gnome-devel-demos/stable/
> >
> > The most annoying is that I often find myself having to deal with the GTK3
> > reference manual : http://developer.gnome.org/gtk3/stable/ and guess what 
> > the
> > python code corresponding to the C code can be.
> >
> > Some adaptations are trivial, like from
> >
> > voidgtk_window_set_title(GtkWindow *window,
> >   const gchar 
> > *title);
> >
> > to
> >
> > Gtk.Window.window.set_title(string)
> >
> > But it is sometimes hard to just guess the name of python constants from C
> > constants.
> >
> > Like from GTK_WINDOW_POPUP to Gtk.WindowType.POPUP, for instance.
> Constants are actually pretty easy once you understand how they are 
> mapped to Python.
> Have a look at the C docs page for all enumerations: 
> http://developer.gnome.org/gtk3/stable/gtk3-Standard-Enumerations.html
> Let's start at the top of these for convenience sake:
> GTK_ACCEL_MASK from GtkAccelFlags becomes Gtk.AccelFlags.MASK
> GTK_ARROWS_BOTH from GtkArrowPlacement becomes Gtk.ArrowPlacement.BOTH
> GTK_ARROW_UP from GtkArrowType becomes Gtk.ArrowType.UP
> 
> You will notice a pattern: take the enumeration name, split the Gtk part 
> and rest with a dot, then leave out GTK_*_ part from the types and 
> append them to the previously splitted name.
> 
> This approach always worked for me till now.

I can confirm this holds for me too (though often with some trial and
error, even after some time), but still I'm curious: is any further
(possibly automatic?) step in documenting pygobject planned?
In the end, introspection is about automatically transforming C
functions/constants into python methods/constants, so automatic
conversion of API docs should be feasible too. The descriptions could be
left as they are, with the possibility of manual overriding (in
particular for examples).

Crazy? Or just lacking manpower?

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

[pygtk] Very weird Gio write_async behaviour

[Pietro Battiston]

Hello,

as I wrote earlier today, I'm unable to copy a file in async mode with
the methods provided by Gio (via introspection).
So I'm trying to workaround this problem with other functions. At the
bottom of this mail, is the best I came to.
Unfortunately, it doesn't work: after running it, the target file starts
with some characters of garbage (which change from execution to
execution!) - the rest of the original file is copied correctly.

I'm really clueless, any help is appreciated.

Pietro

8<8<8<8<8<8<8<

#! /usr/bin/python

import sys
from gi.repository import Gio, GLib


class Uploader(object):
def read(self):
self.f = Gio.file_new_for_commandline_arg( '/tmp/first' )
self.f.load_contents_async( None, self.read_finished, None )

def read_finished( self, gdaemonfile, result, data ):
self.content = self.f.load_contents_finish( result )[1]
print self.content
#self.g =
Gio.file_new_for_uri( 'file:///home/pietro/cancellami/pippopippo2' )
#self.g.delete( None )
self.g = Gio.file_new_for_uri( 'file:///tmp/second' )
self.g.create_async( 0, GLib.PRIORITY_DEFAULT, None,
self.created, None )

def created(self, gdaemonfile, result, data):
self.stream = self.g.create_finish( result )
self.stream.write_async( self.content, GLib.PRIORITY_DEFAULT,
None, self.written, None )

def written(self, gdaemonfile, result, data):
print self.stream.write_finish( result )
self.loop.quit()


u = Uploader()
GLib.timeout_add(10, u.read)
u.loop = GLib.MainLoop()
u.loop.run()

8<8<8<8<8<8<8<



___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

[pygtk] File.copy_async missing

[Pietro Battiston]

Hello,

the following code, using pygtk, works:

import gio

f = gio.File('a')
g = gio.File('b')
f.copy_async( g, (lambda x : None))


while the following, using introspection, doesn't:

from gi.repository import Gio

f = Gio.file_new_for_path('a')
g = Gio.file_new_for_path('b')
f.copy_async( g, (lambda x : None))


because "'__main__.GLocalFile' object has no attribute 'copy_async'".

Is this a bug/work in progress or is there something I'm missing?

I'm using  libglib 2.30.2-4 and gobject-introspection1.31.1-1 under
Debian testing.

thanks in advance

Pietro


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Gtk.Box, homogeneous and expand

[Pietro Battiston]

Il giorno mar, 03/01/2012 alle 17.41 +0100, Jérôme ha scritto:
> Tue, 03 Jan 2012 16:34:37 +0100
> Pietro Battiston a écrit:
> 
> > So if there is no left/right alignment rule, the default is just to
> > distribute them on all the available space, leaving the same empty space
> > among them or, if you instead set "homogeneous", allocating to each the
> > same space, which will then possibly be partly empty.
> > 
> > Your logic could make sense, it is just based on more assumptions.
> 
> The GTK3 docs says :
> http://readthedocs.org/docs/python-gtk-3-tutorial/en/latest/layout.html#boxes
> 
> "If homogeneous is True, all widgets in the box will be the same size, of
> which the size is determined by the largest child widget."
> 
> That's why I would expect homogeneous to mean widgets (for instance buttons)
> of same size, regardless of expand, as I described in my previous message.
> 
> This description does not seem to fit reality. In practice, we saw that when
> homogeneous is set, the N widgets are provided one Nth of the total size,
> though they don't necessarily fill that space, and this size does not depend
> on the largest child widget. 

Yes, you're right, strictly speaking the docs are wrong: widgets are
_allocated_ the same size, they wont't _be_ the same size. That said, it
is clear that that sentence from the doc _couldn't_ be right, because a
widget has the "power" to not expand and hence the Box couldn't
determine its true size anyway: it can only decide how much space to
allocate to it.

> 
> Well, thinking of it, it does, if the total width is determined by the
> widgets, which happens if the HBox is the largest. This is not true if it
> belongs to a VBox with larger HBoxes in it, of if I enlarge the window, for
> instance.
>  
> > I anticipate that your reaction will be "but those are ugly hacks", 
> 
> But those are ugly hacks !
> 
> > and I guess - but again, I might be wrong - the answer of the developers
> > would be "what you're trying to do is ugly".
> 
> Is it ? Perhaps.
> 
> I had the feeling that the logic I exposed allowed more things to be done
> with the same amount of parameters. I must be wrong, since people have been
> working on it much longer than I did. I just don't see why.

You seem to be right on this too: your rule could apparently allow more
things. And in fact, my sentence is exagerated: certainly what you want
to do is not necessarily "ugly" (and in fact, the solution by craf is
less ugly than the one by me), Let's just say that:
1) I'm not sure what you see as a "sane" rule still looks so obvious
when we stop assuming that all children share the same flags (not to
mention the fact that in a table we have the same problem in 2
dimensions, and we expect a behaviour coherent with onedimensional
GtkBoxes)
2) the gtk libs seem to not favour what seems to not be considered as a
logic default: if there is no _logic_ difference between widgets on the
left and on the right, then they should be nicely distributed on all the
available space, while if they are logically different then they will be
separated in different containers (and at this point, GtkFrames are
probably even better suited than nested GtkBoxes).

bye

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Gtk.Box, homogeneous and expand

[Pietro Battiston]

Il giorno mar, 03/01/2012 alle 14.42 +0100, Jérôme ha scritto:
> Hi.
> 
> There's something I don't get with the behaviour of homogeneous in Gtk.Box. I
> guess there must be a reason for it working this way. I just don't get the
> logic.

I may be wrong, but to me it looks the logic is much simpler than what
you expect. You expect a left alignment, but there is no reason why it
should be. If I understand correctly, "pack_start" and "pack_end" refer
to the _order_ of widgets, and not to any alignment of the widgets as a
whole.

So if there is no left/right alignment rule, the default is just to
distribute them on all the available space, leaving the same empty space
among them or, if you instead set "homogeneous", allocating to each the
same space, which will then possibly be partly empty.

Your logic could make sense, it is just based on more assumptions.


> [...]
> What I would expect :
> ---
> 
> 2.a/
> homogeneous = True
> expand = False
> fill = whatever
> -> Objects would be of the same size : the size of the largest one, and they
> would be left-aligned (pack_start() being used).
> 
> [| a ||abc||   |  ]
> 
> [...]
> 
> This seems more logical to me. I can't figure out why it does not work this
> way. 
> 
> Besides, I don't see how to obtain 2.a/ any other way.
> 

(craf already replied to you, but I had already wrote what follows:)

I see at least 2 ways: turn the "homogeneous" flag off, and all "expand"
to the False, then
1) put the last object in a GtkAlignment, make it (the child) appear on
the left, and the "Expand" flag of the GtkAlignment to True, or
2) pack, after the last object, another GtkAlignment, or even a
DrawingArea or a Label (again, with the "Expand" flag to true). 

I anticipate that your reaction will be "but those are ugly hacks", and
I guess - but again, I might be wrong - the answer of the developers
would be "what you're trying to do is ugly".


bye

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] How to clear/delete all values from the gtk.Liststore

[Pietro Battiston]

Il giorno mar, 13/12/2011 alle 20.44 +0530, Arun p das ha scritto:
> I am new to pygtk. currently i am doing one application using pygtk and glade.
> my Question is How to clear/delete all values from the gtk.Liststore.

How about gtk.ListStore.clear() and, more in general, reading the
documentation for gtk.ListStore?

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] "Rolling Up" Calculations

[Pietro Battiston]

Il giorno sab, 12/11/2011 alle 15.05 +0800, Andrew Rowland ha scritto:
> I have a group of information that is related in a hierarchical
> structure.  I display the structure in a treeview.  I am trying to
> roll up various calculations where, the sum of the lower levels
> becomes the unit value of the next higher level.  Below is, hopefully,
> a helpful example of how the calculations should roll up.
> 
> DescriptionQuantityUnit CostTotal Cost
> System  1 21.42
>21.42
>Subsystem 11  12.45
>  12.45
>Assembly 1  24.85
>9.70
>Part 110.10
>  0.10
>Part 221.00
>  2.00
>Part 350.55
>  2.75
>Assembly 2  11.70
>1.70
>Part 420.55
>  1.10
>Part 530.20
>  0.60
>Subsystem 218.97
>  8.97
>Assembly 3  18.97
>8.97
>Subassembly 118.97
>  8.97
>Part 612.98
> 2.98
>Part 715.99
> 5.99
> 
> Clearly, things need to be calculated in the correct order starting
> with Part and working up to System.  I am struggling with a good way
> to "walk" up the tree making all the calculations at one level before
> continuing to the next higher level.  I'm sure it's not as difficult
> as I've convinced myself it is.

I'd proceed recursively (untested/pseudo code):

def value (iter):
if tree.iter_has_child():
val = 0
for index in range( tree.iter_n_children( iter ) ):
val += value( tree.iter_nth_child( iter, i ) )
return val
else:
return  tree.get( iter, 3 )



bye

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] PyObject fails with Gst on signal sync-message::element

[Pietro Battiston]

Il giorno sab, 29/10/2011 alle 10.57 +0200, Angel Guzman Maeso ha
scritto:
> Please, anybody can help me? I search on pygstreamer and GIR files
> code and changelog and there is not reference for changes related with
> syn-message::element.

Nothing to do with the "This signal will not be emitted by default, you
have to set up gst_bus_sync_signal_handler() as a sync handler if you
want this signal to be emitted when a message is posted on the bus, like
this:" I read in the documentation?
(just a guess, I'm not an expert about gstreamer)

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] importing list from another python file

[Pietro Battiston]

This is not a PyGtk related question, but anyway.

Il giorno mer, 26/10/2011 alle 00.42 +0100, ravi ravi ha scritto:
> Hello all,
> 
> I am using python and pygtk to create a GUI. I am storing all the
> values that are to be displayed, in a list.
> --> The values are calculated and stored in a list in the first file
> --> The list is imported in to the second file which is GUI
> file(contains gtk.main()) by using IMPORT statement.
> 
> problem:
> 
> The list is continuously appended in the first file, but this does not
> reflect when imported in to the second file. The second file only
> shows an empty list. I need to get an updated list in my GUI
> file.Please help me out
> 


Just store the list elsewhere. A python script is not the right place to
store data, even less if it is changing.

A good approach would be to use a generic file, with one (list) item per
line, and using glib.io_add_watch to trigger a read().

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Hide scrollbar

[Pietro Battiston]

Il giorno ven, 23/09/2011 alle 12.45 +0200, Hugo Teso ha scritto:
> Hi list!
> 
> I would like to hide the scrollbar of a scrolledwindow but without using
> the gtk.POLICY_NEVER. If I use that policy the text won't be scrolled
> and, as it's quite large, the window grows too much.

Why is gtk.POLICY_AUTOMATIC not fine?

Pietro


> 
> I tried getting the scrollbar with get_vscrollbar() and then using
> hide(), but it doesn't work; also setting a width of 0 for the scrollbar
> won't work.
> 
> Any ideas, please?
> 
> Regards!
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Advice for Debugging Coordinate Translation (my own and cairo's)

[Pietro Battiston]

Il giorno ven, 09/09/2011 alle 12.42 -0400, Jamie Bliss ha scritto:
> This might be considered off-topic, but this is the closest I could
> think of. I need help trying to track down a bug.
> 
> I have an application I'm working called cropper. (Screenshot:
>  Source:
> ) It's basically a tool
> that lets you crop an image in multiple ways at once.
> 
> It's currently suffering from a number of major bugs, but the big one
> that's really bothering me atm is zooming.
> 
> The "workspace" is a single custom widget (ImageSpace, in
> imagespace.py) wrapped in a ScrolledWindow. It has the ability to zoom
> in and out on the content (by setting the zoom property, 1.0 is
> normal, 2.0 is twice as big, 0.5 is half as big). The problem is that
> when zoom != 1.0, it doesn't transform coordinates between the image
> space and widget space correctly.
> 
> For calculations and such, I define two methods (img2widgetcoords and
> widget2imgcoords) for this transformation. (The image is always
> centered in the widget.) But for drawing, I'm using cairo's
> transformation methods.
> 
> As far as I can tell, these two methods should produce the same
> results. But somehow, something's wrong. It's exhibited when creating
> new boxes, in the calculation cache system, and looking at output I
> made specifically for debug (the spot that widget2imgcoords calls
> (0,0) isn't where the upper-right corner of the image).
> 
> Does anyone have any experience they can offer on this? Is this just a
> disconnect between cairo's methods and mine? Am I just doing something
> wrong?
> 

Hello Jamie,

I just gave a very brief look at your code, and have a very brief
suggestion: have you considered using directly Cairo matrix objects to
manage coordinates changes?

That's what I did - notice my problem was sligthly different from yours,
and that code is probably in non-working state - for instance here:

git clone git://pietrobattiston.it/spilla

(if I remember correctly, for instance "transform_point" used in
spillamod/operations.py) and it was very useful - I can always make
drawing bugs, but once I draw, I know clicks are in sync with the
drawing.

> Thank you,

You're welcome, good luck!

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] ScrolledWindow with TreeView is not behaving as expected

[Pietro Battiston]

Giuseppe Penone already answered correctly.

You find a workarounds (a bit old and possibly buggy) here:
http://www.pietrobattiston.it/wiki/pygtk:resizing

Also see this thread if you're interested on some discussion on the
issue:
http://www.daa.com.au/pipermail/pygtk/2009-August/017372.html


bye

Pietro

Il giorno lun, 04/07/2011 alle 10.41 +0200, Giuseppe Penone ha scritto:
> Hi Enrico,
> in my opinion the scrolledwindow behaves correctly.
> The scrolledwindow just takes the size of his parent and can hold
> child
> widgets of any dimension thanks to the scrollbars.
> The scrolledwindow is not supposed to change size according to what
> you place inside.
> Cheers,
> Giuseppe.
> 
> 
> 
> On Sat, Jul 2, 2011 at 20:45, Enrico Minack 
> wrote:
> Hi pygtk users,
> 
> I am facing an unexpected behavior of a Gtk.Window with a
> ScrolledWindow
> containing a TreeView. The window always has minimal size. The
> behavior
> that I desire would be that the Gtk.Window scales as the
> TreeStore /
> TreeView grows until it reaches the limit of the screen. This
> happens
> without the ScrolledWindow. With a ScrolledWindow, the scroll
> bars then
> should appear when the TreeView does not fit the screen.
> 
> I attached demo code. The set_policy method does not lead to
> the desired
> behavior.
> 
> I'd highly appreciate any hints how the resize behavior of the
> ScrollWindow could be manipulated into the desired direction.
> 
> Kind regards,
> Enrico Minack
> 
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/
> 
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] gir1.2-gtk-2.0 and gir1.2-gtk-3.0 together

[Pietro Battiston]

Il giorno gio, 16/06/2011 alle 20.17 +0200, Giuseppe Penone ha scritto:
> Hi all,
> 
> I'm trying (like many others) to port code from pygtk2 to gi.
> 
> I'm running ubuntu 11.04, I first had only gir1.2-gtk-2.0 and, running
> the following lines:
> 
> from gi.repository import Gtk
> print Gtk
> 
> I get  '/usr/lib/girepository-1.0/Gtk-2.0.typelib'>
> 
> then I install also gir1.2-gtk-3.0 (together with gtk3), and running
> the same lines I get:
> 
>  '/usr/lib/girepository-1.0/Gtk-3.0.typelib'>
> 
> so my question is, how can I point to a Gtk version when both 2 and 3
> are installed?


Waiting for someone more competent to answer, I can tell you what I was
explained in chat some time ago:

1) introspection picks the latest installed Gtk version, and you can't
change that,

2) still, that's not a huge problem, because any program you want to
write with introspection, you want to write it for Gtk 3, since
introspection+Gtk2 is more a proof of concept than a production-usable
setup (notice I was searching explanations on how to make a menu popup,
and I discovered it's just not possible).

bye

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] gio.Mount.get_default_location()

[Pietro Battiston]

Il giorno ven, 27/05/2011 alle 11.10 +, Leon Bogaert ha scritto:
> Does anyone know how to get the default location of a gio mount?
> Or maybe knows a place where I could better ask?

Well, if you can affort to migrate to gi...


from gi.repository import Gio

print Gio.Mount.get_default_location





bye

Pietro



> 
> Regards,
> Leon
> 
> 
> From: pygtk-boun...@daa.com.au [pygtk-boun...@daa.com.au] on behalf of Leon 
> Bogaert [l...@tim-online.nl]
> Sent: Wednesday, April 20, 2011 01:11
> To: pygtk@daa.com.au
> Subject: [pygtk] gio.Mount.get_default_location()
> 
> Hi all,
> 
> I'm trying to put something together with python and gio.
> I'm trying to get the default location for a mount (home directory for
> example).
> 
> The c api has a g_mount_get_default_location() function:
> http://developer.gnome.org/gio/2.26/GMount.html#g-mount-get-default-location
> But the python api doesn't (it's not in the docs):
> http://developer.gnome.org/pygobject/stable/class-giomount.html
> 
> Anyone know why this method isn't added? Should I file a bug report
> about this? And where? And is there a another way to get the default
> location?
> 
> Thanks in advance!
> 
> Leon
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] gtk.Builder and memory leak...

[Pietro Battiston]

Il giorno lun, 11/04/2011 alle 18.20 +, Hakan K ha scritto:
> 
> Same behavior with "gtk.glade.XML" object, not only gtk.Builder.
> 
> in attachment, there is a simple window that containing a button. When
> pushes button, it creates a dialog box. When ok button of dialog
> pushes, dialog get destyoyed. 
> 
> problem: approximate every 30 shows of dialog consumes 0.1 Kb of
> memory(linux says it resident memory). 
> is it normal or what is wrong with this code?

As Laszlo told you, you can probably call it "bug", but that's such a
minor bug that it's probably not even worth the effort of reporting.

The wrong thing with your code is that you need to show many times the
same window, and instead than hide()ing and show()ing it every time,
each time you recreate a gtk.glade.XML, retrieve from it the
messagedialog, and finally destroy it.
The smart way is: you have n XML definitions? You'll probably create
only (at most) n gtk.Builder() instances in the course of all the
running time of your app.
> 


> in my previous sample code, i tested code for about 1 hour. Memory
> usage reaches 60 Mb and growing continously.

60 Mb = 18 000 000 messagedialogs open/closed, right?
Or if you prefer, if an user spends 1 month in front of your app,
opening on average 1 messagedialog every 10 seconds, he will have wasted
slightly less than 1 Mb, right?

I admit in an app of mine I'm doing exactly what I suggested to avoid
above, and I guess I still won't loose my sleep tonight.

Pietro

> Please note, memory usage doesn't growing when widgets created with
> code and "gtk.glade.XML" or "gtk.Builder" not used.
> 
> 
> 
> 
> 
> __
> From: hakka...@hotmail.com
> To: pygtk@daa.com.au
> Date: Fri, 8 Apr 2011 16:47:04 +
> Subject: [pygtk] gtk.Builder and memory leak...
> 
> 
> Hi everyone,
> 
> i am learning and writing a pygtk aplication. i have a problem with
> gtk.builder.
> there is very small part of my application code in attachment, for
> test purpose and debugging.
> 
> problem is: 
>   i think, gtk.builder object doesn't destroy completely when owner
> instance destroyed. This causes memory leak. in "system
> monitor" (ubuntu/linux) memory usage growing every time of window
> creation nearly 0.1 kb. (startup memory around 6.3 mb and it exceeds
> 10 mb in minutes and growing)
> 
> small explain for code:
>xTimer instance starting timeout every five secs. on every timer
> event, new window creating and displaying. window destroy itself in 2
> seconds. but it seems to gtk.builder instance of window remains memory
> and causes memory leak.
> 
> * when i disable using gtk.builder and create window with code, no
> memory leaks.
> * when i using using gtk.builder and not calling
> "self.builder.connect_signals(self)", no memory leaks .
> 
> * using ubuntu linux 10.10.   python version 2.6.6
> python-gtk2-dev   2.21.0-0ubuntu1
> * i know that if i create window at application start and use
> show/hide method, it will work. But i want to solve and understand
> this problem :)
> 
> Thanks a lot...
> 
> Hakan Kizilhan
> 
> here is code: (also added as attachment)
> 
> ---main.py-
> 
> import gtk, pygtk, gobject
> 
> #builder = gtk.Builder()
> 
> class Display(object):
> def __init__(self):
> self.builder = gtk.Builder()
> self.builder.add_objects_from_file("gui.glade",
> ["Display_Window"])
> 
> #get widgets
>     ; ; self.display_window =
> self.builder.get_object("Display_Window")
> #self.display_window = gtk.Window()
> self.display_text = self.builder.get_object("Display_Text")
> self.disable_progress =
> self.builder.get_object("DisableProgress")
> 
> self.builder.connect_signals(self)
> 
> #set initials
> self.timer = None
> self.progress = 0
> 
> #timer stuff
> self.timer = gobject.timeout_add(500, self.on_progress_timer)
>  
> #set icon
> pixbuf =
> self.display_window.render_icon(gtk.STOCK_PREFERENCES,
> gtk.ICON_SIZE_MENU)
> self.display_window.set_icon(pixbuf)
> #go on
> self.display_window.show()
> 
> def on_Display_Window_delete_event(self,widget,data=None):
> gobject.source_remove(self.timer)
> self.display_window.destroy()
> 
> 
> def on_progress_timer(self): #timing for window destroy
> seconds = 2
> self.progress = self.progress + ( (1. / seconds) / 2. )
> new_val = self.progress
> 
> if new_val > 1.0:
> # Do Exit#new_val = 0.0
> self.on_Display_Window_delete_event(self)
> return False
> # Set the new value
> print self.progress
> return True
> 
> def on_DisableProgress_button_press_event(self, widget, event):
> 

Re: [pygtk] Hide glade window while running external script

[Pietro Battiston]

Il giorno mer, 06/04/2011 alle 08.31 -0300, Vinicius Massuchetto ha
scritto:
> 2011/4/6 Pietro Battiston :
> > Il giorno mer, 06/04/2011 alle 08.00 -0300, Vinicius Massuchetto ha
> > scritto:
> >> Hi list!
> >>
> >> I think I must be missing some signals concepts here, but I having
> >> trouble reproducing the following behavior:
> >>
> >> 1. Click on a button;
> >> 2. Hide the current window;
> >> 3. Run an external script (that will open another program's window);
> >> 4. Show again the PyGTK window after the external program is closed.
> >>
> >> For that, I've tried something like:
> >>
> >> class Foo:
> >>
> >> def __init__(self):
> >> self.gladefile = gladefile
> >> self.gladetree = gtk.glade.XML(self.gladefile, 'some_window')
> >> self.window = self.gladetree.get_widget('some_window')
> >> events = { 'on_code_submit_clicked' : self.submit }
> >> self.gladetree.signal_autoconnect(events)
> >>
> >> def submit(self):
> >> self.window.hide()
> >> os.system('external_script')
> >> self.window.show()
> >>
> >> What's happening, is that when the button is clicked, it stay pressed,
> >> then the script runs, and after the external program is closed, the
> >> window "blinks", being hidden and shown again.
> >>
> >> I also tried the "pressed" and "released" signals.
> >>
> >> What I can imagine is that the event is being run _during_ the
> >> _clicked_ event, not after. That's why the window remain opened. I
> >> couldn't find something like `gtk_signal_connect_after` [1] on the
> >> glade page [2], that leaves me totally lost about it.
> >>
> >
> >
> > There may be cleaner solutions, but the first thing which comes to my
> > mind is replacing
> >os.system('external_script')
> > with
> >glib.idle_add(os.system, 'external_script')
> > (and maybe replacing "os.system" with "subprocess.call" - but that's not
> > pygtk-related).
> 
> Doing `glib.idle_add (subprocess.call, ['external_script', 'param'])`
> will make the window to:
> 
> 1. Disappear;
> 2. Appear with no content;
> 3. Run the external script;
> 4. Fill the window with content when closing the external program
> 


You see, that's already something!

Seriously, replacing "self.window.show()" with
"glib.idle_add(self.window.show)" should now get you done. Or in
alternative replacing 

os.system('external_script')
self.window.show()
with

glib.idle_add(self.run_script)

def run_script(self):
subprocess.call(['external_script', 'param'])
self.window.show()


Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Hide glade window while running external script

[Pietro Battiston]

Il giorno mer, 06/04/2011 alle 08.00 -0300, Vinicius Massuchetto ha
scritto:
> Hi list!
> 
> I think I must be missing some signals concepts here, but I having
> trouble reproducing the following behavior:
> 
> 1. Click on a button;
> 2. Hide the current window;
> 3. Run an external script (that will open another program's window);
> 4. Show again the PyGTK window after the external program is closed.
> 
> For that, I've tried something like:
> 
> class Foo:
> 
> def __init__(self):
> self.gladefile = gladefile
> self.gladetree = gtk.glade.XML(self.gladefile, 'some_window')
> self.window = self.gladetree.get_widget('some_window')
> events = { 'on_code_submit_clicked' : self.submit }
> self.gladetree.signal_autoconnect(events)
> 
> def submit(self):
> self.window.hide()
> os.system('external_script')
> self.window.show()
> 
> What's happening, is that when the button is clicked, it stay pressed,
> then the script runs, and after the external program is closed, the
> window "blinks", being hidden and shown again.
> 
> I also tried the "pressed" and "released" signals.
> 
> What I can imagine is that the event is being run _during_ the
> _clicked_ event, not after. That's why the window remain opened. I
> couldn't find something like `gtk_signal_connect_after` [1] on the
> glade page [2], that leaves me totally lost about it.
> 


There may be cleaner solutions, but the first thing which comes to my
mind is replacing
os.system('external_script')
with
glib.idle_add(os.system, 'external_script')
(and maybe replacing "os.system" with "subprocess.call" - but that's not
pygtk-related).

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] centralized multiple instances of a pygtk app

[Pietro Battiston]

Il giorno ven, 01/04/2011 alle 17.49 +0200, Giuseppe Penone ha scritto:
> The project is not big and complex, no hard to change, it's just me
> that have not clear how to behave yet.
> 
> You say in gedit there's always one process, I don't understand how he
> can listen to the attempt of the user to open a new file,
> a server should always be in a dedicated process... maybe I'll try to
> search in gedit code.

Gedit was only an example of how a single process can manage different
windows, not of how a single process can receive new calls from it being
executed (because gedit does that through DBus, which is not a solution
for you).

But once you switch to the "one process, any number of windows"
principle, then _that_ single process can spawn, with multiprocessing,
its server, stuck listening, and any new process will just tell _that_
server what to open, and then would die in peace.

For instance, currently when I ask CherryTree to create a new instance,
the currently open one is closed. Instead, the app could open it in a
new window. Being able to do something like that that doesn't solve the
problem of the communication with new processes independently spawned,
but seems to me a first step.

Pietro



> 
> Giuseppe.
> 
> 
> 
> On Fri, Apr 1, 2011 at 8:26 AM, Pietro Battiston
>  wrote:
> Il giorno gio, 31/03/2011 alle 23.59 +0200, Giuseppe Penone ha
> scritto:
> > The reason to have more instances in my app
> (giuspen.com/cherrytree)
> > is that the user can have more tree notes and copy/paste
> from one to
> > the other.
> 
> 
> Again, "instances" != "processes". Take gedit: as many
> toplevel windows
> as you want, each one with as many open notebooks as you want,
> you
> obviously can copy/paste from one to the other... and still,
> only one
> process running at any time.
> 
> Then, if you're saying that your project is big, complex and
> now it's
> too hard to change, that's another point. But if that's the
> point, my
> impression is that _whatever_ communication mechanism you use,
> it will
> be very hard to coordinate open instances: for instance, even
> if you
> could use DBus, what of the many open processes would act as a
> server?!
>     
> Pietro
> 
> 
> 
> 
> >
> > Cheers,
> > Giuseppe.
> >
> >
> >
> > On Thu, Mar 31, 2011 at 9:30 PM, Pietro Battiston
> >  wrote:
> > Il giorno gio, 31/03/2011 alle 20.44 +0200, Giuseppe
> Penone ha
> > scritto:
> > > ok, so you advice that every instance of the app
> would have
> > his own
> > > server (this is the only way any independent
> instance can
> > listen and
> > > control the window in shared memory)
> > >
> >
> >
> >
> > Well, frankly speaking I started from the assumption
> that at
> > every
> > moment there will be only _one_ instance of the app
> (with its
> > own
> > server), handling all the windows. Every time the
> user calls
> > it, a new
> > one starts, but dies within moments, and tells the
> original
> > one to open
> > the file (or open an empty window if no filename is
> given,
> > that depends
> > on the app).
> > Is there some particular reason why you must have
> more
> > instances running
> > at the same time?
> > If there is, then my idea is still extendable, but
> things
> > become indeed
> > more complex.
> >
> > Pietro
> >
> >
> >
> 
> 
> 
> 
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/
> 
> 


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] centralized multiple instances of a pygtk app

[Pietro Battiston]

Il giorno gio, 31/03/2011 alle 23.59 +0200, Giuseppe Penone ha scritto:
> The reason to have more instances in my app (giuspen.com/cherrytree)
> is that the user can have more tree notes and copy/paste from one to
> the other.

Again, "instances" != "processes". Take gedit: as many toplevel windows
as you want, each one with as many open notebooks as you want, you
obviously can copy/paste from one to the other... and still, only one
process running at any time.

Then, if you're saying that your project is big, complex and now it's
too hard to change, that's another point. But if that's the point, my
impression is that _whatever_ communication mechanism you use, it will
be very hard to coordinate open instances: for instance, even if you
could use DBus, what of the many open processes would act as a server?!

Pietro



> 
> Cheers,
> Giuseppe.
> 
> 
> 
> On Thu, Mar 31, 2011 at 9:30 PM, Pietro Battiston
>  wrote:
> Il giorno gio, 31/03/2011 alle 20.44 +0200, Giuseppe Penone ha
> scritto:
> > ok, so you advice that every instance of the app would have
> his own
> > server (this is the only way any independent instance can
> listen and
> > control the window in shared memory)
> >
> 
> 
> 
> Well, frankly speaking I started from the assumption that at
> every
> moment there will be only _one_ instance of the app (with its
> own
> server), handling all the windows. Every time the user calls
> it, a new
> one starts, but dies within moments, and tells the original
> one to open
> the file (or open an empty window if no filename is given,
> that depends
> on the app).
> Is there some particular reason why you must have more
> instances running
> at the same time?
> If there is, then my idea is still extendable, but things
> become indeed
> more complex.
> 
> Pietro
> 
> 
> 


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] centralized multiple instances of a pygtk app

[Pietro Battiston]

Il giorno gio, 31/03/2011 alle 20.44 +0200, Giuseppe Penone ha scritto:
> ok, so you advice that every instance of the app would have his own
> server (this is the only way any independent instance can listen and
> control the window in shared memory)
> 


Well, frankly speaking I started from the assumption that at every
moment there will be only _one_ instance of the app (with its own
server), handling all the windows. Every time the user calls it, a new
one starts, but dies within moments, and tells the original one to open
the file (or open an empty window if no filename is given, that depends
on the app).
Is there some particular reason why you must have more instances running
at the same time?
If there is, then my idea is still extendable, but things become indeed
more complex.

Pietro

> 
> On Thu, Mar 31, 2011 at 8:42 PM, Pietro Battiston
>  wrote:
> Il giorno gio, 31/03/2011 alle 20.27 +0200, Pietro Battiston
> ha scritto:
> 
> > Il giorno gio, 31/03/2011 alle 20.01 +0200, Giuseppe Penone
> ha scritto:
> > >
> > > (Assuming that indeed there's no way of using
> sockets in a
> > > non-blocking
> > > fashion - I'm totally ignorant about that) maybe
> having a
> > > little process
> > > created with multiprocessing would be simpler &
> more portable,
> > > for you,
> > > than using threading? I guess a single one is
> sufficient, so
> > > the
> > > overhead shouldn't be significant, even on
> Windows. Then, at
> > > every
> > > iteration of the main loop, the main process could
> check, from
> > > a shared
> > > Value (or Array), if there's something to open.
> > >
> > > (untested, sorry if I wrote something stupid)
> > >
> > > Hi Pietro,
> > > the problem of having a single and independent process
> dedicated to
> > > the job of server is that the server would not be able to
> rise a
> > > minimized/hidden window as consequence of the situation "a
> new file
> > > open starts (user double click) unaware that the same file
> is already
> > > opened".
> >
> >
> > The server should not, that would be the job of the main
> process...
> >
> > User: "Hey, program, open that file"
> > Main process1: starts, spawns the server through the
> multiprocessing
> > module
> > Server1: "Hey, main process, there is no open instance, have
> fun"
> > Main process1: "thanks", opens the file in a new window
> >
> > later...
> >
> > User: "Hey, program, open that file"
> > Main process2: starts, spawns the server through the
> multiprocessing
> > module
> > Server2: "hey, Main process2, there is an already open
> instance!"
> > Main process2: "OK, tell it to open that file!"
> > Server2: "Server1, could you please tell you friend Main
> process to open
> > that file?"
> > Server1: "Sure, Server2!"
> > (Main process2 & Server2 exit)
> > Server1: "Hey, Main process2,
> 
> 
> Sorry Server1, but that's Main process1.
> 
> 
> Pietro
> 
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/
> 
> 


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] centralized multiple instances of a pygtk app

[Pietro Battiston]

Il giorno gio, 31/03/2011 alle 20.27 +0200, Pietro Battiston ha scritto:
> Il giorno gio, 31/03/2011 alle 20.01 +0200, Giuseppe Penone ha scritto:
> > 
> > (Assuming that indeed there's no way of using sockets in a
> > non-blocking
> > fashion - I'm totally ignorant about that) maybe having a
> > little process
> > created with multiprocessing would be simpler & more portable,
> > for you,
> > than using threading? I guess a single one is sufficient, so
> > the
> > overhead shouldn't be significant, even on Windows. Then, at
> > every
> > iteration of the main loop, the main process could check, from
> > a shared
> > Value (or Array), if there's something to open.
> > 
> > (untested, sorry if I wrote something stupid)
> > 
> > Hi Pietro,
> > the problem of having a single and independent process dedicated to
> > the job of server is that the server would not be able to rise a
> > minimized/hidden window as consequence of the situation "a new file
> > open starts (user double click) unaware that the same file is already
> > opened".
> 
> 
> The server should not, that would be the job of the main process...
> 
> User: "Hey, program, open that file"
> Main process1: starts, spawns the server through the multiprocessing
> module
> Server1: "Hey, main process, there is no open instance, have fun"
> Main process1: "thanks", opens the file in a new window
> 
> later...
> 
> User: "Hey, program, open that file"
> Main process2: starts, spawns the server through the multiprocessing
> module
> Server2: "hey, Main process2, there is an already open instance!"
> Main process2: "OK, tell it to open that file!"
> Server2: "Server1, could you please tell you friend Main process to open
> that file?"
> Server1: "Sure, Server2!"
> (Main process2 & Server2 exit)
> Server1: "Hey, Main process2,

Sorry Server1, but that's Main process1.

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] centralized multiple instances of a pygtk app

[Pietro Battiston]

Il giorno gio, 31/03/2011 alle 20.01 +0200, Giuseppe Penone ha scritto:
> 
> (Assuming that indeed there's no way of using sockets in a
> non-blocking
> fashion - I'm totally ignorant about that) maybe having a
> little process
> created with multiprocessing would be simpler & more portable,
> for you,
> than using threading? I guess a single one is sufficient, so
> the
> overhead shouldn't be significant, even on Windows. Then, at
> every
> iteration of the main loop, the main process could check, from
> a shared
> Value (or Array), if there's something to open.
> 
> (untested, sorry if I wrote something stupid)
> 
> Hi Pietro,
> the problem of having a single and independent process dedicated to
> the job of server is that the server would not be able to rise a
> minimized/hidden window as consequence of the situation "a new file
> open starts (user double click) unaware that the same file is already
> opened".


The server should not, that would be the job of the main process...

User: "Hey, program, open that file"
Main process1: starts, spawns the server through the multiprocessing
module
Server1: "Hey, main process, there is no open instance, have fun"
Main process1: "thanks", opens the file in a new window

later...

User: "Hey, program, open that file"
Main process2: starts, spawns the server through the multiprocessing
module
Server2: "hey, Main process2, there is an already open instance!"
Main process2: "OK, tell it to open that file!"
Server2: "Server1, could you please tell you friend Main process to open
that file?"
Server1: "Sure, Server2!"
(Main process2 & Server2 exit)
Server1: "Hey, Main process2, seems like the user wants to open that
file"
Main process1: as it does in every iteration of the main loop, scans for
new info from the Server1, finds a new filename to open, remembers it's
already opened in some window, rises that window.



(again, maybe I just missed something trivial, but at least that should
be able to avoid any additional misunderstandings)

(notice that _in any case_, with gtk, it is sane to play with GUI only
from one thread/process)

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] centralized multiple instances of a pygtk app

[Pietro Battiston]

Il giorno mer, 30/03/2011 alle 13.50 +0200, Giuseppe Penone ha scritto:
> I found some tips on threading on pygtk
> (http://faq.pygtk.org/index.py?file=faq20.006.htp&req=show) so I tried
> gtk.threads_enter()
> 
> gtk.main()
> gtk.threads_leave()
> that works on the first opened instance but then crashes on the
> second.
> 
> If anybody has a clue about treating many instances of the same app
> being aware of an already running instance/able to
> control the already running instance rather than spawning a new one
> please help me.
> 


(Assuming that indeed there's no way of using sockets in a non-blocking
fashion - I'm totally ignorant about that) maybe having a little process
created with multiprocessing would be simpler & more portable, for you,
than using threading? I guess a single one is sufficient, so the
overhead shouldn't be significant, even on Windows. Then, at every
iteration of the main loop, the main process could check, from a shared
Value (or Array), if there's something to open.

(untested, sorry if I wrote something stupid)

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] self from gtk.builder

[Pietro Battiston]

Il giorno lun, 06/12/2010 alle 00.28 +, Leon Bogaert ha scritto:
> Thanks Marco,
> 
> Messing with __getattr__... I think I'm going to let that pass. It feels 
> kinda messy.
> I'm just begining with gtk and I've been browsing through other people's code 
> but I find it difficult to organize my gtk code.
> 

Anyway, the main message is: if you must use a widget created through a
glade file, you can live without subclassing it. For the "ordinary"
operations, you can just do

class ActionsMenu(object):
def __init__(self, widget):
self.widget = widget

and then access the "widget" argument when you need it; if instead you
have to override some method, you can do

class ActionsMenu(object):
def __init__(self, widget):
self.widget = widget
self.widget.do_size_request = my_newly_written_size_request


My personal (and not particularly authoritative) impression is that
while in the traditional pygtk approach you (grossly speaking) create a
subclass for each "important" widget in your app, when you use
glade/gtk.Builder you just create subclasses for "conceptually
important" objects, which may then be related to (and have as members)
0, 1, or many widgets each. And that this is, in the end, the
traditional way to organize Python code.


Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] gtk.Builder problem

[Pietro Battiston]

Il giorno gio, 25/11/2010 alle 23.04 +0200, Vladimir Gordeev ha scritto:
> builder.connect_signals has no effect
> 
> If I connect signals manualy -- it works.
> But using connect_signals does nothing.

First the bad news: to use connect_signals you have to go, in Glade, in
the "Signals" tab of the widget of your like, and set, for each signal
you want to connect to, the name of the handler.

Then the good news: assume for instance that you have assigned to the
signal "destroy" of your dialog the name "close_app"; then you can just
replace your code

builder.connect_signals({
# any of these don't work
'on_dialog1_delete' : self.close_app,
'on_dialog1_destroy' : self.close_app,
'on_dialog1_close' : self.close_app,
 })


with

builder.connect_signals( self )


have fun!

Pietro   

> 
> 
> 
> import pygtk
> pygtk.require('2.0')
> import gtk
> 
> class Application(object):
> 
> def close_app(self, widget, data=None):
> gtk.main_quit()
> 
> def __init__(self):
> builder = gtk.Builder()
> builder.add_from_file('test.glade')
> 
> self._test = builder.get_object('dialog1')
> # uncommenting this line gets expected behaviour
> # gtk.main_quit() will be called
> #self._test.connect('delete-event',
> self.close_app)
> builder.connect_signals({
> # any of these don't work
> 'on_dialog1_delete' : self.close_app,
> 'on_dialog1_destroy' : self.close_app,
> 'on_dialog1_close' : self.close_app,
> })
> 
> self._test.show()
> 
> if __name__=='__main__':
> app = Application()
> gtk.main()
> 
> 
> 
> test.glade is:
> ---
> 
> 
>   
>   
>   
> 5
> normal
> False
> 
>   
> True
> 2
> 
>   
> True
> True
> 2010
> 10
> 25
>   
>   
> 1
>   
> 
> 
>   
> True
> end
> 
>   
> button
> True
> True
> True
>   
>   
> False
> False
> 0
>   
> 
> 
>   
> button
> True
> True
> True
>   
>   
> False
> False
> 1
>   
> 
>   
>   
> False
> end
> 0
>   
> 
>   
> 
> 
>   button1
>   button2
> 
>   
> 
> 
> 
> Gtk+ version is 2.21.1
> PyGTK version is 2.17.0
> Glade version is 3.6.7
> 
> All simply installed from ubuntu repository.
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] R: Re: Clock in Pygtk but in one or more windows

[Pietro Battiston]

Il giorno ven, 05/11/2010 alle 20.33 +0100, svabodaf...@libero.it ha
scritto:
> Maybe I have not expressed well .. I want to create a clock at the top or 
> bottom of the window of my application and maybe even add the date.
> Searching Google I found only examples of clock graphs, but external 
> applications and windows owner, like this : http://ralph-glass.homepage.t-
> online.de/clock/readme.html
> but is not what I want to do.

Well, just to be sure: your application is written with pygtk, right?

If it is, at some point you are creating a toplevel window which has
some widget inside.

1) If this widget is already a VBox or a Table, you can simply follow
the tutorial (or use a label if you don't want the graphic clock) and
insert the drawing area (or the label) at the top (instead than creating
the gtk.Window object).

2) If it is not, then encapsulate it in a VBox or a Table (which in turn
is contained in the toplevel window), and go back to 1).


The problem is: I'm assuming that you know _something_ of pygtk. Is this
assumption correct, perfect. If it is not, notice you probably won't
find a tutorial explaining how to integrate a clock in _your_ particular
application.

bye

Pietro

> 
> Thanks
> 
> 
> 
> 
> 
> >Messaggio originale
> >Da: m...@pietrobattiston.it
> >Data: 05/11/2010 16.53
> >A: "svabodaf...@libero.it"
> >Cc: 
> >Ogg: Re: [pygtk] Clock in Pygtk but in one or more windows
> >
> >Il giorno ven, 05/11/2010 alle 16.19 +0100, svabodaf...@libero.it ha
> >scritto:
> >> Hello !
> >> 
> >> 
> >> I need to show the updated time in a window (or label).
> >> 
> >> I was looking a example with Tkinter but I do not know how to
> >> integrate in a pygtk window or do it in different way. 
> >> 
> >> Any help will be appreciate.
> >
> >To create a clock in pygtk, I would start from any of the examples that
> >comes out when googling "pygtk clock", not from a tkinter clock.
> >
> >Pietro
> >
> 
> 
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Clock in Pygtk but in one or more windows

[Pietro Battiston]

Il giorno ven, 05/11/2010 alle 16.19 +0100, svabodaf...@libero.it ha
scritto:
> Hello !
> 
> 
> I need to show the updated time in a window (or label).
> 
> I was looking a example with Tkinter but I do not know how to
> integrate in a pygtk window or do it in different way. 
> 
> Any help will be appreciate.

To create a clock in pygtk, I would start from any of the examples that
comes out when googling "pygtk clock", not from a tkinter clock.

Pietro


signature.asc
Description: This is a digitally signed message part
___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] gtk.Assistant

[Pietro Battiston]

Il giorno mar, 12/10/2010 alle 21.16 +0200, Mauro Giacomini ha scritto:
> Hello,
> I'm not able to use the assistant the way I want :(
> Perphas this widget is not solution for my needs.
> 
> In general, there is a way to use the assistant widget in this way:
> - Page One: the user selects various option via a gui
> - Page Two: the app use this option to choose which text to display to 
> continue the configuration;

Sure you can: as I said, connect to the "changed" options of widgets in
page one, and update, or even create from scratch page two accordingly.

Or even better, connect to the "apply" signal of the Assistant and
create one page at a time. Just take care of the fact that the user may
press the "back" button (and "forward" again).


>  From what I understand, the pages are created all at once

Not necessarily. You just create them when you want.

>  and displayed 
> on screen one at a time.
> But in this way I can't never collect data from page one and use it on 
> page two; I can only collect
> this data in the last page of the assistant, a page of type 
> gtk.ASSISTANT_PAGE_SUMMARY.
> Am I right?

No.

If you still have problems using signals right, please provide some
almost working code.

> Do you know any pygtk application that has a wizard configuration so I 
> can study the source code?

http://www.google.com/codesearch?hl=it&sa=N&q=gtk.Assistant+lang:python

And I guess ubiquity does too.

Pietro



> 
> Thanks for all, Mauro
> 
> Il 12/10/2010 19:12, Pietro Battiston ha scritto:
> > Il giorno mar, 12/10/2010 alle 18.53 +0200, Mauro Giacomini ha scritto:
> >
> >> Yes, you undestood correcty what I want to do.
> >> I have already tried to connect a signal from a button (user click when
> >> the treeview
> >> is sorted) to call "set_page_complete(page, True)", but, as you said
> >> previously, this don't
> >> block the flow of code, so I can't collect the data in the next page.
> >> [...]
> >> Now I want to try another way I found in this list, this post
> >> (http://www.mail-archive.com/pygtk@daa.com.au/msg19549.html).
> >> In step_two() I can call "get_children" from the assistant to retrieve
> >> the previous page (step_one)
> >> and from this page I call "get_data" from the treeview.
> >> I will try this ...
> >>  
> >
> > The fact that the flow of code is not blocked should not be a problem at
> > all.
> >
> > And there is no particular need to use get_children, you can just
> > replace, for instance
> >
> >  page_n = gtk.SomeWidget()
> >
> > with
> >
> >  self.page_n = gtk.SomeWidget()
> >
> > and you can do that not just with whole pages, but with single widgets
> > too (possibly organizing them in lists/dictionaries if there are many).
> >
> > If you use Glade and a gtk.Builder, it's even easier (with
> > get_object() ).
> >
> > Pietro
> >
> >
> >


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] gtk.Assistant

[Pietro Battiston]

Il giorno mar, 12/10/2010 alle 18.53 +0200, Mauro Giacomini ha scritto:
> Yes, you undestood correcty what I want to do.
> I have already tried to connect a signal from a button (user click when 
> the treeview
> is sorted) to call "set_page_complete(page, True)", but, as you said 
> previously, this don't
> block the flow of code, so I can't collect the data in the next page.
> [...]
> Now I want to try another way I found in this list, this post 
> (http://www.mail-archive.com/pygtk@daa.com.au/msg19549.html).
> In step_two() I can call "get_children" from the assistant to retrieve 
> the previous page (step_one)
> and from this page I call "get_data" from the treeview.
> I will try this ...


The fact that the flow of code is not blocked should not be a problem at
all.

And there is no particular need to use get_children, you can just
replace, for instance

page_n = gtk.SomeWidget()

with

self.page_n = gtk.SomeWidget()

and you can do that not just with whole pages, but with single widgets
too (possibly organizing them in lists/dictionaries if there are many).

If you use Glade and a gtk.Builder, it's even easier (with
get_object() ).

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] gtk.Assistant

[Pietro Battiston]

Il giorno lun, 11/10/2010 alle 21.17 +0200, Mauro Giacomini ha scritto:
> Il 11/10/2010 19:45, Pietro Battiston ha scritto:
> I write a pseudo-code that can hel you and the others to identify my 
> problem.
> 
> class MyAssistant:
>  def __init__(self):
>  step_one()
>  step_two()
>  step_finale()
> 
>  def step_one(self):
>  text to welcome the user
>  treeview
>  button_up
>  button_down
>  button_apply
>  button_apply.connect('clicked', self.on_confirm_sort_treeview)
> 
>  def on_confirm_sort_treeview(self, button, data = None):
>  I mark page_one of assistant as complete
> 
>  def step_two(self):
>  here I wanto to collect the data from treeview in the order the 
> user set them,
>  so I can operate on them
>  (1)
> 
>  def step_finale(self):
>  confirm all the user parameters
> 
> (1) In this point I can't be able to collect the information of the 
> treeview, so I can't operate on them.

If I understand correctly, your problem is that you think that "step_n"
runs during the time that the user sees the nth page of the assistant.
That's not the way in which the Assistant generally works: you just fill
pages in advance, and then you let the user move along them.

If you have to call "set_page_complete" based on the content/status of
some treeview, probably (depending on what you really need) the best
thing is to just connect to the "changed" signal of the TreeSelection,
and in the callback for that signal check if everything is fine and in
case call "set_page_complete( that_page, True )". You can connect also
to the "changed" signal of more than one widget.

Alternatively, you can monitor the Assistant with some callback called
by glib.timeout_add(), but I think that's generally more difficult to
manage smartly.

> If I put a "print" in every step_*() functions to simply debug my app, 
> on screen I see all the text printed at the beginning of the app.

Yes, that's normal: you first prepare all the pages, then run the
Assistant; its methods do not block the flow of code.

> Hope I described good what I want.
> 
> Maybe I can't fully understood the Assistant Widget and I'm using it bad.
> I mean that until a page in an Assistant isn't marked as "completed", 
> the user-iteration is in a "waiting-mode"
> 
> I googled to search how to use an Assistant, but the tutorials I found 
> are few and not fully explained.

I hope I've clarified a bit. I guess you already seen
http://www.learnpygtk.org/pygtktutorial/assistant.html ?

bye

Pietro

> 
> Thanks, Mauro
> 
> 
> 
> > Il giorno lun, 11/10/2010 alle 19.09 +0200, Mauro Giacomini ha scritto:
> >
> >> Hi,
> >> I have a problem with the creation of an Assistant.
> >>  
> > Ehm... which problem?
> >
> > Pietro
> >
> >
> >> I want to collect information from the user.
> >> In the first page I have a treeview with 3 button (move_up, move_down
> >> and apply).
> >> Until the user don't click on Apply Button, the navigation on the
> >> Assistant is unsensitive.
> >> When the user finished to sort the treeview with the up and down button
> >> and click Apply button, the Next button on Assistant became sensitive
> >> and the user can click it to procede to the second page.
> >> In the second page I want to collect the data from the treeview to make
> >> further processing.
> >> If I have to post some code, tell me, and I will try to post code that
> >> can be executed.
> >> But keep in mind this Assistant is a piece of a bigger project I'm
> >> working on.
> >>
> >> Thanks in advance, Mauro
> >> PS: Sorry for my English, I'm an Italian guy.
> >> ___
> >> pygtk mailing list   pygtk@daa.com.au
> >> http://www.daa.com.au/mailman/listinfo/pygtk
> >> Read the PyGTK FAQ: http://faq.pygtk.org/
> >>  
> >
> >
> >
> 
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] gtk.Assistant

[Pietro Battiston]

Il giorno lun, 11/10/2010 alle 19.09 +0200, Mauro Giacomini ha scritto:
> Hi,
> I have a problem with the creation of an Assistant.

Ehm... which problem?

Pietro

> I want to collect information from the user.
> In the first page I have a treeview with 3 button (move_up, move_down 
> and apply).
> Until the user don't click on Apply Button, the navigation on the 
> Assistant is unsensitive.
> When the user finished to sort the treeview with the up and down button 
> and click Apply button, the Next button on Assistant became sensitive 
> and the user can click it to procede to the second page.
> In the second page I want to collect the data from the treeview to make 
> further processing.
> If I have to post some code, tell me, and I will try to post code that 
> can be executed.
> But keep in mind this Assistant is a piece of a bigger project I'm 
> working on.
> 
> Thanks in advance, Mauro
> PS: Sorry for my English, I'm an Italian guy.
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] dialog response

[Pietro Battiston]

Il giorno sab, 14/08/2010 alle 16.55 +0100, Andrew ha scritto:
> On 09/08/10 10:17, Imre Horvath wrote:
> > Hi!
> > 
> > I've got a dialog, with Ok and Cancel buttons in the actionarea (I'm
> > using gtkbuilder)
> > I want to validate the dialog data. I write an action handler for the Ok
> > button that validates it, but i need the dialog remain open when
> > validation fails. How can i do this?
> > 
> > Thanks in advance:
> > Imre Horvath
> > 
> > ___
> > pygtk mailing list   pygtk@daa.com.au
> > http://www.daa.com.au/mailman/listinfo/pygtk
> > Read the PyGTK FAQ: http://faq.pygtk.org/
> 
> Hi Imre,
> 
> I assume you are using dialog.run(), this will hide the dialog when a
> user clicks an actionarea button

Uhm... as far as I know that's not true...

> and so will not keep the dialog open.
> Instead you could use dialog.show_all() and hide the dialog in a
> callback of one of the buttons.


> 
> Does this make sense? If not please could you post your code?
> 


I think there are two clean approaches (I used both, in different
cases):
1) the dialog is ran in a loop, which always run()s it again when the
data validity check is no passed (possibly after showing an error
message)
2) the buttons are initially unsensitive and a function, which runs
several times per second and checks the validity, takes care of setting
them (un)sensitive

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] push huge array into liststore

[Pietro Battiston]

Il giorno lun, 12/07/2010 alle 17.48 +0200, Cornelius Kölbel ha scritto:
> Dear list,
> 
> I got an array of dictionaries, that I want to add to a GTKListStore,
> that is displayed an a treeview.
> 
> This is very slow. I already replaced the liststore.append by
> liststore.insert, which is much much faster.
> But still, filling the 10.000 values takes about 50 seconds.
> 
> Is there any cool mapping function, to push the array to the liststore?
> I used a for loop to iterate over the array...
> I also tried while an to pop the array elements...
> 
> It is something like this:
> 
> data: array of dictionaries
> 
> data = array( { 'v1' : 'something', 'v2': 'something else' } ,
>   { 'v1' : 'another',   'v2': 'something completely diff' }
>   )
>  
> 
> for d in data:
>self.liststore.insert( 0, ( d.get("v1"), d.get("v2") ))
> 
> 
> ...is there a better way than doing a for loop?
> ...or a way to not have to interate over the 10.000 dicts?
> 
> ...or is there a cool reading on performance tuning pyton?



I really don't know, but... already read
http://faq.pygtk.org/index.py?req=show&file=faq13.043.htp
?

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] FileChooserButton forgets changed file

[Pietro Battiston]

Il giorno lun, 12/07/2010 alle 11.04 +0200, Tobias Weber ha scritto:
> 
> No. It's very simple. Opinions on this are divided, but the fact is
> that most software doesn't change files, it creates a new one and
> moves it over the old one. So the file you selected ceases to exist,
> and therefore gets deselected. It doesn't matter that right after that
> another file with the same name appears. 

I see what you mean. Since the bug already exists, I answered here:

https://bugzilla.gnome.org/show_bug.cgi?id=624136#c1

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] FileChooserButton forgets changed file

[Pietro Battiston]

Il giorno lun, 12/07/2010 alle 10.04 +0800, Jason Heeris ha scritto:
> > I couldn't reproduce what you're seeing unless I'm doing something wrong, 
> > which is likely.
> 
> Basically, run the script, select a file, click "Check". Keep the app
> open, but change the contents of the selected file and save it. Keep
> clicking "check" and the file name has changed to another one in the
> directory. (But if there's no other file in the directory with your
> first file, it doesn't change!)
> 
> I see this on Debian (pygtk 2.17.0) and Windows (git, window branch).
> 
> > self.fcb.get_file().get_path() instead of self.fcb.get_filename()
> 
> No difference :/

I can reproduce this (Debian, 2.17.0 too)...

And I can't see any explanation but "it's a bug".

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] idle_add vs. threads_enter/threads_leave

[Pietro Battiston]

Il giorno lun, 05/07/2010 alle 18.55 +0800, Jason Heeris ha scritto:
> On 5 July 2010 18:32, Pietro Battiston  wrote:
> > You wouldn't need threading if you could do:
> 
> > def do_processing(self):
> >if self.counter < 1000:
> >import time
> >time.sleep(.01)
> >return True
> >self.counter += 1
> >self.emit('processing-done')
> 
> Well... this in itself wouldn't work, since anything after the
> "return" would be skipped.

Uhm sure.

> But I hadn't thought of this before — you
> could make this into a generator (replace "return" with "yield"), and
> somehow wrap it in a "for" loop that did what idle_add expects. But
> now we're getting kind of close to rolling our own threading
> implementation, which seems a bit hacky.

Personally, I find that when the lenghty operation can be fragmented in
small enough parts, this is not hacky, this is perfectly natural (much
more than having threads or even other event loops misteriously flowing
around).

When the operation _can't_ be fragmented, again it's not hacky, it's
just impossible.


If you want an example, my "gvb" app, which you can find in
Debian/Ubuntu, doesn't use threading at all (and multiprocess neither).
That's a problem in the initializations, which take a lot of time and
block the UI, but for drawing a frame at a time it's perfect - and
notice "frames" of the simulation _don't necessarily correspond_ to
frames rendered to screen.

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] idle_add vs. threads_enter/threads_leave

[Pietro Battiston]

Il giorno lun, 05/07/2010 alle 18.09 +0800, Jason Heeris ha scritto:
> On 5 July 2010 17:53, Pietro Battiston  wrote:
> > Apart from 2.c, I guess
> > http://faq.pygtk.org/index.py?file=faq20.006.htp&req=show
> > is clear enough?
> 
> It's clear, except I can't tell if it applies to PyGObject 2.20 or
> 2.21 (the idle_add function moves between glib and gobject depending
> on the version, but I have no idea at what version it first changed).
> 

idle_add, timeout_add_defaults... moved to glib but you can still find
it in gobject in 2.21, I guess simply for backward compatibility.

And anyway, that doesn't concern threads: I didn't experience any break
in applications using threading that I wrote one year ago.

> >>   3. I don't need to do the threads_enter/leave (or use the context
> >> manager) if I only use glib.idle_add (or timeout_add, etc)
> >
> > No, you don't. If you don't really need threads, life is much simpler.
> 
> Indeed. But a time consuming activity still locks the UI. As a trivial 
> example:
> 
> 
> def do_processing(self):
> import time
> time.sleep(10)
> self.emit('processing-done')
> 
> def on_button_clicked(self, widget):
> glib.idle_add(self.do_processing)
> 

Sure... in that case you _do_ really need threads... I simply don't know
what's your case. You wouldn't need threading if you could do:


def do_processing(self):
if self.counter < 1000:
import time
time.sleep(.01)
return True
self.counter += 1
self.emit('processing-done')

def on_button_clicked(self, widget):
self.counter = 0
glib.idle_add(self.do_processing)


Notice the final effect is still sleeping 10 seconds.


> 
> ...will still cause a 10 second hang when the GTK main loop gets
> around to running "do_processing".
> 
> Having said that, I'm trying to write something that runs on Linux and
> Windows. Since GTK threads under win32 are mysterious and feared,
> threads aren't really the answer *anyway*.
> 

I don't know what are your needs: a nice solution could be the
multiprocess module.

But anyway, you find yourself really needing threading, I seem to
understand that using them but not making them directly interact with
the GUI is considered "win-safe" (though I never tested personally on
windows, that is the way I always used threads in pygtk).

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] idle_add vs. threads_enter/threads_leave

[Pietro Battiston]

Il giorno lun, 05/07/2010 alle 16.32 +0800, Jason Heeris ha scritto:
> Hi,
> 
> I've been reading some conflicting advice on PyGTK and threading
> recently, probably because the API went through some fairly rapid
> changes recently.
> 
> I'm a bit confused about the following points (consider them in
> context of PyGTK/PyGObject unstable, ie. 2.17/2.21 respectively):
> 
>   1. If I want to do async activity in a new Python thread spawned
> from the main loop, I need to have called glib.threads_init() *before*
> starting the main loop, right? But what about gtk.gdk.threads_init()?
>   2. Any GTK interaction, such as emitting a signal from this new
> thread, must be either:
>   a. done via glib.idle_add (if I'm happy to let GTK do it
> whenever it next feels like it), -OR-
>   b. wrapped in gtk.gdk.threads_enter()/...leave(), -OR-
>   c. in a "with: gtk.gdk.lock:" block (equivalent to 2.b)

Apart from 2.c, I guess
http://faq.pygtk.org/index.py?file=faq20.006.htp&req=show
is clear enough?

>   3. I don't need to do the threads_enter/leave (or use the context
> manager) if I only use glib.idle_add (or timeout_add, etc)

No, you don't. If you don't really need threads, life is much simpler.

Cheers,

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] How to add extra Vbox fields

[Pietro Battiston]

Il giorno dom, 20/06/2010 alle 17.21 -0700, Lang Hurst ha scritto:
> Then
> 
> bttn = gtk.button()


Capital "B", please!
(all widgets names start with a capital letter)

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] How to add extra Vbox fields

[Pietro Battiston]

Il giorno dom, 20/06/2010 alle 11.21 +0200, Timo ha scritto:
> On 20-06-10 04:06, Lang Hurst wrote:
> > I got this to work using what I think is an ugly hack, but may be how it
> > is supposed to be done.  I created a whole bunch of textviews in glade,
> > and defaulted them to 'not visible'.  Then, as I loop through my
> > results, I put in my information and then make the widget visible.  It
> > works, just doesn't seem right.  Oh well, back to it.
> >
> That doesn't sound good to me. what if you have more records to show 
> than textviews?
> 
> You will find that in some programs it's just impossible to only use 
> Glade for your GUI, so it is advised to learn some plain PyGTK aswell. 
> In your example, this is the case too.
> 
> The best way (I think atleast) is to manually create your textview and 
> append it to your VBox with vbox.pack_start(textview)
> Maybe even subclass gtk.Textview to have more control.
> This way you will not have to create numerous textviews or add a VBox 
> with lot's of rows in Glade.


Just for completness, another way is to create a gtk.Builder for each
textview. But in this case, it would be much better to isolate the
textview in a separate glade file. Evidently, if the textview has no
particular properties set (doesn't take much code to create one withoug
glade), it's not the optimal solution

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] little icon trouble

[Pietro Battiston]

Il giorno mer, 02/06/2010 alle 11.28 +0200, Pasquale Boemio ha scritto:
> Hi everybody.
> I'm working at a little python's applet for the gnome-panel, 
> but some button icons don't show.
> An example:
> this is the code that show the image
> 
> self.PlayButton = gtk.Button()
> self.PlayButtonImage = gtk.Image()
> self.PlayButtonImage.set_from_stock("gtk-media-play",gtk.ICON_SIZE_BUTTON)
> self.PlayButton.set_image(self.PlayButtonImage)
> self.PlayButton.set_relief(gtk.RELIEF_NONE)
> self.PlayButton.connect("clicked",self.myGestour.Play)
> self.ButtonBar.add(self.PlayButton)
> 
> this not
> self.PrevButton = gtk.Button()
> self.PrevButtonImage = gtk.Image()
> self.PrevButtonImage.set_from_stock(gtk.STOCK_MEDIA_PREVIOUS,gtk.ICON_SIZE_BUTTON)
> self.PrevButton.set_image(self.PrevButtonImage)
> self.PrevButton.set_relief(gtk.RELIEF_NONE)
> self.PrevButton.connect("clicked",self.myGestour.Prev)
> self.ButtonBar.add(self.PrevButton)
> 
> where I wrong?

Don't know, but on my system the following shows both.

import gtk

PrevButton = gtk.Button()
PrevButtonImage = gtk.Image()
PrevButtonImage.set_from_stock(gtk.STOCK_MEDIA_PREVIOUS,gtk.ICON_SIZE_BUTTON)
PrevButton.set_image(PrevButtonImage)
PrevButton.set_relief(gtk.RELIEF_NONE)

PlayButton = gtk.Button()
PlayButtonImage = gtk.Image()
PlayButtonImage.set_from_stock("gtk-media-play",gtk.ICON_SIZE_BUTTON)
PlayButton.set_image(PlayButtonImage)
PlayButton.set_relief(gtk.RELIEF_NONE)

w = gtk.Window()
w.add(gtk.VBox())
w.child.pack_start(PlayButton)
w.child.pack_start(PrevButton)
w.show_all()

gtk.main()


So if it doesn't work for you, I guess the problem is not in the code.

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] DrawingArea and multiprocessing?

[Pietro Battiston]

Il giorno mer, 19/05/2010 alle 14.43 -0700, Stuart Axon ha scritto:
> Has anybody successfully used a DrawingArea along with multiprocessing?
> 
> I'm trying to get it to work, but am a bit confused.
> 
> 
> I was imagining I could run gtk.main in one thread, and update the drawing 
> area in the other, is there a simple example somewhere?
> 
> (At the moment I just get no redraws)
> 

Apart from
http://faq.pygtk.org/index.py?req=all#20.1
and from the fact that life is simpler if only main thread plays with
widgets, then consider that multiprocessing does _not_ use threads, but
separate processes instead.

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

pygtk@daa.com.au

[Pietro Battiston]

Il giorno gio, 13/05/2010 alle 10.11 +0800, MG N ha scritto:
> Hi,
> does anybody know how to embed a vpython 3D graphic into a pygtk window?
> 

I don't really know much, but vpython Design, of which you find an old
beta at http://rpmbuildtut.wordpress.com/downloads/ , does.

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] How to add a sound file in glade?

[Pietro Battiston]

Il giorno mar, 04/05/2010 alle 21.42 +0530, varnikat t ha scritto:
> Hi,
> How to add a sound file in glade?
> I want the sound file to start when window pops up and to stop when
> window closes.
> Are there any default sound files which come with glade?

Glade is for making GUI interfaces, not for handling audio...

But playing an audio file with gstreamer is as easy as

#!/usr/bin/python
import pygst
pygst.require("0.10")
import gst, gtk

player = gst.element_factory_make("playbin2", "player")
player.set_property("uri", "file:///path/to/file")
player.set_state(gst.STATE_PLAYING)
gtk.main()


bye

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] General Query

[Pietro Battiston]

Il giorno mer, 24/03/2010 alle 11.27 +0100, Rafael Villar Burke (Pachi)
ha scritto:
> I'm forwarding this to the main PyGTK mailing list, as it may interest 
> other people.
> 
> On 24/03/2010 3:59, David Scott wrote:
> > Hi,
> >
> > I hope this email finds someone who be able to provide some feedback.
> >
> > I did a Computer Science degree a couple of years back and had to work 
> > pretty hard teach myself the material in order to pass the course. It 
> > taught me the importance of good documentation. Since switching to 
> > Linux a couple of years ago I have wanted to develop a few of my ideas 
> > into applications to make available for the community but 
> > unfortunately software development in Linux is not as easy as it is 
> > for Windows. Open Source is great but the lacking area is always 
> > documentation and examples (Google really does become your best friend).
> >
> > Looking at the tutorials for pyGTK I notice they are five years out of 
> > date and too simplistic to be of much use. What the project really 
> > needs is a lot more in the way of tutorials - perhaps even examples 
> > for each of the GTK widgets used in GUI design. Perhaps I am missing 
> > something...is there a companion site where newer tutorials exist but 
> > that I have not yet found? Anyway, I would be interested in helping to 
> > develop some new tutorials to show new comers how to get started. I 
> > don't have a lot of experience with pyGTK since I am still learning 
> > myself but my own efforts so far are definitely further along than the 
> > tutorials on the site. I think it is possible to really improve this 
> > aspect of the site but I can't do it on my own; I'd need someone with 
> > more experience to review my output (code and accompanying text) to 
> > ensure that I am demonstrating the best way of implementing the 
> > widgets. I really don't want to make an idiot of myself by showing a 
> > bad way of doing something when there is likely a more elegant way of 
> > doing it (and we all know what a vindictive environment it can be when 
> > experienced geeks take exception to something that they don't like). 
> > Would anyone be interested in overseeing me if I undertook this 
> > endeavour?
> >
> > Why would I want to do this? Well, for a start I have more time on my 
> > hands than I can deal with. I am in a foreign country with my partner 
> > but I can't work here because I am not fluent in the local language. 
> > Secondly, I have been delaying improving my coding skills for the last 
> > two years in the hope that some sort of cross platform solution would 
> > turn up. Well, nothing much has happened. Adobe's Flex is proprietary 
> > and cumbersome. JavaFX showed promise but now is even worse than Flex 
> > because Oracle have wrapped their corporate tentacles around it. QT is 
> > bloated and ugly to me. And I using ajax frameworks require a 
> > supported server. So python and pyGTK remains the best solution for 
> > Linux (at least from my point of view).
> >
> > Please let me know if anyone is interested or, indeed, whether this is 
> > even possible.
> >
> > Kind regards
> > Dave
> 
> Hi Dave,
> 
> First of all, better documentation is always welcome and more people 
> working on it is what is needed, so your help is really appreciated!
> 
> About the task, I'd give you some general recommendation to try to lower 
> the barrier for others to collaborate with you.
> 
> This usually means:
> - try to get some feedback using the PyGTK users mailing list [1] or the 
> IRC channel [2]. If you require specific people to do the review it's 
> quite possible that they don't have their free time as the same time as you.
> - ask for specific help instead of asking for general review. That way 
> people can contribute just spending a couple of minutes instead of 
> requiring a long time merely read your request.
> - publish your work on a public blog or website. It will be quickly 
> available and you'll get comments, review and valuable feedback soon. We 
> can later host it at the www.pygtk.org website.
> - be specific and don't try to overdesign the whole series. If you start 
> covering topics that adapt to your skill level and are just a step away 
> from  your current knowledge but need some further investigation you'll 
> be able to cope with the task and it's quite possible that others will 
> need to follow your same learning process. Also, it makes asking for 
> help easier, to avoid implicitly asking others: "Teach me PyGTK so I can 
> write it down".
> - build upon the existing documentation instead of covering already 
> existing topics. It will help fill the gaps and it will interest people 
> with different skill levels. Furthermore, rewriting topics that are 
> already covered isn't probably going to fly.
> - joining other related efforts, like Acire [3][4], may be another good 
> way to improve the docs. You could write interesting examples and 
> discuss them in a blog post.
> 
> Re

Re: [pygtk] Resizing a Button with motion_notify_event?

[Pietro Battiston]

Il giorno dom, 07/03/2010 alle 11.49 +0100, Martin Drautzburg ha
scritto:
> Hello all,
> 
> I am trying to implement a gtk.Button which can be resized (by grabbing it 
> near its nower edge) and dragged around (by grabbing it somewhere near its 
> center).  The gtk.Button is placed inside a gtk.Layout. I could get this to 
> work by responding to mouse events WITHIN the Button. 
> 
> However this had the drawback, that the mouse may be too fast while resizing 
> and the gtk.Button will not grow fast enough. Thus the mouse will leave the 
> area of the gtk.Button and no more motion events will be sent to the Button. 
> When moving the Button around this problem is less obvious, because the mouse 
> is less likely to leave the area of the Button. None of these problems became 
> apparent on my desktop box, but on my maemo handheld, the resizing simply 
> didn't work.
> 
> So I thought, I'd better let the gtk.Layout handle the motion events. The 
> strange thing is: it gets motion events only
> 
> - When the mouse is outside any gtk.Button
> - When the mouse is inside a gtk.Button but no mousebutton is pressed
> 
> However no motion events arrive at the Layout when
> - The mouse is inside a gtk.Button and a mousebutton is held pressed
> 
> I found two postings related to this issue:
> 
> - one had the exact same problem, but there were no replies
> - it was said that gtk.Layout does not respond to events, as it does not have 
> its own window. This is hard to believe, because my Layout does respond to 
> events and I can influence the behavior (except for the problem described 
> here)
> 
> 
> 

Couldn't you look at (mouse) events for the whole window?!

(I'm assuming that you know about gtk.HPaned and gtk.VPaned but find
them ugly for your purposes)

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Wnck: Switching to and reporting current workspace (desktop) number.

[Pietro Battiston]

Il giorno dom, 07/03/2010 alle 09.00 +0100, Osmo Maatta ha scritto:
> Re-hello,
> 
> Yes, your code works fine.
> But the following code fails.
> The "self.attuale" print 0 for every loop.
> 
> # Again: This works only with Metacity or similar WM.
> import gtk, gobject, wnck
> import time
> 
> class Cambiatore(object):
>  def __init__(self):
>  self.screen= wnck.screen_get_default()
> 
>  def cambia(self, next_ws):
>  ws = self.screen.get_workspaces()[next_ws]
>  ws.activate(0)
> 
>  ws = self.screen.get_active_workspace()
>  actual = self.screen.get_workspace_index(ws)
>  print "self.attuale=", actual
> 
>  gtk.main_quit()
> 
> c = Cambiatore()
> for i in range(4):
>  gobject.idle_add(c.cambia, i)
>  gtk.main()
>  #gobject.timeout_add_seconds(1, c.cambia)
> 
> Why on earth we have to deal with event-loops to read or set desktop 
> values.

That's a nice question...

Pietro


> I should absolutely send a bomb to Wnck's mailing list!
> 
> // Moma
> 
> 
> On 03/06/2010 08:28 PM, Pietro Battiston wrote:
> > http://lists.gulp.linux.it/pipermail/gulp/2009-September/035843.html
> >
> > That's in Italian, but I guess the code logic is quite understandable...
> > and works (you can verify by adding a print).
> >
> > If I recall correctly, I too at the time had problems that had to do
> > with the gtk main loop not running.
> >
> > cheers
> >
> > Pietro
> 
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Wnck: Switching to and reporting current workspace (desktop) number.

[Pietro Battiston]

Il giorno sab, 06/03/2010 alle 20.16 +0100, Osmo Maatta ha scritto:
> Hello,
> This question is about the Wnck library. I still hope someone here can
> shed light on this issue.
> 
> The following code snippet loops though all active
> workspaces/desktops.
> It then tries to report the actual desktop/workspace number, but the
> "current workspace num" does not change.
> 
> The code is here: http://www.futuredesktop.com/tmp/desktop_test.py
> 
> Look at the last three lines.
>   ws  = screen.get_active_workspace()
>   ws_num = ws.get_number()
>   print "i=", i, "   current workspace num=", ws_num
> 
> I reports something like this:
>   i= 0current workspace num= 1
>   i= 1current workspace num= 0
>   i= 2current workspace num= 0
>   i= 3current workspace num= 0
>   i= 4current workspace num= 0
> 
> The "current workspace num" is totally wrong.
> Why does Wnck behave like this?
> 
> BTW: I run this code on 64bit Ubuntu 9.10 with GNOME + Metacity Window
> Manager (not Compiz WM).
> $ metacity --replace
> 
> References: http://library.gnome.org/devel/libwnck/stable/
> http://library.gnome.org/devel/libwnck/stable/WnckScreen.html#wnck-screen-get-active-workspace
> 
> I may start to use the "wmctrl" command directly.
> It rocks but I would rather not be dependent on external tools,
> subprocess'ing that from my Python modules.


http://lists.gulp.linux.it/pipermail/gulp/2009-September/035843.html

That's in Italian, but I guess the code logic is quite understandable...
and works (you can verify by adding a print).

If I recall correctly, I too at the time had problems that had to do
with the gtk main loop not running.

cheers

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Printing from gtk.TextView

[Pietro Battiston]

Il giorno ven, 26/02/2010 alle 19.53 +0600, Alexander Kuleshov ha
scritto:
> Hello to all. Where can i find simple example - gtk.TextView printing?

pygtk-demo

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Displaying children in a gtk.TreeModelFilter

[Pietro Battiston]

Il giorno ven, 19/02/2010 alle 16.58 +0100, Lionel Dricot ha scritto:
> 
> Possible solution:
> 
> 
> Do you believe that, if I extend the TreeModelFilter object and
> implement the convert_iter_to_iter and convert_path_to_path functions,
> it could possibly work ?
> 
> 
> How is the TreeModelFilter used internally ? Should I make it
> implement GenericTreeModel too ?

Uhm... personally I really don't know, sorry. And indeed, I have no
better ideas.

Pietro

P.S: sorry for the double mail.

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Displaying children in a gtk.TreeModelFilter

[Pietro Battiston]

Il giorno ven, 19/02/2010 alle 13.04 +0100, Lionel Dricot ha scritto:
> Hello,
> 
> 
> I'm currently working closely with gtk.TreeModelFilter and I'm
> currently stuck.
> 
> 
> I've discovered that in order to have a row visible, that row has to
> return True against the visible_func but, also, that *all his parents
> have to be visible*.
> 
> 
> This is rather important and not written in any GTK documentation I've
> seen (maybe I should send a patch against pygtk doc for that).
> 
> 
> 
> 
> As I consequence, I'm currently looking for a way to display children
> that have an hidden parent. That children would be displayed at the
> root.
> 
> 
> For example :
> 
> 
> a
> --> b
> --->c
> -->d
>  (d is child of c which is child of b which is child of b)
> if b is not visible, my tree would display :
> 
> 
> a
> c
> -->d

Isn't it quite inconsistent?!

I think that I'd possibly expect


a
--> b
--->c
-->d

(automatically show parents of a row that has visible_func() True)

or

a
--->c
-->d

(simpler approach, but I guess this is visually _very ugly_ and
counterintuitive for the user).

In any case, I wouldn't want a row to change its appearance...

So, what is the best option between the current behaviour and the "show
all parents" (the first I presented)? I guess there is no general
answer, but that the current is more intuitive for the programmer, and
it is easier to workaround it if you need to (I guess that's what
seahorse does, for instance).

Still, a convenience method to switch from the current behaviour to the
"show all parents" one would be a nice feature.


> (currently, it only display "a").
> 
> 
> 
> 
> How can I do that with my treemodelfilter ? It seems for me a rather
> important usecase for a treemodelfilter but I cannot find any
> documentation or code sample on the web about a way of doing that.
> 

Again, if I understood correctly you can't do that with a
treemodelfilter, because the "depth" of a row shouldn't change.

Pietro


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Displaying children in a gtk.TreeModelFilter

[Pietro Battiston]

My former email was completely wrong, sorry.

Il giorno ven, 19/02/2010 alle 16.46 +0100, Lionel Dricot ha scritto:
> 
> 
> (simpler approach, but I guess this is visually _very ugly_
> and
> counterintuitive for the user).
> 
> In any case, I wouldn't want a row to change its appearance...
> 
> So, what is the best option between the current behaviour and
> the "show
> all parents" (the first I presented)? I guess there is no
> general
> answer, but that the current is more intuitive for the
> programmer, and
> it is easier to workaround it if you need to (I guess that's
> what
> seahorse does, for instance).
> 
> Still, a convenience method to switch from the current
> behaviour to the
> "show all parents" one would be a nice feature.
> 
> 
> 
> 
> The more I'm thinking about, the more I'm scratching my head. In fact,
> as soon as you are using TreeModel with children, I cannot find any
> usecase were filters could be useful in their current shape.
> 
> 
> Take for example a list of emails nested by convestation (gmail-like).
> If you do a search, you don't want a mail to be hidden if it matches
> the search but the parent is not. There should be some usecase were
> the current behaviour is useful but I fail to find one.

I do see one: you are exposing a filesystem with your treeview, and want
to show all folders your applications should process. At a certain
moment, a directory is removed from this list (because the app decides
so, or the user unselects it someway - but you don't want to remove it
from the treeview), so now visible_func returns False for it.

In your desired approach, visible_func must change for _all_ children
(and grandons and so on). In the current one, only for the removed row.

That's why I think there is no obviously "right" approach for every
situation. I'd also say that since a tree is usually associated to some
hierarchy, the current one totally makes sense, while the email example

But that said, what I had totally missed is that while the current
behaviour _could_ be obtained (by changing visible_func) if pygtk
behaved as you desire, vice-versa your desired behaviour is _not_
obtainable in the current situation (as far as I know, obviously)...


> 
> I've tried to take the problem in every possible way but I don't find
> any solution to not hide children with an hidden parent. All the
> examples I could find on the web are always for flat list. I suspect
> that the documentation is also written with flat lists in mind.
> 
> 
> 
> 
> So, here's my question : how can you use filter with TreeModel if you
> are not flat ? Please don't tell me to rewrite my TreeModel. It's
> exactly what I wanted to avoid when I started this refactorisation :
> use GTK as it should be, separating the model from the view.
> 

That makes totally sense... and after reading your example I took a look
at Evolution, and saw it obviously recreates the TreeModel.

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] How to make ScrolledWindow as big as it's content?

[Pietro Battiston]

Il giorno lun, 15/02/2010 alle 21.38 +0100, Matthias Geier ha scritto:
> Dear list!
> 
> My question may sound silly (and maybe it is), but let me explain.
> You could say that a ScrolledWindow that is exactly as big as its
> content doesn't make a lot of sense, but I think in my case it does:

http://www.daa.com.au/pipermail/pygtk/2009-August/017372.html
and following. Also see the linked gtk-devel thread.

But in your case (a kiosk), isn't
http://www.pygtk.org/docs/pygtk/class-gtkwindow.html#method-gtkwindow--maximize
enough?! Or even fullscreen?!

Pietro


> 
> I made a GUI using Glade and want to show it in a kind of "kiosk
> mode", i.e. I want to run it in fullscreen mode with all the widgets
> centered on the screen.
> To achieve this, I placed a gtk.Alignment into the main gtk.Window and
> inside of this I put all my other widgets.
> This worked well until I placed a gtk.ScrolledWindow somewhere inside.
> 
> The reason for this is that I wanted to run the GUI on different
> screen resolutions. On large screens, the Scrolledwindow should show
> all contents and on small screens there should be scrollbars.
> 
> Therefore, I couldn't set a size request to the ScrolledWindow,
> because this would be either too large for small screens or the other
> way round.
> 
> What do I have to do that the ScrolledWindow shows all its contents on
> large screens but still is scrollable if the toplevel window is very
> small?
> 
> I think this should be logically possible, but I don't know how to
> achieve it with pygtk.
> 
> To illustrate my problem, I created a little test script (see below).
> The buttons are of course only place-holders for my actual widgets.
> In a comment there is one line with a size request. If I un-comment
> that, it looks more or less like I want it to look. The thing is even
> if I did know the exact size of the contents, it would still not be
> scrollable if the window is made very small.
> 
> I hope you understand my problem and maybe you know a solution or have
> some hints for me.
> 
> Thanks in advance,
> Matthias
> 
> #
> #!/usr/bin/env python
> 
> import pygtk
> pygtk.require('2.0')
> import gtk
> 
> class ScrolledWindowTest:
> def destroy(self, widget):
> gtk.main_quit()
> 
> def __init__(self):
> window = gtk.Window()
>   window.fullscreen()
> window.connect("destroy", self.destroy)
> window.set_title("ScrolledWindow Test")
> scrolled_window = gtk.ScrolledWindow()
>   # I would like it to look like with this line:
>   #scrolled_window.set_size_request(105,205)
> scrolled_window.set_policy(gtk.POLICY_AUTOMATIC, gtk.POLICY_AUTOMATIC)
>   alignment = gtk.Alignment(0.5, 0.5, 0, 0)
>   alignment.add(scrolled_window)
> window.add(alignment)
>   vbox = gtk.VBox()
> scrolled_window.add_with_viewport(vbox)
> for i in range(5):
>   button = gtk.ToggleButton("button")
>   button.set_size_request(80, 40)
>   vbox.pack_start(button, expand=False)
> window.show_all()
> 
> if __name__ == "__main__":
> ScrolledWindowTest()
> gtk.main()
> 
> #
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Sending a message to the window manager (switch to desktop # X)

[Pietro Battiston]

Il giorno mer, 10/02/2010 alle 11.56 +0100, Osmo Maatta ha scritto:
> Hello,
> 
> I have code that sends a message to the window manager to switch to a
> given desktop number.
> I try converted this code from C to GDK on Ubuntu Linux.
> 

I posted the following on another mailing list some time ago, it cycles
though desktops. It's in Italian, but I think the mechanisms are clear
enough:

import gtk, gobject, wnck

class Cambiatore(object):
def __init__(self):
self.schermo= wnck.screen_get_default()

def cambia(self):
try:
self.attuale
except:
self.massimo = self.schermo.get_workspace_count()
self.attuale =
self.schermo.get_workspace_index(self.schermo.get_active_workspace())

self.attuale = (self.attuale + 1) % self.massimo
prossimo = self.schermo.get_workspaces()[self.attuale]
prossimo.activate(0)
return True

c = Cambiatore()
gobject.timeout_add_seconds(5, c.cambia)

gtk.main()


# bye
# Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Can't set a parent on widget which has a parent

[Pietro Battiston]

Il giorno mar, 09/02/2010 alle 18.36 +0600, Alexander Kuleshov ha
scritto:
> Hello. I have following problem. Am writing a simple program with
> pygtk. I have a window on it located menu, statusbar and NoteBook. The
> tabs should be located NoteBook element GtkTextView. By clicking on
> the menu, I must appear a new tab with GtkTextView. But I get the
> following: Can't set a parent on widget which has a parent
> 
> What to do in this case?
> 

Replace

self.tab_panel.append_page(self.editor, gtk.Label("ASD"))


with

self.tab_panel.append_page(gtk.TextView(), gtk.Label("ASD"))
self.tab_panel.show_all()

, then, fix the organization of the program in order to make it do what
you want.

Pietro


signature.asc
Description: Questa è una parte del messaggio firmata digitalmente
___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] can a treeview be reordered with a CellRendererToggle present

[Pietro Battiston]

Il giorno mer, 03/02/2010 alle 12.38 -0800, Mathew Yeates ha scritto:
> I want to be able to drag rows of my list. i.e. reorder the list

https://bugzilla.gnome.org/show_bug.cgi?id=609000

> 
> On Wed, Feb 3, 2010 at 12:36 PM, Pietro Battiston 
> wrote:
> Il giorno mer, 03/02/2010 alle 12.21 -0800, Mathew Yeates ha
> scritto:
> > Here is an example
> 
> And *what is the problem*?!?
> 
> Your first email was not at all understandeable to me, and the
> second
> didn't help. I assume this must _certainly_ be because I'm not
> a native
> English speaker... still, many questions on this list don't
> even get
> answers, so if I was in you I would try to catch attention by
> _stating
> clearly your problem_. By the way, I also see it as a form of
> respect.
> 
> Notice I _may_ possibly understand the problem by studying
> your code,
> but I expect that you explain it carefully, not that I must
> fight to get
> it.
> 
> Pietro
> 
> 
> 
> > import gtk
> > class ListDisp:
> > def __init__(self):
> > self.builder = gtk.Builder()
> > self.builder.add_from_file("
> > drag.xml")
> > self.window = self.builder.get_object("window1")
> > self.store=gtk.ListStore('gboolean',str)
> > #self.store=gtk.ListStore(str)
> > self.view=self.builder.get_object("treeview1")
> > self.view.set_model(self.store)
> > self.tvcolumn = gtk.TreeViewColumn('File Name')
> > self.view.append_column(self.tvcolumn)
> > self.cell = gtk.CellRendererText()
> > self.toggle=gtk.CellRendererToggle()
> > self.tvcolumn.pack_start(self.toggle, True)
> > self.tvcolumn.pack_start(self.cell, True)
> > self.tvcolumn.add_attribute(self.cell, 'text', 1)
> > self.tvcolumn.add_attribute(self.toggle, 'active',
> 0)
> > self.view.set_reorderable(True)
> > self.store.append([True,"foo"])
> > self.store.append([True,"goo"])
> >
> > if __name__ == "__main__":
> > ld=ListDisp()
> > ld.window.show_all()
> > gtk.main()
> >
> >
> >
> > And here is the glade file
> > 
> > 
> >   
> > 
> >   
> > 
> >id="scrolledwindow1">
> > True
> > True
> >  name="hscrollbar_policy">automatic
> >  name="vscrollbar_policy">automatic
> > 
> >   
> > True
> > True
> >   
> > 
> >   
> > 
> >   
> > 
> >
> >
> > On Tue, Feb 2, 2010 at 11:37 PM, Pietro Battiston
> 
> > wrote:
> > Il giorno mar, 02/02/2010 alle 16.08 -0800, Yeates,
> Mathew C
> > (388D) ha
> > scritto:
> >
> > > I have a CellRendererToggle and CellRendererToggle
> packed in
> > a column
> > > and cannot reorder. However, if I don’t pack the
> > CellRendererToggle
> > > then I can’t.
> > >
> > >
> > >
> > >
> > >
> > > Any clues or example code showing this?
> > >
> > >
> >
> >
> > I humbly suggest that you rephrase your problem more
> clearly,
> > perhaps
> > providing a simple and running snippet exposing it.
> >
> > Pietro
> >
> >
> > ___
> > pygtk mailing list   pygtk@daa.com.au
> > http://www.daa.com.au/mailman/listinfo/pygtk
> > Read the PyGTK FAQ: http://faq.pygtk.org/
> >
> 
> 
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/
> 


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] can a treeview be reordered with a CellRendererToggle present

[Pietro Battiston]

Il giorno mer, 03/02/2010 alle 12.21 -0800, Mathew Yeates ha scritto:
> Here is an example

And *what is the problem*?!?

Your first email was not at all understandeable to me, and the second
didn't help. I assume this must _certainly_ be because I'm not a native
English speaker... still, many questions on this list don't even get
answers, so if I was in you I would try to catch attention by _stating
clearly your problem_. By the way, I also see it as a form of respect.

Notice I _may_ possibly understand the problem by studying your code,
but I expect that you explain it carefully, not that I must fight to get
it.

Pietro


> import gtk
> class ListDisp:
> def __init__(self): 
> self.builder = gtk.Builder()
> self.builder.add_from_file("
> drag.xml") 
> self.window = self.builder.get_object("window1")
> self.store=gtk.ListStore('gboolean',str)
> #self.store=gtk.ListStore(str)
> self.view=self.builder.get_object("treeview1")
> self.view.set_model(self.store)
> self.tvcolumn = gtk.TreeViewColumn('File Name')
> self.view.append_column(self.tvcolumn)
> self.cell = gtk.CellRendererText()
> self.toggle=gtk.CellRendererToggle() 
> self.tvcolumn.pack_start(self.toggle, True)
> self.tvcolumn.pack_start(self.cell, True)
> self.tvcolumn.add_attribute(self.cell, 'text', 1)
> self.tvcolumn.add_attribute(self.toggle, 'active', 0)
> self.view.set_reorderable(True)
> self.store.append([True,"foo"])
> self.store.append([True,"goo"])
> 
> if __name__ == "__main__":
> ld=ListDisp()
> ld.window.show_all()
> gtk.main()
> 
> 
> 
> And here is the glade file
> 
> 
>   
> 
>   
> 
>       
> True
> True
> automatic
> automatic
> 
>   
> True
> True
>   
> 
>   
> 
>   
> 
> 
> 
> On Tue, Feb 2, 2010 at 11:37 PM, Pietro Battiston 
> wrote:
> Il giorno mar, 02/02/2010 alle 16.08 -0800, Yeates, Mathew C
> (388D) ha
> scritto:
> 
> > I have a CellRendererToggle and CellRendererToggle packed in
> a column
> > and cannot reorder. However, if I don’t pack the
> CellRendererToggle
> > then I can’t.
> >
> >
> >
> >
> >
> > Any clues or example code showing this?
> >
> >
> 
> 
> I humbly suggest that you rephrase your problem more clearly,
> perhaps
> providing a simple and running snippet exposing it.
> 
> Pietro
> 
> 
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/
> 


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] can a treeview be reordered with a CellRendererToggle present

[Pietro Battiston]

Il giorno mar, 02/02/2010 alle 16.08 -0800, Yeates, Mathew C (388D) ha
scritto:
> I have a CellRendererToggle and CellRendererToggle packed in a column
> and cannot reorder. However, if I don’t pack the CellRendererToggle
> then I can’t.
> 
>  
> 
>  
> 
> Any clues or example code showing this?
> 
>  

I humbly suggest that you rephrase your problem more clearly, perhaps
providing a simple and running snippet exposing it.

Pietro


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] TreeView (liststore) sorting.

[Pietro Battiston]

Il giorno mar, 02/02/2010 alle 22.59 +0100, middleofdre...@gmail.com ha
scritto:
> I was looking for this in net but still i have no idea how to set
> priority of sorting. For example i'm doing:
>  somelistmodel.set_sort_column_id(0,gtk.SORT_ASCENDING) and it sort it
> right. But when elements in column 0 are the same, a want to sort by
> column 1.
>  How to?
> I've tried
> somelistmodel.set_sort_column_id(1,gtk.SORT_ASCENDING)
> somelistmodel.set_sort_column_id(0,gtk.SORT_ASCENDING), but that
> doesn't work.
> 

http://www.pygtk.org/docs/pygtk/class-gtktreesortable.html#method-gtktreesortable--set-sort-func

I strongly suggest using devhelp and taking a look at the page of the
classes you happen to use: even by a fast glance, you can learn many
things.

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Dialog hide method doesnt hide at the moment

[Pietro Battiston]

Il giorno sab, 30/01/2010 alle 23.07 +0100, Pablo Recio Quijano ha
scritto:
> 
> 
> 2010/1/30 Pietro Battiston 
> Il giorno sab, 30/01/2010 alle 20.36 +0100, Pablo Recio
> Quijano ha
> scritto:
> > Hi.
> >
> >
> > I have a code more or less like:
> >
> >
> > while ...: #some comprobations
> > # other stuffs
> > R = round_result.roundResult() #a dialog object
> > response = R.result_dialog.run()
> > if response == 13: #13 is the ID of button to close
> > R.result_dialog.destroy()
> 
> 
> Could you try adding the line
>   gtk.main_iteration(False)
> at the end?
> 
> 
> It doesn't work neither.

You're right, that processes only one event; try with:



while gtk.events_pending():
gtk.main_iteration(False)


Pietro


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Dialog hide method doesnt hide at the moment

[Pietro Battiston]

Il giorno sab, 30/01/2010 alle 20.36 +0100, Pablo Recio Quijano ha
scritto:
> Hi.
> 
> 
> I have a code more or less like:
> 
> 
> while ...: #some comprobations
> # other stuffs
> R = round_result.roundResult() #a dialog object
> response = R.result_dialog.run()
> if response == 13: #13 is the ID of button to close
> R.result_dialog.destroy()

Could you try adding the line
   gtk.main_iteration(False)
at the end?

Pietro

> 
> The problem is that the dialog doesn't destroy in that moment.
> Instead, is destroyed in the next loops's iteration. I also tried to
> map a function to the event trigged by clicking that button, using
> hide or destroy, but doesn't work either. 
> 
> 
> Is there any way to hide the dialog in the moment I want to? Because I
> don't understand what's happening.
> 
> 
> Thanks in advance.
> 
> -- 
> Pablo Recio Quijano
> 
> Estudiante de Ingeniería Informática (UCA)
> Becario en Alquimia Proyectos Digitales
> Alumno colaborador del Departamento de Lenguajes y Sistemas
> Informáticos
> Participante del IV Concurso Universitario de Software Libre
> 
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Deploying a PyGTK application

[Pietro Battiston]

Il giorno gio, 28/01/2010 alle 22.23 +0100, Pietro Battiston ha scritto:
> Il giorno gio, 28/01/2010 alle 11.44 -0500, Luis Felipe López Acevedo ha
> scritto:
> > El jue, 28-01-2010 a las 22:08 +0530, Thameera Senanayaka escribió:
> > > Hello,
> > > I'm quite new to PyGTK programming. How can I deploy a PyGTK
> > > application in linux? (eg: How to create a deb file, etc) Where can I
> > > get more information from? 
> > > Thanks!
> > > 
> > 
> > http://showmedo.com/videotutorials/video?name=linuxJensMakingDeb
> > 
> 
> That video is nice, but since it has been made debhelper 7 was born, and
> I strongly suggest to use it.
> 
> Basically, if your application has a nice setup.py, just skip all the
> part that talks about the "rules" file, and put inside it just:
> 
> #!/usr/bin/make -f
> # -*- makefile -*-
> 
> # Uncomment this to turn on verbose mode.
> #export DH_VERBOSE=1
> 
> # This has to be exported to make some magic below work.
> export DH_OPTIONS
> 
> %:
>   dh  $@
> 
> 
> (Beware, the last line contains a tab, not spaces)
> 

(and anyway, notice that if you work in a debian unstable or testing,
this debian/rules is created automatically by dh_make)

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Deploying a PyGTK application

[Pietro Battiston]

Il giorno gio, 28/01/2010 alle 11.44 -0500, Luis Felipe López Acevedo ha
scritto:
> El jue, 28-01-2010 a las 22:08 +0530, Thameera Senanayaka escribió:
> > Hello,
> > I'm quite new to PyGTK programming. How can I deploy a PyGTK
> > application in linux? (eg: How to create a deb file, etc) Where can I
> > get more information from? 
> > Thanks!
> > 
> 
> http://showmedo.com/videotutorials/video?name=linuxJensMakingDeb
> 

That video is nice, but since it has been made debhelper 7 was born, and
I strongly suggest to use it.

Basically, if your application has a nice setup.py, just skip all the
part that talks about the "rules" file, and put inside it just:

#!/usr/bin/make -f
# -*- makefile -*-

# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1

# This has to be exported to make some magic below work.
export DH_OPTIONS

%:
dh  $@


(Beware, the last line contains a tab, not spaces)

Pietro


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Dialog too large

[Pietro Battiston]

Il giorno mer, 27/01/2010 alle 10.47 +, Peyman ha scritto:
> >
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of pygtk digest..."
> Understood
> >
> >
> > Il giorno dom, 24/01/2010 alle 18.03 +, Peyman ha scritto:
> >> Sorry for the late reply, but I skipped over this e-mail. I have
> >> commented your e-mail below.
> >
> > Please, *do not* reply to digests, _in particular_ do not leave parts
> > that have nothing to do with the mail you're answering to.
> I do not understand, is this a 'digest' (pygtk@daa.com.au)? Who should  
> I send the e-mails to otherwise?
> >
> > If you ask for help, it is your job to put together some code that  
> > runs,
> > isn't huge and reproduces the problem. Attaching a single file  
> > depending
> > on tons of imports doesn't help.
> No problem, I will will provide a self contained example. Attached is  
> a simple example executes two methods. The first, effective_dialog(),  
> creates a dialog which is the appropriate size. I created the most  
> basic dialog for this. The second, deffective_dialog(), creates a  
> dialog which is too large. This is how I implement it in my program,  
> and it is causing problems.
> >
> > On the other hand, I recognize if you do the job if isolating the
> > problem, you'll maybe solve it yourself.
> I think it may have to do with the way I create the buttons in the  
> create_buttons_with_image() helper function.
> >

I where not exactly able to solve the problem, but I may have understood
something more: the problem is that the action_area is a gtk.HBox, but
it seems it doesn't behave as a HBox in the fact that it doesn't take
care of the "homogeneous" property. Since the text field you add is 160
pixels wide, every other widget in the action_area takes up the same
space, and hence the window is huge.

Take a look at the attachment: I just stopped using the action_area and
added a new HBox, and it works. If instead you uncomment the
"set_homogeneous(True)" call, the problem is here again.

Now: I realize this is not a solution, and if I made no mistakes you may
also want to file a bug about that HBox not behaving like a HBox;
however, about your problem, my advice is that you're using the action
area - and, in general, the Dialog object - in a way that it is not
intended to be used: usually a dialog is really a lot of stuff, and some
_buttons_ in the bottom of the window (the action_area), so if I was in
you I would:
- just use a gtk.Window, or
- just move those controls, which are atypical for an action_area, in
other parts of the dialog.

bye

Pietro
#!/usr/bin/env python

import sys
try:
	import pygtk
	pygtk.require("2.0")
except:
	pass
try:
	import gtk
	import gtk.glade
except:
	sys.exit(1)

def make_effective_dialog(window):
	"""Create all the widgets in here
	"""
	dialog=gtk.Dialog(title='Effective Dialog',parent=window,flags=gtk.DIALOG_MODAL|gtk.DIALOG_DESTROY_WITH_PARENT)

	#disable the separator
	
	#get the vbox
	vBox=dialog.vbox

	#create and entry
	label=gtk.Label("I'm afraid I can't do that, Dave")

	#add entry to vertical box
	vBox.pack_start(label,expand=True,fill=True,padding=10)

	window.show_all()
	label.show()

	if dialog.run():
		print True
	else:
		print False

	dialog.destroy()

def make_deffective_dialog(window):
	dialog=gtk.Dialog(title='Deffective Dialog',parent=window,flags=gtk.DIALOG_MODAL|gtk.DIALOG_DESTROY_WITH_PARENT)
	
	dialog.resize(300,300)

	fill_dialog(dialog)

	return dialog

def fill_dialog(dialog):
	"""Recursively create the widgets, starting from the vertical box
	"""
	#get vertical box
	vBox=dialog.vbox

	#add the drawing area and the menubar as left and right children	
	vBox.pack_start(create_da(),expand=True,fill=True,padding=0)
	
	create_buttons(dialog)

def create_da():
	"""Create the drawing area for this window
	"""
	#create the scrolled window
	outputWindowScrolledWindow=gtk.ScrolledWindow()

	#create the event box
	eventBox=gtk.EventBox()

	#set the events
	eventBox.set_events(gtk.gdk.POINTER_MOTION_MASK|gtk.gdk.BUTTON1_MOTION_MASK|gtk.gdk.BUTTON_PRESS_MASK|gtk.gdk.BUTTON_RELEASE_MASK|gtk.gdk.SCROLL_MASK)
	
	#create the drawing area and pixmap
	da=gtk.DrawingArea()
	
	#add da to eventbox
	eventBox.add(da)

	#minimum size of the drawing area
	da.set_size_request(1,1)

	#set the scrolled window policies
	outputWindowScrolledWindow.set_policy(gtk.POLICY_AUTOMATIC, gtk.POLICY_AUTOMATIC)

	#first add the vBox to the scrolled windows
	outputWindowScrolledWindow.add_with_viewport(eventBox)

	#show all the widgets
	outputWindowScrolledWindow.show()
	da.show()
	eventBox.show()

	return outputWindowScrolledWindow
	
def create_buttons(dialog):
	"""Create the bar with the relevant information
	"""
	
	#get horizontal box
	hBox=gtk.HBox()
	dialog.vbox.pack_end(hBox)
#	hBox.set_homogeneous(True)

	playButton=create_button_with_image(gtk.STOCK_MEDIA_PLAY)
	pauseButton=create_button_with_image(gtk.STOCK_MEDIA_PAUSE)
	nextButton=create_button_with_i

Re: [pygtk] Dialog too large

[Pietro Battiston]

Il giorno mer, 27/01/2010 alle 10.47 +, Peyman ha scritto:
> >
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of pygtk digest..."
> Understood
> >
> >
> > Il giorno dom, 24/01/2010 alle 18.03 +, Peyman ha scritto:
> >> Sorry for the late reply, but I skipped over this e-mail. I have
> >> commented your e-mail below.
> >
> > Please, *do not* reply to digests, _in particular_ do not leave parts
> > that have nothing to do with the mail you're answering to.
> I do not understand, is this a 'digest' (pygtk@daa.com.au)? Who should  
> I send the e-mails to otherwise?


"digest" is a way of receiving the pygtk mailing list.

You have the choice (that you made when you first subscribed, and can be
changed at any time) to receive every message by itself, or to receive
them in groups of some (5 usually): the latter is called "digest".

You can manage your subscription at
http://www.daa.com.au/mailman/listinfo/pygtk

If you do reply to a digest, please remove every part of it that does
have to do with the mail you are answering to.

Now I have to go, I will reply to the rest of the email later.

Pietro

> >
> > If you ask for help, it is your job to put together some code that  
> > runs,
> > isn't huge and reproduces the problem. Attaching a single file  
> > depending
> > on tons of imports doesn't help.
> No problem, I will will provide a self contained example. Attached is  
> a simple example executes two methods. The first, effective_dialog(),  
> creates a dialog which is the appropriate size. I created the most  
> basic dialog for this. The second, deffective_dialog(), creates a  
> dialog which is too large. This is how I implement it in my program,  
> and it is causing problems.
> >
> > On the other hand, I recognize if you do the job if isolating the
> > problem, you'll maybe solve it yourself.
> I think it may have to do with the way I create the buttons in the  
> create_buttons_with_image() helper function.
> >
> > Pietro
> 
> Cheers
> 
> 
> Peter
> >
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Dialog (was: Re: pygtk Digest, Vol 83, Issue 22)

[Pietro Battiston]

Il giorno dom, 24/01/2010 alle 18.03 +, Peyman ha scritto:
> Sorry for the late reply, but I skipped over this e-mail. I have  
> commented your e-mail below.

Please, *do not* reply to digests, _in particular_ do not leave parts
that have nothing to do with the mail you're answering to.

> >
> > Message: 1
> > Date: Thu, 21 Jan 2010 23:13:53 +0100
> > From: Pietro Battiston 
> > Subject: Re: [pygtk] Dialog
> > To: PYGTK 
> > Message-ID: <1264112033.4712.276.ca...@vousci>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > Il giorno gio, 21/01/2010 alle 09.36 +, Peyman ha scritto:
> >> Hello
> >>
> >> I recently switched a few of my windows from being of type gtk.Window
> >> to gtk.Dialog.
> >
> > If you can show us the code, it will be much simpler...
> No problem I have attached it for you, but I essentially create the  
> Dialog with the following call
> window 
> = 
> gtk 
> ..Dialog 
> (title=title,parent=widgets['main_window'],flags=gtk.DIALOG_MODAL| 
> gtk.DIALOG_DESTROY_WITH_PARENT)


Yes, but this call doesn't create a huge window at all...


> >
> >> I fixed everything so the dialogs show up, but now
> >> they are HUGE.
> >
> > In one dimension or both?
> Generally in the horizontal dimension (because the buttons are  
> expanded), but in one case (embedded shell console) it is in both  
> directions
> >
> >> This has to do with the size_request of the horizontal
> >> boxes (action_area).
> >
> > How do you know? How are things distributed?
> I discovered this by doing a size request call on both the dialog and  
> the action_area (where the buttons are), and they both had the same  
> width whereas the vertical box was much smaller
> >
> >> Both the vbox and the action_area have
> >> homogeneous=False and spacing=0
> >
> > What about running
> >
> > while widget:
> >print widget, widget.size_request(), widget.get_size_request()
> >parent = widget.get_parent()
> >if parent:
> >try:
> >print parent.child_get_property('expand')
> >print parent.child_get_property('fill')
> >except:
> >pass
> >
> >
> > ?
> When I run the above code I get the following output
>  (1400,129) (-1,-1)

Sorry, I didn't mean to run it on the dialog itself, but on some widget
nested inside the ones that are reclaiming too much space.
_That_ is the information you should be interested in.

> 
> There is no parent, even though  I created the dialog with a parent  
> passed as a parameter

Your "parent" parameter establishes a relation between toplevel windows,
while the "get_parent()" method of widgets just (usually) returns the
gtk.Container containing it: they are too different things, see the
documentations for details.


I took a look at your code, and after briefly stripping everything that
impeded its usage without the external dependencies, it didn't reproduce
the behaviour you described.

If you ask for help, it is your job to put together some code that runs,
isn't huge and reproduces the problem. Attaching a single file depending
on tons of imports doesn't help.

On the other hand, I recognize if you do the job if isolating the
problem, you'll maybe solve it yourself.

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] See output

[Pietro Battiston]

Il giorno dom, 24/01/2010 alle 21.01 +0530, Manjot Pahwa ha scritto:
> I am new to Python and Linux. Can you tell me how to view my output (I
> am creating programs via PyGTK) in Ubuntu 9.04 via Terminal?
> And how to view it from the command line in Windows?

There are more appropriate mailing lists for generic Python and
Linux/Windows enquiries.

Anyway: in PyGTK programs (unless you play with strange configurations),
exactly as in regular Python programs, "print" prints to the terminal.

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] gobject.timeout_add()

[Pietro Battiston]

Il giorno sab, 23/01/2010 alle 15.51 -0800, dj ha scritto:
> Thanks for your continued help on this, Pietro.
> 
> Here is a very basic look at what the program does:
> 1. At a specified time, tune the radio and launch ecasound to make a 
> recording.
> 2. After the recording has finished, tune the radio to another frequency and 
> launch ecasound again.
> 
> The version of the program I had been using launched ecasound in a
>  thread so that the GUI would not be blocked.  gobject.timeout_add()
>  was used to stop the program from immediately re-tuning and trying to
>  record again before the previous recording was finished.  This happens
>  hourly plus an additional 0-4 schedules within each hour.  When I
>  tried to add another schedule within the hour, I couldn't get
>  gobject.timeout_add() to work with it.
> 
> The threaded version uses os.system() to launch ecasound.  I've been
>  experimenting with subprocess.Popen and subprocess.call in the
>  non-threaded version, but I don't understand those too well, and they
>  both block the GUI.  I understand that nobody has suggested that I
>  block the GUI, but I can live with that as long as the rest of the
>  program works.


import sys
import subprocess
p = subprocess.Popen(['sleep', '10'])
sys.exit(0)



Run the above and you'll see Popen() _doesn't_ block the code flow. You
must be doing something else strange. Maybe you don't care about
blocking the GUI, but you certainly care about understanding what's
wrong.


> 
> How I monitor the clock: Every 5 seconds I call time.gmtime() and check
>  the hour and minute.  When those correspond with the waiting schedule,
>  the tuning a recording sequence starts.

Can't you run gobject.timeout_add_seconds() _with_ the number of seconds
which the recording must last?!

Anyway your solution seems reasonable also to me.

Pietro

> 
> westli
> 
> --- On Sat, 1/23/10, Pietro Battiston  wrote:
> 
> > From: Pietro Battiston 
> > Subject: Re: [pygtk] gobject.timeout_add()
> > To: "PYGTK" 
> > Date: Saturday, January 23, 2010, 5:51 AM
> > Il giorno ven, 22/01/2010 alle 21.44
> > -0800, dj ha scritto:
> > > Thank you John and Pietro for your observations and
> > advice.
> > > 
> > > Because of them, I did some rethinking of my
> > program.  Threading has
> > >  worked okay for a couple of years in this
> > program as I continually
> > >  improved it.  But the GUI I started with
> > had to be useful while
> > >  recordings were taking place.  I use the to
> > tune a radio receiver
> > >  according to a schedule and record what was
> > found there, and I needed
> > >  to be able to make adjustments on the fly. 
> > I use a different radio
> > >  and GUI now, and except for Start and Quit
> > buttons, the GUI is just to
> > >  supply information.  So I don't need
> > threading or the timeouts to
> > >  pause the program until the recording is
> > finished.  I'm not thrilled
> > >  with seeing the GUI go dark during recording,
> > but it's okay.
> > 
> > Notice I was not at all suggesting to you to block the
> > GUI... How do you
> > call your external processes?
> > 
> > 
> > > Now
> > >  there is only one 5-second timeout to check the
> > clock between
> > >  scheduled recordings.
> > > 
> > > Is there a better way to monitor the clock?  I
> > have to use time-of-day
> > >  rather than time periods, and I haven't figured
> > out a better way than
> > >  executing time.gmtime() every 5 seconds.
> > > 
> > 
> > I unfortunately cannot understand _what_ type of monitoring
> > you need,
> > and hence how you are currently implementing it.
> > 
> > Pietro
> > 
> > > westli
> > > 
> > > --- On Thu, 1/21/10, Pietro Battiston 
> > wrote:
> > > 
> > > > From: Pietro Battiston 
> > > > Subject: Re: [pygtk] gobject.timeout_add()
> > > > To: pygtk@daa.com.au
> > > > Date: Thursday, January 21, 2010, 1:56 PM
> > > > Il giorno gio, 21/01/2010 alle 08.56
> > > > +0100, John Stowers ha scritto:
> > > > > On Wed, 2010-01-20 at 21:22 -0800, dj
> > wrote:
> > > > > > I hope this is the right place to ask
> > this...
> > > > > > 
> > > > > > I have a python program (using Glade to
> > create
> > > > the gui) that periodically launches ecasound to
> > make audio
> > > &g

Re: [pygtk] gobject.timeout_add()

[Pietro Battiston]

Il giorno ven, 22/01/2010 alle 21.44 -0800, dj ha scritto:
> Thank you John and Pietro for your observations and advice.
> 
> Because of them, I did some rethinking of my program.  Threading has
>  worked okay for a couple of years in this program as I continually
>  improved it.  But the GUI I started with had to be useful while
>  recordings were taking place.  I use the to tune a radio receiver
>  according to a schedule and record what was found there, and I needed
>  to be able to make adjustments on the fly.  I use a different radio
>  and GUI now, and except for Start and Quit buttons, the GUI is just to
>  supply information.  So I don't need threading or the timeouts to
>  pause the program until the recording is finished.  I'm not thrilled
>  with seeing the GUI go dark during recording, but it's okay.

Notice I was not at all suggesting to you to block the GUI... How do you
call your external processes?


> Now
>  there is only one 5-second timeout to check the clock between
>  scheduled recordings.
> 
> Is there a better way to monitor the clock?  I have to use time-of-day
>  rather than time periods, and I haven't figured out a better way than
>  executing time.gmtime() every 5 seconds.
> 

I unfortunately cannot understand _what_ type of monitoring you need,
and hence how you are currently implementing it.

Pietro

> westli
> 
> --- On Thu, 1/21/10, Pietro Battiston  wrote:
> 
> > From: Pietro Battiston 
> > Subject: Re: [pygtk] gobject.timeout_add()
> > To: pygtk@daa.com.au
> > Date: Thursday, January 21, 2010, 1:56 PM
> > Il giorno gio, 21/01/2010 alle 08.56
> > +0100, John Stowers ha scritto:
> > > On Wed, 2010-01-20 at 21:22 -0800, dj wrote:
> > > > I hope this is the right place to ask this...
> > > > 
> > > > I have a python program (using Glade to create
> > the gui) that periodically launches ecasound to make audio
> > recordings of various lengths.  In order to keep the
> > gui viable, ecasound runs in a separate thread.  In
> > order to keep the program from getting ahead of itself and
> > trying to launch ecasound before the current recording
> > process has finished, I use gobject.timeout_add() for the
> > length of the recording (plus a second or two for safety).
> > > > 
> > > > Most of the calls to gobject.timeout_add() are in
> > separate functions with different intervals.  All but
> > one of them work.  The last one only works if
> > gobject.timeout_add(..., ...)/return False is appended to
> > the end of the function that needs it, rather than calling
> > it.
> > > 
> > > This doesn't sound like a particuarly nice design,
> > 
> > More specifically: are you sure you need threads at all?!
> > subprocess.call will block the GUI, but subprocess.Popen
> > won't.
> > 
> > Pietro
> > 
> > ___
> > pygtk mailing list   pygtk@daa.com.au
> > http://www.daa.com.au/mailman/listinfo/pygtk
> > Read the PyGTK FAQ: http://faq.pygtk.org/
> > 
> 
> 
>   
> 
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] How to organize my app?

[Pietro Battiston]

Il giorno gio, 21/01/2010 alle 23.43 +0100, Pietro Battiston ha scritto:
> Il giorno gio, 21/01/2010 alle 23.14 +0100, middleofdre...@gmail.com ha
> scritto:
> > Hi,
> > I don't have experience in creating big apps. I want to know how to
> > split app into files. For example - I have main class in main file and
> > I want to move widgets (loading widgets from gladefile) into new file.
> > It should be in the mainclass i think.. but i can't import something
> > inside class (it works but it's not proper).
> 
> "If you don't want it into the same file of the main class, you
> certainly don't want it into the main class" is a rule for which I'm not
> able to see any exception.

Wait, just forget that. Your problem is obviously not that you want the
_code_ in your main class, but that you want another object as a member
of your main class. Which is perfectly fine.

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] How to organize my app?

[Pietro Battiston]

Il giorno gio, 21/01/2010 alle 23.14 +0100, middleofdre...@gmail.com ha
scritto:
> Hi,
> I don't have experience in creating big apps. I want to know how to
> split app into files. For example - I have main class in main file and
> I want to move widgets (loading widgets from gladefile) into new file.
> It should be in the mainclass i think.. but i can't import something
> inside class (it works but it's not proper).

"If you don't want it into the same file of the main class, you
certainly don't want it into the main class" is a rule for which I'm not
able to see any exception.

That said, what I do in many projects is creating this file:


import gtk

class Ui(object):
def __init__(self, APP, filename):
self._builder = gtk.Builder()
self._builder.set_translation_domain(APP)
self._builder.add_from_file(filename)

def __getattr__(self, attr_name):
try:
return object.__getattribute__(self, attr_name)
except AttributeError:
obj = self._builder.get_object(attr_name)
if obj:
self.obj = obj
return obj
else:
raise AttributeError, "no object named \"%s\" in the
GUI." % attr_name



and importing Ui from it; then, the main class will, in __init__, do
something like

self.ui = Ui("nameoftheapp", "path/to/the/file.glade")

so that from now on you just access widgets as

self.ui.name_of_the_widget


_But_ this is just what _I_ find convenient, and not really because I
want to separate it from the main class, but just to avoid some
get_object() calls and get cleaner code. In general, there are no
particular requirements to separate something from some class: if you
see it grew too big and there is something that can be separated from
it, just separate it.


> Or signal handlers - how to move them into other file and do it right?

I'm not really sure I would want to move signal handlers... if all your
handlers are method of this main class and you want to save some coding,
just use signals_autoconnect.

>  Another thing is i have some (not main) class, but it should interact
> with gui (some changes like showing widgets etc). It's assigned in
> mainclass and constructor of it looks like this:
> 
> 
> __init__(gui):
> self.gui=gui
> 
> 
> and then.. in functions of this class I can change for example
> self.gui.some_widget.show() 
> And again.. I don't think it's proper method for doing this.
> 

Well, in my opinion it's hard to say _in general_ that this is wrong.
When you choose the optimal size for some class, just think in terms of
functionalities: the best rule to respect is that it must be
comfortable.

Certainly, if "self.gui.some_widget.show()" is part of a block of code
that works on the gui, it may be smart to move it to a method of the gui
and call that from your class.


> 
> Some tips, please?
> 

Read other people's code, and just try. And obviously, be ready to
change things that you find not optimal.

Pietro


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Dialog

[Pietro Battiston]

Il giorno gio, 21/01/2010 alle 09.36 +, Peyman ha scritto:
> Hello
> 
> I recently switched a few of my windows from being of type gtk.Window  
> to gtk.Dialog. 

If you can show us the code, it will be much simpler...

> I fixed everything so the dialogs show up, but now  
> they are HUGE.

In one dimension or both?

> This has to do with the size_request of the horizontal  
> boxes (action_area).

How do you know? How are things distributed?

> Both the vbox and the action_area have  
> homogeneous=False and spacing=0

What about running

while widget:
print widget, widget.size_request(), widget.get_size_request()
parent = widget.get_parent()
if parent:
try:
print parent.child_get_property('expand')
print parent.child_get_property('fill')
except:
pass


?

When you can't for some reason provide code, please at least provide
lots of informations.

Pietro


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] gobject.timeout_add()

[Pietro Battiston]

Il giorno gio, 21/01/2010 alle 08.56 +0100, John Stowers ha scritto:
> On Wed, 2010-01-20 at 21:22 -0800, dj wrote:
> > I hope this is the right place to ask this...
> > 
> > I have a python program (using Glade to create the gui) that periodically 
> > launches ecasound to make audio recordings of various lengths.  In order to 
> > keep the gui viable, ecasound runs in a separate thread.  In order to keep 
> > the program from getting ahead of itself and trying to launch ecasound 
> > before the current recording process has finished, I use 
> > gobject.timeout_add() for the length of the recording (plus a second or two 
> > for safety).
> > 
> > Most of the calls to gobject.timeout_add() are in separate functions with 
> > different intervals.  All but one of them work.  The last one only works if 
> > gobject.timeout_add(..., ...)/return False is appended to the end of the 
> > function that needs it, rather than calling it.
> 
> This doesn't sound like a particuarly nice design,

More specifically: are you sure you need threads at all?!
subprocess.call will block the GUI, but subprocess.Popen won't.

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] How do I force resize of a top-level window?

[Pietro Battiston]

Il giorno gio, 17/12/2009 alle 21.25 +0330, Saeed Rasooli ha scritto:
> I think this is what you need: if the three zones are placed
> vertically(one below other), then set a "height-request" to every
> zone(the fixed height that it need). and pack every zone with
> expand=False and fill=False. for exmaple:
> ___
> 
> ## first Create three widgets zone1, zone2, zone3, and then...
> 
> zone1.set_property('height-request', 200)
> zone2.set_property('height-request', 200)
> zone3.set_property('height-request', 200)
> 
> vbox = gtk.VBox()
> win = gtk.Window()
> 
> ## Now pack them will NO EXPAND and NO FILL options

I'm afraid it's not enough. The window will leave some empty space, it
won't shrink.

But indeed, at this point you can call resize(1,1)

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] restore window position

[Pietro Battiston]

Il giorno gio, 17/12/2009 alle 22.13 +1100, Simon Burton ha scritto:
> On Thu, 17 Dec 2009 12:01:30 +0100
> Pietro Battiston  wrote:
> 
> ...
> > > On my system it moves the window down 24 pixels and to the right 5 pixels.
> > 
> > OK, now I understand. Which system is it?
> > 
> > Pietro
> > 
> 
> ubuntu 8.04, gnome, compiz, ...

OK, that's the difference.


> I'd like to write crossplatform code though.

Maybe
https://bugzilla.gnome.org/show_bug.cgi?id=535236
has the (two possible) answer(s) to your problem.

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] restore window position

[Pietro Battiston]

Il giorno gio, 17/12/2009 alle 21.53 +1100, Simon Burton ha scritto:
> On Thu, 17 Dec 2009 09:42:00 +0100
> Pietro Battiston  wrote:
> 
> ...
> > I didn't try all of these, nor did study the decorations problem, but I
> > did verify that:
> > 
> > w.move(*w.get_position())
> > 
> > does leave the window where it is. To my eyes, this would seem enough,
> > isn't it?!
> 
> On my system it moves the window down 24 pixels and to the right 5 pixels.

OK, now I understand. Which system is it?

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] restore window position

[Pietro Battiston]

Il giorno gio, 17/12/2009 alle 18.13 +1100, Simon Burton ha scritto:
> When finding out the position of a window i get a position that is offset by
> the window manager decorations. So I haven't been able to restore a windows
> position because the move function takes a position that is not offset by
> the decorations.
> 
> Is there a way around this problem ?
> 
> I have tried all the following:
> 
> window.window.get_frame_extents()
> window.allocation
> 
> window.get_position()
> 
> window.window.get_origin()
> 
> They all return coordinates offset by the window manager decorations.
> 

I didn't try all of these, nor did study the decorations problem, but I
did verify that:

w.move(*w.get_position())

does leave the window where it is. To my eyes, this would seem enough,
isn't it?!

That said, if you program for Linux also make sure you read
documentation for gtk.Window.set_role.

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] How do I force resize of a top-level window?

[Pietro Battiston]

Il giorno mer, 16/12/2009 alle 08.30 -0500, Eric Raymond ha scritto:
> For the GPSD project , I have just rewritten
> our crufty old Motif-based test client, xgps, in pygtk.  It was a
> pleasant experience. There is one feature I want that I can't seem to
> get working right, however.
> 
> The client display consists of three horizontal zones: a sky
> view, a raw-data display, and a GPS report display. I have written a
> "View" menu with three toggle-button entries to toggle showing or
> hiding each of these zones.  All are initially shown. Toggling hides
> and re-shows them; so far, so good.
> 
> But...the *intended* behavior (which I used to exploit under TkInter) 
> is that when I hide a zone, the top-level window shrinks vertically
> to fit the remaining zones, which are still packed as before. Conversely,
> when I re-show a zone, the window should re-size to the minimum needed
> to hold it and its siblings.
> 
> Calling queue_resize() on the top-level window doesn't do this. Is there
> some magic I need to mutter at the window manager?

If I recall correctly:
1) what you're trying to do is not contemplated in (py)gtk for the
reason that a user should presumably hate to see the window size
changing in front of his eyes when it's not strictly necessary
2) the best approach to force that behaviour is to explicitely call
gtk.Window.resize(). There are two cases
 1: your widgets (those still showing up) currently all occupy exactly
their size request: then just the_window.resize(1,1) is fine - it
resizes to the smallest possible size
 2: some widget is currently bigger than its current size request (and
you don't want to shrink it): if you _know_ their size, there's no
problem; if you don't, you should be able to get it from the
size_request() (NOT get_size_request()!) of the biggest child (an HBox,
I presume).
3) the "gtkish" way to do something similar to what you're trying to
should be to not make the zone disappear, but for instance just set it
as insensitive.

Pietro

P.S: you'll probably not need it, but just in case:
http://www.pietrobattiston.it/wiki/doku.php?id=pygtk:resizing

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] is there a Manual for PyGTK 2.0 Reference Manual to download?

[Pietro Battiston]

Il giorno lun, 07/12/2009 alle 17.59 +0800, engine spot ha scritto:
> I know there is a web manual
> 
> http://library.gnome.org/devel/pygtk/stable/
> 
> but but is there a Manual to download?

Sure. For instance, you can install python-gtk2-doc in Debian or Ubuntu,
or just find it in the original pygtk tarball from the official site.

(html format)

(to browse it, devhelp is particularly nice)

Pietro


> 
> 2009/12/7 engine spot :
> > Hello
> >is there a Manual for PyGTK 2.0 Reference Manual to download?
> >maybe the format is pdf or html is best
> >
> ___
> pygtk mailing list   pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/



signature.asc
Description: Questa è una parte del messaggio firmata digitalmente
___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] glib under Windows

[Pietro Battiston]

Il giorno ven, 04/12/2009 alle 20.01 +0300, Abdul-Wahid Paterson ha
scritto:
> Hi
> 
> I have been programming for sometime under Linux using pygtk and now
> someone wants to run my application under Windows. I am not an expert
> in Windows or Python under Windows but made a test install with a test
> GTK app and it all worked fine.
> 
> With my app it is not working and can not find the glib module which I
> thought was apart of pygobject which I have sucessfully installed
> under Windows. glib is not there though. Any ideas what I am missing?
> Are there are any other dependencies for the Python glib bindings
> under Windows?
> 

I'm not a Windows expert neither, however pygobject _certainly_ uses
glib, so if it's correctly installed and working, glib is too.

What do you mean exactly by "glib is not there"?

Pietro


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] How to destroy Window hierarchy and corner cases

[Pietro Battiston]

Il giorno ven, 04/12/2009 alle 19.20 +0100, Alessandro Dentella ha
scritto:
> Hi,
> 
>   I have an application that writes to StatusBar and uses timeout_add to
>   delete the message after a fixed number of seconds.
> 
>   If in the meanwhile I destroy() the toplevel window I notice that under
>   Linux I get the following message:
> 
> /home/misc/src/hg/py/sqlkit/sqlkit/layout/layout.py:661: GtkWarning: 
> gtk_label_set_text: assertion `GTK_IS_LABEL (label)' failed
>   msg_id = sb.push(idx, txt)
> /home/misc/src/hg/py/sqlkit/sqlkit/layout/layout.py:669: GtkWarning: 
> gtk_label_set_text: assertion `GTK_IS_LABEL (label)' failed
>   sb.remove(idx, msg_id)
> 
>   Under Windows sometimes it just crashed the application.
> 
>   
>   The problem is that when I receive a delete-event from a window, I
>   destroy() it but the children are not really destroyed, e.g., with
>   ipython you can still browse all its methods. The difference is that
>   get_toplevel() will return the widget itself rather than the toplevel.
> 
>   
>   Which is the correct/suggested way to destroy all elements of a hierarcy
>   of widgets upon delete-event?
> 


(I might be wrong, but) I think that "destroy()" is not exactly what you
think. I mean: for instance,

w=gtk.Window()
w.destroy()
w.get_position()

works perfectly and returns (0,0).

Destroying a widget simply means deleting it from any widget gerarchy:
for instance, if your widget is in a container, the container will
"forget" about it; if your widget is a toplevel, it will disappear from
the toplevels list.

Then, if(f) the reference count for the object goes to 0, the object
will be presumably really destroyed (its memory freed), but if you
(through pure python, not pygtk) keep some reference to it, it will stay
there: that's why the above "w.destroy" has no effect at all.

When you destroy a toplevel, its children are destroyed only in the
sense that they may become unreferenced, and then disappear.

That said, I don't understand the error you get, neither why you'll
experience crashes in Windows, and there _may_ be some (py)gtk bug
showing; however, if I understood correctly what you're assuming, I hope
I explained correctly why it's not a correct assumption.

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Drawing polygon with Cairo

[Pietro Battiston]

Il giorno mar, 01/12/2009 alle 22.39 +0530, nipun batra ha scritto:
> 
> 
> On Tue, Dec 1, 2009 at 10:37 PM, Pietro Battiston 
> wrote:
> Il giorno mar, 01/12/2009 alle 22.11 +0530, nipun batra ha
> scritto:
> > There seems to be an easy way to draw polygons using
> Graphics Context
> > as described in chap 12 of manual.How can the same thing be
> done using
> > cairo
> 
> 
> What (easy) way?
> What manual?
> Some particular kind of polygon?
> 
> For a generic polygon, I don't think anythink sensibly
> "easier" than a
> sequence of "line_to" followed by "close" and "strike" (or
> "fill") is
> conceivable.
> 
> But I think that, both to increase the probability of a
> satisfying
> answer and as a mere matter of respect for people to whom
> you're asking
> to help you, you should be more clear in your questions.
> 
> Pietro
> 
> 
> 
> This is what i have thought as of now.wanted to use faster
> implementations.
> 
> 
> def draw_polygon(x0, y0,x1,y1,x2,y2,x3,y3):
> cr.move_to(x0,y0)
> cr.line_to(x1,y1)
> cr.move_to(x1,y1)
> cr.line_to(x2,y2)
> cr.move_to(x2,y2)
> cr.line_to(x3,y3)
> cr.move_to(x3,y3)
> cr.line_to(x0,y0)
> 
> #cr.arc(x, y, 2, 0, 2 * pi)
> cr.set_source_rgba(0, 0, 0, 1)
> cr.stroke()
> 
> 

What makes you think this is slow?

Pietro


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Drawing polygon with Cairo

[Pietro Battiston]

Il giorno mar, 01/12/2009 alle 22.11 +0530, nipun batra ha scritto:
> There seems to be an easy way to draw polygons using Graphics Context
> as described in chap 12 of manual.How can the same thing be done using
> cairo 

What (easy) way?
What manual? 
Some particular kind of polygon?

For a generic polygon, I don't think anythink sensibly "easier" than a
sequence of "line_to" followed by "close" and "strike" (or "fill") is
conceivable.

But I think that, both to increase the probability of a satisfying
answer and as a mere matter of respect for people to whom you're asking
to help you, you should be more clear in your questions.

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] gtk.Curve issues

[Pietro Battiston]

Il giorno lun, 23/11/2009 alle 18.40 +0100, danieleisca ha scritto:
> Hi all,
> I am trying to add the BUTTON_RELEASE_MASK to this widget, but 
> connecting the signal with the callback, nothing happens.

... and it's not just a problem of BUTTON_RELEASE_MASK: the signal
'button_press_event' is only triggered by double clicks...

See https://bugzilla.gnome.org/show_bug.cgi?id=80978#c5

Pietro




___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] How to build a PyGTK application with autotools for Windows

[Pietro Battiston]

Il giorno lun, 23/11/2009 alle 01.34 -0200, Leonardo Ferreira Fontenelle
ha scritto:
> Hello, I've written a small application for GNU/Linux with Python 2.5
> +, PyGTK, PyGobject and Sqlite3, and I'd like to port it to Windows as
> well. I used the GNU Build System, a.k.a. autotools, because I thought
> it would be easier to integrate translation support with Intltool. But
> on the other hand every instruction on porting Python applications to
> Windows uses Python's distutils, or presumes a simple Python script.
> 
> Could anyone please show me a tutorial on building Python/PyGTK
> applications with autotools for Windows? If it's not possible, would
> anyone please show me a tutorial on integrating Intltools and GNOME
> Doc Utils on distutils?

I discover GNOME Doc Utils in this moment, but can suggest to take a
look at DistUtilsExtra.

I couldn't find a tutorial; however I do use it here:

http://bazaar.launchpad.net/~toobaz/gvb/trunk/annotate/head%3A/setup.py

... though probably not optimally, since I bet it shouldn't be necessary
to play with all omf files. Also, DistUtilsExtra should be able to cope
also with installation of localization, but I still don't use it for
that.


http://www.glatzor.de/projects/python-distutils-extra/


Pietro



--

This email would probably have arrived sooner if "reply" replied to the
mailing list I'm replying to.


___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Embedding ipython in pygtk

[Pietro Battiston]

Il giorno ven, 20/11/2009 alle 17.20 +0100, David Trem ha scritto: 
> Hi,
> 
>   I'm wondering whether anybody port the
> ipython_view.py from the Accerciser project which allows to
> embed ipython in pygtk app, to the current version of ipython ?
> See:
> http://ipython.scipy.org/moin/Cookbook/EmbeddingInGTK
> 
> It seems that the new ipython scheme to integrate better with GUI 
> toolkit event loops broke this nice peace of code.
> 
> If someone was successful in embedding current version
> of ipython in pygtk, I hope this person would be eager to share.
> 
> I was not lucky posting on ipython list, thus I try on pygtk one.


I'm not totally sure I'm answering to your question, but I do often use
an ipython nested into pygtk to play with pygtk without having to block
the interface with a loop() call.


I use the attached files (run "shell.py").

It's certainly not perfect, though: ipython does not behave exactly as
in an ordinary terminal.

Pietro



--

This email would probably have arrived sooner if "reply" replied to the
mailing list I'm replying to.

"""
Backend to the console plugin.

@author: Eitan Isaacson
@organization: IBM Corporation
@copyright: Copyright (c) 2007 IBM Corporation
@license: BSD

All rights reserved. This program and the accompanying materials are made 
available under the terms of the BSD which accompanies this distribution, and 
is available at U{http://www.opensource.org/licenses/bsd-license.php}
"""
# this file is a modified version of source code from the Accerciser project
# http://live.gnome.org/accerciser

import gtk
import re
import sys
import os
import pango
from StringIO import StringIO

try:
import IPython
except Exception,e:
raise "Error importing IPython (%s)" % str(e)

ansi_colors =  {'0;30': 'Black',
'0;31': 'Red',
'0;32': 'Green',
'0;33': 'Brown',
'0;34': 'Blue',
'0;35': 'Purple',
'0;36': 'Cyan',
'0;37': 'LightGray',
'1;30': 'DarkGray',
'1;31': 'DarkRed',
'1;32': 'SeaGreen',
'1;33': 'Yellow',
'1;34': 'LightBlue',
'1;35': 'MediumPurple',
'1;36': 'LightCyan',
'1;37': 'White'}

class IterableIPShell:
  def __init__(self,argv=None,user_ns=None,user_global_ns=None,
   cin=None, cout=None,cerr=None, input_func=None):
if input_func:
  IPython.iplib.raw_input_original = input_func
if cin:
  IPython.Shell.Term.cin = cin
if cout:
  IPython.Shell.Term.cout = cout
if cerr:
  IPython.Shell.Term.cerr = cerr

if argv is None:
  argv=[]

# This is to get rid of the blockage that occurs during 
# IPython.Shell.InteractiveShell.user_setup()
IPython.iplib.raw_input = lambda x: None

self.term = IPython.genutils.IOTerm(cin=cin, cout=cout, cerr=cerr)
os.environ['TERM'] = 'dumb'
excepthook = sys.excepthook
self.IP = IPython.Shell.make_IPython(argv,user_ns=user_ns,
 user_global_ns=user_global_ns,
 embedded=True,
 shell_class=IPython.Shell.InteractiveShell)
self.IP.system = lambda cmd: self.shell(self.IP.var_expand(cmd),
header='IPython system call: ',
verbose=self.IP.rc.system_verbose)
sys.excepthook = excepthook
self.iter_more = 0
self.history_level = 0
self.complete_sep =  re.compile('[\s\{\}\[\]\(\)]')

  def execute(self):
self.history_level = 0
orig_stdout = sys.stdout
sys.stdout = IPython.Shell.Term.cout
try:
  line = self.IP.raw_input(None, self.iter_more)
  if self.IP.autoindent:
self.IP.readline_startup_hook(None)
except KeyboardInterrupt:
  self.IP.write('\nKeyboardInterrupt\n')
  self.IP.resetbuffer()
  # keep cache in sync with the prompt counter:
  self.IP.outputcache.prompt_count -= 1

  if self.IP.autoindent:
self.IP.indent_current_nsp = 0
  self.iter_more = 0
except:
  self.IP.showtraceback()
else:
  self.iter_more = self.IP.push(line)
  if (self.IP.SyntaxTB.last_syntax_error and
  self.IP.rc.autoedit_syntax):
self.IP.edit_syntax_error()
if self.iter_more:
  self.prompt = str(self.IP.outputcache.prompt2).strip()
  if self.IP.autoindent:
self.IP.readline_startup_hook(self.IP.pre_readline)
else:
  self.prompt = str(self.IP.outputcache.prompt1).strip()
sys.stdout = orig_stdout

  def historyBack(self):
self.history_level -= 1
return self._getHistory()

  def historyForward(self):
self.history_level += 1
return self._getHistory()

  def _getHistory(self):
try:
  rv = self.IP.user_ns['In'][sel

Re: [pygtk] [Denemo-devel] denemo.ttf

[Pietro Battiston]

Il giorno mar, 17/11/2009 alle 15.55 +, Richard Shann ha scritto:
> On Tue, 2009-11-17 at 15:25 +0100, Nils wrote:
> > Is it possible to add more things to denemo.ttf? Maybe I can try out a font 
> > editor some time or we find a person who likes such small tasks. 
> > The lilypond graphics for things like the double barline are ok,
> denemo.ttf is only used for menu labels etc, where it is mixed with
> ordinary text (so that you can write sentences with 1/4 note without
> using the words). The denemo display is made of
>   built-in: xbm files generated from LilyPond's own fonts (IIRC)
>   directives: png files, usually generated by capture from LilyPond
> printpreview, but anything we like, e.g. gimp.
> 
> Richard
> 

If you touch denemo.ttf, I'd suggest it's the right moment...

Il giorno sab, 07/11/2009 alle 12.39 +0100, Pietro Battiston ha
scritto: 
> a) replace, in denemo.ttf, the mention of this "free public license"
> with a mention of the OFL
> b) at the beginning of LICENSE_OFL, write "denemo.ttf was derived from
> font Musi{appropriate suffix}; what follows is the Mus{appropriate
> suffix} license.


bye

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] ANN: PyGUI 2.1

[Pietro Battiston]

Il giorno mar, 17/11/2009 alle 11.19 +1300, Greg Ewing ha scritto:
> Pietro Battiston wrote:
> 
> > And I promise I won't come there just saying that PyGUI API sucks
> 
> Okay, that particular remark was a bit rude, and I
> apologise for it.
> 
> Let me rephrase: One of the reasons I created PyGUI
> is that none of the existing cross-platform GUI APIs,
> including pygtk, are entirely to my taste. So making
> PyGUI emulate pygtk wouldn't make sense from my
> point of view.
> 
> I certainly don't mean to dissuade anyone from
> using pygtk. If you like it, by all means continue
> to use it.
> 


OK, that's more diplomatic.

My opinion is that if you create a mailing list for PyGUI (and I suggest
Mailman [0], the software running this mailing list, for it), a message
"if anybody is interested in a different approach to pygtk, a PyGUI
mailing list has been created at this address" on this mailing list will
cause no complaints (notice your first email didn't mention pygtk at
all).


Pietro


[0]: http://www.gnu.org/software/mailman/index.html

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] ANN: PyGUI 2.1

[Pietro Battiston]

Il giorno lun, 16/11/2009 alle 10.17 +1300, Greg Ewing ha scritto:
> John Finlay wrote:
> > Greg,
> > 
> > Why do you post to mailing lists that are unrelated to your project? I 
> > would appreciate it if in future you didn't post a message about your 
> > project ot the PyGTK mailing list.
> 
> I posted the announcement to the pyobjc, pygtk and pywin32
> lists because PyGUI uses all of those libraries, and because
> I don't know of any single mailing list where people interested
> in Python GUIs in general can be found.
> 
> However, if the consensus is that PyGUI announcements are
> not welcome on those lists, I will be happy to cease posting
> them there.
> 
> What is the general feeling out there? Should I stop posting
> PyGUI messages to these lists?

Obviously.


> Is there another GUI-related
> list that would be more appropriate?


PyGUI mailing list, if it exists.

And I promise I won't come there just saying that PyGUI API sucks
(though I honestly think it does, at least for the parts of it I
personally know) and you should abandon it in favour of PyGTK.


best luck

Pietro Battiston



signature.asc
Description: Questa è una parte del messaggio firmata digitalmente
___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Re: [pygtk] Stock Icons with no Image

[Pietro Battiston]

Il giorno mer, 04/11/2009 alle 12.16 +0100, Timo ha scritto:
> Search a bit in gconf-editor. There is a key you can set back to True to 
> let the stock icons show.

/desktop/gnome/interface/{buttons_have_icons,menus_have_icons}

Pietro


--

This email would probably have arrived sooner if "reply" replied to the
mailing list I'm replying to.




> 
> Timo
> 
> 
> Timothy Ulusoy schreef:
> > Then this is a case of "it's not a bug, it's a feature!"
> >
> > Is there any document relating to this decision of the developers, 
> > that you can direct me to?
> >
> > Thanks a lot.
> >
> > On Tue, Nov 3, 2009 at 10:23 PM, Marco Antonio Islas Cruz 
> > mailto:mar...@islascruz.org>> wrote:
> >
> > Actually it is not a problem, developers wanted to behave like that.
> >
> > On Tue, 2009-11-03 at 22:08 +0200, Timothy Ulusoy wrote:
> > > Thank you Marco,
> > >
> > > Now at least I know that it is a general problem, and it is not only
> > > my system that fails. :)
> > >
> > >
> > >
> > > On Tue, Nov 3, 2009 at 9:56 PM, Marco Antonio Islas Cruz
> > > mailto:mar...@islascruz.org>> wrote:
> > > On karmic, I can't remember if it is because of Gtk+ or
> > GNOME
> > > there are
> > > no icons in stock buttons. You must use a custom button
> > (with
> > > a hbox for
> > > example) with a gtk.Image and a gtk.Label.
> > >
> > >
> > >
> > > On Tue, 2009-11-03 at 21:03 +0200, Timothy Ulusoy wrote:
> > > > Hello,
> > > >
> > > > I have a problem with stock items. When I try to show a
> > > button with
> > > > stock icon, I only see the text. For example, the
> > following
> > > code from
> > > > Zetcode website only gives me the texts of the buttons (no
> > > images):
> > > >
> > > > import gtk
> > > >
> > > > class PyApp(gtk.Window):
> > > > def __init__(self):
> > > > super(PyApp, self).__init__()
> > > >
> > > > self.set_title("Buttons")
> > > > self.set_size_request(250, 200)
> > > >
> > > > self.set_position(gtk.WIN_POS_CENTER)
> > > >
> > > > btn1 = gtk.Button("Button")
> > > > btn1.set_sensitive(False)
> > > > btn2 = gtk.Button("Button")
> > > > btn3 = gtk.Button(stock=gtk.STOCK_CLOSE)
> > > >
> > > > btn4 = gtk.Button("Button")
> > > > btn4.set_size_request(80, 40)
> > > >
> > > > fixed = gtk.Fixed()
> > > >
> > > > fixed.put(btn1, 20, 30)
> > > > fixed.put(btn2, 100, 30)
> > > > fixed.put(btn3, 20, 80)
> > > >
> > > > fixed.put(btn4, 100, 80)
> > > >
> > > > self.connect("destroy", gtk.main_quit)
> > > >
> > > > self.add(fixed)
> > > > self.show_all()
> > > >
> > > >
> > > > PyApp()
> > > > gtk.main()
> > > >
> > > > I'm running Ubuntu Karmic Koala. Thinking that this may be
> > > related to
> > > > the GTK theme I use (Human theme), I tried the other
> > themes,
> > > but to no
> > > > avail. Any comments will be much appreciated.
> > > >
> > > > Thanks.
> > > > Timothy
> > >
> > > > ___
> > > > pygtk mailing list   pygtk@daa.com.au
> > 
> > > > http://www.daa.com.au/mailman/listinfo/pygtk
> > > > Read the PyGTK FAQ: http://faq.pygtk.org/
> > >
> > >
> > > --
> > > <--Linux... Because I'm Free-->
> > > Marco Antonio Islas Cruz
> > > "Markuz"
> > > Linux User #280229
> > > mar...@islascruz.org 
> > > mar...@unixmexico.org 
> > > mar...@linuxpozarica.com 
> > > marco.is...@gmail.com 
> > > islac...@yahoo.com 
> > > http://www.islascruz.org
> > > http://.christine-project.org
> > > http://www.linuxpozarica.com
> > >
> >
> >
> > --
> > <--Linux... Because I'm Free-->
> > Marco Antonio Islas Cruz
> > "Markuz"
> > Linux User #280229
> > mar...@islascruz.org 

Re: [pygtk] UIManager submenu in a popup?

[Pietro Battiston]

Il giorno mar, 03/11/2009 alle 18.25 -0600, Raymond Maple ha scritto:
> Hello,
>I've used uimanager to construct a popup menu that contains a
>  with several s as follows:
> 
> popup1 = """
> 
>   
>   
>   
> 
> 
> 
> 
>   
> 
> """
> 
> The resulting menu displays correctly, but the submenu action
> callbacks only execute If I click on the "Display" menu item to open
> up the submenu, and then click on the sub-item..  If i just hover over
> 'Display' until the  submenu opens and  then release over one of the
> submenu items, the action callback is not executed.  I've tried
> similar menus in a menubar, and they work correctly (hover-release
> executes the callback).  Is this a "feature" of gtk popups, or is
> there something I am missing?


Take a look at https://bugzilla.gnome.org/show_bug.cgi?id=533492 , which
also suggests a workaround.

Pietro

___
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/