Re: A question about deprecated widget
Hi,
A year ago I posted my comments about the GtkComboBox to this list,
this link shows the thread:
http://marc.theaimsgroup.com/?t=11324387691r=1w=2
Still, the GtkComboBox is the biggest problem in my application. I'm
sorry to say, but the combo control is both ugly and clumsy. But as
you can read in the thread, it won't be changed soon if at all because
it's been designed this way to follow Gtk policies and UI
consistency.
Paul Pogonyshev:
Not having such a limit is a conscious decision by GTK+ team. Not a
missed feature.
It IS a missed feature. Because:
1. A too big list overlaps other widgets containing useful
information. Suppose you have a form with lots of labels and entries
like a database frontend. Usually you fill in the fields from top to
bottom. So if the combobox is nearer the bottom of the screen than
top, the popuplist will popup above the gtkcombobox, therefore your
just filled in entries become invisible. This is bad and at the moment
not controllable. Being able to limit the number of rows in the
scrolled popup is useful because now it will be placed below the
gtkcombobox widget itself. Replacing gtkcombobox with a treeview is
often not suitable, see below.
2. It's ugly. This widget crosses the line where visual apealingness
becomes more important than sticking to design philosophies. The fact
that every now and then someone posts a question about setting the
maximum number of rows shows that there clearly is demand for such
features. In addition, apps like gnumeric show they come up with some
alternative selection (like the font selection in gnumeric) where the
natural choice would be GtkComboBox.
3. Gtk+ current behaviour is inconsistent. The fact that
GtkEntryCompletion does not take as much space a possible is in my
opinion contradicting to GtkComboBox. So why doesn't completion take
as much screen space as possible?
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.
The best alternative would be GtkTreeView, but in so many places it
just doesn't fit because it takes too much space, like a fontselection
in a toolbar. So you could make it into a separate window which opens
when you push the selector button (like GtkFontButton). This makes
selection not really economic: first, you have to click selector
button to open the treeview window, then you select, and then yet
another click to close the treeview window. With a proper GtkComboBox
one click could suffice.
And please, stop taking it personally, cause that makes me take it
personally too.
I understand :)
And please don't take my comments personally, I'm not trying to piss
people off or being a pessimist. Gtk+ as it is now is very
good. Having a decent combobox would make it really good for me.
BTW: appears-as-list is a read-only style property but you can force
an individual GtkComboBox to set this property like this:
combo_box=gtk_combo_box_new_text();
gtk_rc_parse_string(style \list-combo-style\ {\n
GtkComboBox::appears-as-list=1}
widget \*.list-combo\ style
\list-combo-style\);
gtk_widget_set_name(combo,list-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
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
