1. Widget Wish List
What generic widgets would improve GTK+ if added?
1.1. Animated Pixbuf Cell Renderer
This can probably be an "animation" property on the GtkCellRendererPixbuf widget. See gnomebug:310327.
1.2. Text + Progress Meter Cell Renderer
A standard text cell renderer that can display a faint progress meter behind the text. This would be useful in Sound Juicer or any other program that needs to process each thing in a list.
DavydMadeley: can't you do this now by setting the "text" property on a GtkCellRendererProgress?
RossBurton: sort of, but the text is aligned differently to the text renderer (it's centered), and cannot be editted.
MatthiasClasen: see gnomebug:334576
ShaunMcCance: An actual progress bar would also have a decorative border and different text color in most themes, which I think would just be jarring as SJ goes through the list. I think it would be prefereable to have a very subtle filling of the background, while leaving all other rendering details the same.
1.3. Composite Cell Renderer
Firstly: This has nothing to do with the X11 Composite extension. A cell renderer that you can pack other cell renderers in to. Should allow both horizontal and vertical layout of children. See fx: http://www.grillbar.org/wordpress/?p=233.
1.4. Icon Entry
A standard entry with an icon on the left. See the URL entry in epiphany for an example. A recent implementation by Christian Hammond is in libsexy, see http://www.chipx86.com/blog/archives/000107.html.
chpe: This isn't enough; Epiphany actually needs an entry with icons on both ends, as well as DND from the icons and tooltips on the icons.
DanWinship: What about having a GtkEntryBox, subclassing GtkHBox, and you can pack_start whatever arbitrary widgets (not just icons) you want on the left, and pack_end whatever widgets you want on the right, and the entry is in the middle (with has_frame set FALSE and the assorted other tricks to make the whole widget look like a single entry). That should handle all of these cases, as well as providing a base class for the Search Entry described below.
chpe: That's exactly how EphyIconEntry works: it's a GtkHBox containing a frameless GtkEntry, and the drawing is done using the entry's style, so it looks like an entry. The problem with it is that some themes, e.g. Crux, still draw an inner frame when the entry is focused.
ChristianHammond: The icon entry (which is now part of libsexy as SexyIconEntry) does now support icons on both ends, including proper right-to-left support. Drag-and-drop is in the works. The nice thing about this entry is that, as a GtkEntry, it doesn't need to provide special functions for getting the entry inside of it, and the themeing should always Just Work.
1.5. Search Entry
A text entry subclass specifically for entering in search terms. Ideally, it could have a search icon inside that you could click to get a menu of search methods. Themes could make the search entry look distinct from regular text entries.
PaoloBorelli: other possible features for a search entry are
- themable background color for no matches (like in firefox where the entry turns red)
- optional dropdown with history of searches (in other words it should be a combobox entry)
1.6. Column View
A widget that can display a GtkTreeModel in columns, like in NeXT or OS X.
1.7. Pie Menus
Pie menus are circular menus which arrange the options around an inactive area in the middle.
- "Pie menus are a naturally efficient user-interface technique -- directional selection of pie slice-shaped targets. The cursor starts out in the inactive center region of a pie, and all target slices are large, nearby, and in different directions. Pie menus are quite easy for new users. You simple follow the pop-up directions to use them. They are also extremely efficient for experienced users. Once you know the directions, you can quickly and reliably 'mouse ahead' without looking. Fitts' Law explains the pie menu advantage -- their fast selection speed and low error rate is due to their large target size and the small distance between each item." Natural Selection: The Evolution of Pie Menus
1.8. Conditional cascading menus
Conditional cascading menus allow for the activation of a menu item with a submenu. See bug gnomebug:82162
1.9. Sheet or Table
A very simple (spread)sheet/table, nothing fancy. See bug gnomebug:119085
TreeView already does almost everything that is needed. The only problem is that you can only select rows. If it would be possible to enhance the TreeView in a way that it allows arbitrary selections (or maybe just arbitrary rectangular selections), then there would be no need to duplicate any code for a sheet/table widget.
1.10. Flowing Vertical Container
A container with columns, like a newspaper, so that the child widgets flow into the next column when there there is not enough space in the first column. The column height depends on the vertical allocation given to the container. As another possibility, the number of columns could be fixed, which would make the height dependent on column width and number of widgets (optimizing for similar lengths).
BenjaminDauvergne: better would be a Paginated Flowing Vertical Container, item are placed in columns whose height is the same as the viewport, and those blocks of columns are repeated as if "paginated". ( it should also be the standard for CSS3 but... ) It corresponds to the way we read, no need to scroll until you have reviewed all the currently displayed data. Scrolling should remain vertical because we are not used to horizontal scrolling of text; at least not in the western world I think. Example:
1 3 5 2 4 6 --------- 7 9 11 8 10 12 --------- etc...
1.11. Flowing Horizontal Container
Similar to above, a widget that lays out its children horizontally, flowing onto new lines if they would extend beyond the horizontal allocation.
Doing this correctly requires height-for-width geometry, but it can be done in a hacky way.
1.12. Vertical File Chooser
A widget appropiated for use in side panels or vertical spaces. See http://flickr.com/photos/diegoe/120940642/
1.13. Scrollet
JohnPeterson: A very simple list pager, often seen in menu panes when they exceed the screen's height, but also used for icons on panels, tabs (see Firefox 2.0), etc. It is basically just an arrow on the top/left and an arrow on the bottom/right with list content sandwiched in-between, scrolled one item at a time by the arrows. Also when a user hovers over the content, the scroll button should work the same as it does with a scrollbar. It is really only useful for small lists of 100 items or less, but it is reinvented by thousands of applications.
1.14. Charset Encoding Selector
YounghoCha: Some applications (Gedit, Epiphany, Gnome-Terminal, Totem, and etc..) use this function. But they are implemented by each other. Can it be possible to implement in gtk level?
1.15. Notebook Tab with Close Buttons
JonesLee: A very useful widget that is currently employed by many apps such gnome-terminal, hotss and etc..
- See also UsabilityProject/Whiteboard/StockItems