On 2001.12.07 09:35 Philippe Ney wrote: > Hi Micah, > > In one of our app, we don't have any input device other then the > virtual keyboard. > In this way, it is useful to have the possibility to scroll with it. > But I don't succeed in doing this. The scrollbar widget seems not to > be focusable. > Did I miss something?
The scrollbar isn't focusable, but there is a little hack so the 'hotspot' keyboard navigation works with scrolling. It will just scroll a widget into view if it isn't already. A good example of this is in the file open/save dialog in dialogdemo- you can use up/down or tab/shift-tab to move up and down, scrolling the list. > > Maybe the scroolbar widget have to act in a special way when focused > as the field one. > > Normale navigation mode > ----------------------- > * right, left, up, down arrows --> next widget in the corresponding > direction > * tab --> next widget (internal server list?) tab will navigate across in rows left, then down to the next row. Shift-tab does the opposite. Also, tab and shift-tab wrap around while the arrow keys do not. > > When a Field widget is focused > ------------------------------ > * right and left arrows move the cursor _in_ the widget > * up, down arrows and tab key change focus to next widget > > note: for a text editing area, maybe only the tab key will change the > focus to next widget Right, this is how it should work. I would prefer however to finish the text editing capability of the textbox widget and replace the field widget with the much more powerful textbox. > > When a Scrollbar widget is focused > ---------------------------------- > * up and down arrows control the scroll > * right, left arrows and tab key change focus to next widget This would work, but I don't think it's necessary. The current method works alright for lists of buttons or similar items. Marcus Smith is working on a list widget that will probably implement scrolling using this hotspot mechanism, adding hotspots to rows that don't already contain an interactive widget. The problem with the current hotspot system is that the widget sorting isn't always intuitive to the user. For example, if you have two side-by-side lists it usually confuses the hotspot code. Instead of redoing the scrolling completely, it would be better to fix the hotspot code. Maybe have it first group widgets by container, rather than only relying on their position on the screen. > > > -philippe > > _______________________________________________ > Pgui-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pgui-devel > _______________________________________________ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
