Re: combo rant
control H wrote: Well, I must admit that I haven't used Windows more than occasionaly for the last three or four years, but the last time I checked, Windows combo box was much _worse_ than GTK+'s, in my opinion. You would often get a five-line combo where you'd have to scroll like hell to skip all those 200 items to get to the one you want. Ok it certainly sucks when you have to scroll those 200 items within a five-line combo. But that's part of the programmers job I think. At least you are able to force a five-line combo on Windows! And that's what I miss. A function where you can scale such things, as I stated in my original email. In other words, you miss function(s) to make the UI suck to users? The problem with such functions is that many programmers are not just happy about their existence but unhesitatingly (mis)use them to create UIs that suck, indeed. The pretty common 500-items-3-lines combobox in Windows is a good example for this. While the programmer may be happy for having achieved exactly what he wanted to, the users of those applications have to suffer from such mislead efforts. I am personally happy that GTK+ tries to make it significantly harder for programmers to reduce usability of applications / GUIs in ways which are rather common on i.e. native Windows applications. Due to its open source nature and extensibility nearly nothing is impossible to achieve in GTK+. However, such sort of restriction functions which give the programmer more control at the expense of usability (user's happiness) require significantly more efforts by programmers. Efforts which most programmers should rather invest in improving or extending their applications rather than restricting the UIs. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: combo rant
It is the trade-off of the policy that the selected item is under the pointer in the just shown popup, period. I think it is generally good, but this is an example of where it shows its drawbacks. However, for the sake of UI consistency, I believe it should _not_ be changed. I.e. it be under the pointer, period, not under the pointer, but only if... So, why can't we just move the mouse? If the popup window fits (or is over-large enough), with the current item where it should be, then good. Do it. In the cases where the popup hits a screen edge and has to be moved (those situations where in the present system would make part of the popup empty), then here are two options based on controlling the mouse, to throw into the mix; 1) if we can't put the current item beneath the cursor, then simply move the cursor to the current item. 2) allow the popup to be created partially off-screen, then scroll the popup when the user tries to move the mouse towards the off-screen end. I saw that done very successfully in one Windows program that did a very GTK-like combobox. The mouse should always be free to move towards the center-line of the widget, but trying to move away from that center-line will scroll the popup in the opposite direction if it's not yet in its nominal position. These kinds of functionality SHOULD be optional. Most people shouldn't find it too difficult to grasp, but some using different input devices (a touch screen, for instance), may find it less intuitive. But for mouse, trackball or keyboard users, I think either option would be fine. But whatever happens, I agree, those little arrows at the ends are crap. My system gets dog damn slow at times, even the mouse starts to jump and skip. And trying to use those little arrows is hopeless. And that's when I'm not trying to use my GUI remotely! I'd rather have the current item start somewhere else than have a mostly empty popup -- it just plain old looks ugly. I notice that such things as the screen saver lock the mouse in to a certain rectangle. Some window managers, even a couple graphics card drivers I've had in Windows, have been using the scroll on out of bounds moves concept for years to support a viewport into a larger screen. So the concept isn't that unusual. Fredderic ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: combo rant
David Necas (Yeti) wrote: On Fri, Nov 25, 2005 at 11:26:58PM +0200, Paul Pogonyshev wrote: It is the trade-off of the policy that the selected item is under the pointer in the just shown popup, period. I think it is generally good, but this is an example of where it shows its drawbacks. However, for the sake of UI consistency, I believe it should _not_ be changed. I.e. it be under the pointer, period, not under the pointer, but only if... It's funny you say that in a thread where intents to make an alternative implementation were mentioned just a few mails ago. If a policy leads to consequences disliked so much that people start implementing their own widgets, you failed twice: first, you these new widgets will be far more inconsistent, not speaking about follow the policy; and second, you wasted these people time. Yeah, so I should shut up and hold my opinion, because this thread is dedicated to bashing GTK+ combo, or what? If `these people' (assuming you speak for them) don't want their time wasted by dissenting opinions, they should not post to this list. After all, many/most developers of GTK+ itself will disagree, since they developed this combo widget. Second, policy `the items always appear in the same positions (relative to the combo)' would be at least as much consistent. If the position was for exmple below combo, one would be in trouble only if the combo was near bottom screen edge, not any horizontal edge like now. Yes, ``the popup starts with the first item'' policy is no less consistent than GTK+'s. I was trying to say that ``the popup sometimes starts with the selected item under the pointer, sometimes not'' policy would not be consistent. How many problems must a policy cause to make people realize it's wrong? Just recently I had usability problems with Java Swing combo, because I wanted to switch from an item to a different, close one. With GTK+ it would have been close to the pointer in the popup, obviously. With Java, I still had to scroll a lot. So, while GTK+ policy is obviously not flawless, saying that it is outright wrong is ridiculous. How long is it since you've last seen a combo box with only two or three choices that could be replaced with radiobuttons (or even a yes/no checkbox!) immediately getting: - visibility of all the choices - posibility to assign mnemonics to individual choices - constant positions of the choices - fix of sceeen edge interaction problems - fix of obscuring of other widgets - ease of use (less clicks) - improved accessibility Hardly more than a few minutes ago... So I have a preferences page in my program with 8 radios in three groups instead of three combos. Believe me or not. Anyway, this is not relevant to GTK+ combo discussion, only with regard to GNOME HIG. Paul ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: combo rant
I am pretty negative about the combo as a control, not just the GTK combo. Widget sets don't have much of a choice but to include it since it's considered a core control, but as a developer, I try to avoid it if I can. As has been discussed previously, the problem with the combo as a control is that if you have just a few items then your better off displaying them as radio buttons. If you have more than say 20 items or you want to display multiple columns or you want to allow multiple selection, then your better off displaying a custom screen that allows the user to easily resize/sort/select items. So essentially, combo controls are good for very simple lists that aren't too short. Say a single column of data between 4 and 50 unique items. On Fri, 2005-11-25 at 02:19, control H wrote: I'm not that negative about a combo control. After all, a good combo like the Windows one lets me select the item I want quickly and simple (enough), and in an acceptable style. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: combo rant
[snip] To be fair, I've worked with combo controls from at least 4 different widget sets and they all were horrible. Win32, GTK, Web, Borland, Java, they all suck. I think as a control, the combo control is just a bad concept. I'm not that negative about a combo control. After all, a good combo like the Windows one lets me select the item I want quickly and simple (enough), and in an acceptable style. I will probably create my own combo type control in addition to the native Win32/GTK combo box controls. It will basically be a text field with a button directly to the right of it. When the button is clicked a separate window will be opened with a grid inside it. This allows me to bypass all the horrible problems with combos on each platform. It will be a little slower for a user to use than a combo, but the ease of use should be better since the user/developer can resize the grid, etc if needed. When you have a working prototype please let me know, I'd like to see it for sure. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: combo rant
control H wrote: [snip] To be fair, I've worked with combo controls from at least 4 different widget sets and they all were horrible. Win32, GTK, Web, Borland, Java, they all suck. I think as a control, the combo control is just a bad concept. I'm not that negative about a combo control. After all, a good combo like the Windows one lets me select the item I want quickly and simple (enough), and in an acceptable style. Well, I must admit that I haven't used Windows more than occasionaly for the last three or four years, but the last time I checked, Windows combo box was much _worse_ than GTK+'s, in my opinion. You would often get a five-line combo where you'd have to scroll like hell to skip all those 200 items to get to the one you want. I'm not saying GTK+'s combo is perfect, but I think it is generally better than anything else I've seen. At least it always uses all the screen space it has. The main problem, to me, is when the combo is too close to the screen edge, especially to the bottom one. Then you can easily get a too small popup. And yes, I agree that a real scroll bar could be helpful. While you should avoid presenting the user with a hundreds-items combo box in the first place, it doesn't mean GTK+ should make such combos even less usable. Paul ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: combo rant
Well, I must admit that I haven't used Windows more than occasionaly for the last three or four years, but the last time I checked, Windows combo box was much _worse_ than GTK+'s, in my opinion. You would often get a five-line combo where you'd have to scroll like hell to skip all those 200 items to get to the one you want. Ok it certainly sucks when you have to scroll those 200 items within a five-line combo. But that's part of the programmers job I think. At least you are able to force a five-line combo on Windows! And that's what I miss. A function where you can scale such things, as I stated in my original email. I'm not saying GTK+'s combo is perfect, but I think it is generally better than anything else I've seen. At least it always uses all the screen space it has. But this is one of my other objections: it merely _tries_ to use all the screen space available. It draws the menu layout, but without all items: you have to scroll them in if current selection item is near the beginning, using those scroll arrows. It's not the most economic handling of a selection. After all, if you have no more items than would fit on the screen, it could have shown the menu compleet, ie, showing all items at once (but would of course require that the current selected item may be located at a different height than the combo widget itself, but tha'ts no problem to me. I even think that should be configurable). The main problem, to me, is when the combo is too close to the screen edge, especially to the bottom one. Then you can easily get a too small popup. I'm happy you agree on this one :) And yes, I agree that a real scroll bar could be helpful. While you should avoid presenting the user with a hundreds-items combo box in the first place, it doesn't mean GTK+ should make such combos even less usable. I agree completely. Thanks for you comments. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: combo rant
control H wrote: I'm not saying GTK+'s combo is perfect, but I think it is generally better than anything else I've seen. At least it always uses all the screen space it has. But this is one of my other objections: it merely _tries_ to use all the screen space available. It draws the menu layout, but without all items: you have to scroll them in if current selection item is near the beginning, using those scroll arrows. It's not the most economic handling of a selection. After all, if you have no more items than would fit on the screen, it could have shown the menu compleet, ie, showing all items at once (but would of course require that the current selected item may be located at a different height than the combo widget itself, but tha'ts no problem to me. I even think that should be configurable). It is the trade-off of the policy that the selected item is under the pointer in the just shown popup, period. I think it is generally good, but this is an example of where it shows its drawbacks. However, for the sake of UI consistency, I believe it should _not_ be changed. I.e. it be under the pointer, period, not under the pointer, but only if... Yes I wish, it was somehow alleviated. A scroll bar would help. Maybe a keyboard shortcut for the popup that causes it to instantly be filled with items (i.e. scroll in the right direction until the first item is at the very top or the last item is at the very bottom.) But generally, I consider this an inevitable trade off. Paul ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
combo rant
[I already posted this to the gtk-list, I'm not sure which list I should use] I'll start with apologies for upcoming rant. In general I like Gtk: I'm programming with it for a couple of years now and it's easy to learn, reasonably fast, has many bindings, runs on windows, and is highly themable. However, an ever returning frustration for me is the lack of a decent combobox. With every release of Gtk I hoped for a better combo, but to be fair, GtkCombo is in some ways still a better option than GtkComboBox. I notice several problems, that don't seem to be solved soon, if at all. Since I don't understand the inner workings of Gtk and I also don't have time for that, I'll write to this list with the hope that something will change, or at least that I know _why_ it is the way it is. 1. Could someone please explain to me why we don't have a gtkcombobox widget that's comparable with the Windows one or QT's combo? Please give me at least a good reason! I'll address some specific things now: 2. Popup behaviour. Lots about this is already in this thread: http://mail.gnome.org/archives/gtk-devel-list/2005-March/msg00149.html I can only agree. For me, the most important things are the direction of the popup, and the size. Because of screenspace menus are sometimes poped up above the widget, sometimes below, therefore covering information you just filled in those widgets. A function where you can specify the popup behaviour would be nice, eg gtk_combo_box_set_popup_direction(DOWN) or gtk_combo_box_set_popup_direction(SELECTED) for current behaviour. When I make a multi column combo it already behaves much more the way I'd like to. 3. Default mode (so no apears-as-list mode) pops up the menu with the current selected item at the location (height) of the widget itself. If an item from somewhere of the midle was chosen, the menu appears both above and below the widget. If you don't know what I mean, start gimp and save something. The filetype (extension) selection shows this problem. Also, when the active item was near the beginning, you already see the full height of menu list, with some scrollbar-like thing on top and bottom. Not only does that look bad, it's also quite useless, because you'll almost by definition want to scroll down, therefore filling the menu; it could have shown all items imediately. When the menu is filled with all options, these scroll things disappear. If you have so many options that they can't fit on the screen, these scroll things remain. Since these scroll things are not a scrollbar, you can't quickly drag the bar and go quickly to the item you're iterested in. So, why not make A) a scrollbar like in treeview, or B) make long items branch like in windows 4. In apears-as-list mode, again te popup direction and size are a problem. This time we have a scrollbar however, so a function where you can specify the maximum number of items before forcing a scrollbar would be nice. Just like in html. I think this really should be possible. Others want this as well: http://mail.gnome.org/archives/gtk-app-devel-list/2004-June/msg00342.html Unfortunately, nobody gave a reaction to this. I really hope at least someone will share his thaughts about this. I know I know, the Gnome Human Interface Guidelines say that with many items a treeview selection may be a better solution, but I disagree. There are just too many situations where you want a single row widget where you can select from, instead of a space consuming treeview. Even the big Gtk examples are suffering from this problem: I already mentioned Gimp, but also Dia (realy obvious), Gnumeric (has its own combo, eg the font selector) and gftp (still uses the deprecated GtkCombo). On with the problems: A When you click in the textbox (and not the arrow), you have to keep mouse button pressed B When you click the double arrow and just start typing for completion you have te type enter twice. In my opinion one time should be enough, even in the situation where there's no match (just return currect selection) C The width is not optimal. When showing the list it should use the width of the biggest item, or provide a horizontal scrollbar if necesary as well OK, this is a lot of text for maybe not-so-important details. But these details are annoying. And I suspect I'm not the only one. Please give some reaction and possible solutions. Thanks a lot. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: combo rant
My current project requires that I write wrappers around all common GTK and Win32 .NET controls to give them a common functionality set. Sort of like what wxWindows would do but much much more simple with much less functionality. I mention this because with the exception of the GtkComboBox control, GTK flat out embarrasses the .NET widgets. Most of the time I'm struggling to make the .NET controls do something simple while scaling the GTK functionality back dramatically. It isn't so much that the GTK combo is bad, but way to complex. I would say the Win32 combo is much better, but at least it's simple. To be fair, I've worked with combo controls from at least 4 different widget sets and they all were horrible. Win32, GTK, Web, Borland, Java, they all suck. I think as a control, the combo control is just a bad concept. I will probably create my own combo type control in addition to the native Win32/GTK combo box controls. It will basically be a text field with a button directly to the right of it. When the button is clicked a separate window will be opened with a grid inside it. This allows me to bypass all the horrible problems with combos on each platform. It will be a little slower for a user to use than a combo, but the ease of use should be better since the user/developer can resize the grid, etc if needed. On Wed, 2005-11-23 at 13:55, control H wrote: [I already posted this to the gtk-list, I'm not sure which list I should use] I'll start with apologies for upcoming rant. In general I like Gtk: I'm programming with it for a couple of years now and it's easy to learn, reasonably fast, has many bindings, runs on windows, and is highly themable. However, an ever returning frustration for me is the lack of a decent combobox. With every release of Gtk I hoped for a better combo, but to be fair, GtkCombo is in some ways still a better option than GtkComboBox. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
