Re: [pygtk] removing remaining rows in a liststore
John Finlay <[EMAIL PROTECTED]> writes: > However the docs are right that > remove(iter) will advance the iter (i.e. point at the next row if any) > unless there is no next row in which case iter is invalid. Thanks for pointing this out. This matches the behavior of the C API. I was much too quick to assume that Pygt behavior didn't match your very fine documentation -- I should have tested it. ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Is there an automated way to create IconSources/IconSets/IconFactories ?
[...] > I do it the way you describe, and it's a very simple bit if code. Using XML > seems like it would actually be more work. (I'd probably use a dictionary, > now instead of a list of tuples.). [...] FAQ 8.12: http://www.async.com.br/faq/pygtk/index.py?req=show&file=faq08.012.htp I always wanted to have an easy way of doing that, thanks! -- Johan Dahlin <[EMAIL PROTECTED]> ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Is there an automated way to create IconSources/IconSets/IconFactories ?
On Thu, Nov 18, 2004 at 11:12:48AM -0500, Chris Lambacher wrote:
> I am attempting to use UIManager to generate a ToolBar and a MenuBar.
> I want to add icons that are not stock icons, but UIManger requires
> that you use stock icons. That means that an IconFactory needs to be
> created for the icons I wish to use. IconSets need to be added to the
> IconFactory for each icon and IconSources have to be added to the
> IconSets. I have my icons and I could just write a module to create
> the IconFactory (I want to share the icons between several related
> projects), but given that I can specify my menus and toolbars in XML I
> was wondering if there was a way to do the equivalent for IconFactory
> creation. Styles obviously do something similar to this. Can I
> create a partial style and just grab the IconFactory for that style
> and run the set_default method?
I do it the way you describe, and it's a very simple bit if code. Using XML
seems like it would actually be more work. (I'd probably use a dictionary,
now instead of a list of tuples.).
import gtk
'''Registers new icons with gtk. Tries to use already existing icons
if they are available, otherwise it loads them from files.'''
ICON_INFO = [
('gnome-stock-mic', 'gnome-stock-mic.png'),
('gnome-stock-midi', 'stock_midi.png'),
('gnome-stock-attach', 'stock_attach.png'),
('classicollect-composer', 'composer.png'),
('classicollect-work', 'work.png'),
('classicollect-role', 'role.png'),
('classicollect-artist', 'artist.png'),
('classicollect-performance', 'performance.png')
]
def register_iconsets(icon_info):
iconfactory = gtk.IconFactory()
stock_ids = gtk.stock_list_ids()
for stock_id, file in icon_info:
# only load image files when our stock_id is not present
if stock_id not in stock_ids:
pixbuf = gtk.gdk.pixbuf_new_from_file(file)
iconset = gtk.IconSet(pixbuf)
iconfactory.add(stock_id, iconset)
iconfactory.add_default()
register_iconsets(ICON_INFO)
Dave Cook
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] delete lines from draw area
This is some good info. See also
http://www.async.com.br/faq/pygtk/index.py?req=show&file=faq18.008.htp
You'll notice DrawingArea is a fairly low-level widget. A good
alternative is to use GnomeCanvas, which takes care of most problems for
the programmer.
There is hope gtk+ will have a cairo-based canvas widget in gtk+2.8.
Until then we're stuck with either GtkDrawingArea or GnomeCanvas.
Regards.
Sex, 2004-11-19 às 17:15 +0100, Danny Milosavljevic escreveu:
> Hi,
>
> Am Mittwoch, den 17.11.2004, 23:30 -0400 schrieb Luis Useche:
> > hi,
> > i wanna know, how can delete a line from a draw area that i do with a gc.
>
> 'delete' a line ? What do you mean ?
>
> [ memorized objects ]
> This is not a vector graphics canvas so 'line' isnt a memorized object
> and *not* stored in the drawingarea. So in the worst case you'd have to
> restore each pixel from before (when you did save them before calling
> draw_line). sloow.
>
> As far as I understand it is like this:
> [ Drawable ]
> A Drawable is an object with a signal where one will be told 'hey, I
> need to be redrawed' ('expose-event') and then one has to redraw
> everything onto it again (and again... and again... and again...)
>
> [ Drawingarea ]
> A Drawingarea is a gtk widget that contains a drawable (within the
> attribute "window").
>
> [ 'expose-event' signal ]
> So you'd have to register a function with 'expose-event' signal (with
> connect()) and, elsewhere, from the time on where you want the line to
> vanish, modify some program data that removes the line from its memory.
>
> [ queue_draw() ]
>
> Then request it to redraw with queue_draw().
> Sometime later X/Gdk/Gtk will ask you to redraw by emitting the expose
> signal you told it to emit.
> Your callback will be called.
>
> [ in the callback ]
>
> You clear the drawingarea (with draw_rectangle or something)
> You check your program data and iterate over all objects [since now you
> memorize the line objects because they are stored in your object], and
> call draw_*() for each of them.
>
> [ flickering, double buffering ]
> This could flicker like hell. So use a Pixmap as temporary storage(a
> Pixmap can be used the same as a drawable) and only at the end copy the
> Pixmap content into the original drawingarea. Given a half-recent
> graphics adapter it will stop flickering (since ideally the Pixmap ->
> Drawable transfer is done entirely in graphics adapter memory which are
> fast enough)
>
> [ other kinds of classes ]
> To be complete, other kinds are:
> A Pixmap is a in-(graphics-adapter-)memory but offscreen Drawable that
> will remember what is drawn on it (just the pixels, so it has hazy
> recollection ;)).
>
> A Bitmap is a Pixmap with only black/white (on/off) pixels.
>
> A Pixbuf is a storage class that will store some picture and allow only
> primitive manipulation (no draw_line, no draw_spline, no
> draw_mandelbrot, just some alpha blending and mixing and matching :)).
>
> To show a pixbuf it is drawn on a drawable (usually a Pixmap or some
> Drawable like GdkWindow).
>
> Therefore there is a 'Image', that is a widget somewhat like a
> Drawingarea that draws either a pixbuf or pixmap automatically (that is,
> when and 'expose-event' arrives, the callback from the Image will call
> draw_pixbuf to redraw it again... and again... and again... when told
> to).
>
> >
> > code:
> > self.area.window.draw_line(self.gc, x1, y1, x2, y2)
>
> [ bad ways ]
> If you meant to draw over the existing line using the background color
> (which usually doesnt do it right), then you probably could do it like
> this [although you should not, for reasons listed below]
> self.black_color =
> self.area.get_colormap().alloc_color(gtk.gdk.color_parse("black"))
> ...
> color = self.black_color
> self.gc.set_foreground(color)
> self.area.window.draw_line(self.gc, x1frombefore, y1frombefore,
> x2frombefore, y2frombefore)
>
> [ why bad ]
> Reasons not to:
> - it will wreck havoc on the other still visible lines in the
> drawingarea (try intersecting lines and you'll see)
> - one doesnt know if the widget background is a picture rather than a
> color (I think that holds less true for Drawingareas though)
>
> [ 'good' ways ]
> So there were some ways introduced in ancient times: :)
>
> [ XOR ]
> The fastest is XOR drawing the line. That will draw the line pixel for
> pixel, but not by *setting* each drawable pixel to the 'foreground
> color' (from the gc), but by using XOR with each existing drawable pixel
> and the 'foreground color' (from the gc).
> because A XOR B XOR B = A, it will vanish with every second draw_line
> call.
> Advantages:
> - fast like hell
> Disadvantages:
> - need to find a clearly visible "B" (that will give a color that is
> distinguishable from A easily)
> - before changing anything on the underlying lines, one always has to
> remove the 'xored once' line first (by xor-drawing it), then draw the
> underlying lines
Re: [pygtk] delete lines from draw area
Hi,
Am Mittwoch, den 17.11.2004, 23:30 -0400 schrieb Luis Useche:
> hi,
> i wanna know, how can delete a line from a draw area that i do with a gc.
'delete' a line ? What do you mean ?
[ memorized objects ]
This is not a vector graphics canvas so 'line' isnt a memorized object
and *not* stored in the drawingarea. So in the worst case you'd have to
restore each pixel from before (when you did save them before calling
draw_line). sloow.
As far as I understand it is like this:
[ Drawable ]
A Drawable is an object with a signal where one will be told 'hey, I
need to be redrawed' ('expose-event') and then one has to redraw
everything onto it again (and again... and again... and again...)
[ Drawingarea ]
A Drawingarea is a gtk widget that contains a drawable (within the
attribute "window").
[ 'expose-event' signal ]
So you'd have to register a function with 'expose-event' signal (with
connect()) and, elsewhere, from the time on where you want the line to
vanish, modify some program data that removes the line from its memory.
[ queue_draw() ]
Then request it to redraw with queue_draw().
Sometime later X/Gdk/Gtk will ask you to redraw by emitting the expose
signal you told it to emit.
Your callback will be called.
[ in the callback ]
You clear the drawingarea (with draw_rectangle or something)
You check your program data and iterate over all objects [since now you
memorize the line objects because they are stored in your object], and
call draw_*() for each of them.
[ flickering, double buffering ]
This could flicker like hell. So use a Pixmap as temporary storage(a
Pixmap can be used the same as a drawable) and only at the end copy the
Pixmap content into the original drawingarea. Given a half-recent
graphics adapter it will stop flickering (since ideally the Pixmap ->
Drawable transfer is done entirely in graphics adapter memory which are
fast enough)
[ other kinds of classes ]
To be complete, other kinds are:
A Pixmap is a in-(graphics-adapter-)memory but offscreen Drawable that
will remember what is drawn on it (just the pixels, so it has hazy
recollection ;)).
A Bitmap is a Pixmap with only black/white (on/off) pixels.
A Pixbuf is a storage class that will store some picture and allow only
primitive manipulation (no draw_line, no draw_spline, no
draw_mandelbrot, just some alpha blending and mixing and matching :)).
To show a pixbuf it is drawn on a drawable (usually a Pixmap or some
Drawable like GdkWindow).
Therefore there is a 'Image', that is a widget somewhat like a
Drawingarea that draws either a pixbuf or pixmap automatically (that is,
when and 'expose-event' arrives, the callback from the Image will call
draw_pixbuf to redraw it again... and again... and again... when told
to).
>
> code:
> self.area.window.draw_line(self.gc, x1, y1, x2, y2)
[ bad ways ]
If you meant to draw over the existing line using the background color
(which usually doesnt do it right), then you probably could do it like
this [although you should not, for reasons listed below]
self.black_color =
self.area.get_colormap().alloc_color(gtk.gdk.color_parse("black"))
...
color = self.black_color
self.gc.set_foreground(color)
self.area.window.draw_line(self.gc, x1frombefore, y1frombefore,
x2frombefore, y2frombefore)
[ why bad ]
Reasons not to:
- it will wreck havoc on the other still visible lines in the
drawingarea (try intersecting lines and you'll see)
- one doesnt know if the widget background is a picture rather than a
color (I think that holds less true for Drawingareas though)
[ 'good' ways ]
So there were some ways introduced in ancient times: :)
[ XOR ]
The fastest is XOR drawing the line. That will draw the line pixel for
pixel, but not by *setting* each drawable pixel to the 'foreground
color' (from the gc), but by using XOR with each existing drawable pixel
and the 'foreground color' (from the gc).
because A XOR B XOR B = A, it will vanish with every second draw_line
call.
Advantages:
- fast like hell
Disadvantages:
- need to find a clearly visible "B" (that will give a color that is
distinguishable from A easily)
- before changing anything on the underlying lines, one always has to
remove the 'xored once' line first (by xor-drawing it), then draw the
underlying lines normally, then readd the 'xored' line (by xor-drawing
it) again. Can get tedious.
[ redraw all ]
Thus nowadays usually one just redraws all the stuff and be over with.
(since comps are faster)
As I said, in your callback you'll just leave the line out that you dont
want to see anymore and it is gone :)
[ damage system ]
Some use a 'damage system' that will notice changes in areas and add the
areas to a list of damaged areas. When redrawing it will only redraw
what has been 'damaged' (well, one only stores rectangular areas so most
of the time more than needed is redrawn).
(I think gtk can do that too, since there is a queue_draw_area call. I
am too lazy and so never checked the
Re: [pygtk] How to Set a Window Icon to a Stock Image
On Thu, Nov 18, 2004 at 02:21:46PM -0600, Doug Quale wrote: > > Fair enough. So how do I instead set a window's icon to a stock image? > > Alternatively, how do I get a pixbuf from a stock image? > > > > As you note, since you want a pixbuf rather than a gtkImage widget a > more direct approach would be nicer. You can get a stock icon pixbuf > using the gtkWidget render_icon() method. (Unfortunately ethods like > these that are far up the inheritance hierarchy can be hard to find.) > > pixbuf = dialog.render_icon(gtk.STOCK_FIND, gtk.ICON_SIZE_MENU) > dialog.set_icon(pixbuf) -> FAQ 8.11 http://www.async.com.br/faq/pygtk/index.py?req=show&file=faq08.011.htp Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] removing remaining rows in a liststore
Doug Quale wrote: Chris Lambacher <[EMAIL PROTECTED]> writes: if iter does not override the __nonzero__ method from object, the while loop will always evaluate iter as true. The documenation says that listtstore.remove sets iter to the next valid row so the original unless it is the last row in which case the iter is invalidated. so the while loop needs to check if iter is valid using liststore.iter_is_valid: while self.lstore.iter_is_valid(iter): self.lstore.remove(iter) if remove invalidates iter rather than setting it to the next line, the documentation needs to be updated. I think the docs are wrong and remove(iter) won't advance the iter. In the C API, iter is a reference parameter. This is a handy C idiom but it's pretty hostile to bindings. In order to advance the iter you need to call iter_next(). You have to be careful though, because this won't work: # don't do this while self.lstore.iter_is_valid(iter): iter = self.lststore.iter_next(iter) The iter_next() method returns None when applied to an iter to the last row, so ultimately when you run off the end of the list you will get an error because None isn't a GtkTreeIter: >>> self.lstore.iter_is_valid(None) Traceback (most recent call last): File "", line 1, in ? TypeError: iter should be a GtkTreeIter The original "while iter:" test is good and it's almost always what you want. In normal use your iters will come from get_iter_first(), iter_next() and append() and the like. The iters should always be valid or None unless you remove the row they refer to. Since you're the one removing the row you know when the iter isn't valid -- there's rarely a need to test. # A slow way to do self.lstore.clear() iter = self.lstore.get_iter_first() while iter: next = self.lstore.iter_next(iter) self.lstore.remove(iter) iter = next Thanks to everyone that posted replies. I found that both of these work: while iter and self.lstore.iter_is_valid(iter): self.lstore.remove(iter) while iter: next = self.lstore.iter_next(iter) self.lstore.remove(iter) iter = next In the end I used the second one, because the reference manual says that iter_is_valid(iter) is slow and should only be used for debugging. I can confirm thought at self.lstore.remove(iter) does move iter on to point at the next row. Thanks again, Stuart ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
