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

[Ralph Versteegen]

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.


>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20170705/c667368b/attachment-0001.htm>