Creating GTK+ 2 key press event
I wrote a small GTK+ 2+ program (in Python) that responds to a button click by sending a gtk.Event to simulate a key press. It works fine on every version of Ubuntu that I have including Kubuntu, but it fails on every version of Lubuntu. On Lubuntu, the character that gets transmitted by the Event is determined by event.hardware_keycode; event.keyval doesn't matter. On every other platform, the character is determined by event.keyval and event.hardware_keycode doesn't matter. The problem is that as far as I can tell it is not possible to specify Unicode characters through event.hardware_keycode because they do not have a corresponding key. Unicode works fine on other platforms using keyval. Does anyone know how to get Lubuntu to behave the same as Ubuntu in this regard? Jeffrey Barish ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Getting X error on reordering columns in TreeView
Try running this simple program (reordercols.py):
# The purpose of this program is to test reorderable columns in a TreeView.
import gtk
class ReorderableColumns(object):
def __init__(self):
self.window = gtk.Window()
self.window.connect(destroy, gtk.main_quit)
self.window.set_size_request(240, -1)
liststore = gtk.ListStore(str, str, str)
for i in range(10):
liststore.append([%d % i] * 3)
treeview = gtk.TreeView(liststore)
for i in range(3):
cell = gtk.CellRendererText()
col = gtk.TreeViewColumn('%s' % i, cell, text=i)
col.set_expand(True)
col.set_reorderable(True)
treeview.append_column(col)
self.window.add(treeview)
self.window.show_all()
gtk.main()
def run(self):
gtk.main()
app = ReorderableColumns()
app.run()
As soon as I try to drag a column, the program crashes with:
The program 'reordercols.py' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
(Details: serial 1289 error_code 8 request_code 56 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Any idea what's wrong? GTK version 2.24.10 on Ubuntu 12.04.
--
Jeffrey Barish
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re-selecting icon in IconView
Here's another annoying quirk: In a TreeView, if I click a row that is already selected, nothing happens. I don't expect to get the changed signal from the corresponding TreeSelection because the row is already selected so the selection did not change. This behavior is good. In an IconView, if I click an icon that is already selected, I get selection-changed even though the selection did not change. This behavior is bad. Why these two views behave differently is a mystery to me. -- Jeffrey Barish ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Drag from treeview to eventbox
Is it possible to drag from a treeview to an eventbox? I'm using enable_model_drag_source for the treeview and drag_dest_set for the eventbox. Is that mixing permitted? The drag is not recognizing the eventbox as a target. -- Jeffrey Barish ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Status for long-running operation
My application has one operation that runs for a long time (~1 minute). During this time, the user is not allowed to do anything. Nevertheless, I felt that it was important to give the user some feedback that the application is still alive and that the operation is running. My solution was to print a message in a TextBuffer and follow the message with a string of dots that grows in length by one every second. To get the TextView to update, I used events_pending/main_iteration. This all works nicely. However, because of the events_pending/main_iteration statements, the entire GUI is now alive. Thus, the user is able to do things that disrupt the long-running operation. Basically, what I want is a way to get the TextView to update so that I can update the progress indicator but for everything else still to be locked out. Is there a way to do this? -- Jeffrey Barish ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Status for long-running operation
Jeffrey Barish wrote: My application has one operation that runs for a long time (~1 minute). During this time, the user is not allowed to do anything. Nevertheless, I felt that it was important to give the user some feedback that the application is still alive and that the operation is running. My solution was to print a message in a TextBuffer and follow the message with a string of dots that grows in length by one every second. To get the TextView to update, I used events_pending/main_iteration. This all works nicely. However, because of the events_pending/main_iteration statements, the entire GUI is now alive. Thus, the user is able to do things that disrupt the long-running operation. Basically, what I want is a way to get the TextView to update so that I can update the progress indicator but for everything else still to be locked out. Is there a way to do this? Here's a possibility that seems to work: I used event_handler_set to define an event handler that filters out all events (by not calling main_do_event) except EXPOSE while the long-running operation is underway. I wish that there were a way to restore the default event handler, but there is only a set method. Anything bad about this solution? -- Jeffrey Barish ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Status for long-running operation
Lex Trotman wrote: On 18 September 2010 08:22, Jeffrey Barish jeff_bar...@earthlink.net wrote: Jeffrey Barish wrote: My application has one operation that runs for a long time (~1 minute). During this time, the user is not allowed to do anything. Nevertheless, I felt that it was important to give the user some feedback that the application is still alive and that the operation is running. My solution was to print a message in a TextBuffer and follow the message with a string of dots that grows in length by one every second. To get the TextView to update, I used events_pending/main_iteration. This all works nicely. However, because of the events_pending/main_iteration statements, the entire GUI is now alive. Thus, the user is able to do things that disrupt the long-running operation. Basically, what I want is a way to get the TextView to update so that I can update the progress indicator but for everything else still to be locked out. Is there a way to do this? Here's a possibility that seems to work: I used event_handler_set to define an event handler that filters out all events (by not calling main_do_event) except EXPOSE while the long-running operation is underway. I wish that there were a way to restore the default event handler, but there is only a set method. Anything bad about this solution? -- Jeffrey Barish You should show progress and block the application by showing a modal dialog containing a progress bar. Cheers Lex Good point. The TextView is where I put all messages, so I didn't want to put the progress indicator in a different place, if I could avoid it. My solution still seems to be working, but I worry about having all events go through my filter all the time because it seems a bit inefficient. -- Jeffrey Barish ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Is widget in Notebook visible
Tristan Van Berkom wrote: On Thu, Sep 2, 2010 at 11:03 AM, Jeffrey Barish jeff_bar...@earthlink.net wrote: I have a custom widget that resides on a page of a notebook. I would like for the widget to be able to detect by itself when it becomes visible or invisible (as the user selects pages of the notebook). The expose-event tells me when the widget becomes visible, but I can't find a corresponding event that tells me the converse. Likewise, the visibility-notify-event tells me only when the widget becomes visible, not the converse. Any suggestions? Firstly if its a custom widget of your making and needs to run code.. it should generally not connect to signals on its own class... instead you should implement the appropriate methods on the class directly. A widget's visibility status is not exactly what you are looking for (A widget's visible flag is TRUE if the client code wants the widget to be visible... whether its on a page that is mapped or not). You will (most probably) want to implement -map() and -unmap() in your custom widget class to detect if its actually shown or not. Thanks. map/unmap did the trick. How to I implement appropriate methods directly? Is this where the do_ methods come in? I tried do_map_event and do_unmap_event, but they don't get called. Ah, do_map gets called, but then doesn't do anything. do_unmap does not get called. I'm just guessing here. -- Jeffrey Barish ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Is widget in Notebook visible
I have a custom widget that resides on a page of a notebook. I would like for the widget to be able to detect by itself when it becomes visible or invisible (as the user selects pages of the notebook). The expose-event tells me when the widget becomes visible, but I can't find a corresponding event that tells me the converse. Likewise, the visibility-notify-event tells me only when the widget becomes visible, not the converse. Any suggestions? -- Jeffrey Barish ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Getting the height of a treeview
I have a treeview which contains only text. I have word wrapping set for the text, so sometimes the text consumes more than one line. I need to know the height of the treeview. It appears that the size-allocate signal for the treeview happens before the text wrapping. If I am right, I need a suggestion as to how one gets the height of the treeview. I thought about using the get_size method for CellRenderer. However, a CellRenderer is used to render the contents of every row of its column. If I ask CellRenderer for its size, for which row is it responding? The last one, I imagine. I don't see a way to use it to tell me the size of every cell in the column. It would have been nice if CellRenderer had a size- allocate signal. -- Jeffrey Barish ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Drag from TreeView to non-TreeView
Is it possible to drag from a TreeView to a widget that is not a TreeView? In my case, I am trying to drag to an EventBox. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Popup window for alert
I would like a popup window with a black line on its border in which I can put a label to alert the user to a failure condition. A Dialog doesn't work because the appearance and disappearance of the window is entirely under program control. A WINDOW_POPUP doesn't work because it lacks the black line on its border (even when I set decorate). A WINDOW_TOPLEVEL is almost right, but I would prefer that the destroy button and the window menu button not appear -- not to mention the title bar at the top. Is there a way to make any of these things disappear? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Popup window for alert
John Coppens wrote: On Wed, 18 Mar 2009 16:55:35 -0600 Jeffrey Barish jeff_bar...@earthlink.net wrote: I would like a popup window with a black line on its border in which I can put a label to alert the user to a failure condition. A Dialog doesn't work because the appearance and disappearance of the window is entirely under program control. A WINDOW_POPUP doesn't work because it lacks the black line on its border (even when I set decorate). A WINDOW_TOPLEVEL is almost right, but I would prefer that the destroy button and the window menu button not appear -- not to mention the title bar at the top. Is there a way to make any of these things disappear? You can do everything with a normal window, Jeffrey. Look up the right functions, but you can: 1) Make de decorations disappear, leaving a clean rectangle. 2) Put an image on the background, with the black border you want, making it fill the window entirely, 3) Put a label in the center of that window, and enter the text you wish to show. You might want to search for the many examples of 'splash screens' with GTK available on the 'net. Thanks to you and Ardhan for the suggestions. They led me to the following solution: Get the Gdk_Window. It has a set_decorations method. One of the options is DECOR_BORDER, which draws only a black line around the window -- no title bar. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK warning
Stefan Kost wrote: How should gobject know the name of your variable? In GStreamer we have a GstObejct which has a name property, that makes it easier. How do you know it's one of my variables that is being unreferenced? The warning message refers me to line 118 where I don't see that any of my variables is being unreferenced. If there's a problem in the set_from_pixbuf call, I don't see why GTK can't provide more information about the nature of the problem. If there's a problem somewhere else, I don't see why GTK is directing me to line 118. I have now established that running the program with --g-fatal-warnings on the command line does do something: It causes the program to exit, just as it does in C. However, in Python, I need to catch the exception before exiting so that I can run the debugger and view the traceback, but it is not possible to catch SystemExit. I'm still clinging to the hope that a traceback will be helpful despite your advice that it usually isn't when the problem is a refcount issue. Nevertheless, I clearly have fallen out of the purview of this group, so I'll try to figure out a better place to post. Thanks anyway for all the suggestions. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK warning
Dov Grobgeld wrote: 2009/2/21 Jeffrey Barish jeff_bar...@earthlink.net I hate the warning messages that GTK provides because they rarely help me find the problem. What does this one mean? /myprogram.py:118: Warning: g_object_unref: assertion `object-ref_count 0' failed self['myimage'].set_from_pixbuf(mypb) What object is producing the warning? I suppose it must be myimage. What am I supposed to do? If I exit the program and run it again, 9 times out of 10 I don't get the warning. The message means exactly what it sais, that you try to reduce the ref count of an object that doesn't exist. Of course. My complaint is that the message doesn't tell me which object. It refers me to a specific line in which it isn't obvious that any object is being unreferenced. That line sets the pixbuf, which, if anything, would increase the ref count of something. If the dereference occurs somewhere else, then the warning shouldn't refer me to this line of code. But since the example you give is in Python this probably means that there is an error in the python binding. You should try to create a minimum example that triggers the problem and try to create a bug report. If there were an error in the Python binding, then I would expect the warning to be consistent. For that matter, it should be consistent if the error were in my code or in GTK. I'm running my program with --g-fatal-warnings at the end of the command line. I don't know whether that flag does anything in PyGTK, though. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Tooltips blown away by ProgressBar
When I hover over any of a number of widgets in my application, a tooltip appears. However, as soon as a progressbar updates, the tooltip disappears. Is there a way to get the tooltips to stick around the way they do when there is no progressbar update? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Column separator line in Ubuntu 8.10
After upgrading to Ubuntu 8.10, treeviews have a dashed vertical line between columns. Anyone know how to turn it off? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
FileSelection widget and DnD
Does the FileSelection widget support DnD? I would like to use the FileSelection widget to select a folder and then drag filenames to the icon for that folder to cause the files to be written to the selected folder. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Handler disconnect vs. block
Is there a reason to block/unblock a handler rather than disconnect/connect it? Is the overhead for block/unblock significantly lower? One thing I don't like about block/unblock is that GTK issues a warning when you try to unblock a handler that is not blocked, but there is no way to ask first whether the handler is currently blocked. disconnect/connect offers the handler_is_connected query. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Focus chain ineffectual
I'm trying to set the focus chain. I have 3 widgets that I want to chain, so I specified them as the arguments of the set_focus_chain method on the top-level window. I expect focus to move from one to the next as I hit tab. Instead, focus moves to many widgets not in the chain in addition to some that are in it. It seems as if the set_focus_chain call is not doing anything. can_focus is set on all three widgets. Am I not allowed to call it on the top-level window? Are the widgets required to be immediate descendants (the manual says only that the widgets should be descendants, which these are)? Is there a different explanation? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Composite children
I surround the creation of a particular widget with widget_push_composite_child and widget_pop_composite_child. Afterward, I see that property composite-child is True for the new widget. However, when I run get_children on the parent, the widget appears in the list even though documentation says that get_children returns the container's non-internal children. Is this a bug, or is there something else I'm supposed to do to prevent a child from showing up as a child? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Getting GtkCellRenderer's
dhk wrote: How do you get a GtkCellRenderer from a treeview or a GtkTreeViewColumn? Thanks, Dave gtk_tree_view_column_get_cell_renderers ()? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Drag'n'drop problems
John Coppens wrote:
On Sat, 6 Sep 2008 11:58:00 -0300
John Coppens [EMAIL PROTECTED] wrote:
I couldn't find a list of valid format
descriptions. Can anyone point me in the right direction?
Adding some more info: I found an (incomplete) chunk of code on the net
that defines the row data in the GtkTargetEntry array as:
{GTK_TREE_MODEL_ROW, GTK_TARGET_SAME_APP, 0}
I put this in my program, and behold, it worked. I searched for
GTK_TREE_MODEL_ROW as a target type, but couldn't find any reference to
that... So can anyone tell me what the possible values are?
And I'm still interested in an example on how to process row data
received from a drop, into a gtk_tree_store. I promise to write a
tutorial if I can get to understand this.
John
The first argument only has to match the first argument of the source.
There is some information in this tutorial:
http://scentric.net/tutorial/sec-dnd.html#sec-dnd-selected-item-info
There is also some good information in:
http://www.pygtk.org/pygtk2tutorial/sec-TreeViewDragAndDrop.html
but you have to be able to read Python.
--
Jeffrey Barish
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Drag'n'drop problems
John Coppens wrote:
Thanks, Jeffrey, but:
On Mon, 08 Sep 2008 08:19:42 -0600
Jeffrey Barish [EMAIL PROTECTED] wrote:
The first argument only has to match the first argument of the source.
This does not seem to be true. If I replace
{GTK_TREE_MODEL_ROW, GTK_TARGET_SAME_APP, 0} // This works
by, eg.:
{STRING, GTK_TARGET_SAME_APP, 0} // Doesn't work
So the string _is_ interpreted somewhere (outside of my program, that is).
To be specific, the drag seems to work, but drop doesn't - no event is
generated in the second case. BTW, it's not just STRING. I tried with
several other things, like xml_node_pointer (which described what I was
doing), but that didn't work either.
I was going to tell you that you are crazy, but when I tried putting
GTK_TREE_MODEL_ROW in my program in place of the arbitrary string that I
was using, I found that the behavior of my program changed to something
bizarre (I get too many signals). So I am forced to agree that
GTK_TREE_MODEL_ROW is interpreted somewhere. It's news to me. I have
always used an arbitrary string that matches in the source and destination
specifications.
There is some information in this tutorial:
http://scentric.net/tutorial/sec-dnd.html#sec-dnd-selected-item-info
I had found this tutorial, but was somewhat concerned about the '***needs
revision***' statement, and also, it uses the lowest level of interface,
using x and y coordinates. I tried some versions of this, but couldn't
get it to work. Thinking back now, the problem might have been with the
Target string.
There is also some good information in:
http://www.pygtk.org/pygtk2tutorial/sec-TreeViewDragAndDrop.html
There's a C version of this Python tutorial somewhere (I've downloaded
the C code, but lost the URL). It works well, but only drops are shown,
and then only simple strings. I do commend the python guys though - I'm
tempted to switch to Python just for the better docs.
The problem I'm now stuck with is what to do with the path I receive in
data_received (the destination path). I made a simple (destination) tree,
and get 'drop possibles' like this:
- Ok
Main item-- Ok
- No
--- Ok
Subitem 1 No
--- Ok
Subitem 2 No
BUT, if I convert those paths into iters, and set some data, I'm
destroying the next existing item. Do I have to insert an item before the
path/iter? I'll try that next. It wouldn't explain why I get a 'possible'
on Main item though.
The PyGTK FAQ has some hints:
http://faq.pygtk.org/index.py?req=showfile=faq13.030.htp
--
Jeffrey Barish
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Default icon in treeview DnD
Kristian Rietveld wrote:
On Tue, Aug 26, 2008 at 10:55 PM, Jeffrey Barish
[EMAIL PROTECTED] wrote:
Until this morning, whenever I dragged a row to a new location in the
same
treeview, the drag icon would look like the original row. I still get
that
icon when I drag from another treeview to the one in question. Is that
icon considered to be the default? Now the icon that I get looks like a
page of text with the top right corner dog-eared. I'm not aware of
making any changes to the code that would account for the change in
appearance. Any suggestion how to get back the original behavior?
Did you override the drag-begin signal or stop using
gtk_tree_view_enable_model_drag_source()? These are both possible
causes for not getting an image of the row as drag icon.
I call gtk_drag_begin for a drag from tv2 to itself. However, I do not
handle the signal. I call gtk_tree_view_enable_model_drag_source for a
drag from tv1 to tv2 (the drag that works correctly). I tried changing the
code for the drag from tv1 to tv2 so that it also uses
gtk_tree_view_enable_model_drag_source (which defeats some of the
functionality I need) instead of gtk_drag_begin. I still get the wrong
icon for that drag.
In examining my code, I noticed that I am specifying targets like this:
('tv1_row', GTK_TARGET_SAME_APP, 1)
I have the identical specification for source and destination. However,
every example I see has targets that look like this:
('tv1_row', 0, 1)
Sometimes the source target looks the same and sometimes it looks like my
first example (in which case the source and destination targets do not
match). Moreover, 0 isn't even a valid value for the second parameter. It
seems as if the second parameter doesn't matter. Is that conclusion
correct?
--
Jeffrey Barish
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Default icon in treeview DnD
Until this morning, whenever I dragged a row to a new location in the same treeview, the drag icon would look like the original row. I still get that icon when I drag from another treeview to the one in question. Is that icon considered to be the default? Now the icon that I get looks like a page of text with the top right corner dog-eared. I'm not aware of making any changes to the code that would account for the change in appearance. Any suggestion how to get back the original behavior? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Sort indicator disappeared
Chris Vine wrote: On Wed, 13 Aug 2008 16:48:36 -0600 Jeffrey Barish [EMAIL PROTECTED] wrote: When did the sort indicator disappear? The sort-indicator property is True, but I don't see anything. I used to. Was it lost in some upgrade? I am on Ubuntu 8.04. My libgtk is 2.12.9-3ubuntu4. There have been different bugs affecting the sort indicator in both GTK+-2.10 and GTK+-2.12. It was fixed in GTK+-2.10.7, was broken again in GTK+-2.12.1, and was eventually fixed again in GTK+-2.12.11. See http://bugzilla.gnome.org/show_bug.cgi?id=352738 Chris Thanks. I will upgrade as soon as Ubuntu has a new package available. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
CellRendererToggle with custom pixbuf?
I am using a CellRendererToggle. I would like to be able to specify pixbufs to use to draw the toggle in its two states. Basically, I want to toggle between two images in a TreeView. When I click on one image, it changes to the other. Is there an easy way to do this? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Sort indicator disappeared
When did the sort indicator disappear? The sort-indicator property is True, but I don't see anything. I used to. Was it lost in some upgrade? I am on Ubuntu 8.04. My libgtk is 2.12.9-3ubuntu4. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Slow treemodel loading
The solution was to perform the sort myself. The update is now nearly 20x faster. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Slow treemodel loading
Damien Caliste wrote: Hello, If I'm not wrong, you may be interested with gtk-list-store-insert-with-values() function: http://library.gnome.org/devel/gtk/unstable/GtkListStore.html#gtk-list-store-insert-with-values Thank you for your suggestion. The documentation is characteristically ambiguous, so I can't tell whether this function would solve the problem. The documentation says that the function does not emit the rows_reordered signal, but it does not say that the list store is not resorted. Perhaps suppressing the rows_reordered signal also suppresses sorting, but I don't find that crucial detail documented anywhere. In any case, insert_with_values does not appear to be available in PyGTK, which is what I am actually using. This problem with list stores seems serious to me, so I am surprised that Gtk suffers from it. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Slow treemodel loading
The first time I load the liststore (during program start), it loads quickly. Then I set sort column ID so that I can sort by column. When I clear the liststore and load the next data set, the treeview updates slowly even when it's actually the same dataset. If I substitute a simple sort function during loading, performance improves a bit. If I never set the sort column ID, performance improves even more. I conclude that it's the sort function that is retarding the update. If there were a way to turn off the sort, I would not have a problem. As it says in the documentation for TreeSortable: Once a sort column ID has been set on a gtk.TreeModel...you cannot set the gtk.TreeModel to have no sort function. The inability to clear the sort function seems very unfortunate to me right now. I considered starting over with a new liststore, but doing so is inconvenient. Now I am considering loading the liststore with only some of the data initially and the rest on idle. But first I am hoping that someone will tell me that there actually is a way to turn off sort. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Highlighting text with color
I need to highlight some text in a TreeView. I know how to change the color, but I am wondering what color to use. I am thinking that I should choose a color that is used elsewhere so that the highlighted text does not clash with the theme, even if the user were to change the theme. Perhaps themes define a color to use for highlighting text. Where would I find information about the colors that are defined by themes? How would I get one of these colors from within my code? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Ellipsize text in Entry
Am I missing something, or is it not possible to specify that text in an Entry should be ellipsized? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Image with shadow
I would like to put a shadow behind an Image. I suppose that the way to do this is to superimpose the desired image on an image of a shadow. Does anyone know where I can find an image of a shadow? Any sample code? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Image with shadow
Claudio Saavedra wrote: El mar, 25-03-2008 a las 16:46 -0600, Jeffrey Barish escribió: I would like to put a shadow behind an Image. I suppose that the way to do this is to superimpose the desired image on an image of a shadow. Does anyone know where I can find an image of a shadow? Any sample code? ?In gnome-utils/gnome-screenshot there is code for that. I will look at this code. Thanks. In the meantime, I found an image of a shadow surrounding a black region. I am attempting to use Pixbuf composite to superimpose my image on the black region. My attempt almost works, but the source image gets smeared to the edge of the shadow (the destination) by extending the last pixels on every edge of the source to the corresponding edge of the destination. Can anyone guess from this description what I'm doing wrong? I have tried every type of interpolation. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Image with shadow
Jeffrey Barish wrote: In the meantime, I found an image of a shadow surrounding a black region. I am attempting to use Pixbuf composite to superimpose my image on the black region. My attempt almost works, but the source image gets smeared to the edge of the shadow (the destination) by extending the last pixels on every edge of the source to the corresponding edge of the destination. Can anyone guess from this description what I'm doing wrong? I have tried every type of interpolation. I had the width and height slightly wrong. Best to get them from the pixbuf. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
TreeView indent-expanders style property
Does anyone know what the indent-expanders style property does? I currently see | Line 1 | Line 2 |Line 3 | Line 4 What I would like is | Line 1 | Line 2 | Line 3 | Line 4 Can I use indent-expanders to achieve this effect? Is there a way to achieve it? The point is to avoid wasting space on lines that don't require an expander arrow. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Order of children in Box
[EMAIL PROTECTED] wrote: Generally the most recently added child of any gtkcontainer is at the head of the list. However ... you can't really rely on it 100%. Yes, I too have observed this behavior when I use foreach or get_children. I was wondering whether I could count on it. You say that I cannot. If I cannot count on these functions to preserve order, I am wondering what function I can count on. Would there not have to be a function for getting the child in position i? I could label the children, I suppose, and put them in order myself, but Box must know the order because it has a function for reordering a child to position i. If foreach and get_children do not preserve the order on retrieval, what does? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Order of children in Box
If I do foreach on a Box, will the order in which the children are retrieved correspond to the order in which they were packed? How about get_children? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview column width changed signal
With some trepidation about extending this wearisome thread, I thought that I would post for the benefit of the record some information about a solution that I found. It is based on a suggestion made by Kristian Rietveld in the previous incarnation of this thread (which I quoted when I resurrected the thread). He suggested connecting to the notify::width signal on each column. He warned that I needed to keep the callback fast and specifically directed that I not write a file in the callback. As writing a file was the purpose for detecting that column width had changed, it did not seem as if his suggestion would work. However, what does work is to use notify::width to set a flag indicating that the file needs to be written. Then catch the button-release event for the treeview that contains the columns. If the flag is set when I get button release, then I write the file (and clear the flag). This solution works almost perfectly, but I do get a spurious write when I first select a row. I hope that someone will be able to glean something useful from this thread so that it can now rest in peace. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview column width changed signal
Gorshkov wrote: Lack of patience, and the feeling that I was talking to a brick wall, to be perfectly honest. I even posted all the code he needed to implement the solution - and given that it was only about 20 or 30 lines total, I wouldn't exactly call it overly complicated. The only code I did not give him was the code to actually save the data to a file - everything else - the signal handlers, callbacks, etc, is there. I had already implemented the solution you gave me before I resurrected the old thread. It works for restoring the column widths after exiting and restarting the program. My lengthy comments were not criticism of your suggestion but an attempt to explain why its application does not meet all of my needs in a straightforward manner. The remaining problem is that a remote section of code needs to know the column widths while the program is running. It would have been trivial to obtain the information from the file, but the file does not get updated when the column widths change, only when the treeview is destroyed. The solution which you, Dave Howorth, and even I have suggested in this thread is to read the column widths from the treeview. Usually, implementing that solution is also trivial. It is not trivial in my situation because the remote section of code does not know about the treeview. Nevertheless, the solution is practicable. Note that in my original posting I did not ask for a solution, I asked why GTK has this small limitation. I understand that there is a way to implement a solution, but I long for the solution that would have been trivial. The implication that writing the file when the treeview is destroyed is equivalent to writing it when the column widths change is wrong. Although there are cases where the two approaches are equivalent, they are not equivalent in situations that Scott and I have encountered. Moreover, the designers of Qt and wxWidgets evidently don't consider the two approaches to be equivalent because they chose to support both. My objective in posting my message was simply to encourage the designers of GTK also to support both. With that resolution, you would be free to continue to use the destroy signal and I would be free to use the column-width-changed signal, even if we were both doing so out of stubborn adherence to the familiar. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview column width changed signal
As I observed previously, there are usually ways to design around limitations of toolkits, but sometimes they are awkward. In my case, the TreeView in question is instantiated in class A. Class A is instantiated in class B. The code that needs to know the column widths is in class D which is instantiated in class C which is instantiated in class B. There are ways to pass a column width getter from class A to class D, but they are awkward. Although class D needs to know the column widths, it does not currently know about the treeview in class A (and shouldn't, to minimize coupling). Another solution would be to make the column-width-getter global, which is probably what I will do even though it is also poor programming practice. I must have a file of column widths anyway so that the treeview can restore its column widths the next time the program starts. The only problem with having class D simply read the file is that it is difficult to assure that the contents of the file are updated when the column widths change. I wondered two things in my original posting: (1) How can wxWidgets provide a column-width-changed signal if GTK does not when wxWidgets runs on top of GTK? I realized that the obvious answer to this question is that wxWidgets does not use TreeViews to create lists of things. Whatever it uses must make it possible for wxWidgets to provide the column-width-changed signal. (2) Is there an argument for excluding the signal from GTK, especially considering that wxWidgets and Qt both provide it? Catching destroy/delete may serve the purpose in many cases, but it is not equivalent to a column-width-changed signal. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview column width changed signal
Gorshkov wrote: I do this exact thing in an application I'm developing now. But I only do it in one place - a callback routine that is called for both the delete and destroy events. Thank you for your suggestions. I don't get a delete, destroy, or even a hide signal when the treeview disappears because I switched to a different page of a notebook. I could, of course, detect when I change pages of the notebook, but then I am off plugging holes in the dike. The problem is that there are ways to get to portions of my code that read the column-width file in which the treeview has not been destroyed, so the column-width file has not been updated. I suppose that this code will have to extract column widths from the treeview rather than read them from the file, but then remote portions of the code will need to be coupled to this treeview. The file was a neat way to decouple the code because I need to store the widths anyway. There is always a way to get around a limitation of a library, but I still wonder why the GTK developers are comfortable with this limitation when other GUI toolkits provide the appropriate signal. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview column width changed signal
Kristian Rietveld wrote: If just saving the column widths of the tree view when the tree view is destroyed is not enough, the easiest way to do this is probably to connect to the notify::width signal on each column. Remember to keep the callback fast (do not write to files, etc) as your callback will be called a lot, especially when the user is resizing columns with the mouse. The problem with your first suggestion is that I have to hook every situation in which the tree view can be destroyed. The obvious one is when I change data sets. Exiting the program is another. There will be others when I implement more of the program. It certainly is possible to record the column widths at each of these points, but it sure is clumsy. The problem with the second suggestion is that writing a file is exactly what I need to do. The point of this exercise is to record in a file the width of each column as established by the user with the mouse so that the columns will have the same width the next time the program runs. A signal seems the ideal solution and it's the one I used previously (in wxWidgets), but any other suggestions are welcome. In the meantime, I'll work on capturing the column widths at every point where the tree view can be destroyed. Designing around the lack of a signal keeps getting harder. It is not sufficient to save the column widths everytime the treeview is destroyed. Sometimes the column widths need to be saved when the treeview becomes invisible (e.g., because it is on a different page of a notebook). There are many ways this can happen in my program. I'm running out of fingers to stick in the dike. I wonder about two things. wxWidgets provides this signal and wxWidgets runs on GTK on some platforms. So how can wxWidgets provide the signal if we GTK programmers can't get it? wxWidgets has this signal; Qt has it too. Is there an argument for excluding it from GTK? When I used wxWidgets, I frequently encountered situations where I had to design around deficiencies in the toolkit. I believe that this is the first time I have had to design around a deficiency in GTK. That's pretty good. I'm still impressed with this toolkit even as I plead for a small enhancement. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Scrolling in ComboBox popup
Is there a way to control scrolling in the popup for a ComboBox? I have a ComboBox with only 10 items. The ComboBox pops up a window with the active item positioned near the top. If the active item is not one of the first two items, then scrollbars appear and there is a vast empty space below the last item. I can scroll to the top, at which point the scrollbars disappear and the items neatly fill the space that was originally available. I don't understand why the ComboBox is resorting to scrollbars when the popup has enough room for all items. Is there a way to tell the ComboBox not to use scrollbars? Can I force the first item to appear so that the scrollbars disappear? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
ComboBox and set_cell_data_func
I am using set_cell_data_func with a ComboBox. I noticed that when I call the append method of the TreeStore, set_cell_data_func is called twice. The first time, the row has not yet been written into the TreeStore, so the set_cell_data_func can't perform its function. Is there a reason that GTK calls set_cell_data_func twice? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Contents of VBox don't draw after putting it in Viewport
It's a long shot, but I am hoping that someone might recognize my problem from this general description. I tried to reduce my code to a test case, but it works there. After spending an entire day on this problem, I am stumped. I have a bunch of labels and entries in a vbox. I added the vbox to page 1 of a notebook (the second page). Everything worked fine. I encountered a situation in which some of the labels and entries did not fit on the page, so I put the vbox in a viewport, the viewport in a scrolledwindow, and I added the scrolledwindow to the notebook instead of the vbox. Now when I go to the mode in which the notebook is visible I find that page 0 appears, but when I select page 1 I see nothing. If *after exposing (the blank) page 1* I leave the mode in which this notebook is active and then return, the contents do appear. The contents appear promptly when I add the vbox to the page directly, but when the same vbox is inside a scrolledwindow with viewport they appear only after trying once to view them, switching to a mode in which the notebook is not visible, then returning. My first thought was show_all. However, if that were the problem then it would not work to leave and return. In any case, I do a show_all on the scrolledwindow. I modified the code so that page 1 appears initially when I enter the mode in which the notebook is visible. In that case, the contents of page 1 appear immediately, but when I switch to page 0 I now see none of the widgets that reside inside the scrolledwindow with viewport on that page (a combobox that is not inside the scrolledwindow with viewport is visible). (And incidentally, I cannot make them appear by leaving the mode in which the notebook is visible and returning, although that procedure does make the contents of page 1 appear in the unmodified code. However, when I activate the combobox, the contents of page 0 appear instantly.) If I further modify the code so that the vbox on page 0 is added directly to page 0 without the scrolledwindow with viewport, then all the contents of page 0 appear as soon as I select page 0. The problem seems to be related to a scrolledwindow with viewport on a hidden page of a notebook. However, in my test program I put a bunch of labels in a vbox in a viewport in a scrolledwindow on two pages of a notebook and both pages appear without coaxing. Any suggestions greatly appreciated. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Contents of VBox don't draw after putting it in Viewport
Tristan Van Berkom wrote: If for instance, your toplevel widget is already realized then adding pages to the notebook (and thier contents recursively) will result in all pages being realized at the start, on the other hand if your toplevel is invisible, or your notebook is not anchored at creation time (anchored means inside a toplevel somewhere), then the subhierarchies will only be realized when those pages are gtk_widget_show()n AND in an active notebook page. You might try making sure that all of your pages are realized at the startup, this would typically mean after glade_xml_new() with a visible toplevel, you would call gtk_notebook_set_page() for each page provoking a realize before ever entering gtk_main(). The contents do appear when I add the vbox to the page directly. It is only when I add the vbox to a scrolledwindow with viewport and then add the scrolledwindow to the page that nothing appears when I select the page. I think that this behavior exonerates the notebook. Nevertheless, I tried catching the realize signal on the vbox, the viewport, the scrolledwindow, and a widget in the vbox. I do get all the signals when I switch to the page. Finally, note that with the modified code (in which page 1 appears first), I do see a combobox when I switch to page 0 (it is not in the scrolledwindow with viewport). I believe that its appearance confirms again that the page is being realized. It is only the contents of the scrolledwindow/viewport/vbox on the same page that do not appear. Thank you for your suggestions. By suggesting new directions, they provide exactly the sort of help I need. I can think of only a few reasons for widgets not to appear. Failure to realize is one. Perhaps it is still a possibility if my analysis above is flawed. Visibility is another, but I am already calling show_all on the scrolledwindow. Could they be positioned incorrectly? Is there something I may need to do to the scrolledwindow to get it positioned correctly? I tried catching the realize and size-allocate signals. When the widgets are realized, their allocation is (-1, -1, 1, 1). They never get a size-allocate signal. When I add the vbox to the notebook directly, their allocation is the same when they are realized but then they are immediately allocated. It seems that the widgets are invisible not because they are not being realized, but because they are not being sized. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Contents of VBox don't draw after putting it in Viewport
Jeffrey Barish wrote: I tried catching the realize and size-allocate signals. When the widgets are realized, their allocation is (-1, -1, 1, 1). They never get a size-allocate signal. When I add the vbox to the notebook directly, their allocation is the same when they are realized but then they are immediately allocated. It seems that the widgets are invisible not because they are not being realized, but because they are not being sized. So I call queue_resize() on the vbox in the handler for its realize signal. That change eliminates the problem. It does seem as if there is a bug in GTK, though. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Selecting words in textbuffer
Because I'm just learning how to use textbuffer, I may be missing the correct solution to my problem. I want to be able to sweep a selection of several words without having to hit the beginning and end of the words exactly. I found textiter.backward_word_start() and textiter.forward_word_end() for adjusting the textiters that bound the selection and select_range() for selecting the entire selection once the textiters have been adjusted. My problem is that I need a trigger that invokes the code for making the adjustment. My current solution hooks button release. It works, but it catches too much. The next thing I do after making the selection is to drag it to an entry. When I release the button at the end of the drag, the code for widening the selection is invoked again. I can suppress the second invocation by setting a flag when I start dragging, but the correct solution would hook text-selected rather than button-release, a signal that does not seem to exist. Did I miss it? Is there a different better solution? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Spontaneous background colors in treeview
Kristian Rietveld wrote: When you sort a column in a tree view with = 3 columns, the sorted column is drawn with a background that is slightly darker than the default background (in the default theme it is a shade of grey). This is the default and correct behavior. What is the rationale for ignoring set_sort_indicator when the number of columns is less than 3? If I go to the trouble of setting the sort indicator, it seems to me that gtk should respect my desires and show it. If I don't want the sort indicator to appear when ncols 3, I could detect that condition myself. I am annoyed that the sort indicator disappears from my GUI when I present data that requires only 2 columns. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Spontaneous background colors in treeview
Andrew Cowie wrote: On Wed, 2007-10-10 at 19:45 -0600, Jeffrey Barish wrote: I believe that the manual is wrong when it says that an arrow appears. One most certainly does appear when you click on the header to sort. Do you have gtk_tree_view_column_set_headers_visible() set to true? That's where the arrow shows up. *(assuming you have a proper Linux distro that maintains GNOME properly and that you are using a sane and maintained theme) AfC San Francisco Sure (it is set in Glade) -- and the headers are visible. But no arrows. This is on Ubuntu 7.04 with the default theme. On another platform, I see arrows but no shading -- exactly the reverse of what I get on Ubuntu. I am satisfied with just the shading on Ubuntu, although I am curious about the discrepancy with your observations. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview column width changed signal
Kristian Rietveld wrote: If just saving the column widths of the tree view when the tree view is destroyed is not enough, the easiest way to do this is probably to connect to the notify::width signal on each column. Remember to keep the callback fast (do not write to files, etc) as your callback will be called a lot, especially when the user is resizing columns with the mouse. The problem with your first suggestion is that I have to hook every situation in which the tree view can be destroyed. The obvious one is when I change data sets. Exiting the program is another. There will be others when I implement more of the program. It certainly is possible to record the column widths at each of these points, but it sure is clumsy. The problem with the second suggestion is that writing a file is exactly what I need to do. The point of this exercise is to record in a file the width of each column as established by the user with the mouse so that the columns will have the same width the next time the program runs. A signal seems the ideal solution and it's the one I used previously (in wxWidgets), but any other suggestions are welcome. In the meantime, I'll work on capturing the column widths at every point where the tree view can be destroyed. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Spontaneous background colors in treeview
Mikael Hallendal wrote: Would it be possible to provide a screenshot that shows the problem you are seeing? It now appears that I fell victim to misleading documentation. The reference manual says that setting the sort indicator to true causes an arrow to appear in the header button indicating the column is sorted. On my system I see no arrow. Instead, the column is shaded. I believe that the manual is wrong when it says that an arrow appears. The second problem is an ambiguity in the manual. The statement describing the effect of setting the sort indicator to true seems to imply that the arrow will not appear if the column is not sorted. This interpretation prompted me to set the sort indicator on all columns with the expectation that the arrow would appear only on the one that was sorted. What actually happens when one sets the sort indicator is that the column is shaded, so setting the sort indicator on all columns results in what looks like a colored background. I suspect that I am supposed to set the sort indicator manually on the appropriate column (and only that column) whenever I switch sort column. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Spontaneous background colors in treeview
Kristian Rietveld wrote: Hi, On Mon, Oct 01, 2007 at 11:30:58AM -0600, Jeffrey Barish wrote: Stop presses. It's the number of columns. All data sets that require 3 columns have a background. All data sets that require 2 columns do not. Here it is. If I comment out the line that sets the sort indicator, I do not get the colored background for any data set. I thought you meant the rows had alternating background colors in your previous mails. When you sort a column in a tree view with = 3 columns, the sorted column is drawn with a background that is slightly darker than the default background (in the default theme it is a shade of grey). This is the default and correct behavior. I did mean the rows. With 3 columns (or more, perhaps -- my data sets never require more than 3 so I don't know) and with set sort indicator set to true, I get alternating *rows* of color. With 2 columns and with set sort indicator set to true, the background is white. With set sort indicator set to false, the background is white for any number of columns. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Spontaneous background colors in treeview
Kristian Rietveld wrote: To get the alternating colors you would set the rules-hint property on GtkTreeView to TRUE (the default is FALSE). If you do not set this property to TRUE, the background should always be a solid color. Also note that rules-hint is only a hint to the theme engine; if the theme engine sets the allow-rules style property to FALSE (the default is TRUE) the colors will not be alternating. The application always has the final call about showing alternating colors, if the application sets rules-hint to FALSE and the theme still shows alternating colors, the theme is broken and needs to be fixed. The rules-hint property is always False in the TreeView regardless of which data set I display. If I set rules-hint to True, I do indeed get alternating colors in the background with all data sets. However, the colors are darker for the data sets that had alternating colors already. From your last statement, I conclude that the Ubuntu theme is broken. I gather that the reason I do not get alternating colors in the background of the treeview on the other platform with exactly the same code is that the theme on that platform is not broken. Because the background comes and goes depending on the data I display, it must be that something in the data is provoking the defect in the theme. If I can find out what that is, perhaps I will have a clue how to fix the theme. Stop presses. It's the number of columns. All data sets that require 3 columns have a background. All data sets that require 2 columns do not. Here it is. If I comment out the line that sets the sort indicator, I do not get the colored background for any data set. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Spontaneous background colors in treeview
After making some changes to my program (not directly related to the GUI), I find that one treeview has a background of alternating light and dark bands, but only for certain data sets. I never set the background in my code, so I expect it to be white for every data set. The program has this behavior only under Ubuntu. On another platform, I do get a white background for all data sets (with the same code). Does anyone have a clue what might be causing this bizarre behavior? If I wanted to set the background of the treeview to alternating light and dark bands, how would I do that? I find that modify_bg on the treeview does nothing (although modify_text works). -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Treeview column width changed signal
Is there a way to be notified when the width of a column in a treeview changes? I would like to record the new column widths so that I can set them to the same values the next time the window opens. The only signal in TreeViewColumn is clicked, which doesn't seem to do what I need. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
widget_push_composite_child
I asked this question on the pygtk mailing list, but got no response. As the scope is not limited to PyGTK, I am hoping that someone here knows the answer. - I understand that I can add composite children to a widget by creating them between widget_push_composite_child and widget_pop_composite_child calls. gtk.widget_push_composite_child() widget1 = gtk.Widget1() widget2 = gtk.Widget2() gtk.widget_pop_composite_child() widget1.set_parent(main_widget) widget2.set_parent(main_widget) Aside from the difference between foreach and forall, is this code otherwise equivalent to widget1 = gtk.Widget1() widget2 = gtk.Widget2() main_widget.add(widget1) main_widget.add(widget2) I ask this question because I am trying to understand exactly what is meant by composite children. The documentation also uses the term internal children. Are they the same as composite children? Also, the Container class has a method get_children() which returns a list of all non-internal children. What is the method for obtaining a list of internal children? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Fixing size of window containing 2 buttons
I am just starting with GTK, so no doubt I am missing something basic. I have a window with a buttonbox with 2 buttons. I use size_allocate on the buttons to position them. One of the buttons starts hidden. I would like to size the window so that it will accommodate both buttons, but I keep getting a window wide enough only for the one visible button. I have tried set_size_request on the window. I tried catching size-request on the window to confirm that the requisition is correct. It is. I also have set_size_request on the buttonbox, which I believe should not be necessary (and seems to do nothing). What am I missing? -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
