Re: [pygtk] GTK+ Webcore in Python
[Andrew Conkling] To do so (as far as I've read), I must use Pyrex or SWIG. I've heard that Pyrex is probably easier to use (i.e. induces less headaches). I tried both, and quickly fell in love with Pyrex, to the point I did not retry SWIG in a long time. (It might have changed, I do not know). Most likely that SWIG is easier for wrapping an existing library as is, but then, you obtain exactly the flavour of that library, which may fit Python OO more or less happily, depending of the library design. Pyrex allowed me to adjust the interfaces, improving them until they really got the Python flavour I wanted. This was probably more work overall, but the results were more satisfying, and less headaches for my users. -- François Pinard http://pinard.progiciels-bpi.ca ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Can't find libglade bindings for python
[Erik Williamson]
I'm going nuts. While I can find rpm's for the glade-python bindings, I
can't seem to find the source anywhere.
Normally, you do:
rpm -qil glade-python
given `glade-python' is the source of your installed package, and then you
will see where everything got installed.
About the bindings, there is not much needed to know. In my notes:
.. Bref de `libglade.py'
. : Tutoriels
. , http://www.linuxfocus.org/English/July2000/article160.shtml
. : Module libglade
. , tree = libglade.GladeXML('FICHIER.glade')
. , tree = get_widget_tree(widget)
. , get_widget_name(widget)
. , get_widget_long_name(widget)
. : Classe GladeXML
. , tree.signal_connect(name, handler, *arguments)
. , tree.signal_autoconnect(dictionary)
. , widget = tree.get_widget(name)
. , widget = tree.get_widget_by_long_name(name)
--
François Pinard http://www.iro.umontreal.ca/~pinard
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: rotate text
[John Hunter] Andrew == Andrew P Lentvorski [EMAIL PROTECTED] writes: Andrew However, if you really want to handle text well, you Andrew should probably look at something like PyFT (Python Andrew Freetype) to render things with full flexibility and Andrew accuracy. Thanks for the tip. I just upgraded my freetype lib and installed PyFT. Do you have any demo code for PyFT, even better integrating PyFT with pygtk, to speed my along in getting up to speed with this vast new world? One thing I liked a lot with Freetype (and PyFT) was the ability to generate correctly anti-aliased letters on transparent background. This helped for later GIMP montage, and printing at good resolution, without too apparent loss of quality. If I remember well, I chose to defeat the outline caching in PyFT, because it was not very likely that I use the same letter twice at the same size and in the same orientation. This was for generating the labels (I'm not sure of the English word, I really mean the papers to contain the art work) for a CD-ROM and its plastic box. I used PyFT with PIL (Python Imaging Library), but not in `pygtk' context, so even if my two programs are not big, I'm hesitant cluttering this mailing list with them. Just ask me if you think they could be useful as examples. I'm not even sure they would work with the most recent releases of Freetype and PyFT... -- François Pinard http://www.iro.umontreal.ca/~pinard ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Re: Questions about GtkDrawingArea
[Ben Escoto] FP Within the update function: FP [...] # Redraw everything. Is the "update function" called in response to window expose events as in my previous post? I presume yes. If so it seems that the window will still be redrawn a lot (and, in your example, the base pixmap also recreated?). Yes. It is allocated within the `update' function, and reclaimed by Python by falling to the end of the function (I keep no other reference to the variable). The goal of the exercise was, for me, to evaluate if I could use `pygtk' to produce a flicker-less animation of a possibly complex curve, and I was pleasantly surprised. By flicker, I mean seeing the lines, seeing the background, seeing the lines, etc. in quick succession. However, when the curves go complex to compute, the animation gets jerky, but I expected this. It isn't a big deal, but at least the way I am doing it (and the way shown in the scribble example) everytime I switch desktops or screens I see the window get covered in the default gtk background (burnished metal or whatever it's called) and then the pixmap is drawn on top of it. Using a pixmap as an intermediate will only hide the actual steps of redrawing, and show the result all at once. I'm guessing that the default gtk background is the initial step of that redrawing, and this step like the others, will get hidden by the technique. Of course, using a pixmap as an intermediate will not make the overall result to appear faster. What background you will then see might depend of your window manager. -- François Pinard http://www.iro.umontreal.ca/~pinard ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
[pygtk] Re: Init trouble
[Deirdre Saoirse] Because of the politics of gnome, it isn't going to happen. Period. This is a strange statement, and I am not familiar at all with "the politics of gnome". Would you be kind enough to elaborate a bit, or give me some pointers I could follow to better understand what you meant? I discovered, but it took years for me to do so, that software is not as free as it appears to be when run by committees, politicians, lawyers, or haughty maintainers. I'm now trying to be more careful when choosing. -- François Pinard http://www.iro.umontreal.ca/~pinard ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
[pygtk] Re: Questions about GtkDrawingArea
[Ben Escoto]
This produces a window which is very slow to redraw, for instance after
a workspace or virtual screen is changed. Whenever this happens, I see
the whole window being covered with the default gtk metal theme (which
seems to happen quickly), and then the pixmap is redrawn on top of it.
Is there a way not to have the metal stuff drawn underneath, or perhaps
to put the pixmap where the metal stuff is so it doesn't need to be
redrawn all the time?
I'm not fully sure I'm replying to your question, but a good way to update
a display is to draw it into a memory pixmap instead of in the real drawing
area, and once done in memory, fastly transfer the memory to the window.
The following lines are taken from an exercise I gave to myself:
In the initialisation section:
[...]
drawing_area = GtkDrawingArea()
drawing_area.size(400, 400)
frame.add(drawing_area)
drawing_area.show()
self.area = drawing_area.get_window()
self.cyan_gc = self.area.new_gc()
self.cyan_gc.foreground = drawing_area.get_colormap().alloc('cyan')
self.black_gc = drawing_area.get_style().black_gc
self.white_gc = drawing_area.get_style().white_gc
[...]
Within the update function:
[...]
# Redraw everything.
pixmap = create_pixmap(self.area, xmax+1, ymax+1)
draw_rectangle(pixmap, self.white_gc, TRUE, 0,0, xmax+1,ymax+1)
draw_lines(pixmap, self.black_gc, points)
draw_pixmap(self.area, self.white_gc, pixmap, 0,0, 0,0, xmax+1,ymax+1)
--
François Pinard http://www.iro.umontreal.ca/~pinard
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] PyQt/PyKDE Bindings
Moshe Zadka [EMAIL PROTECTED] writes: As long as you're breaking things anyway, let me suggest one change: have the "Gtk" prefix stripped from the classes' names (GtkText - Text, etc) [...] For one, I would be happy to make that change, as well (partly because I've not that much written so far :-). However, should we write `Gtk.FILL' instead of `FILL'? Just from an aesthetical viewpoint, since we already use `GDK.' to prefix GDK constants, maybe we should import GTK and write `GTK.FILL', or just `from GTK import *' if we like to stay terse with GTK constants. The need of another import might be unwelcome, but on the other hand, `import gtk, GTK, GDK' is easy to write on one line. I'm not sure of anything, beside the fact I would like to turn `GtkText' into `Gtk.Text'. We might even guess that `pygtk' intensive applications/users would like `from gtk import *' still, and just use unprefixed `Text'. What is not nice is having the module name repeated in module objects. -- François Pinard http://www.iro.umontreal.ca/~pinard - To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
[pygtk] Re: pygtk and GTK+ tutorial
[EMAIL PROTECTED] (Berthold Höllmann) writes:
I try to learn about GTK+ programming using python. I read the tutorial
and port the examples to python. But I can't get "colorsel.py" working
properly. The GtkColorSelectionDialog does not set the drawingarea's
color. Any hint, or shall I send my code?
This has been discussed recently on the `pygtk' mailing list: you should
be there. Here is the way I did it (style may be questionable, I'm still
learning :-). Note that in `destroy_window', I used `return TRUE' because
the C code did this, but it works more nicely if you write `return FALSE'.
I later found in another experiment that the late allocation of `gc'
in the callback could have been done sooner, but after having called
`window.realize()' within the first few lines of main(). It also seems you
have to call `window.show_now()' instead of `window.show()' if you want
to draw in the window as part of your initialisation. The documentation
on these things is very terse, so far that I could see :-).
from gtk import *
import GDK
colorseldlg = None
drawingarea = None
gc = None
def color_changed_cb(widget, colorsel):
window = drawingarea.get_window()
global gc
if not gc:
gc = window.new_gc()
red, green, blue = colorsel.get_color()
gc.foreground = window.colormap.alloc(65535*red, 65535*green, 65535*blue)
# Above could also have been:
#text = '#%04x%04x%04x' % (65535*red, 65535*green, 65535*blue)
#gc.foreground = window.colormap.alloc(text)
draw_rectangle(window, gc, TRUE, 0, 0, window.width, window.height)
# The above to get around the fact that `window.clear()' is missing.
def area_event(widget, event):
if event.type == GDK.BUTTON_PRESS and colorseldlg is None:
global colorseldlg
colorseldlg = GtkColorSelectionDialog('Select background color')
colorsel = colorseldlg.colorsel
colorsel.connect('color_changed', color_changed_cb, colorsel)
colorseldlg.show()
return TRUE
return FALSE
def destroy_window(widget, event):
mainquit()
return TRUE
def main():
window = GtkWindow()
window.set_title('Color selection test')
window.set_policy(TRUE, TRUE, TRUE)
window.connect('delete_event', destroy_window)
global drawingarea
drawingarea = GtkDrawingArea()
drawingarea.size(200, 200)
drawingarea.set_events(GDK.BUTTON_PRESS_MASK)
drawingarea.connect('event', area_event)
window.add(drawingarea)
drawingarea.show()
window.show()
mainloop()
main()
--
François Pinard http://www.iro.umontreal.ca/~pinard
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
[pygtk] Re: pygtk and GTK+ tutorial
Berthold Hoellmann [EMAIL PROTECTED] écrit: I've found the pygtk mailing list later, and am now subscribed to it. Good. We might meet there, once in a while :-). I also found a question concerning the colorsel example, but could not find any answers. I hope you found answers in the code I provided in my preceding reply... My only sources of information are the "GTK v1.2 tutorial" for C, the examples installed with the `pygtk' distribution in the SuSE 6.2 Linux CD-ROMs, and all archived messages I could find of the `pygtk' mailing list. I made a Python script to clean out MHonArc generated clutter, so I can use Gnus and RMAIL instead of Netscape to read, shuffle and sort everything :-). I'm sure that a lot of clues slipped between my fingers while handling that big lot of messages, but I also found some answers, sometimes well hidden within the code samples provided for unrelated questions. It helped me. By trying to closely translate all tutorial examples from C to Python, even if I did not reinsert the comments from the tutorial, I have the hope it might be useful to others. It's 2/3 done by now. I would guess many of us did that work already, but I did not stumble on such results yet :-). -- François Pinard http://www.iro.umontreal.ca/~pinard To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Anti-aliasing ?
Matt Wilson [EMAIL PROTECTED] écrit: The code below shows the case of a line needing anti-aliasing. Would someone knowledgeable tell me if/how I can, within `pygtk', produce an anti-aliased line, or else (:-), how I could handle an alpha channel for later display? The easiest way to do this by far is to use the canvas. [...] The canvas does all this for you. Thanks for the example, Matt, but this is not pure `pygtk' (or GDK) anymore, if it needs `gnome.ui' and GnomeCanvas. When things like Gnome get in the picture, the mix of versions to use is never new and fine tuned enough. As I wrote a few days ago, I would like to stay oriented towards applications, without being drawn into UI development. This would be much prematurate for me, as I still have a lot to learn first. Moreover, as a proof by example, GIMP surely does a great deal successfully while relying on GTK, without resorting to Gnome libraries. So, I would like to know if/how I can, using GTK and GDK, and the `pygtk' interface to both, create and handle an alpha channel, and feel able do anti-alias myself if I want to (that is, if GTK has no provision for it). canvas = GnomeCanvas(aa=TRUE) I tried your example here (using the software as found within SuSE 6.2), and even if the line displayed is undoubtly different from what I got so far, it seems to try to provide anti-alias by some strange use of dark points here and there, all along. Or maybe, presumably, it is a side effect of poor colour map allocation (here, this is a 8-bit depth display). I'm seeking for more traditional anti-aliasing, where line pixel colours should be picked from a ramp between the background and the foreground colour. -- François Pinard http://www.iro.umontreal.ca/~pinard To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Anti-aliasing ?
Bernhard Herzog [EMAIL PROTECTED] écrit: François Pinard [EMAIL PROTECTED] writes: Matt Wilson [EMAIL PROTECTED] écrit: The easiest way to do this by far is to use the canvas. [...] The canvas does all this for you. Thanks for the example, Matt, but this is not pure `pygtk' (or GDK) anymore, if it needs `gnome.ui' and GnomeCanvas. I don't think there's a way to do what you want in pure pygtk. I guess you are right. I just played with GIMP a bit, and indeed, I did not see anti-aliased lines in it. The GIMP goal is images, and lines are only used in interaction tools. While I hope that `pygtk' gives access to the whole GTK/GDK, it does not have to provide what these do not have! By the way, I may sometimes look like moaning, but do not read me that way. I'm quite satisfied with `pygtk' so far. I observed a few glitches (memory leaks, slight problems in some interfaces), but nothing serious that would prevent immediate usage. Problems were surely reported and are likely solved in later versions. I may not be running the latest/greatest one, but as it stands, `pygtk' looks quite solid to me already, and I enjoy it a great deal. This is a blessing for me, and I'm grateful to James and his collaborators. FWIW, the development versions of Sketch [...] I saved a few messages about Sketch already, and maybe the time would be right for me to give it a good look. It sounds interesting and appealing. So, I would like to know if/how I can, using GTK and GDK, and the `pygtk' interface to both, create and handle an alpha channel [...] With some luck, I'll stumble on solutions while pursuing my study. Of course, early hints are welcome. I'll do my homework, anyway :-). Keep happy, all. It's fun being here! -- François Pinard http://www.iro.umontreal.ca/~pinard To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] Hello, and `pygtk' reminder
"J.W. Bizzaro" [EMAIL PROTECTED] écrit: François Pinard wrote: I still have to learn `pygtk' usage, and to help me doing so, through an editing session over the Python sources, made myself a compact reminder. That's nice. Can we include it in the documentation? What do you think, Daniel? By the way, while doing so, I paid attention for being able to later write some script to redo the same thing automatically. I did not make that script yet, but will surely do instead of redoing the job "by hand" the next time. However, and should I confess, I've be a bit destabilised (:-), going through mail archives for `pygtk', while reading: From: James Henstridge Subject: [pygtk] pyglade/libglade ignores default-width/default-height ? X-Sent: 2 semaines, 1 heure I suppose I should put in a message stating that the pyglade module is deprecated. It is probably better to use the libglade module, which uses libglade rather than being pure python. It handles the default_width and default_height attributes correctly. James. I'm not much of a mouse man, and was often (but not always) deceived by user interfaces, where I see a lot of chrome, but not much of engines. It seemed to me that there is a finite amount of energy an author puts in a program, and it is unusual that the engine _and_ the user interface are both seducing. That's why I did not allow me, so far, to invest the massive amounts of energy which are required to learn X programming, or even C programming of nicely packaged widget systems. Even if these are far much efficient to write than pure X, programmer-wise, and surely worth a lot of admiration, praise, and enthusiasm, I still find these too much distracting. However, recently, Python has been changing my appreciation of things, and approaches like `pygtk' brings the user interface burden to acceptable proportions. At least, for someone who wants to stay primarily interested by engines. :-) So! After having spent some time studying and trying Tkinter, than PIL, than revising a lot of messages I saved about various other alternatives at many graphical levels (I found it somewhat confusing to look at everything at once), I thought I was doing a good choice betting on the pyglade/pygtk combination, and now feel rather ready to take a real dive. However, I do not run Gnome, and would prefer to not ought to change window managers as well. A new language and a new design spirit is a lot already for the poor little me, I do not feel like embracing a new religion as well! I tried both KDE and Gnome for a while, and returned to my previous habits, probably because I merely failed to quickly see the promised wonders. :-) However, I repeatedly read on the `pygtk' mailing list archives that PyGnome (whatever it is :-) is the way to go, yet the same lists report a lot of build and unstability problems (but maybe I misinterpreted them?). I merely want to be a satisfied, humble programming user, much more than a participant in the big adventure of GUI system development, finding the proper mix of CVS branches that would flawlessly compile in my environment. Thanks for having read me so far, my friends! :-). In your opinion, is it really a lost investment for me to rely on `pyglade'? Should I better have to consider swallowing Gnome as well, and right now? (Fiou! Shudder and dismay! :-) Could `pygtk' be adequately be used outside Gnome contexts, at least long enough to let me recover from the time it takes to become more seriously acquainted with all these new things? Or else, is there something fundamentally wrong in my attitude? Am I unreasonable? -- François Pinard http://www.iro.umontreal.ca/~pinard To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
[pygtk] Hello, and `pygtk' reminder
name) . + set_events(events) . + set_extension_events(exevents) . + set_name(name) . + set_parent(parent) . + set_parent_window(parent) . + set_rc_style() . + set_scroll_adjustments(hadj, vadj) . + set_sensitive(s) . + set_state(s) . + set_style(style) . + set_uposition(x, y) . + set_usize(w, h) . + shape_combine_mask(mask, ofs_x, ofs_y) . + show(obj=None) . + show_all(obj=None) . + show_now(obj=None) . + size_allocate(a) . + size_request() . + unlock_accelerators() . + unmap(obj=None) . + unparent() . + unrealize(obj=None) .* GtkWindow(type=WINDOW_TOPLEVEL, title=None) . + (GtkBin) . + activate_default(obj=None) . + activate_focus(obj=None) . + add_accel_group(group) . + position(pos) . + remove_accel_group(group) . + set_default_size(width, height) . + set_geometry_hints(geometry_widget=None, **hints) . + set_icon(pixmap, mask=None) . + set_icon_name(name) . + set_modal(modal) . + set_policy(as, ag, autos) . + set_position(pos) . + set_title(title) . + set_transient_for(parent) . + set_wmclass(wmc_name, wmc_class) -- François Pinard http://www.iro.umontreal.ca/~pinard
