Re: Proper way to show unique icon in treeview --with code
On Sun, Dec 17, 2006 at 11:06:14PM -0500, Tony Freeman wrote:
a What am I doing wrong?
g_object_set(icon_renderer, stock-id, gtk-close, NULL);
...
g_object_set(icon_renderer, stock-id, gtk-save, NULL);
...
g_object_set(icon_renderer, stock-id, gtk-open, NULL);
So while the model is constructed, some random renderer's
stock-id property is set to various things, at the end to
gtk-open stock icon. And it remains so. Then this
renderer is used for rendering some view which accidentally
displays the model. Therefore when the icons are actually
rendered it always renders gtk-open icon.
What happens to some renderer duing the tree model
construction is absolutely irrelevant, there is no
connection between these two: the tree view may not exist at
that time at all, the model data can be shown by a thousand of
different renderes later... Your code is exactly equivalent
to
liststore = gtk_list_store_new(2, GDK_TYPE_PIXBUF, G_TYPE_STRING);
/* workstations */
count = g_strv_length(workstations);
for (i=0; icount; i++) {
gtk_list_store_append(liststore, iter);
gtk_list_store_set(liststore, iter,
0, icon_renderer,
1, workstations[i], -1);
}
/* linux servers */
count = g_strv_length(servers_linux);
for (i=0; icount; i++) {
gtk_list_store_append(liststore, iter);
gtk_list_store_set(liststore, iter,
0, icon_renderer,
1, servers_linux[i], -1);
}
/* hp servers */
count = g_strv_length(servers_hp);
for (i=0; icount; i++) {
gtk_list_store_append(liststore, iter);
gtk_list_store_set(liststore, iter,
0, icon_renderer,
1, servers_hp[i], -1);
}
icon_renderer = gtk_cell_renderer_pixbuf_new();
gtk_tree_view_insert_column_with_attributes (GTK_TREE_VIEW(treeview),
0,
,
icon_renderer,
NULL);
g_object_set(icon_renderer, stock-id, gtk-close, NULL);
g_object_set(icon_renderer, stock-id, gtk-save, NULL);
g_object_set(icon_renderer, stock-id, gtk-open, NULL);
text_renderer = gtk_cell_renderer_text_new();
gtk_tree_view_insert_column_with_attributes (GTK_TREE_VIEW(treeview),
1,
,
text_renderer,
NULL);
(In fact, this is the order on would normally write it.)
Only the properties of the renderer *when a cell is being
rendered* matter. So you either have to actually store the
icons to the now useless GDK_TYPE_PIXBUF column and map
column 0 to the pixbuf property with
gtk_tree_view_insert_column_with_attributes(), or change it
to a G_TYPE_STRING column, store the stock ids to this
column and map it to the stock-id property (or use a cell
data func, or just anything that sets the properties when
they are actually used).
Yeti
--
Whatever.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Proper way to show unique icon in treeview --with code
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Dec 17, 2006 at 11:06:14PM -0500, Tony Freeman wrote:
Hello,
[...]
void build_server_list (GtkWidget *treeview)
{
GtkListStore *liststore;
GtkTreeIter iter;
GtkCellRenderer *text_renderer;
GtkCellRenderer *icon_renderer;
gint i = 0;
gint count = 0;
icon_renderer = gtk_cell_renderer_pixbuf_new();
gtk_tree_view_insert_column_with_attributes (GTK_TREE_VIEW(treeview),
0,
,
icon_renderer,
NULL);
text_renderer = gtk_cell_renderer_text_new();
gtk_tree_view_insert_column_with_attributes (GTK_TREE_VIEW(treeview),
1,
,
text_renderer,
NULL);
liststore = gtk_list_store_new(2, GDK_TYPE_PIXBUF, G_TYPE_STRING);
/* workstations */
count = g_strv_length(workstations);
g_object_set(icon_renderer, stock-id, gtk-close, NULL);
for (i=0; icount; i++) {
gtk_list_store_append(liststore, iter);
gtk_list_store_set(liststore, iter,
0, icon_renderer,
^
So the icon slot of each row in the store points to the same icon
renderer. Hm. I don't have the ref ready (I'd expect an image to go
here, not a renderer), but it's no surprise that the image in each row
is equal. You'd have to put a different image in each row's image slot.
Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFFhlkJBcgs9XrR2kYRAlrHAJsFB6HUMXA3GFIBLXXR8bCQwk126ACfUaxZ
MzBdhBoejyd/8bqr4nabwjU=
=Xtxq
-END PGP SIGNATURE-
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory Issue
On Mon, Dec 18, 2006 at 10:02:52AM +0530, Preeti Joshi wrote: I am attaching a small piece of sample code that explains my problem. The sample code is not compilable, not speaking about runnable -- where's the stuff lookup_widget() acts on? The above code creates a main window and from button1 click creates a message box . On closing this message box , memory allocated to message box should have been freed. However gnome-system-monitor shows the following stats: when main window is displayed: 3.5 MB when message box is also displayed: 3.9 MB message box closed: 3.9 MB main window closed through 'X' button: 3.9 MB So I will just comment on this: Does the memory use increase when you repeat this 10 times? If it does, then it's really a leak. Yeti -- Whatever. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Change GtkTreeViewColumn header background color
There is an easy way to do it, a rc option would be very nice but I've not found it! Adding a custom object as column header is not ok, since you get your background only under the label (the border and the arrow keep the old background). Lurking in the sources I've found this way, but it's way too implementation dependant: GtkWidget *l = gtk_label_new(title.c_str()); gtk_widget_show(l); gtk_tree_view_column_set_widget(col, l); GtkWidget *w = gtk_tree_view_column_get_widget(col); // From the sources this is the object hiearchy: // get_widget object - alignment - hbox - button GtkWidget *b = w-parent-parent-parent; GdkColor bg; gdk_color_parse(#b8b8b8, bg); gtk_widget_modify_bg(b, GTK_STATE_NORMAL, bg); -- Bye, Gabry ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Debugging application
Hello list! I'm developing a gtk application. The point is that I see in Gnome System Monitor that my application (a loop that continuously read a file and update data in the window) is eating more memory as it is executing... There are no problems (no errors or warnings) during compilation and valgrind, with: -v --leak-check=full doesn't show any problems of my code. However, it seems to be some problems with other code (like CORBA and more...). The fact is that my application grows (slowly) as Gnome System Monitor says: it starts with 4.6 MB and it reaches 5.6 after more than an hour... The point is that if I look at the gnome-system-monitor process in itself, this program also grows from 5.2 to 6.4... Is this normal? Is this related to the GSlice allocator or something similar? Should I be worried about memory leaks in my application? If I should... since valgrind doesn't show any errors, which tool should I use? Thanks in advance. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory Issue
On Mon, 18 Dec 2006, Preeti Joshi wrote: I am attaching a small piece of sample code that explains my problem... The code you posted is broken. The functions create_window1() and lookup_window() are not defined. I guess the call to lookup_window() can just be deleted, but it looks as if create_window1() is needed. The code is so convoluted it's hard to see how to fix it. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GStrings and sorting GLists
It doesnt matter. As I moved on to widgets it seems they couldnt cope with a GList of GStrings anyway : so its back to normal g_string/gchar* stuff. Cuts out the hassle of using (GString *)-str anyway. David Nečas (Yeti)-2 wrote: On Sun, Dec 17, 2006 at 04:00:42AM +0100, Hadron Quark wrote: Are there no comparison operations other than g_string_equal in order to facilitate the sorting of GList objects that contain GStrings? I'm not sure how g_string_equal() facilitates sorting when it returns only TRUE/FALSE for equality, but any C string comparison function is usable on gstring-str. Yes, you have to write the one-line wrapper yourself. Yeti -- Whatever. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- View this message in context: http://www.nabble.com/GStrings-and-sorting-GLists-tf2835397.html#a7922139 Sent from the Gtk+ - Apps Dev mailing list archive at Nabble.com. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Debugging application
On 12/18/06, Fernando Apesteguía [EMAIL PROTECTED] wrote: Hello list! I'm developing a gtk application. The point is that I see in Gnome System Monitor that my application (a loop that continuously read a file and update data in the window) is eating more memory as it is executing... There are no problems (no errors or warnings) during compilation and valgrind, with: -v --leak-check=full doesn't show any problems of my code. However, it seems to be some problems with other code (like CORBA and more...). The fact is that my application grows (slowly) as Gnome System Monitor says: it starts with 4.6 MB and it reaches 5.6 after more than an hour... The point is that if I look at the gnome-system-monitor process in itself, this program also grows from 5.2 to 6.4... Is this normal? Is this related to the GSlice allocator or something similar? Should I be worried about memory leaks in my application? If I should... since valgrind doesn't show any errors, which tool should I use? OK, after the application reached 7.3 MB it went down (according to gnome-system-monitor) to 6.4 again... Any clues? Thanks in advance. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Debugging application
On 12/18/06, Fernando Apesteguía [EMAIL PROTECTED] wrote: executing... There are no problems (no errors or warnings) during compilation and valgrind, with: -v --leak-check=full doesn't show any problems of my code. OK, after the application reached 7.3 MB it went down (according to gnome-system-monitor) to 6.4 again... Any clues? I wouldn't worry about it. It's normal to see memory use going up and down a bit (RSS, anyway, which is the one that matters (usually)). If valgrind says you are OK, you are probably OK. Plus leaks generally run out of control rather quickly and you are only observing rather small changes in mem use. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory Issue
On Mon, 18 Dec 2006, Preeti Joshi wrote: The above code creates a main window and from button1 click creates a message box . On closing this message box , memory allocated to message box should have been freed. However gnome-system-monitor shows the following stats: when main window is displayed: 3.5 MB when message box is also displayed: 3.9 MB message box closed: 3.9 MB main window closed through 'X' button: 3.9 MB You don't have any call to gtk_main_quit() in your program, so closing the main window will not free the basic gtk/gnome memory allocation. Besides that, gnome-system-monitor is not a leak checker. If you saw the memory usage increasing every time you opened and closed the message box, that would indeed suggest a leak. But what you're describing above is normal behaviour. When a program calls free(), that action in principle makes the previously claimed dynamic memory available to the operating system. But the operating system need not reclaim it. The OS may leave the memory in question lying around for possible future use by the same program. This increases efficiency. For example, when you open the dialog a second time, the OS doesn't have to find the extra memory needed, it's still allocated to your program. People sometimes seem to think that good memory management means having as much free RAM as possible available at any given moment. But if you think about it, that makes no sense. Memory is there to be used. It's more efficient (if you're not about to run out of RAM) to keep previous memory allocations cached. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Debugging application
Be aware that glib has it's own allocation and deallocation functions which may keep destroyed widgets or other data structures around in a memory pool, so the OS may think your program is using memory but it's just glib's memory pool. That memory would still be still is use (has references to it) from the perspective of valgrind as well. Reed ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Scrolled Window With TreeView in it
Hello everyone, I have a GtkTreeView packed inside a GtkScrolledWindow. The GtkScrolledWindow is packed inside a GtkVBox and I want that whenever the windows' size changes the GtkScrolledWindow fills the unused space. I've have two dialogs created in the same way, one works, the other doesn't. Here is the code: /* GtkTreeModel GtkTreeView */ contactbox-treeview = do_contact_treeview (); /* TreeView's Scrolled Window */ contactbox-sw = gtk_scrolled_window_new (NULL, NULL); gtk_scrolled_window_set_shadow_type (GTK_SCROLLED_WINDOW (contactbox-sw), GTK_SHADOW_ETCHED_IN); gtk_scrolled_window_set_policy (GTK_SCROLLED_WINDOW (contactbox-sw), GTK_POLICY_AUTOMATIC, GTK_POLICY_AUTOMATIC); gtk_container_add (GTK_CONTAINER (contactbox-sw), contactbox-treeview); gtk_box_pack_start (GTK_BOX (contactbox), contactbox-sw, TRUE, TRUE, 6); This is how i pack the other widgets of the dialog: Initialization of the class: /* Initialize contact box init */ gtk_box_set_homogeneous (GTK_BOX (contactbox), FALSE); gtk_box_set_spacing (GTK_BOX (contactbox), 6); /* Packing of its widgets */ gtk_box_pack_start (GTK_BOX (contactbox), hbox, FALSE, FALSE, 0); gtk_box_pack_start (GTK_BOX (contactbox), contactbox-search_button, FALSE, FALSE, 0); gtk_box_pack_start (GTK_BOX (contactbox), contactbox-sw, TRUE, TRUE, 6); gtk_box_pack_start (GTK_BOX (contactbox), buttonbox, FALSE, FALSE, 6); gtk_box_pack_start (GTK_BOX (contactbox), label, FALSE, FALSE, 6); gtk_box_pack_start (GTK_BOX (contactbox), table, FALSE, FALSE, 6 ); As you can see the only widget which should expand is the scrolled window but for some reason, it doesn't. Thanks in advance, Matias. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RadioButton question
How do you determine which radio button is selected? I would think that there would be a procedure like gtk_radio_button_group_get_selected(), but I don't see one. So, if you know I would appreciate some help. Thanks in advance, Steve Boyls ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
A question about deprecated widget
As API reference states and both FAQ and tutorial on gtk.org have yet to notice, GTK_COMBO has been deprecated for some time. There's of course advice about GTK_COMBO_BOX, but that's not what I have in mind. As such I've got following questions: 1. One of the parts of GTK_COMBO seemed to be a scrolled window, what would be the simplest combination of widgets to have similar look-and-feel, cause GTK_COMBO_BOX with longer lists is simply ugly. 2. As GTK_COMBO_BOX uses GTK_LIST_STORE, what would be the most efficient way to transform a GList or char** to such thing. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: RadioButton question
On Mon, Dec 18, 2006 at 11:48:13AM -0600, Steven Boyls wrote: How do you determine which radio button is selected? 1. By knowing the initial state, connecting to button signals and updating the state immediately so that it never gets out of sync. If you respond to the selection immediately somehow, you have to do this anyway. 2a. By iterating over the buttons checing the state. 2b. With some convenience functions you wrote for your common use cases such as http://gwyddion.svn.sourceforge.net/viewvc/gwyddion/trunk/gwyddion/libgwydgets/gwyradiobuttons.c?view=markup because who cares about the widgets anyway? The widgets just represent some choices and you want to say `select option Foo' or `which option is selected?', this is what you mean, not `select this button widget', this is just the mechanism. Yeti -- Whatever. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A question about deprecated widget
On Mon, Dec 18, 2006 at 07:33:34PM +0100, [EMAIL PROTECTED] wrote: 1. One of the parts of GTK_COMBO seemed to be a scrolled window, what would be the simplest combination of widgets to have similar look-and-feel, cause GTK_COMBO_BOX with longer lists is simply ugly. This is a matter of Gtk+ theme. Try setting appears-as-list style property of GtkComboBox to 1 in your gtkrc-2.0. 2. As GTK_COMBO_BOX uses GTK_LIST_STORE, what would be the most efficient way to transform a GList or char** to such thing. Use gtk_combo_box_new_text() to create a simple text-only combo and fill it with the strings. Then throw away the GList or array. Yeti -- Whatever. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A question about deprecated widget
David Nečas (Yeti) napisał(a): On Mon, Dec 18, 2006 at 07:33:34PM +0100, [EMAIL PROTECTED] wrote: 1. One of the parts of GTK_COMBO seemed to be a scrolled window, what would be the simplest combination of widgets to have similar look-and-feel, cause GTK_COMBO_BOX with longer lists is simply ugly. This is a matter of Gtk+ theme. Try setting appears-as-list style property of GtkComboBox to 1 in your gtkrc-2.0. 2. As GTK_COMBO_BOX uses GTK_LIST_STORE, what would be the most efficient way to transform a GList or char** to such thing. Use gtk_combo_box_new_text() to create a simple text-only combo and fill it with the strings. Then throw away the GList or array. You got it all wrong. As appears-as-list is a style property, it's read-only, so it would be pointless for me. The effect I'm looking for is a non-depreciated widget combination that would look and act like GTK_COMBO did, I mean a scrolled window and all, preferably one with number of rows set by me. As it goes for the second point, glist (char**) is a result of calling a function from a separate library, so I'm interested in a way of converting it back and forth in an efficient way. While GTK_COMBO to GTK_COMBO_BOX transition was what triggered the need for it, gtk_combo_box_new_text is a non-solution, cause I will be changing that list, looking up values it contains, etc., so I need a method of displaying it and certain usability issues, force something that should look and act like GTK_COMBO. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A question about deprecated widget
[EMAIL PROTECTED] wrote: The effect I'm looking for is a non-depreciated widget combination that would look and act like GTK_COMBO did, I mean a scrolled window and all, preferably one with number of rows set by me. I agree. This would be much appreciated. The same goes for the popup done by GtkEntryCompletion, which also has no configurable maximum amount of rows. I guess patches that fix these issues would be gladly accepted. I ended up using GtkCombo in some of my projects, although I'm very aware of its status... I just hope it doesn't go away soon :/ Regards, :M: -- Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A question about deprecated widget
Michael 'Mickey' Lauer wrote: [EMAIL PROTECTED] wrote: The effect I'm looking for is a non-depreciated widget combination that would look and act like GTK_COMBO did, I mean a scrolled window and all, preferably one with number of rows set by me. I agree. This would be much appreciated. The same goes for the popup done by GtkEntryCompletion, which also has no configurable maximum amount of rows. I guess patches that fix these issues would be gladly accepted. Not having such a limit is a conscious decision by GTK+ team. Not a missed feature. Paul ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A question about deprecated widget
Paul Pogonyshev napisał(a): Not having such a limit is a conscious decision by GTK+ team. Not a missed feature. Actually, that feature is not that important to me, the important part is that scrolled window, instead of that long ugly thing that a really long list turns GTK_COMBO_BOX into. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A question about deprecated widget
Paul Pogonyshev wrote: Michael 'Mickey' Lauer wrote: [EMAIL PROTECTED] wrote: The effect I'm looking for is a non-depreciated widget combination that would look and act like GTK_COMBO did, I mean a scrolled window and all, preferably one with number of rows set by me. I agree. This would be much appreciated. The same goes for the popup done by GtkEntryCompletion, which also has no configurable maximum amount of rows. I guess patches that fix these issues would be gladly accepted. Not having such a limit is a conscious decision by GTK+ team. Not a missed feature. Is that so? Feel free to elaborate... Where is the sanity in having a fullscreen completion popup window hiding important controls on the screen? Regards, :M: -- Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A question about deprecated widget
On Mon, Dec 18, 2006 at 09:58:35PM +0100, [EMAIL PROTECTED] wrote:
You got it all wrong.
Thank you. I wish people told me this more often. Really.
Preferably when I get it all wrong, but one takes what one
can get.
As appears-as-list is a style property, it's read-only, so it would be
pointless for me.
The funny thing is that setting style properties is not only
possible but also discussed here often. But maybe I just
got it all wrong again.
The effect I'm looking for is a non-depreciated widget
combination that would look and act like GTK_COMBO did, I mean a
scrolled window and all,
You set appears-as-list in your gtkrc. Everyone who wants
the list-like look sets appears-as-list in their gtkrc.
Everyone who does *not* like the list look will unset it.
And everyone will live happily ever after -- or at least
until people who like a particular look and feel learn how
to change style properties in their apps and start enforcing
their preferences on users.
As it goes for the second point, glist (char**) is a result of calling a
function from a separate library, so I'm interested in a way of
converting it back and forth in an efficient way.
void
gtk_combo_set_popdown_strings (GtkCombo *combo,
GList*strings)
{
GList *list;
GtkWidget *li;
g_return_if_fail (GTK_IS_COMBO (combo));
gtk_combo_popdown_list (combo);
gtk_list_clear_items (GTK_LIST (combo-list), 0, -1);
list = strings;
while (list)
{
li = gtk_list_item_new_with_label ((gchar *) list-data);
gtk_widget_show (li);
gtk_container_add (GTK_CONTAINER (combo-list), li);
list = list-next;
}
}
The code speaks for itself. I suggest to read the source
code, including all the pango stuff, and count how many
times the string is copied before it's finally rendered (and
all the other bizarre shows that take place along the way).
Then think about the efficiency of copying of a handful of
strings again.
Of course it is possible to use static arrays as tree view/
icon view/combo box backends with with a simple wrapper
model that does not allocate any data itself, but the reason
for doing this is convenience not efficiency.
While GTK_COMBO to
GTK_COMBO_BOX transition was what triggered the need for it,
You evidently disagree with other design decisions, so what
prevents you from disagreeing GtkCombo should not be used in
newly written code? Does it do what you want? Certainly.
Is it going to disappear? Definitely not sooner than in 3.0.
In addition, you seem to be rewritting code in the name of
some transition which is a questionable goal of itself.
Yeti
--
Whatever.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A question about deprecated widget
Actually, that feature is not that important to me, the important part is that scrolled window, instead of that long ugly thing that a really long list turns GTK_COMBO_BOX into. I agree that the combo box does look ugly when there are too many elements, but the solution, to me, seems to be to use a different type of control instead. It's quite painful for a user to choose one of hundreds of items from a list, and when that list is transient, it's even worse. I'd say a GtkTreeView would be a better choice of widget for such an application. Just my 2c. -Jim ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A question about deprecated widget
Jim George napisał(a): Actually, that feature is not that important to me, the important part is that scrolled window, instead of that long ugly thing that a really long list turns GTK_COMBO_BOX into. I agree that the combo box does look ugly when there are too many elements, but the solution, to me, seems to be to use a different type of control instead. It's quite painful for a user to choose one of hundreds of items from a list, and when that list is transient, it's even worse. I'd say a GtkTreeView would be a better choice of widget for such an application. Just my 2c. I'm not opposed to GtkTreeView, however what I want to have is a widget that displays a list only durring selection and (sometimes) has a single editable entry field, visible all of the time, just like GtkCombo did. As for the other reply: 1. I'm a bit new to the list and most of my gtk knowledge comes either from API reference which is a bit vague on style properties (or at least I missed the part where it was explained) or from playing with sources of various programs, most of them containing standard amount of comments - nearly none. 2. I'm geting a glist/char**, I want to be able to search it, sort it, remove items I found, change their position, well actually most of it is for a history list combined with an entry field, if entered item is on the list, it should be removed from old position and prepended, but in a diffrent app I'm simply getting a list of strings, I want to change their order, but it's riddiculously long, so there's neither point nor possibility of displaying all of them. And please, stop taking it personally, cause that makes me take it personally too. As for the last remark - my goals are mine to choose and only person with the right to question them is myself. One more thing, by mistake I sent this message at first only to last poster instead to this list. Sorry for that. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GLib 2.12.5 released
GLib 2.12.5 is now available for download at: ftp://ftp.gtk.org/pub/glib/2.12/ http://download.gnome.org/sources/glib/2.12/ glib-2.12.5.tar.bz2 md5sum: 08f51fd565805289879819964bb8192b glib-2.12.5.tar.gzmd5sum: 058d86472a73b5d53a7c6173be258a93 GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.12.4 to GLib 2.12.5 === * Various portability fixes * Bugs fixed 302672 poll is completely broken on Mac OS X 10.4 362328 errorcheck_mutex_test fails to compile due to missing -pthread 316434 glib-2.6.6 fails to compile on AIX 5.1 due to assembler errors 172406 gconvert.c, function open_converter 327800 Hang during self-test of threads 343825 Double expansion in m4macros/glib-gettext.m4 will fail with newer autoconf 380801 build on Solaris does not work out of the box 386252 HEAD broken with last commit 138153 g_utf8_next_char problem with gcc -Wcast-qual 161288 glib doesn't configure well on Mac OS 10.3 321977 GIOChannel ref_count private variable should be gint instead of guint 343191 GKeyFile silently loses values 346373 test failures in glib-2.10.3 on NetBSD 347944 make check fails 2 test on Solaris 9 355955 Hash tables in gwin32.c do not g_strdup their keys 357585 Calls to set_cloexec inefficient on Solaris 359190 gtimer.c failes to compile on solaris-2.9 378078 extremely unlikely read-after-free in instance_real_class_get 379207 gthreadpool.h causes warning with GCC and -Wshadow 385132 solaris gettext support fix 385910 Suprising behaviour with duplicate groups in GKeyFile 386838 mapping-test freezes 315061 compiler specific flag in gthread-2.0.pc 362543 Compilation fail when configured with --disable-visibility 362918 monotonic clock test uses AC_TRY_RUN 369908 g_key_file_get_string not stripping final space 373864 sanity_check is a bash script * Translation updates (ar,en_CA,es,he,nb,pl,sq) A list of all bugs fixed in this release can be found at http://bugzilla.gnome.org/buglist.cgi?bug_id=359190,355955,347944,362328,362543,373864,343825,138153,316434,302672,385132,385910,172406,357585,386252,327800,315061,321977,362918,386838,380801,379207,346373,343191,161288,378078,369908 Thanks to all contributors: Andreas Köhler, Tor Lillqvist, Dan McMahill, Javier Villavicencio, Sebastian Wilhelmi, Peter Kjellerstedt, Behdad Esfahbod, James Henstridge, Nikolai Weibull, Hans Rosenfeld, Toby Peterson, Dave Vasilevsky, Laszlo Peter, Joe Halliwell, Morten Welinder, Padraig O'Briain, Guillaume Desmottes, Andrew Paprocki, Han-Wen Nienhuys, Jeremy Lainé, Marco Barisione, Marek Rouchal, Christian Biere, Thomas Klausner, Tommi Komulainen, Jonathan Matthew, Tapani Pälli Matthias Clasen December 18, 2006 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Tooltip to Clist elements
Hi, Is it possible to add tooltip to individual CList rows created dynamically through programming? Regards, Preeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Proper way to show unique icon in treeview -- FIXED :-)
Hello,
I need help understanding how one would create a treeview so that the
first column is an icon and the second column is text. The icon and
text represent the type of machine the user can choose (linux
workstation, linux server, hp). I want to have a different icon for
each machine; however, I notice that whatever icon is called last in the
code that I have written, is the icon that is shown for ALL the rows.
Please help! What am I doing wrong?
I forgot to attach the code!
Here it is:
void build_server_list (GtkWidget *treeview)
{
GtkListStore *liststore;
GtkTreeIter iter;
GtkCellRenderer *text_renderer;
GtkCellRenderer *icon_renderer;
gint i = 0;
gint count = 0;
icon_renderer = gtk_cell_renderer_pixbuf_new();
gtk_tree_view_insert_column_with_attributes (GTK_TREE_VIEW(treeview),
0,
,
icon_renderer,
NULL);
text_renderer = gtk_cell_renderer_text_new();
gtk_tree_view_insert_column_with_attributes (GTK_TREE_VIEW(treeview),
1,
,
text_renderer,
NULL);
liststore = gtk_list_store_new(2, GDK_TYPE_PIXBUF, G_TYPE_STRING);
/* workstations */
count = g_strv_length(workstations);
g_object_set(icon_renderer, stock-id, gtk-close, NULL);
for (i=0; icount; i++) {
gtk_list_store_append(liststore, iter);
gtk_list_store_set(liststore, iter,
0, icon_renderer,
1, workstations[i], -1);
}
/* linux servers */
count = g_strv_length(servers_linux);
g_object_set(icon_renderer, stock-id, gtk-save, NULL);
for (i=0; icount; i++) {
gtk_list_store_append(liststore, iter);
gtk_list_store_set(liststore, iter,
0, icon_renderer,
1, servers_linux[i], -1);
}
/* hp servers */
count = g_strv_length(servers_hp);
g_object_set(icon_renderer, stock-id, gtk-open, NULL);
for (i=0; icount; i++) {
gtk_list_store_append(liststore, iter);
gtk_list_store_set(liststore, iter,
0, icon_renderer,
1, servers_hp[i], -1);
}
gtk_tree_view_set_model(GTK_TREE_VIEW(treeview),
GTK_TREE_MODEL(liststore));
}
Thanks to all who replied with comments.
Here is the working function:
void build_server_list (GtkWidget *treeview)
{
GtkListStore *liststore;
GtkTreeIter iter;
GtkCellRenderer *text_renderer = gtk_cell_renderer_text_new();
GtkCellRenderer *pixbuf_renderer = gtk_cell_renderer_pixbuf_new();
GdkPixbuf *ws_pixbuf, *sv_pixbuf, *hp_pixbuf;
GtkTreeViewColumn *pixbuf_column, *text_column;
gint i = 0;
gint count = 0;
/* CREATE THE LISTSTORE MODEL */
liststore = gtk_list_store_new(2, GDK_TYPE_PIXBUF, G_TYPE_STRING);
/* ATTACHED THE LISTSTORE MODEL TO THE TREEVIEW */
gtk_tree_view_set_model(GTK_TREE_VIEW(treeview),
GTK_TREE_MODEL(liststore));
/* DESCRIBE EACH COLUMN */
pixbuf_column = gtk_tree_view_column_new_with_attributes (
Icon,
pixbuf_renderer,
pixbuf, 0,
NULL);
gtk_tree_view_append_column (GTK_TREE_VIEW(treeview), pixbuf_column);
text_column = gtk_tree_view_column_new_with_attributes (
Machine,
text_renderer,
text, 1,
NULL);
gtk_tree_view_append_column (GTK_TREE_VIEW(treeview), text_column);
/* GET SOME STOCK ICONS */
/* getting a 'pixbuf' icon is the key here */
ws_pixbuf = gtk_widget_render_icon(treeview, GTK_STOCK_ABOUT,
GTK_ICON_SIZE_SMALL_TOOLBAR, NULL);
sv_pixbuf = gtk_widget_render_icon(treeview, GTK_STOCK_HARDDISK,
GTK_ICON_SIZE_SMALL_TOOLBAR, NULL);
hp_pixbuf = gtk_widget_render_icon(treeview, GTK_STOCK_NETWORK,
GTK_ICON_SIZE_SMALL_TOOLBAR, NULL);
/* FILL LISTSTORE MODEL WITH DATA */
/* workstations */
count =
