Re: HELP! Widgets drawn in reverse order
Hi! Please check which locale you're using. Gtk+ does automatic changes in packing direction in some cases, like for rtl-locales. The effect in screenshot is a bit weird, though. Does this happen for all gtk+ apps or just for those written using gtkdialog? Br, -Markku- Barry Kauler bkau...@gmail.com wrote: Guys, I sent the following message to the gtk-app-dev mail-list, but the only reply I received was a suggestion that I should ask at the gtk-devel list. Here is my message: I am the founder and current maintainer of Puppy Linux, and I am porting Puppy to run on the ARM architecture. Puppy can be built using binary packages from another distro, and I am currently using the Ubuntu Lucid Lynx arm debs. Success, I have a desktop, the apps work. However, there is one big show-stopper. We use a utility called 'gtkdialog', which is like zenity and yad, for creating GUI windows from shell scripts. Lots of apps in Puppy use gtkdialog. The problem is that gtkdialog renders the widgets in a window in reverse order. That is, a widget that should be bottom-right, draws top-left. These snapshots show the problem: http://bkhome.org/blog/?viewDetailed=02809 This is a generic problem, it happens everytime, for all apps that use gtkdialog. I sent an email to the current maintainer of gtkdialog, but not yet any reply, and there is a note on the project page that development is on hold: http://code.google.com/p/gtkdialog/ However, I am sure that this problem is something that a gtk developer would recognise the solution to immediately. If one of you guys can advise me about this, it will be greatly appreciated! Regards, Barry Kauler http://bkhome.org/blog/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: decrease widget show time
Hi, On Fri, 2011-03-18 at 14:13 +0800, czk wrote: hello everyone, I use gtk+-3.0 in a embedded device. If I create a window put 4 buttons , 4 entrys 3 labels in it, from gtk_window_new to the window was showed spend 4 seconds totally. It a long time for me. Most time spend in gtk_widget_show_all. Less than 1.5 second can acceptable. Any one has ideas? Thanks. Sounds like you're searching the reason from a wrong place. The core Gtk functions like gtk_widget_show_all consume practically no time by themselves (even on embedded device). It's far more likely that you encounter some hidden lazy initialization. For example, on Gtk+2.0 the theme parsing and realization took place when you first time tried to show a toplevel. cheers, -Markku- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: set_resize
Hi, Quoting Pietro Battiston too...@email.it: the documentation for gtk_widget_size_request () says: Also remember that the size request is not necessarily the size a widget will actually be allocated. While there may be a lot of reasons why a widget doesn't get the area requested, I imagine(d) the basic one would be because there is not enough space on the screen for everyone. The most common case when requisition and allocation differ is that a widget gets more space than it requested. This happens easily when widget is packed into container (like GtkVBox/GtkHBox) and is set to expand. Cheers, -Markku- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: set_resize
Hi, 0On Wed, 2009-01-14 at 17:00 +0100, Pietro Battiston wrote: Forcibly clipping window size would anyway only be band-aid to the real problem in the application, which can be: ... - it doesn't constrain the size of a dynamically resizing widget I don't see how this is a problem; instead, it is where my question came from: I had a ScrolledWindow which I wanted to be as big as possible, but not as big as its child if that meant overflowing screen. The problem here is that the application might, for example, display a label with content it reads from somewhere. So, the application doesn't know in advance, how long the text can be. If it's displayed straight away, it can end up containing thousands of characters, which will expand the window very large horizontally. The right approach would be to enable ellipzation (or scrolling), which quarantees that the label will only consume some sane amount of space, no matter how long string it will display. Then the user can resize the window if she wants to see larger piece of ellipsized content. Usually it's better to left sizing of the window to the user. So, you don't need to make your scrolled window as large as possible. The user will make the toplevel window larger if she is interested about the content. But certainly you can provide some initial size for your app. Cheers, -Markku- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Fuse paths with gvfs
Hi list, I'm wondering whether gvfs-fuse-daemon is expected to support multiple mounts from the same server. I have the following kind of situation: sftp://[EMAIL PROTECTED]/some/path sftp://[EMAIL PROTECTED]/some/path When I mount these shares, I end up having: $HOME/.gvfs/sftp on server/ $HOME/.gvfs/sftp on server/ which is certainly not a good thing... Since the username doesn't appear in fuse path, both shares end up having identical paths. Should this kind of use case be OK? If yes, then GIO uri = fuse path mapping needs a fix, if not, then I would expect some kind of error message from some of the components. Cheers, -Markku- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk color API
Hi,
This question belongs to gtk-list (place where you can discuss about
using GTK+ toolkit).
Anyway, please read the documentation about gtk_widget_modify_bg, it
directly answers your question.
-Markku-
On Sat, 2008-03-29 at 03:14 -0500, nisha jain wrote:
Hi All,
I have requirement of making boxes filled with colors without any
functionality.
To acheive this i am using the labels and trying to fill them with
colors
as doing it with other widgets i am not able to figure out...
I am using following code to acheive it but i am not getting any
output...
GtkWidgets *labels[2];
GtkWidget color;
for(i = 0; i2; i++)
{
labels[i] = gtk_label_new();
}
gdk_color_parse(red, color);
gtk_widget_modify_bg(GTK_WIDGET(labels[0]), GTK_STATE_NORMAL,
color);
gdk_color_parse(green, color);
gtk_widget_modify_bg(GTK_WIDGET(labels[1]), GTK_STATE_NORMAL,
color);
I am trying to pack these in a box but that is not working though i
am not getting any errors.
Please let me know if some one has similar functionality in any
application? How i can acheive this?
Regards,
Nisha
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Can I use gtk_widget_unref() to releasetthe object created by gtk_invisible_new()?
Hi,
Answers to your questions:
1) Yes, the GtkInvisible is *not* floating (see the my description
earlier in this thread to find out why). Note that any toplevel
widget (GtkWindow, GtkDialog) is *not floating* either, for the same reason.
2) Yes, you need to use gtk_widget_destroy in this case, not g_object_unref.
(the reason is mentioned earlier in this thread).
The floating references in GTK make the whole reference counting a bit messy.
The following points make life easier:
* Always have a matching g_object_unref for each g_object_ref you have
* Always have a g_object_unref for each function that returns new GObject
that *doesn't use* floating references (GtkTreeModels, GtkSizeGroups)
* When creating new objects that *may be floating* (all GtkWidget based
ones, GtkInvisible being one example), don't try to use g_object_unref
(if not adding extra reference trough g_object_ref earlier). Pack them
to containers and use gtk_widget_destroy when you are done
with them. Usually you need to use g_object_ref/unref with widgets
only if you are implementing a custom container.
Hope this helps,
-Markku-
Lainaus [EMAIL PROTECTED]:
Hi, Markku,
Thanks a lot for your help.
I did some further investigation on this issue. I have two questions on
this issue:
1. The object created by gtk_invisible_new() is not floating.
Here is a snippet from gtk+-2.12.5/tests/testselection.c
init_atoms();
selection_widget = gtk_invisible_new ();
* m = GTK_OBJECT_FLOATING(selection_widget); //***
dialog = gtk_dialog_new ();
gtk_widget_set_name (dialog, Test Input);
The black line (marked with **) is added by me.
When I run testselection, m is set to 0 instead of 1. Which means the
selection_widget is not floating.
right or I used a wrong macro?
2. How to release an object created by gtk_invisible_new()?
Look at following snippets:
void InitWidget() {
mWidget = gtk_invisible_new();
*gtk_object_ref(GTK_OBJECT(mWidget)); //***
gtk_object_sink(GTK_OBJECT(mWidget));
gtk_widget_ensure_style(mWidget);
mStyle = gtk_widget_get_style(mWidget);
}
nsLookAndFeel::~nsLookAndFeel()
{
// gtk_widget_destroy(mWidget);
gtk_widget_unref(mWidget);
}
If I comment out the black line (marked with **), the mWidget
reference count is 1 as expected,
but when unref it in nsLookAndFeel::~nsLookAndFeel, thunderbird will
crash.
It looks like that I can't us gtk_widget_unref() on the object returned
by gkt_invisible_new().
So my question is how to free an object returned by gtk_invisible_new()?
Thanks a lot
Brian
Markku Vire wrote:
Hi,
The reference that is returned by gtk_invisible_new is not owned by the
caller. If one tries to unref it, it's an immediate memory corruption.
When a toplevel widget is concerned, the things go like the following:
* New floating GtkWidget is created (not owned by anyone).
* GTK library takes ownership of the toplevel (calling
g_object_ref_sink). Floating reference is converted to normal one.
* Widget pointer is returned (refcount = 1, owner = gtk).
So, in the code you attached gtk_object_ref increases the reference
count to 2, gtk_object_sink does nothing (since it not floating any
more).
Later gtk_widget_unref decreases refcount back to 1, but there is still
one reference left (owned by gtk). Trying to remove it by g_object_unref
is a bug (as you noticed). The way to ask GTK to release the last
reference is to call gtk_widget_destroy.
If you are just interested about the GtkStyle object, you could try
using gtk_rc_get_style_by_paths for example?
Cheers,
-Markku-
On Fri, 2008-01-11 at 16:53 +0800, Brian Lu wrote:
Thanks a lot for your explanation. But look at following snippet from
firefox latest code base:
void InitWidget() {
mWidget = gtk_invisible_new();
gtk_object_ref(GTK_OBJECT(mWidget));
gtk_object_sink(GTK_OBJECT(mWidget));
gtk_widget_ensure_style(mWidget);
mStyle = gtk_widget_get_style(mWidget);
}
see
http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsLookAndFeel.h#77
and
nsLookAndFeel::~nsLookAndFeel()
{
// gtk_widget_destroy(mWidget);
gtk_widget_unref(mWidget);
}
see
http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsLookAndFeel.cpp#78
I find mWidget is leaked (detected by using libumem.so provided by
solaris).
I don't understand why calling gtk_object_ref() to increase mWidget
reference count.
This causes mWidget's reference count to be 2 and gtk_widget_unref() in
deconstructor decreases it to 1.
Thanks
Brian
Markku Vire wrote:
Hi,
The caller doesn't own the returned reference in case of any gtk_*_new
functions, but the results are floating references (they are removed
once somebody
Re: Can I use gtk_widget_unref() to releasetthe object created by gtk_invisible_new()?
Hi,
The reference that is returned by gtk_invisible_new is not owned by the
caller. If one tries to unref it, it's an immediate memory corruption.
When a toplevel widget is concerned, the things go like the following:
* New floating GtkWidget is created (not owned by anyone).
* GTK library takes ownership of the toplevel (calling
g_object_ref_sink). Floating reference is converted to normal one.
* Widget pointer is returned (refcount = 1, owner = gtk).
So, in the code you attached gtk_object_ref increases the reference
count to 2, gtk_object_sink does nothing (since it not floating any
more).
Later gtk_widget_unref decreases refcount back to 1, but there is still
one reference left (owned by gtk). Trying to remove it by g_object_unref
is a bug (as you noticed). The way to ask GTK to release the last
reference is to call gtk_widget_destroy.
If you are just interested about the GtkStyle object, you could try
using gtk_rc_get_style_by_paths for example?
Cheers,
-Markku-
On Fri, 2008-01-11 at 16:53 +0800, Brian Lu wrote:
Thanks a lot for your explanation. But look at following snippet from
firefox latest code base:
void InitWidget() {
mWidget = gtk_invisible_new();
gtk_object_ref(GTK_OBJECT(mWidget));
gtk_object_sink(GTK_OBJECT(mWidget));
gtk_widget_ensure_style(mWidget);
mStyle = gtk_widget_get_style(mWidget);
}
see
http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsLookAndFeel.h#77
and
nsLookAndFeel::~nsLookAndFeel()
{
// gtk_widget_destroy(mWidget);
gtk_widget_unref(mWidget);
}
see
http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsLookAndFeel.cpp#78
I find mWidget is leaked (detected by using libumem.so provided by solaris).
I don't understand why calling gtk_object_ref() to increase mWidget
reference count.
This causes mWidget's reference count to be 2 and gtk_widget_unref() in
deconstructor decreases it to 1.
Thanks
Brian
Markku Vire wrote:
Hi,
The caller doesn't own the returned reference in case of any gtk_*_new
functions, but the results are floating references (they are removed
once somebody calls gtk_object_sink). This is different from normal
GObjects. So, unreffing the returned value causes practically a double
free.
gtk_widget_destroy in turn runs dispose, ie. asks widget to drop
references to other widgets. Dropping external references usually causes
somebody else to drop the last reference to your widget, so it
efectively gets destroyed. In case of toplevels some global window list
is holding the reference.
Calling gtk_widget_destroy without taking ownership a a widget is
usually a bug that causes a memory leak, but this is not the case here,
since we are talking about a toplevel.
Cheers,
-Markku-
On Wed, 2008-01-09 at 17:39 +0800, Brian Lu wrote:
Hi, experts,
I found following codes will crash in gnome 2.21 environment:
...
GtkWidget *foo = gtk_invisible_new();
gtk_widget_unref(foo);
...
But it works well if gtk_widget_unref() is replaced with
gtk_widget_destroy().
Does that mean that we can't use gtk_widget_unref() on such object and
we can only
use gtk_widget_destroy() to release it?
Thanks
Brian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Can I use gtk_widget_unref() to releasetthe object created by gtk_invisible_new()?
Hi, The caller doesn't own the returned reference in case of any gtk_*_new functions, but the results are floating references (they are removed once somebody calls gtk_object_sink). This is different from normal GObjects. So, unreffing the returned value causes practically a double free. gtk_widget_destroy in turn runs dispose, ie. asks widget to drop references to other widgets. Dropping external references usually causes somebody else to drop the last reference to your widget, so it efectively gets destroyed. In case of toplevels some global window list is holding the reference. Calling gtk_widget_destroy without taking ownership a a widget is usually a bug that causes a memory leak, but this is not the case here, since we are talking about a toplevel. Cheers, -Markku- On Wed, 2008-01-09 at 17:39 +0800, Brian Lu wrote: Hi, experts, I found following codes will crash in gnome 2.21 environment: ... GtkWidget *foo = gtk_invisible_new(); gtk_widget_unref(foo); ... But it works well if gtk_widget_unref() is replaced with gtk_widget_destroy(). Does that mean that we can't use gtk_widget_unref() on such object and we can only use gtk_widget_destroy() to release it? Thanks Brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
Hi, Lainaus Yevgen Muntyan [EMAIL PROTECTED]: [clip] Yes you can set the name after construction. gtk_builder_build_stuff(); widget1 = gtk_builder_lookup (foo); gtk_widget_set_name (widget1, gtk-tooltips); /* oops, forgot to set up widget2 after adding it in glade, since we set all the properties in glade, don't we? */ IMHO, it's silly. I don't think it's a big deal because we won't get to the level of doing everything in glade anyway. Still, it's a weird thing. Anyway, let us stop. People are fine with this, good. No need to tell how to work it around, it's clear how to work it around; and no need to explain how it's wrong to do these nasty things with styles, because it's *not* wrong (it sucks one has to do things like that, indeed). What about the opposite scenario: Application developer wants that some widgets designed by glade need to have their names set, in order to be themed in a special way. If the builder won't set the names, then developer ends up fetching the pointers and set the names by hand... just like in your example. So, I'm asking: Why not include something like set widget name option into glade and xml-file, or separate property for the name to be set?? Those widgets that have this flag set will have gtk_widget_set_name called, other do not (name is just a internal reference, like a variable name in C). By default this would be off (since most widgets are certainly not special ones, you are not calling gtk_widget_set_name for each widget if you write the UI by hand, do you...) -Markku- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
Hi, Perhaps gtk_builder_connect_signals_with_data (or something like that) is the way to go. At least in a case we plan to include the DestroyNotify. Otherwise we could tolerate one extra parameter into connect_signals, right? Putting a DestroyNotify there will create the following (easy) bug scenario: data = g_new(...); ... gtk_builder_connect_signals_with_data(builder, data, g_free); and now the memory is freed once per signal connected... Of course this is a programmers mistake (no proper refcounting), but I think it would be good to place a warning into the documentation? -Markku- Lainaus Johan Dahlin [EMAIL PROTECTED]: Of course one can use connect_full variant to achieve this, but that also means that GModule-related code needs to be written into app. Exactly, I think this use case is valid to avoid duplicating that code. I see two possible solutions; 1) Change gtk_builder_connect_signals () to accept a gpointer to the user data 2) Add a new method which is similar to gtk_builder_connect_signals but accepts user_data and perhaps a GDestroyNotify. Any preference? I'm leaning towards the latter. -- Johan Dahlin [EMAIL PROTECTED] Async Open Source ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuildable type resolver
Hi, I faced similar scenario while writing a tiny gobject code generator. I ended up to use similar techinique than your second alternative. It works nicely in 99% of the cases, but cannot handle cases like: GtkIMContext = gtk_i_m_context_get_type != gtk_im_context_get_type Otherwise this would be a nice way to force everybody to use GObject naming conventions ;) But you had a nice idea described in the bug #172535 (to use separate get_type attribute in the xml). This technique would save the day if the automatic classname = function mapping failed. The bad thing is that somebody still needs to know howto turn GtkIMContext (for example) into gtk_im_context_get_type. UI builders can detect when they cannot find get_type function with expected name, but how they actually form the final result? Perhaps the widget catalog that the UI builders use will contain this information. Just my 2 cents. -Markku- On Mon, 2007-06-04 at 16:04 -0300, Johan Dahlin wrote: One of the problems pointed out by Matthias in the GtkBuilder bug[1] is how a third-party library can define a type name mapping to get type function. First, let me try explain a bit more about the problem; Matthias suggested a couple of alternatives, which you can read in comment 51[2]: - if you play games with __attribute__(constructor), that gets executed before main() - if you try to heuristically guess the mapping from type name to get_type() function name, it is going to fail sometimes - you could try to dump that mapping into some files somewhere in the filesystem and parse those at gtk_init() time - that might be the least evil option I went ahead and implemented the second alternative using g_module_symbol), that code can be found in this patch[3], inside _gtk_resolve_type_lazily. Does anyone have any other suggestions on how to solve the problem, or comments on my solution? [1]: http://bugzilla.gnome.org/show_bug.cgi?id=172535 [2]: http://bugzilla.gnome.org/show_bug.cgi?id=172535#c51 [3]: http://bugzilla.gnome.org/attachment.cgi?id=89349 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: ideas on improving the performance of gtk_tree_view
Hi, Lainaus Federico Mena Quintero [EMAIL PROTECTED]: El jue, 29-03-2007 a las 17:43 +0300, [EMAIL PROTECTED] escribió: Using arrays in GtkTreeDataSortHeader doesn't appear to be optimal, because their length is not constant. We would end up to alloc/dealloc/copy sequence when adding new items. From a quick look at the code, the only place where _gtk_tree_data_list_header_new() gets called is from gtk_list_store_set_n_columns(), which is an internal construct-time function. So the number of headers cannot change. Wouldn't it be possible that calling gtk_tree_sortable_set_sort_func with some strange sort_column_id causes _gtk_tree_data_list_set_header to append new items to header list? At least it contains the code to create new items. However, why this step is needed at all for each comparisison!! It's certainly the case that there will be more sort function calls than changes to sort criteria. This would allow us to cache the pointer to active GtkTreeDataSortHeader directly, providing us constant time O(1) access. Or did I miss something? Oh, you are completely right! You could indeed cache the current header and only refresh it when the sort_column_id changes. Who's got a patch burning a hole in their pocket? :) I made my first try :) There is now a new bug in bugzilla to follow the patches related to this matter: http://bugzilla.gnome.org/show_bug.cgi?id=430095 -Markku- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: ideas on improving the performance of gtk_tree_view
Hi, On Mon, 2007-03-26 at 19:06 -0600, Federico Mena Quintero wrote: I was looking at the GtkTreeView code and it looks like there are other places that could get the array treatment. One place in particular was the sorting machinery... GtkListStore also uses a GList of information for the sort headers, and walks the list in g_list_store_compare_func (!). Using arrays in GtkTreeDataSortHeader doesn't appear to be optimal, because their length is not constant. We would end up to alloc/dealloc/copy sequence when adding new items. They are also accessed according to sort_id (which can come from application program and are not neccesarily contiguous). This means that if we would have an ordered vector we could reach O(log n) search time. Yes, it's better than current O(n) one. However, why this step is needed at all for each comparisison!! It's certainly the case that there will be more sort function calls than changes to sort criteria. This would allow us to cache the pointer to active GtkTreeDataSortHeader directly, providing us constant time O(1) access. Or did I miss something? -Markku- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: ideas on improving the performance of gtk_tree_view
Hi,
Lainaus Federico Mena Quintero [EMAIL PROTECTED]:
Exactly. GtkListStore is implemented as a GSequence (a splay tree),
where each node is one row in the list. Then, the data for the row's
columns is stored in a linked list (GtkTreeDataList). You could
reimplement GtkTreeDataList in terms of an array and get a good speedup
for *all* uses of GtkListStore (i.e. you'd be replacing a dominant
O(n^2) for get/set operations in the list store with a simpler O(log n)
for splay tree lookups, plus the constant time to access a column within
a node).
Using an array instead of a linked list for GtkTreeDataList is a great
idea, and we should definitely review a patch for that :)
I tried this idea and changed the GtkTreeDataList to be an array instead of
linked list (see the attached patch, made against svn head). The original
testcase (5000x50 model) started up faster (but was still slow), but I didn't do
any actual measurements yet (let's see tomorrow ;)
I made the following changes:
* Added dimension/index parameter to many GtkTreeDataList calls (I understood
that this API was OK to be changed). The GtkTreeDataList is now an array of
n elements instead of single list node.
* GtkListStore and GtkTreeStore needed similar patches, including:
Simpler get_value/set_value implementation, because we know that the
datalist will contain n elements and they can be indexed easily.
* Drag'n'drop code now uses simpler _gtk_tree_data_list_copy (I renamed
_gtk_tree_data_list_node_copy, since we now have more than one element).
-Markku-
Index: gtk/gtktreestore.c
===
--- gtk/gtktreestore.c (revision 17562)
+++ gtk/gtktreestore.c (working copy)
@@ -386,8 +386,11 @@
node_free (GNode *node, gpointer data)
{
if (node-data)
-_gtk_tree_data_list_free (node-data, (GType*)data);
- node-data = NULL;
+ {
+GtkTreeStore *store = GTK_TREE_STORE(data);
+_gtk_tree_data_list_free (node-data, store-column_headers, store-n_columns);
+node-data = NULL;
+ }
return FALSE;
}
@@ -398,7 +401,7 @@
GtkTreeStore *tree_store = GTK_TREE_STORE (object);
g_node_traverse (tree_store-root, G_POST_ORDER, G_TRAVERSE_ALL, -1,
- node_free, tree_store-column_headers);
+ node_free, tree_store);
g_node_destroy (tree_store-root);
_gtk_tree_data_list_header_free (tree_store-sort_list);
g_free (tree_store-column_headers);
@@ -557,20 +560,17 @@
{
GtkTreeStore *tree_store = (GtkTreeStore *) tree_model;
GtkTreeDataList *list;
- gint tmp_column = column;
g_return_if_fail (column tree_store-n_columns);
g_return_if_fail (VALID_ITER (iter, tree_store));
list = G_NODE (iter-user_data)-data;
- while (tmp_column-- 0 list)
-list = list-next;
-
if (list)
{
_gtk_tree_data_list_node_to_value (list,
tree_store-column_headers[column],
+ column,
value);
}
else
@@ -719,8 +719,6 @@
gboolean sort)
{
GtkTreeDataList *list;
- GtkTreeDataList *prev;
- gint old_column = column;
GValue real_value = {0, };
gboolean converted = FALSE;
gboolean retval = FALSE;
@@ -748,61 +746,23 @@
converted = TRUE;
}
- prev = list = G_NODE (iter-user_data)-data;
-
- while (list != NULL)
+ list = G_NODE (iter-user_data)-data;
+ if (G_UNLIKELY(list == NULL))
{
- if (column == 0)
- {
+ G_NODE (iter-user_data)-data = list =
+ _gtk_tree_data_list_alloc (tree_store-n_columns);
+}
+
if (converted)
- _gtk_tree_data_list_value_to_node (list, real_value);
+ _gtk_tree_data_list_value_to_node (list, column, real_value);
else
- _gtk_tree_data_list_value_to_node (list, value);
+ _gtk_tree_data_list_value_to_node (list, column, value);
retval = TRUE;
if (converted)
g_value_unset (real_value);
if (sort GTK_TREE_STORE_IS_SORTED (tree_store))
-gtk_tree_store_sort_iter_changed (tree_store, iter, old_column, TRUE);
+gtk_tree_store_sort_iter_changed (tree_store, iter, column, TRUE);
return retval;
- }
-
- column--;
- prev = list;
- list = list-next;
-}
-
- if (G_NODE (iter-user_data)-data == NULL)
-{
- G_NODE (iter-user_data)-data = list = _gtk_tree_data_list_alloc ();
- list-next = NULL;
-}
- else
-{
- list = prev-next = _gtk_tree_data_list_alloc ();
- list-next = NULL;
-}
-
- while (column != 0)
-{
- list-next = _gtk_tree_data_list_alloc ();
- list = list-next;
- list-next = NULL;
- column --;
-}
-
- if (converted)
-_gtk_tree_data_list_value_to_node (list, real_value);
- else
-_gtk_tree_data_list_value_to_node (list, value);
-
- retval = TRUE;
- if (converted)
-g_value_unset (real_value);
-
- if (sort GTK_TREE_STORE_IS_SORTED (tree_store))
-gtk_tree_store_sort_iter_changed (tree_store, iter, old_column, TRUE);
-
- return retval;
}
/**
@@
Re: Some wxpython questions about gtk wxPython Unicode 2.8.1.1
Hi,
Almost all public gtk+ functions use g_return_if_fail -family of macros
to validate preconditions when an API function is called. This could
look like the following:
gpointer foo(gpointer a)
{
g_return_val_if_fail(a != NULL, NULL);
... Do some real stuff here
}
So, this checks that the programmer has not made a mistake and calls the
function with invalid parameters (This is not meant to be input
validation, but a logic validation).
If this function is then called with an invalid value, like
a = NULL;
b = foo(a);
This causes something like this to appear into console:
CRITICAL **: foo: assertion `a != NULL' failed
And function returns NULL. This doesn't crash your program, though.
The crash may take place if the application doesn't take into account
that the function can return NULL (for example). In our previous case,
the following would crash:
a = NULL;
b = foo(a);
*b = ;
This causes NULL-pointer reference, which leads to segfault.
To put it short, if you see the criticals about failed assertions, your
program is suffering a bug at program logic somewhere. It may be that
the problem is somewhere int the Python bindings of gtk.
-Markku-
On Tue, 2007-02-06 at 10:21 +0100, Franz Steinhaeusler wrote:
Hello List/Group,
Sorry for crossposting, but I think the chances are higher to get an answer.
I also already asked in other forums/groups, but here are the experts,
and I want to get so much information as possible. :)
Problem is:
I have wxPython 2.8.1.1 Unicode on Ubuntu (6.10) Linux, and the same program
runs flawlessly on Windows, but not on Linux
1) If a Segmentation fault (core dumped) happend, it is a crash, isn't it?
So after that assertions, a segmentation fault follows.
** (python:12488): CRITICAL **: gail_menu_item_ref_child: assertion `(i
= 0)' failed
Segmentation fault (core dumped)
** (python:12542): CRITICAL **: gail_menu_item_ref_child: assertion `(i
= 0)' failed
Segmentation fault (core dumped)
a) How can I trace back, what a segmentation fault caused?
b) What does that mean (gail_menu_item_ref_child: assertion `(i = 0)'
failed)?
c) What is the best way to debug or isolate this to a certatin piece of
code this?
2) (python:4848): Gtk-CRITICAL **: gtk_window_realize_icon: assertion
`info-icon_pixmap == NULL' failed
What does that mean?
3) After startup, the message: GTK Accessibility Module initialized
appears.
Is this message necessary?
Many thanks in advance!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
