Interaction problems in gtk+ General ------- - when a scrolling widget is resized it should stay where it is *in root coordinates*. This should be the case only when it is resized, not when it is just moved. - inspired by http://blogs.gotdotnet.com/raymondc/PermaLink. aspx/1712c223-ddac-4c36-8954-bfc9e7c86b4c - Letting widgets know the direction they are resized A widget should be able to track its position in *root* coordinates. This will make it possible to make (opaque) resizing from the top left work reasonably. This should be coupled with a special "widget gravity" flag that determines what will happen with a widget's pixels in case of resizing (if it has REDRAW_ON_ALLOCATE == FALSE) - static, the pixels stay where they are in root coordinates - northwest, the pixels move with the allocation's nw corner - etc. - textgravity, This can work for nowindow widgets if we track what pixels are actually solid, ie., are the result of a solid draw, then subtract when something alpha is actually drawn. Note: widgets have to be position independent already, because otherwise they couldn't be scrolled around in a viewport. Note2: something clever could be done here in size_allocate, given the gravity flag: Use gdk_move_area() to move no window widgets around when they don't change size and don't contain fragile pixels. The moving around would have to be done in the right order, or alternatively a non-moving region should be tracked Note3: the feature "how much of this cairo_t is alpha" could be useful. Benefits: - when a widget inside a scrolledwindow is resized from the top left the natural thing can happen: more of the top of the widget is revealed - TreeView can do no-draw-on-allocate for RTL languages - Animations: - TreeView unfolding (move rows, not just arrow). Should probably be a bit faster - smooth scrolling - fade in/fade out - Menus popups - Notebook page switches - Combo popups - Desktop switches - Probably other cases - windows appearing/disappearing There is a bug about this somewhere - make better use of dnd graphics (show the real text for text drags, show rows for file rows etc.) If any part of the graphics (or the most part?) is inside the window, then the drag should be considered inside. - Prelighting should probably in general be delayed by 10ms or so. There is also a bug about being able to turn prelight off. Maybe the solution could be combined: Add a GtkWidget::prelight virtual Then have gtk_widget_set_prelight() gtk_widget_end_prelight() that that the widget would call when it enters/leaves the prelight state. The prelight virtual would be called with (TRUE) when the widget should actually start prelighting, and (FALSE) when it should be turned off. - Right click should always either show a context menu, or be ignored, - Menus are shown on right click, they shouldn't be - Scroll bar shouldn't use right click Label ----- - Labels should be selectable across widgets. Also, the selection should disappear anytime a click anywhere is not handled. - selection should be blue when _any_ of the labels have focus - labels should support drag and drop of selected text (This could be difficult to do across plug/socket). Entry ----- - There should be a little extra space before (and after?) the text in the entry, so that if the entry is overfull, it is still possible to select everything by just clicking the extra space and dragging down. - A timeout (or an idle) should be installed when you select "out of the widget" Paned ----- - if one or both of a paned's children are frames, use the frame as active area for the split bar. When the paned contains another paned which contains a frame, use the part of that lines up with the paned, but not the other paned. Algorithm: for each non-paned child of a paned: if (child is frame) for (parent = child->parent; GTK_IS_PANED (parent); parent = parent->next) { if (parent is vpaned) if (child2) add top of frame to paned else add bottom of frame to paned ...; etc. } - If one of the children is another paned widget, make grab on the connection point move both handles. Scrollbars ---------- - Scrollbars that are aligned with a screen edge should be useful when the cursor is at the edge - The 1 pixel edge around the scrollbar should probably not be active. If you miss the thumb, it should not start moving. Menus ----- See the separate file menuproblems ComboBox -------- - menus pop down on release [Fixed] - Can't drag select Textview -------- - dragging selected text into the TextView doesn't feel well, especially if you are scrolling. - scrolls way too fast - something about dnd-leaving out through the top/bottom should mean "dnd full speed", possibly based on the distance moved - The nautilus icon view got this right (nautilus-dnd.c, nautilus-icon-dnd.c) - several different speeds - should start after a short timeout - scrolling the cursor out of a text view, then moving it results in a big jump. Copy the Notepad algorithm. - IE like selection - maybe page up/page down should always scroll a *full* page even when there isn't a full page to scroll. This would leave blank space at the end of the page. Problem is where do you put the cursor. - When moving outside the textview during selection a timeout/idle should be started - There is something wrong about selections and empty lines (need some investigation) Probably a new-line (both an implicit and an explicity) should simply be considered a space that expands to the end of the line. Whether the newline is part of the selection is determined by the usual rule: whether the mouse is more than half ways inside it. KWrite has this, except that it only considers a newline selected when it is completely selected. That seems to work well. - Dragging text somewhere else should be a "move", not a "copy". [fixed, I think] - If you start dragging within the "scroll zone", you will immediately get scrolled away. - After middle click pasting, the cursor should be positioned where you clicked. TreeView -------- - scrolling the cursor out of a tree view, then moving it results in a big jump. Copy the Notepad algorithm. - treeview should not start editing before the double click time has passed - When you drop something in a TreeView, the new item is scrolled to the top. - Drop in a TreeView should highlight the drop position when you are hovering over the TreeView. - treeview should only start editing when you click on the *text* of the row, not on the blank space. There should be a small area before and after the text (5-15 pixels or so) that acts as text area (so that you can select the full text even on a row that is only text). - when you start editing the treeview, the cursor should be positioned at the place you click. The cursor should be placed as soon as the double click time has passed. If you don't release the button, you should be selecting. There should be a fairly generous area before and after the text that counts as text area (15 pixels, maybe) One problem: What about dragging? - Maybe you could start editing if you hold down the button and move more than say 3 pixels, regardless of the double click time having passed. Again: what about dragging? - The GtkEntry should be placed such that the text doesn't move. It should probably have a shadow_in frame. Actually it looks quite weird right now. - mouse cursor should become a vertical bar when hovering over potentially editable text - when you are folding a tree branch that extends to the bottom of the treeview, blank space should be left. This blank space should disappear when you scroll it away. Would probably require a GtkAdjustment::end_of_scroll signal indicating a "the interaction is finished". - arrows shouldn't be indented. (Themes can fix this). The reason is that if you are expanding a deep hierarchy, it is quicker to move down instead of diagonally down. - The expander arrows should be bigger (the active area around them). The graphics should show this somehow. - it should be programmer settable which columns should be expanded when the tree view is resized. (This may already be the case) - maybe page up/page down should always scroll a *full* page even when there isn't a full page to scroll. This would leave blank space at the end of the page. Problem is where do you put the cursor (maybe at the end of the text, and have it "think of itself" as in the blank area) Would have to be tried. - the scroll during drag and drop when you get close to the edge of the TreeView should not happen until after a short timeout. That way if you drag something out of the treeview it won't do an annoying scroll if a drag happen to cross the bottom edge. The same algorithm as the TextView should be used. - Column resize area should be bigger - Column resizing should be faster - rubber banding Metacity: --------- - the "throttling" of resize makes it possible that the mouse cursor can be outside the frame, and the window only updates when you release the mouse button. There is a bug about this in bugzilla. - Focus should almost never be on the panel. Only if the user very explicitly gives focus to the panel, like clicking in an entry. Menu selection and workspace switching and clicking on applets should not in general give focus to the panel. - There is a bug where clicking on a resize grip and moving out of it can result in "resize mode" getting stuck. - when window is constrained to grid, use better algorithm, perhaps the same as gnumeric. - New transient children should pop up centered on their parent as they do now, but not if they are wider or taller than their parent. In that case walk the tree of transient parents until you find one. (Hopefully at least the root window will be bigger than the child ...) Tooltips: --------- - Tooltips are too intrusive. The text should be smaller, and they should appear below and to the right of the cursor, ie. |\ ___________ | | tooltip | - In "normal" mode, tooltips should appear after ~1.5 s. - When in "browse" mmode (tooltips appear immediately), tooltips should not actually appear immediately, but rather after ~75-100 ms of not moving, so that you can move over a set of objects without getting a ton of tooltips thrown in your face. - After a period of say 500ms without any tooltip showing, "browse" mode should be turned of. (That way you can get rid of tooltips by 'shaking' the mouse a bit) - Browse mode should be turned off when you leave the area of the tooltip group. - They should probably not appear before we have seen at least one motion event on the window (ie. stuff that pops up under the mouse should not get a tooltip). (Or possibly an "enter" that doesn't come from popping up if such a thing is possible). - The widget itself should say when the tooltips are to be shown. Maybe something like "begin_tooltip"/"end_tooltip" and a different "tooltip engine" would be responsible for actually showing the tooltips Nautilus -------- Droppping into a non-open folder should probably be disabled. It is generally more useful and easier to drop into an open folder. Currently dropping over a folder item will drop into that folder. The only feedback is that the icon opens. Icon View (Nautilus): --------------------- - Prelighting should only start after a short timeout, so we don't get flashing when wheel scrolling (maybe only an issue with smooth scrolling) Scroll Bar: ----------- - When you keep the button down, scroll slowly for a while, then fast Already Fixed: -------------- - drag threshold is probably too big (that's configurable ...) - start_dnd should report *grab* coordinate, not "start dnd" coordinate (either that, or the Nautilus icon view should be fixed) [fixed in Nautilus] - can't drag select from a combo. [Fixed] - If an entry has a selection but isn't focused, you can't give focus to it without losing the selection. Worse, you can't give focus and select at the same (click and drag up to select everything for example). Not clear what to do - Don't have selection when it doesn't have focus. The problem with this is that then middle click pasting won't work as well, unless we break the "whatever is selected is middle-click-pasted" principle. - What does Mac OS do? What about Windows? The best thing to do here is probably to have clicks on blank area clear the selection and not start dragging. - Dragging should only start when you click the text, not the blank space. Actually clicking on blank area should probably remove the selection and start selecting. That would also take care of the "give focus to selected entry" problem.