New Theme config & WimpClickSubmenu

If WimpClickSubmenu is set ‘on’ then it’s not possible to select a theme in the new configuration manager. A conflict of intent (open submenu or select option only in this case the option is just an image)?

This isn’t a bug in the application per se, it’s that WimpClickSubMenu hasn’t been fully thought through (it was only slapped in for a stylus driven demonstrator around 2001 ).

There are many many menus around the place where WimpClickSubMenu is suffering from this same problem, that is, that a menu entry with a submenu has some operation tied to clicking on it. Indeed, the style guide suggests this should be done (in the chapter on menus) and cites the example of ‘Save’ where a click on the menu entry saves the file with its current name and traversing the submenu opens the drag save box. Others that spring to mind are “Grid” and “Paper” in the !Draw menus.

Other desktop stuff doesn’t really work with a stylus/touch either. Hovering over a menu to see its popup interactive help is also impossible.

One option would be to restrict WimpClickSubMenu to needing you to tap on the submenu arrow specifically so a tap elsewhere had the ‘select’ behaviour, for example. I’ve no idea how you adjust click with a stylus!

Ta. 2001! I thought it was new. I’ve survived so far without that option so I’ll continue to do so.

This isn’t a bug in the application per se, it’s that WimpClickSubMenu hasn’t been fully thought through

Indeed, and there’s nothing wrong with the concept, there’s just an omission in the implementation.

One option would be to restrict WimpClickSubMenu to needing you to tap on the submenu arrow specifically so a tap elsewhere had the ‘select’ behaviour, for example.

Alternatively, first click opens submenu, second click is a click on the menu item (or a drag, which isn’t impossible). Hence, code just needs a “Is submenu open?” clause.

Other desktop stuff doesn’t really work with a stylus/touch either. Hovering over a menu to see its popup interactive help is also impossible.

Well assuming the target isn’t draggable, then one could employ the release-to-click idiom of many other touch interfaces, allowing the initial touch to move the cursor and hence ‘hover’. Dragging away from the target then prevents the click-on-release. Draggable targets are different though.

I’ve no idea how you adjust click with a stylus!

Same as Menu – you need another button. On many tablet devices that would have to be a virtual button on the screen or touch sensor.

a virtual button on the screen or touch sensor

Or multi-touch (2 fingers, provided the resolution/phyical screen size combination doesn’t make it impractical) or perhaps a long click?

a virtual button on the screen or touch sensor

Or multi-touch

Indeed, multitouch was implied. Not clearly enough it seems! ;_;

OK – “my bad”, or whatever they say these days!