Smalltalk › Squeak › Squeak - Dev

MenuMorph fitting to height of screen/window/etc

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

timrowledge

MenuMorph fitting to height of screen/window/etc

So far as I can see there is no code to make a MenuMorph do anything help when its height exceeds the screen (or indeed any other limit) unlike the old MVC CustomMenu et al.

Is there anything there that I’m missing? I note the even the system menu -> add new morph -> from alphabetical list -> S-S menu exceeds any plausible height.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
USER ERROR: replace user and press any key to continue.

marcel.taeumel (old)

Re: MenuMorph fitting to height of screen/window/etc

Well, the user may not want to manually browse those long menu entries. To alleviate this problem, there is already support for text-based search. In its current implementation, unmatched items gray out. We should consider removing them to reduce the height of the respective menu.

Other approaches like columns and/or scroll bars do not help here because I think it is tedious to manually look for an item in a list longer than ... say 7 items. There was a book/article about that phenomenon... what was it....

Best,
Marcel

Karl Ramberg

Re: MenuMorph fitting to height of screen/window/etc

In reply to this post by timrowledge

On Fri, Jun 20, 2014 at 12:00 AM, tim Rowledge <[hidden email]> wrote:

So far as I can see there is no code to make a MenuMorph do anything help when its height exceeds the screen (or indeed any other limit) unlike the old MVC CustomMenu et al.

Is there anything there that I’m missing? I note the even the system menu -> add new morph -> from alphabetical list -> S-S menu exceeds any plausible height.

You can click and drag on the 2-3 outermost pixels on each side of the menu to reposition it.

You can also right click to get to the halo and use a handle to move the menu.

But it a automatic handling of long menus would be nice.

Actually PopUpMenu already handles this issue, the functionality could be implemented in TheWorldMenu

PopUpMenu>>startUpWithCaption: captionOrNil icon: aForm at: location allowKeyboard: aBoolean

"Display the menu, with caption if supplied. Wait for the mouse button to go down, then track the selection as long as the button is pressed. When the button is released,

Answer the index of the current selection, or zero if the mouse is not released over any menu item. Location specifies the desired topLeft of the menu body rectangle. The final argument indicates whether the menu should seize the keyboard focus in order to allow the user to navigate it via the keyboard."

| maxHeight |

(ProvideAnswerNotification signal: captionOrNil) ifNotNil:

[:answer | ^ selection := answer ifTrue: [1] ifFalse: [2]].

maxHeight := Display height*3//4.

self frameHeight > maxHeight ifTrue:

[^ self

startUpSegmented: maxHeight

withCaption: captionOrNil

at: location

allowKeyboard: aBoolean].

^ Project current

dispatchTo: self

addPrefixAndSend: #StartUpWithCaption:icon:at:allowKeyboard:

withArguments: {captionOrNil. aForm. location. aBoolean}

Karl

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
USER ERROR: replace user and press any key to continue.

timrowledge

Re: MenuMorph fitting to height of screen/window/etc

In reply to this post by marcel.taeumel (old)

On 20-06-2014, at 7:01 AM, Marcel Taeumel <[hidden email]> wrote:

> Well, the user may not want to manually browse those long menu entries. To
> alleviate this problem, there is already support for text-based search. In
> its current implementation, unmatched items gray out. We should consider
> removing them to reduce the height of the respective menu.

This is true but I need to keep the entire user experience as ‘original’ as possible since teachers really don’t want to have to explain more UI cleverness when the lesson is supposed to be about building scripts. I *might* be able to do neat tricks later.

>
> Other approaches like columns and/or scroll bars do not help here because I
> think it is tedious to manually look for an item in a list longer than ...
> say 7 items. There was a book/article about that phenomenon... what was

That’s a long established UI principle and I completely agree with its value. I’d love to have time to improve the menus in the main system to make proper use of hierarchical menus and so on but…
Having said that, there is a possible place for long menus for choosing from lists like available language translations but the menus really ought to grow scroll bars or some other affordance when too long. Proper chooser dialogues are better, but again, compatibility is an issue for now.

It’s likely you’ve read it but just in case, I recommend my old friend Jef Raskin’s book ‘The Humane Interface’ for some very interesting ideas and a good bit of well documented advice.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- One too many lights out in his Christmas tree.

timrowledge

Re: MenuMorph fitting to height of screen/window/etc

In reply to this post by Karl Ramberg

On 20-06-2014, at 10:10 AM, karl ramberg <[hidden email]> wrote:
> You can click and drag on the 2-3 outermost pixels on each side of the menu to reposition it.
> You can also right click to get to the halo and use a handle to move the menu.
> But it a automatic handling of long menus would be nice.

Exactly; and in Scratch I need to prevent the menu-edge drag and halo, just to make things more fun.

>
> Actually PopUpMenu already handles this issue, the functionality could be implemented in TheWorldMenu

True, though it does it via a rather annoyingly long and complicated process of fudging the mvc/custom/etc menus into menumorphs; something I’d prefer to avoid if possible. I guess that it might be the best practical answer for today though.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Looks for the "Any" key.

marcel.taeumel (old)

Re: MenuMorph fitting to height of screen/window/etc

In reply to this post by timrowledge

I didn't get the problem with compatibility issues. Grayed-out versus hidden is no real difference. In both cases, you cannot select the unmatched items and in both cases you see the current search term at the bottom. Sounds like a minor, compatible change to me.

Where are the issues? :) Which other system/app/tool out there has such a search feature in its pop-up menus anyway? I would argue that the current behavior is pretty unique.

Best,
Marcel

timrowledge

Re: MenuMorph fitting to height of screen/window/etc

On 20-06-2014, at 12:20 PM, Marcel Taeumel <[hidden email]> wrote:

> I didn't get the problem with compatibility issues

Sorry if I wasn’t clear; the compatibility is with the ‘original’ version of Scratch, which uses rather older code for a lot of things. I’m stuck with making the UI (and indeed functionality) as close as possible whilst still using the newer image’s code. Sometimes it’s a bit tricky...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
egret - apology by email