[Ohrrpgce] SVN: teeemcee/8963 Reenable and rewrite mouse support in menus.

Fri Jul 7 00:30:52 PDT 2017

On 7 July 2017 at 15:26, James Paige <Bob at hamsterrepublic.com> wrote:

> Hmmm... Why don't we change the starting resolution of custom to 320x210
> (or larger) and add a menu-bar along the top?
>
> That way we can continue to use right-click for other things.
>
> Moving every screen down a bit to make room for it might be a pain though,
> so we might want just a menu button in a corner, which would reduce the
> amount of stuff that has to be moved out of the way
>
>
Yes, I prefer that too: I suggested it before when I mentioned a tabbed
interface.

We wouldn't actually need to change the way that existing menus are drawn,
since a video page can be a view onto another video page. This would also
allow split-screen tabs. We can add a function to cause mouse coordinates
to be reported relative to a certain video page. The only code change that
I expect will be required is to replace keyval(scEsc) > 1 with escape_menu()

>
> On Thu, Jul 6, 2017 at 6:22 PM, Ralph Versteegen <teeemcee at gmail.com>
> wrote:
>
>>
>>
>> On 5 July 2017 at 03:14, Ralph Versteegen <teeemcee at gmail.com> wrote:
>>
>>>
>>>
>>> On 5 July 2017 at 01:53, James Paige <Bob at hamsterrepublic.com> wrote:
>>>
>>>>
>>>>
>>>> On Monday, July 3, 2017, Ralph Versteegen <teeemcee at gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 4 July 2017 at 16:24, James Paige <Bob at hamsterrepublic.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 3, 2017 at 9:18 PM, <subversion at hamsterrepublic.com>
>>>>>> wrote:
>>>>>>
>>>>>>> teeemcee
>>>>>>> 2017-07-03 21:18:05 -0700 (Mon, 03 Jul 2017)
>>>>>>> 444
>>>>>>> Reenable and rewrite mouse support in menus.
>>>>>>>
>>>>>>> (Yikes, it's been 4 years since James disabled his first attempt!)
>>>>>>> The difference is that this time, hovering the mouse over a menu item
>>>>>>> highlights it (setting .hover) instead of selecting it.
>>>>>>>
>>>>>>> This is blanket-disabled in Game. I'm not sure whether we want the
>>>>>>> mouse control
>>>>>>> in Game to be per-MenuDef or per-MenuState or global (and
>>>>>>> overridable when
>>>>>>> in a debug menu, etc), and how that should work.
>>>>>>>
>>>>>>
>>>>>> I was planning a global mouse-menu enable option in the menu options
>>>>>> menu. Probably a per-menudef overide would make sense too.
>>>>>>
>>>>>> I have also been thinking a lot about how we will need separate
>>>>>> support for mouse-menus and touch-menus, since hover is pretty meaningless
>>>>>> in touch mode.
>>>>>>
>>>>>> One possibility I was thinking of was that if you touch and drag up
>>>>>> or down it changes your selection, but if you touch and release with no
>>>>>> drag, then it confirms the current selection. I'll have to give it a test
>>>>>> to see if it actually feels usable. (fortunately I have a touch-screen
>>>>>> laptop now, so I'll be able to test this sort of thing without having to go
>>>>>> through a full android build+deploy each time I want to iterate a test)
>>>>>>
>>>>>
>>>>> I had totally forgotten about touch.
>>>>> I'll leave all of these things to you.
>>>>>
>>>>> How does the OHR work with a touch-screen laptop? Do we need to extend
>>>>> the backends to report whether the device has a touch screen? But you could
>>>>> use both the mouse or a touch screen...
>>>>>
>>>>
>>>> I don't think we should attempt to detect or report touch laptops, but
>>>> I was thinking that I might want a Mouse/Touch toggle that could optionally
>>>> be added to the options menu along with volume.
>>>>
>>>> Mostly though, I don't care about touch on laptops, beyond the fact
>>>> that it makes testing touch for mobile easier
>>>>
>>>
>>> Could you test scrolling using touch? In particular, scrolling slowly
>>> and whether the direction is correct.
>>>
>>>
>>>>
>>>>
>>>>> I'm going to add right-click controls to select a menu item without
>>>>> entering, or cancel out of a menu, since it's often necessary to do both of
>>>>> those in Custom; in particular Previous Menu isn't always available.
>>>>>
>>>>
>>>> I think in most cases it would be best to add the missing "Previous
>>>> Menu" menu item.
>>>>
>>>
>>> Even when there is a Previous Menu item, it might be above the top of
>>> the screen.
>>>
>>> My idea was to right click to select a menu item (important in some
>>> menus), which I already implemented, and right click outside the boundaries
>>> of the menu to exit. I'm not sure if it will work yet. Any screen which has
>>> multiple menus would have to be handled specially. And it might make any
>>> other purposes of right-clicking aside from selecting a menu item
>>> unintuitive.
>>> Another problem is that some menus fill the entire screen. The number of
>>> such menus which also don't have a Previous Menu option might be zero
>>> (however, those are also the ones where the Previous Menu option is likely
>>> to be off the top of the screen).
>>>
>>> An alternative is to click off the right edge of a menu item (but within
>>> the menu rect) to select it, having to click directly on the text to
>>> activate it.
>>>
>>> Alternatively, with larger window sizes we can put extra UI at the edges
>>> of the screen. I'd like to experiment with a tabbed interface (or
>>> potentially split-screen). Each menu would run in a separate co-routine, so
>>> that you can switch between them freely. I figure this would be optional,
>>> and in particular the tab UI would be disabled if running at 320x200. Would
>>> still be possible to have a pop-up menu to switch between menus, though.
>>>
>>
>> Another option would be popping up a small menu when you right-click away
>> from anything right-clickable (eg menu items). That menu could have three
>> options: ESC, F1 and F9. This avoids accidentally going back because you
>> thought maybe right clicking did something useful.
>> However, it does remind me of the sort of odd UI seen in old X11
>> environments.
>>
>> Of course, instead of clicking twice, you could click, drag to the
>> desired option, and release. Or similarly, right click and swipe to the
>> right to go back. How do you do a right-button drag on a touch screen? I
>> guess left-button dragging is more natural as a modern UI?
>>
>>
>>
>>>
>>>
>>>>
>>>>> I don't know how to handle that with touch controls at all, but this
>>>>> is probably only going to affect menus in Custom anyway, so it's probably
>>>>> not necessary to support touch there.
>>>>>
>>>>
>>>>  Yes. Touch is important for game, but I am not worried about touch for
>>>> custom.
>>>>
>>>> On Mobile, you can currently right click with a two finger press, which
>>>> I might make use of, but we shall see.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ohrrpgce mailing list
>>>> ohrrpgce at lists.motherhamster.org
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
>>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170707/8abee739/attachment.htm>