Re: [pygtk] setting font for gtk.Entry?
george young wrote:
[pygtk-1.99.13, gtk-2.1.1, python-2.2.1, linux]
I am just trying to set the font for a gtk.Entry. I tried:
import gtk
top = gtk.Window(gtk.WINDOW_TOPLEVEL)
top.show()
e = gtk.Entry()
sty = e.get_style().copy()
sty.font = gtk.load_font('fixed')
e.set_style(sty)
e.set_text('the rain')
e.show()
top.add(e)
gtk.mainloop()
but the font I get is some default, variable width font. What am
I doing wrong? [I *have* scoured the FAQ and mailing list archives...]
GTK 2.0 uses a new text layout system called Pango, which is why the old
method of changing the font does not work.
If you want to change an entry field to a monospaced font, use the
following:
font_desc = pango.FontDescription('monospace')
entry.modify_font(font_desc)
The "monospace" font will map to the user's preferred monospaced font.
James.
--
Email: [EMAIL PROTECTED] | Linux.conf.au http://linux.conf.au/
WWW: http://www.daa.com.au/~james/ | Jan 22-25 Perth, Western Australia.
___
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] feature request: binding for gtk_propagate_event?
Brian Warner wrote: With gtk1/gnome1, binding the signals seems to happen when a widget-tree is added to the AppletWidget container. So, if you add Buttons to a GtkHBox, and then add that box to the AppletWidget, the button-events are processed by the panel. If you first add the GtkHBox, and then add the buttons to the GtkHBox, then those buttons receive events button2 and button3. Some explicit mechanism for gnome2 to bind the signals would be better. Hmm, interesting that you mention this layout, because I just tried the same hack with a different applet (one that puts a GtkButton and a GtkProgressBar into a VBox, then the VBox in the applet), and in this case the hack does not help. I suspect the signals are being sent to the VBox, which ignores them. So the menu is accessible by button3 from within the progress bar, but not from the button (just as it without the parent.emit hack). Am I right in thinking that events are propagated "backwards" (from window to parent window and so on up to the root window) until somebody claims them, but that gtk signals are not? That might be why the gnome-applets authors used gtk_propagate_event instead of re-emitting signals: the immediate parent might not be the appropriate recipient. A single signal emission will only call handlers attached to the object it was emitted on. The propagation of events up the heirachy is acheived by emitting the signal a number of times. For events such as the button presses and motion events, the event is delivered first to the widget the event occurred in. It will emit the appropriate event signal. If the event signal returns false (indicating that the event hasn't been handled), then a signal will be emitted on the parent. This continues all the way up to the toplevel if no one handles the event. Keyboard events are handled differently. When your window receives a keyboard event, it is first dispatched to the toplevel window, which will check if it matches any keyboard shortcuts. If the key press doesn't match a shortcut, then the event is dispatched to the child widget that currently has focus. James. -- Email: [EMAIL PROTECTED] | Linux.conf.au http://linux.conf.au/ WWW: http://www.daa.com.au/~james/ | Jan 22-25 Perth, Western Australia. ___ 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] auto-expansion of gtk.Entry?
On Tue, Nov 12, 2002 at 04:05:52PM -0500, george young wrote: > [pygtk-1.99.13, gtk-2.1.1, python-2.2.1, linux] > I would like to have a gtk.Entry (for data entry) that is first > presented with a default width, but will dynamically expand as the > user types more text than fits. I suppose this will cause ripples of > layout reconfigurations -- maybe I need to trap some event and expand > by batches of more than one character at once? > > I also wish to disallow (horizontal) scrolling, because > it is crucial that trailing text not be missed when read (by a harried > operator in a bunny suit handling very valuable wafers and dangerous chemicals...). > All text in the widget should always be visible. > > Any suggestions? This is such an ugly hack I am afraid to say it but.. - Hook a handler to the "changed" signal. - Take the number of characters in the entry (len(e.get_text)) - Multiply it by the width of the character (there is a way to do this using pango, I hear) - set the widget's with to this (using set_size() or something) Batching is left as an exercise to the reader. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL ___ 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] Crash with a gtkcellrenderer in python and threads
On Tue, 2002-11-12 at 17:15, Joe Shaw wrote:
> Maybe it should call pyg_block_threads() and chain up to its parent?
> I'll try it and send a patch if it works.
Sigh. Obviously this doesn't work, as I don't care about the parent's
properties. I care about the child's.
So I think the right thing to do is probably to add the
pyg_block_threads() and pyg_unblock_threads() to
pyg_object_set_property(), but I don't know how to fix the failed
assertion that I get ("Fatal Python error: PyThreadState_Get: no current
thread").
Anyone have any ideas?
Joe
___
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] Crash with a gtkcellrenderer in python and threads
Hi, I have a cell renderer written in python which derives from gtk.GenericCellRenderer. When I run my program with gtk.threads_init(), python crashes when I try to set a property on the cell renderer. It dies in a call to PyObject_CallMethod(). For other crashes I've seen like this, wrapping the calls in pyg_block_threads()/pyg_unblock_threads() fixes the problem, but when I try it this time, I get: Fatal Python error: PyThreadState_Get: no current thread The program crashes in gobjectmodule.c:pyg_object_set_property(), trying to call my object's do_set_property() method. I noticed that pygtkcellrenderer.c doesn't overload the set_property() and get_property() methods on GObjectClass. Maybe it should call pyg_block_threads() and chain up to its parent? I'll try it and send a patch if it works. Here's are a few frames from the stack trace: #8 0x40018861 in _r_debug () from /opt/pygtk/lib/python2.2/site-packages/gtk-2.0/gobjectmodule.so #9 0x401a7e37 in g_object_set_property (object=0x8424e88, property_name=0x84255e8 "value", value=0xbfffd0f0) at gobject.c:571 #10 0x404656b0 in gtk_tree_view_column_cell_set_cell_data ( tree_column=0x8425540, tree_model=0x841fe80, iter=0xbfffd1e0, is_expander=0, is_expanded=0) at gtktreeviewcolumn.c:2270 Joe ___ 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] setting font for gtk.Entry?
[pygtk-1.99.13, gtk-2.1.1, python-2.2.1, linux]
I am just trying to set the font for a gtk.Entry. I tried:
import gtk
top = gtk.Window(gtk.WINDOW_TOPLEVEL)
top.show()
e = gtk.Entry()
sty = e.get_style().copy()
sty.font = gtk.load_font('fixed')
e.set_style(sty)
e.set_text('the rain')
e.show()
top.add(e)
gtk.mainloop()
but the font I get is some default, variable width font. What am
I doing wrong? [I *have* scoured the FAQ and mailing list archives...]
--
I cannot think why the whole bed of the ocean is
not one solid mass of oysters, so prolific they seem. Ah,
I am wandering! Strange how the brain controls the brain!
-- Sherlock Holmes in "The Dying Detective"
___
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] Patch for pygtktreemodel.c
Hi,
None of the calls to PyObject_CallMethod() in pygtktreemodel.c is
wrapped with pyg_block_threads()/pyg_unblock_threads(), which will cause
python to segfault if you use gtk.threads_init() in your program. The
attach patch adds these.
I've filed this as bug #98344.
Joe
Index: pygtktreemodel.c
===
RCS file: /cvs/gnome/gnome-python/pygtk/gtk/pygtktreemodel.c,v
retrieving revision 1.9
diff -u -p -u -r1.9 pygtktreemodel.c
--- pygtktreemodel.c 7 Jul 2002 12:45:45 - 1.9
+++ pygtktreemodel.c 12 Nov 2002 21:34:49 -
@@ -197,7 +197,9 @@ pygtk_generic_tree_model_get_flags(GtkTr
#ifdef DEBUG_TREE_MODEL
g_message("get_flags()");
#endif
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "get_flags", "");
+pyg_unblock_threads();
if (py_ret) {
guint ret = PyInt_AsLong(py_ret);
@@ -223,7 +225,9 @@ pygtk_generic_tree_model_get_n_columns(G
#ifdef DEBUG_TREE_MODEL
g_message("get_n_columns()");
#endif
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "get_n_columns", "");
+pyg_unblock_threads();
if (py_ret) {
gint ret = PyInt_AsLong(py_ret);
@@ -249,8 +253,10 @@ pygtk_generic_tree_model_get_column_type
#ifdef DEBUG_TREE_MODEL
g_message("get_column_type(%d)", index);
#endif
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "get_column_type",
"(i)", index);
+pyg_unblock_threads();
if (py_ret) {
GType ret = pyg_type_from_object(py_ret);
@@ -280,8 +286,10 @@ pygtk_generic_tree_model_get_iter(GtkTre
g_message("get_tree_iter(%p)", path);
#endif
py_path = pygtk_tree_path_to_pyobject(path);
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "get_iter",
"(O)", py_path);
+pyg_unblock_threads();
Py_DECREF(py_path);
if (py_ret) {
@@ -318,8 +326,10 @@ pygtk_generic_tree_model_get_path(GtkTre
#ifdef DEBUG_TREE_MODEL
g_message("get_tree_path(%p)", iter);
#endif
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "get_tree_path",
"(O)", (PyObject *)iter->user_data);
+pyg_unblock_threads();
if (py_ret) {
GtkTreePath *path = pygtk_tree_path_from_pyobject(py_ret);
@@ -354,8 +364,10 @@ pygtk_generic_tree_model_get_value(GtkTr
/* init value to column type */
g_value_init(value, pygtk_generic_tree_model_get_column_type(tree_model, column));
+pyg_block_threads();
py_value = PyObject_CallMethod(self, METHOD_PREFIX "get_value",
"(Oi)", (PyObject *)iter->user_data,column);
+pyg_unblock_threads();
if (py_value) {
pyg_value_from_pyobject(value, py_value);
@@ -380,8 +392,10 @@ pygtk_generic_tree_model_iter_next(GtkTr
#ifdef DEBUG_TREE_MODEL
g_message("iter_next(%p)", iter);
#endif
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "iter_next",
"(O)", (PyObject *)iter->user_data);
+pyg_unblock_threads();
if (py_ret) {
if (py_ret != Py_None) {
/* handle reference counting here */
@@ -420,8 +434,10 @@ pygtk_generic_tree_model_iter_children(G
#endif
if (parent && parent->user_data != NULL)
py_parent = (PyObject *)parent->user_data;
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "iter_children",
"(O)", py_parent);
+pyg_unblock_threads();
if (py_ret) {
if (py_ret != Py_None) {
/* handle reference counting here */
@@ -457,8 +473,10 @@ pygtk_generic_tree_model_iter_has_child(
#ifdef DEBUG_TREE_MODEL
g_message("iter_has_child(%p)", iter);
#endif
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "iter_has_child",
"(O)", (PyObject *)iter->user_data);
+pyg_unblock_threads();
if (py_ret) {
gboolean ret = PyObject_IsTrue(py_ret);
@@ -485,8 +503,10 @@ pygtk_generic_tree_model_iter_n_children
#ifdef DEBUG_TREE_MODEL
g_message("iter_n_children(%p)", iter);
#endif
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "iter_n_children",
"(O)", (PyObject *)iter->user_data);
+pyg_unblock_threads();
if (py_ret) {
gint ret = PyInt_AsLong(py_ret);
@@ -516,8 +536,10 @@ pygtk_generic_tree_model_iter_nth_child(
#endif
if (parent && parent->user_data != NULL)
py_parent = (PyObject *)parent->user_data;
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "iter_nth_child",
"(Oi)", py_parent, n);
+pyg_unblock_threads();
if (py_ret) {
if (py_ret != Py_None) {
/* handle reference counting here */
@@ -556,8 +578,10 @@ pygtk_generic_tree_model_iter_parent(Gtk
#endif
if (child && child->user_data != NULL)
py_child = (PyObject *)child->user_data;
+pyg_block_threads();
py_ret = PyObject_CallMethod(self, METHOD_PREFIX "iter_parent",
"(O)", py_child);
+pyg_unblock_threads();
if (
[pygtk] auto-expansion of gtk.Entry?
[pygtk-1.99.13, gtk-2.1.1, python-2.2.1, linux] I would like to have a gtk.Entry (for data entry) that is first presented with a default width, but will dynamically expand as the user types more text than fits. I suppose this will cause ripples of layout reconfigurations -- maybe I need to trap some event and expand by batches of more than one character at once? I also wish to disallow (horizontal) scrolling, because it is crucial that trailing text not be missed when read (by a harried operator in a bunny suit handling very valuable wafers and dangerous chemicals...). All text in the widget should always be visible. Any suggestions? -- I cannot think why the whole bed of the ocean is not one solid mass of oysters, so prolific they seem. Ah, I am wandering! Strange how the brain controls the brain! -- Sherlock Holmes in "The Dying Detective" ___ 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] rotating text
Sæl ! I saw in the archive that drawing rotated text with python 1.5 is not straight forward. The discussed solution is based on PyFT, but I may need the other one as making a pixmap to be rotated. since this is a very common task, many must have written scipts to do so. Can anybody point me to an example ? Takk Kveðja Jean-Baptiste -- - [EMAIL PROTECTED] Department of Statistics deCODE genetics Sturlugata,8 570 2930 101 Reykjavík ___ 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] feature request: binding for gtk_propagate_event?
Christian Reis <[EMAIL PROTECTED]> writes: > On Tue, Nov 12, 2002 at 08:33:20AM +0100, Andreas Degert wrote: > > With gtk1/gnome1, binding the signals seems to happen when a > > widget-tree is added to the AppletWidget container. So, if you add > > "binding the signals"? Do you mean connect() itself, or something else? > > > Buttons to a GtkHBox, and then add that box to the AppletWidget, the > > button-events are processed by the panel. If you first add the > > GtkHBox, and then add the buttons to the GtkHBox, then those buttons > > receive events button2 and button3. Some explicit mechanism for gnome2 > > to bind the signals would be better. > > I'm not entirely sure I understand (or agree) with what you describe? It > could just be that the hierarchy through which the signal propagates is > killing the signal somewhere, or some handler is not doing what it should. > > AFAIK, it shouldn't matter at all the order in which the widgets are > composed. ok, I took some time and checked it with the source. All of this is only valid for gtk1 and gnome1 (at least I haven't checked what changed in gnome2). The class AppletWidget in module applet.py has a method "add_full" to add the widget-tree for the applet into the AppletWidget: add_full(self, child, bind_events) This corresponds to the c-function "applet_widget_add_full" in the file applet-widget.c. "bind_events" is a boolean parameter. If set, the function "bind_applet_events" is called at the end of function. It recursivly connects the signal-handler applet_event to the signal "event" to each widget (with a window) in the widget-tree. The python method "add" is equivalent to "add_full" with bind_events set to true. There is also a separate method "bind_events". So, it seems to be cleaner to call "add_full" with the bind-events parameter set to false, and then call "bind_events" explicitely at some point, because it affects all widgets it finds in the tree. If you use "add", you get the order-dependency as a consequence of that side-effect. ___ 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] feature request: binding for gtk_propagate_event?
On Tue, Nov 12, 2002 at 01:04:40AM -0800, Brian Warner wrote: > Am I right in thinking that events are propagated "backwards" (from window to > parent window and so on up to the root window) until somebody claims them, > but that gtk signals are not? That might be why the gnome-applets authors > used gtk_propagate_event instead of re-emitting signals: the immediate parent > might not be the appropriate recipient. I have no idea; from the tutorial it does say that this is for all signals, but only cites as example an "_event" signal. http://www.gtk.org/tutorial/sec-signalemissionandpropagation.html It could just be that there is a default handler somewhere that gobbles the signal up (returns gtk.TRUE), which is why the authors work around it. Or it could be something else :) Owen definitely knows the answer, as does gtk+-2.0.4.tar.gz ;-) Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL ___ 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] feature request: binding for gtk_propagate_event?
On Tue, Nov 12, 2002 at 08:33:20AM +0100, Andreas Degert wrote: > With gtk1/gnome1, binding the signals seems to happen when a > widget-tree is added to the AppletWidget container. So, if you add "binding the signals"? Do you mean connect() itself, or something else? > Buttons to a GtkHBox, and then add that box to the AppletWidget, the > button-events are processed by the panel. If you first add the > GtkHBox, and then add the buttons to the GtkHBox, then those buttons > receive events button2 and button3. Some explicit mechanism for gnome2 > to bind the signals would be better. I'm not entirely sure I understand (or agree) with what you describe? It could just be that the hierarchy through which the signal propagates is killing the signal somewhere, or some handler is not doing what it should. AFAIK, it shouldn't matter at all the order in which the widgets are composed. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] PyGTK-0.x changes
I've checked in two changes in the stable 0.6.x branch of PyGTK: - libglade.py now raises an exception when the GladeXML object it would return is None. This is in preparation for better checking inside libglade which I should work on sometime soon. - GtkCList now offers a set_focus_row, which allows you to change the focus row to work around a bug using select_row() and the SELECTION_BROWSE and SELECTION_EXTENDED modes (the selected row changed, but the focused row didn't). You can also use it to change the focus row when in the other modes, too. As always, testing is very welcome, and let me know if anything has broken. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL ___ 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] feature request: binding for gtk_propagate_event?
> With gtk1/gnome1, binding the signals seems to happen when a > widget-tree is added to the AppletWidget container. So, if you add > Buttons to a GtkHBox, and then add that box to the AppletWidget, the > button-events are processed by the panel. If you first add the > GtkHBox, and then add the buttons to the GtkHBox, then those buttons > receive events button2 and button3. Some explicit mechanism for gnome2 > to bind the signals would be better. Hmm, interesting that you mention this layout, because I just tried the same hack with a different applet (one that puts a GtkButton and a GtkProgressBar into a VBox, then the VBox in the applet), and in this case the hack does not help. I suspect the signals are being sent to the VBox, which ignores them. So the menu is accessible by button3 from within the progress bar, but not from the button (just as it without the parent.emit hack). Am I right in thinking that events are propagated "backwards" (from window to parent window and so on up to the root window) until somebody claims them, but that gtk signals are not? That might be why the gnome-applets authors used gtk_propagate_event instead of re-emitting signals: the immediate parent might not be the appropriate recipient. More ideas are most welcome.. thanks, -Brian ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
