A problem with GtkFileChooserButton (minor correction)
OK, should have noticed that, "file-set" will be in 2.12. Any sane way to emulate it before ? Something simpler than making a "response" callback for dialog of the GtkFileChooserButton, if not, any tips about one ? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
A problem with GtkFileChooserButton
Does GtkFileChooserButton have "file-set" signal or not ? GTK API (on the web) claims it does, but when I try to connect to it, I'm getting GLib-GObject-WARNING **: gsignal.c:1669: signal `file-set' is invalid for instance `0x82ab978' and I'm connecting right after creating it, so I seems it should work. Using Gtk 2.10.9, if it matters. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
A few gtk/glib related questions
What would be the correct way of removing all rows from a text combobox,
as I'm trying not to use a full combobox. Now I'm thinking about
something along the lines of:
i = gtk_tree_model_iter_n_children (gtk_combo_box_get_model(combobox),
NULL);
while (i>0) {i--; gtk_combo_box_remove_text(combobox, i);}
but I want to make sure that's correct.
Next question: when going from GnomeUIInfo to GtkUIManager stock menu
items stay translated, but is there a way to do it for menus (File,
Edit, etc.)?
Finally, what are the important differences between using
AM_GNU_GETTEXT([external]) and AM_GLIB_GNU_GETTEXT ?
And yeah, I still think that having no other way than
gtk_rc_parse_string of forcing combobox to become a list really sucks.
___
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
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
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
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
