Re: Using a TextView as a sort of Hbox with wrapping
Chris,
If I interpret what you are trying to do correctly (not necessarily a
given), then I would have thought that GtkScrolledWindow (possibly in
conjunction with GtkViewport) would be the tool for the job.
James
On 26 January 2014 14:50, Chris Angelico ros...@gmail.com wrote:
My application has a status bar which can have an arbitrary number of
items added to it. Currently, I use an Hbox with no padding, which
works fine as long as there aren't too many statusbar elements added;
but if there are a lot, the tail starts wagging the dog, in that the
size of the window becomes dictated by the status bar (which normally
is supposed to be subtle, not intrusive/controlling). So I figured
that wrapping elements onto another line of status bar would be a more
useful way to lay them out, but that's really tricky. Enter TextView:
it's a widget designed to handle wrapping, and it can have child
widgets embedded in it.
Here's some proof of concept code. (This is in Pike, so you may not be
able to run it directly.)
int main()
{
GTK2.setup_gtk();
object
buf=GTK2.TextBuffer(),view=GTK2.TextView(buf)-set_editable(0)-set_wrap_mode(GTK2.WRAP_WORD)-set_cursor_visible(0);
view-modify_base(GTK2.STATE_NORMAL,GTK2.GdkColor(240,240,240));
foreach (({Asdf asdf,Qwer qwer,Zxcv zxcv,Testing,
testing,1, 2, 3, 4}),string x)
{
view-add_child_at_anchor(GTK2.Frame()-add(GTK2.Label(x))-set_shadow_type(GTK2.SHADOW_ETCHED_OUT),
buf-create_child_anchor(buf-get_end_iter()));
buf-insert(buf-get_end_iter(), ,-1);
}
GTK2.Window(GTK2.WindowToplevel)-set_default_size(500,300)-add(GTK2.Vbox(0,0)
-add(GTK2.Label(Blah blah blah, this\nhas lots and\nlots of
content\n\nLorem ipsum dolor sit\namet))
-pack_start(GTK2.Button(This sets the base width),0,0,0)
-pack_start(view,0,0,0)
)-show_all()-signal_connect(delete-event,lambda() {exit(0);});
return -1;
}
Two questions.
Firstly: Is this a really REALLY stupid thing to do? When I Googled
for a wrapping layout manager, nothing mentioned this possibility, so
I'm wondering if this is somehow fundamentally bad and I just haven't
seen it.
And secondly: The TextArea defaults to having a white background, but
I want to use the window's default background. On my system, setting
the color to (240,240,240) does that, but that means I'm explicitly
setting a color, so it's going to be grey even if the UI theme
specifies that a window's background should be vibrant orange. Is
there a way to tell the TextView not to draw its background, or
alternatively, a way to query the default background color for a
window?
Thanks in advance!
ChrisA
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Get column no. of edited cell.
Another possibility would be to use g_object_set_data to give the renderer a column number, and g_object_get_data in the handler. On 2 June 2013 07:15, dE de.tec...@gmail.com wrote: On 06/02/13 00:27, Arnel A. Borja wrote: On Sunday, 02 June, 2013 01:44 AM, dE wrote: I've set the editable property of GtkCellRenderer to true, and set the call back for the edited signal. This particular signal tells the node/row in which the edit has occurred, but not the column/filed. How can I get that? Thanks! Use a different renderer for each column. Then check in the edited signal which renderer was edited. I'm trying this out, but isnt this also possible with gtk_tree_view_get_cursor clubbed with gtk_tree_view_column_get_sort_** column_id. Cause I'm getting segfault with -- gtk_tree_view_get_cursor ( detect_object ( DataDisplay, build_object ), tree_path, focus_column ); Where -- GtkTreeViewColumn **focus_column; GtkTreePath **tree_path; __**_ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/**mailman/listinfo/gtk-app-**devel-listhttps://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
g_timeout handling, is this the best way?
I have a program that uses a g_timeout loop to control the display of a sequence of plots (produced via plplot), and I need to be able to change the delay between displaying the plots. The method I am using is this: 1. Use g_timeout_add_full to create the timeout, with the GSourceFunc as a routine that checks whether a termination flag has been set, and either displays the next frame and returns TRUE or just returns FALSE. 2. Set up a GDestroyNotify function that checks if a restart flag is set and if it has then starts a new timeout loop. 3. The callback that changes the speed, updates the delay and then sets both the termination and restart flags, so that on the next timeout call, the loop is destroyed and recreated with the new delay. Is this the best way to do it or is there a more convenient way? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Lack of gtk_application_get_window_by_id function despite of documentation
On 17 November 2012 16:05, Jakub Kucharski dexc...@gmail.com wrote: I was trying to compile my application and it appears that one documented function called 'gtk_application_get_window_**by_id' ( http://developer.gnome.org/**gtk3/stable/GtkApplication.** html#gtk-application-get-**window-by-idhttp://developer.gnome.org/gtk3/stable/GtkApplication.html#gtk-application-get-window-by-id) doesn't exist. I run Debian Sid on my machine and I've installed 'libgtk-3-dev' package, so I don't really see what's wrong. Maybe this output will be useful for you: According to the Debian package list they are still at 3.4 in Sid, and the routine is marked Since 3.6. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Examples of ComboBox using an explicit model?
Thanks to those who send examples on or off list. With the guidance of those I was able to figure out how the different bits fit together and get a working code. James ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Examples of ComboBox using an explicit model?
I am currently trying to implement combobox cell renderers in the high-level gtk-fortran code. Unfortunately unlike normal comboboxes where there is the convenience type of GtkComboBoxText this is not available for cell renderers. I have hunted for examples of a working combobox that uses an explicit tree model without any success. Does anybody on this list have such an example (or even better, of a CellRendererCombo) that they would be willing to share. James ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
g_value_set_instance -- how to use?
There is very little documentation that I can find explaining how
g_value_set_instance is supposed to work. Is the following anywhere near
correct?
void my_gvalue_setter( const GValue *gv,
gpointer val,
Gtype type)
{
g_value_unset(gv);
g_value_init(gv, type);
g_value_set_instance(gv, val);
}
Then provided val is a pointer to a quantity of type type, it's equivalent
to using the specific setting routine or am I barking up quite the wrong
tree?
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How do I fix the window size?
On 5 June 2012 11:00, Ferdinand Ramirez ramirez.ferdin...@yahoo.com wrote: I have a treeview and a scrollbar which are both within a hbox. The hbox is within a window. When I expand the treeview, the window resizes itself to include the whole treeview. The biggest problem is when the treeview has more elements than what can be seen on a single screen. The window size becomes larger than the display. I want the window size to remain the same and use my scrollbar to navigate my treeview. How do I achieve this? gtk_window_resize does not seem to be the solution. I think the solution is to place the treeview in a gtk_scrolled_window rather than using an hbox and an explicit scrollbar. You may also need to make a call to gtk_widget_set_size_request on the scrolled window to get what you want. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How do I fix the window size?
On 5 June 2012 12:50, Ferdinand Ramirez ramirez.ferdin...@yahoo.com wrote: --- On Tue, 6/5/12, James Tappin jtap...@gmail.com wrote: I think the solution is to place the treeview in a gtk_scrolled_window rather than using an hbox and an explicit scrollbar. The reason for trying out with an explicit hbox is that the column headers scroll out of view with a gtk_scrolled_window. I'm puzzled as it doesn't do that in my RPN calculator stack and registers display. This uses a list model (i.e. no sub-rows). Here are the key bits of code (in Fortran 2003 -- I'm not a C programmer). The list creator function: function hl_gtk_listn_new(scroll, ncols, types, changed, data, multiple, width, titles, height, swidth, align, ixpad, iypad, sensitive, tooltip, sortable, editable, colnos, edited, data_edited) result(list) type(c_ptr) :: list type(c_ptr), intent(out) :: scroll integer(kind=c_int), intent(in), optional :: ncols integer(kind=type_kind), dimension(:), intent(in), optional :: types . . . ! Create the storage model model = gtk_list_store_newv(ncols_all, c_loc(types_all)) ! Create the list in the scroll box scroll = gtk_scrolled_window_new(C_NULL_PTR, C_NULL_PTR) call gtk_scrolled_window_set_policy(scroll, GTK_POLICY_AUTOMATIC, GTK_POLICY_AUTOMATIC) list = gtk_tree_view_new_with_model(model) call gtk_container_add(scroll, list) . . . And in the calculator itself: ! Registers. jbase = hl_gtk_box_new() idx = hl_gtk_notebook_add_page(mstabs, jbase, label=Registers//c_null_char) fmemory = hl_gtk_listn_new(smemory, changed=c_funloc(memsel), height=300, titles= (/ Index//c_null_char, Value//c_null_char /), types = (/ g_type_int, g_type_double /)) call hl_gtk_listn_set_cell_data_func(fmemory, memcol, func=c_funloc(show_list), data=c_loc(memcol)) call hl_gtk_box_pack(jbase, smemory) I hope that this will at least give some clues as to how the bits fit together. P.S. hl_gtk_* routines are Fortran routines that bundle settings together and use Fortran's optional argument system to hide much of the complexity of the raw gtk_* calls. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Multiple selections in list/treeview widgets and accelerator groups?
Is it possible that having an accelerator group associated with the top-level window of a hierarchy could prevent multiple selections in a list widget within that window from working? I have an application that is supposed to have multiple selections enabled (gtk_tree_selection_set_mode(selection, GTK_SELECTION_MULTIPLE) has been called on the selection object associated with the treeview). But when I do a control-click or shift-click on the list nothing happens [I don't expect Ctrl-A to work as that is bound to a button]. The only significant difference I can see from a demo program that does work is that the top-level window has an accelerator group in the application and not in the demo. James ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Getting the busy cursor to display.
On 11 April 2012 04:36, jcup...@gmail.com wrote: On 10 April 2012 18:33, James Tappin jtap...@gmail.com wrote: Thanks for the suggestion. Unfortunately in this case it doesn't help. (I have also tried gdk_display_flush and gdk_window_flush, but still the same story). Here's a tiny test program that works for me with gtk2. It just uses: gdk_window_set_cursor( win-window, busy_cursor ); gdk_flush(); J That program works, as does a translation into Fortran. But I'm still not having any joy with my display monitor. Maybe the only convenient fix is to show a window with a message Reading database during the read and then create the monitor afterwards. To Igor: I thought that a progress bar in activity mode had to be prodded to show the animation, which is not possible while I'm doing the read. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Getting the busy cursor to display.
On 11 April 2012 09:25, James Tappin jtap...@gmail.com wrote: On 11 April 2012 04:36, jcup...@gmail.com wrote: On 10 April 2012 18:33, James Tappin jtap...@gmail.com wrote: Thanks for the suggestion. Unfortunately in this case it doesn't help. (I have also tried gdk_display_flush and gdk_window_flush, but still the same story). Here's a tiny test program that works for me with gtk2. It just uses: gdk_window_set_cursor( win-window, busy_cursor ); gdk_flush(); J That program works, as does a translation into Fortran. But I'm still not having any joy with my display monitor. Maybe the only convenient fix is to show a window with a message Reading database during the read and then create the monitor afterwards. To Igor: I thought that a progress bar in activity mode had to be prodded to show the animation, which is not possible while I'm doing the read. I'm now really confused -- I've reordered some of the code so that the set_cursor call precedes putting a message in the status bar. And the status bar updates but not the cursor. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Getting the busy cursor to display.
On 11 April 2012 10:51, James Tappin jtap...@gmail.com wrote: I'm now really confused -- I've reordered some of the code so that the set_cursor call precedes putting a message in the status bar. And the status bar updates but not the cursor. OK: I think I've figured it. The problem is/was that since the pointer was not normally inside the monitor window when the cursor change was made AND there was no event polling during the read, the cursor was stuck in what ever state it entered the window. Since other parts of the program use openmp for parallel DO loops, I've put a parallel section so that one thread polls events while the other does the reads. Thanks for all the comments, they did help getting me thinking down the right lines. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Getting the busy cursor to display.
I have a gtk (fortran) application that displays a progress monitor while computing, and I would like to display the busy cursor while the program is reading a large data file. Right now what I have is: To define the busy cursor and GDK window (module [global] variables). draw_window = gtk_widget_get_window(window) busy_cursor = gdk_cursor_new_for_display(gdk_display_get_default(), GDK_WATCH) and then to activate/deactivate it: ! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ! Set a busy cursor on the progress monitor (for reading the database) subroutine set_monitor_busy(is_busy) logical, intent(in) :: is_busy if (is_busy) then call gdk_display_sync(gdk_display_get_default()) call gdk_window_set_cursor(draw_window, busy_cursor) call gdk_display_sync(gdk_display_get_default()) else call gdk_display_sync(gdk_display_get_default()) call gdk_window_set_cursor(draw_window, NULL) call gdk_display_sync(gdk_display_get_default()) end if end subroutine set_monitor_busy The just before I start to read the big file I have: call set_monitor_busy(.TRUE.) and after reading: call set_monitor_busy(.FALSE.) However, even with both gdk_display_sync calls as shown, sometimes the busy cursor appears and sometimes it doesn't (in fact sometimes the whole window shows blank until after the file read). The commonest case is that the monitor window renders but still keeps the regular cursor. Is there some other call (or calls) I should be making to force the updates to take place? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Getting the busy cursor to display.
On 10 April 2012 10:09, jcup...@gmail.com wrote: On 10 April 2012 16:58, James Tappin jtap...@gmail.com wrote: call gdk_display_sync(gdk_display_get_default()) call gdk_window_set_cursor(draw_window, busy_cursor) call gdk_display_sync(gdk_display_get_default()) My gtk2 program does this with: gdk_window_set_cursor( window, cursor ); gdk_flush(); If that's any help :( I've not tried gtk3 yet. J Thanks for the suggestion. Unfortunately in this case it doesn't help. (I have also tried gdk_display_flush and gdk_window_flush, but still the same story). ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Getting the busy cursor to display.
On 10 April 2012 11:36, Michael Cronenworth m...@cchtml.com wrote: James Tappin wrote: Is there some other call (or calls) I should be making to force the updates to take place? I use the following for widget updates during background processing: while ( gtk_events_pending( ) ) gtk_main_iteration( ); Not sure if it will work for cursor drawing though. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list I have tried that as well -- and still no joy. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
An issue with Qt styling and/or threads?
I have a problem running a Gtk program when using the Qt style as supplied via gtk-qt-engine and kde-config-gtk-style. The program is a fairly heavy duty computation that uses openmp for parallel computation and has a gtk progress monitor (which is updated from within a critical section so it can never be accessed by more than one thread at a time). When the Qt style is selected, the progress bars (gtk_progress_bar) are corrupted and the errors below are displayed repeatedly: (th_run:2015): Gdk-CRITICAL **: gdk_pixmap_foreign_new_for_display: assertion `(anid != 0)' failed (th_run:2015): Gdk-CRITICAL **: gdk_draw_drawable: assertion `GDK_IS_DRAWABLE (src)' failed (th_run:2015): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed QPixmap: It is not safe to use pixmaps outside the GUI thread QPixmap: It is not safe to use pixmaps outside the GUI thread QPainter::begin: Paint device returned engine == 0, type: 2 QPixmap: It is not safe to use pixmaps outside the GUI thread QPainter::end: Painter not active, aborted The problem does not occur with other Gtk style settings (e.g. Nuvola). I'm not sure if the problem is with the Qt wrapper, Gtk+ or my code. FWIW I'm running Debian stable, with Gtk+ 2.20. Any ideas? James ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: how to use hbox?
2011/12/11 Gary Kline kl...@thought.org: can somebody help me figure out how to pack the buttons horizontally, or is is not possible to mix hbox and vbox? It should be as simple as: make the vbox put the various items in it, including the hbox put the increase decrease buttons in the hbox. That certainly works in one of the example codes in gtk-fortran (hl_containers.f90). [An alternative might be to use a 2xn table and make most of the items span 2 columns.] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Alignment of markup labels in menu items
I'm trying to add the capability to add a label formatted with Pango markup to buttons and menu items in the high-level interface to gtk-fortran. While the following is successful in producing subscripts in labels when the markup flag is set, there is a problem with alignment: while a plain text label is correctly centred in the pulldown menu, a markup label begins at the centre (even if it does not actually include any markup). if (markup) then item=gtk_menu_item_new() label_w=gtk_label_new(label) call gtk_label_set_markup(label_w, label) call gtk_container_add(item,label_w) else item = gtk_menu_item_new_with_label(label) end if Am I missing something, or is that a fundamental limitation? I'm using Gtk+-3.2.0, in Ubuntu 11.10, with gcc gfortran 4.6.1. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Alignment of markup labels in menu items
On 30 November 2011 11:31, James Tappin jtap...@gmail.com wrote: there is a problem with alignment: while a plain text label is correctly centred in the pulldown menu, a markup label begins at the centre (even if it does not actually include any markup). I should add, the problem does not manifest itself for simple gtk buttons. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Cairo, Gtk+, Gdk GdkPixbuf -- making a pixel-based backing store for vector graphics
Just to let folks know that the pointers here have given me the lead in that I needed and I've got a working code. (A bit more elegant in the Gtk3 case than Gtk2 but both work). ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Cairo, Gtk+, Gdk GdkPixbuf -- making a pixel-based backing store for vector graphics
I would like to be able to make a code that draws some (possibly very complex) vector graphics, copies it to an off-screen backing store and then when an expose-event (Gtk2) or draw signal (Gtk3) is received, the backing store is copied to the screen rather than doing a complete redraw of all the vectors which could potentially take several seconds. Unfortunately all the potential model codes I've been able to find use the obsolete Gdk Pixmap as backing store. Likewise the routine that looks promising gdk_pixbuf_render_to_drawable () is marked as deprecated (since 2.4) and suggests gdk_draw_pixbuf () as an alternative. However that is also marked deprecated (since 2.22) and recommends gdk_cairo_set_source_pixbuf() and cairo_paint() or cairo_rectangle() and cairo_fill() but it is not at all clear how to combine those routines to produce the required effect. I have searched many times for suitable examples and come up empty. So does anybody here have any suggestions, examples or link that provide pointers to the following operations?: 1) Getting cairo to draw to a pixmap or pixbuf, or draw to a window and then copy the resulting window contents to an in-memory storage. 2) Making the expose handler copy that pixbuf (or whatever) to the visible window (while only copying the affected region would be the best option I can live with copying the whole window). 3) (Less important for now) Adding new material to the plot and updating the backing store -- my guess is that once I crack 1 2 then 3 will be fairly obvious. James ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Cairo, Gtk+, Gdk GdkPixbuf -- making a pixel-based backing store for vector graphics
On 14 June 2011 15:00, Stefan Salewski m...@ssalewski.de wrote: On Tue, 2011-06-14 at 14:30 -0600, James Tappin wrote: I would like to be able to make a code that draws some (possibly very complex) vector graphics, A better place for asking may be the cairo mailing list? At least there was some discussion about such tasks in the past. One recommended way was using cairos create_similar() function for creating the backup surface. I did a small demo in Ruby some time ago, see http://www.ssalewski.de/PetEd-Demo.html.en I found this related thread with some helpful replies: http://lists.freedesktop.org/archives/cairo/2009-March/016756.html It looks as if this example: http://www.gtkforums.com/viewtopic.php?t=5204, may at least provide part of the answer to (1) in my original posting -- I'm still trying to disentangle the housekeeping and the real logic, to figure exactly what it does. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GdkEvent question (is it a bug?)
While working on a script to convert the GdkEvent structures to
Fortran derived types for the GtkFortran project I came across the
following
struct _GdkEventClient
{
GdkEventType type;
GdkWindow *window;
gint8 send_event;
GdkAtom message_type;
gushort data_format;
union {
char b[20];
short s[10];
long l[5];
} data;
};
This looks to me like a 32-bit-specific construct as (a) there's no
int type and (b) on a 64-bit system the long tag in the union will be
twice as long as the short char tags, should this be regarded as a
bug?
Also, since Fortran's iso_c_binding does not have any support for
unions so any attempt to include this will be at best a kludge, is
this an important event ?
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk_tree_view_column query.
Hello, I'm working on some aspects of gtk-fortran (an interface of GTK+ to Fortran95/2003), and so need to implement things without using varargs routines. However I'm getting unexpected behaviours. I don't think the problem is in the Fortran interface as I can reproduce the errors in C-examples. The first is in setting up the column attributes, the original C code was: column = gtk_tree_view_column_new_with_attributes(#, renderer, text, 0, NULL); Which if I interpret the manual correctly ought to be replaceable by: column = gtk_tree_view_column_new(); gtk_tree_view_column_set_title(column, #); gtk_tree_view_column_add_attribute(column, renderer, text, 0); But the latter gives an assertion error: (list1:6044): Gtk-CRITICAL **: gtk_tree_view_column_cell_layout_add_attribute: assertion `info != NULL' failed The second comes when trying to add a value to a column, the original was: gtk_list_store_set(store,iter, 0, nrow, -1); /* The index column */ Which (again if I'm interpreting the manual right) should be equivalent to: gtk_list_store_set_value(store, iter, 0, (Gvalue *) nrow); but instead the latter gives a segfault 0x755effc9 in type_check_is_value_type_U (value=0x7fffdcac) at /build/buildd/glib2.0-2.26.1/gobject/gtype.c:4073 Does anybody see a grave error in interpreting the manual or is there a real problem with some of these routines? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_tree_view_column query.
On 17 March 2011 15:55, James Tappin jtap...@gmail.com wrote: Hello, I'm working on some aspects of gtk-fortran (an interface of GTK+ to Fortran95/2003), and so need to implement things without using varargs routines. However I'm getting unexpected behaviours. I don't think the problem is in the Fortran interface as I can reproduce the errors in C-examples. I should have added: I'm running 64-bit Linux and using gcc ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
