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

[James Paige]

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


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