Smalltalk › Pharo › Pharo Smalltalk Developers

Morphic menus

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Matthieu

Morphic menus

Hello everyone,

I had to understand how menus work in Morphic lately and I noticed some things :

1) When a menu has strictly more than 1 submenu active it cannot regain the focus if the mouse doesn't pass over the submenus first. It is a bit hard for me to explain so I will give you an example :

Open a Nautilus browser on any package and right click on a class. Now browse "Refactoring => Code Rewriting => Rewrite Code but don't click on any of these items. You will have 3 menus. Now if you exit the last menu without returning to the previous one (make a loop from the right for example if you have enough place) and go back directly to the first one you'll see that it doesn't respond (it is like frozen).

I don't know if it is a bug or if it is intended but I find it strange as it is not how it is working on Windows nor Ubuntu for example.

So if it is indeed a bug, what I propose as a "fix" would be this:

Replace :

MenuItemMorph >> activateOwner Menu: evt
    "Activate our owner menu; e.g., pass control to it"
    owner ifNil:[^false]. "not applicable"
    (owner fullContainsPoint: evt position) ifFalse:[^false].
    owner activate: evt.
    ^true

by:

MenuItemMorph >> activateOwner Menu: evt

    | popUpOwner |

    owner ifNil: [^false].
    (owner fullContainsPoint: evt position) ifTrue: [
        owner activate: evt.
        ^true.
    ].

    popUpOwner := owner popUpOwner.
    [ popUpOwner ] whileNotNil: [
        (popUpOwner owner fullContainsPoint: evt position) ifTrue: [
            popUpOwner owner activate: evt.
            ^true.
        ]
        ifFalse: [
            popUpOwner := popUpOwner owner popUpOwner.
        ].
    ].
    ^false.

It should work with any number of submenus but i couldn't find anywhere in Pharo with more than 3 menus so i couldn't test it further.

2) When you leave a submenu and quickly come back to its popUpOwner, the item in the submenu won't be deselected. So if you navigate a bit in the menu and then want to come back to this submenu, you won't be able to select the item by passing your mouse over it. It is not a big deal in 99.9% of the time as you will still be able to click on it but when this item is supposed to open a submenu it won't. You need to go to another item in the submenu and to come back.

I noticed that it happened because if you are leaving the submenu too quickly there is no "mouseLeave" event generated so the itemMenu is not deselected. Thus, as it is considered as selected, if you come back to it later a "mouseEnter" event will not trigger anything.

It is quite easy to reproduce with the same menu than for the 1) :

Right click on a class in a Nautilus browser then browse Refactoring => Code Rewriting.

Now if you quickly come back to Refactoring sometimes you'll see that Code Rewriting won't be deselected (it will still be blue after the 500ms time out). If it is the case you can go back on "Rename..." and then if you quickly come back to Refactoring => Code Rewriting, you won't be able to get the 3rd submenu.

I can reproduce this very easily but it is not really a problem because it only happens if you are fast with your mouse.

I did not try to fix it but I guess that reinitializing all the itemMenus to unselected when poping a menu could do the trick.

3) This one is mostly insignificant because it is quite hard to reproduce and doesn't trigger often at all. But sometimes when you quickly navigate between 3 menus (I have not been able to reproduce it with only 2 menus) when you want to go back to the first one it freezes and it doesn't handle the mouseOver events anymore (you can still click though).

This is not the same thing than the first point because here you correctly pass through the previous submenus to go to the first one.
I don't really know why this happens sometimes but I think it may be because the focus was not passed quickly enough between windows and one on the submenus gets deactivated and removed from the world wheras it still had the focus on him.

Anyway these 3 things are not really important but I just wanted to share what i found with you in case you think it is valid.

Cheers,

Matthieu

Nicolai Hess

Re: Morphic menus

2015-05-21 16:50 GMT+02:00 Matthieu Lacaton <[hidden email]>:

Hello everyone,

I had to understand how menus work in Morphic lately and I noticed some things :

1) When a menu has strictly more than 1 submenu active it cannot regain the focus if the mouse doesn't pass over the submenus first. It is a bit hard for me to explain so I will give you an example :
Open a Nautilus browser on any package and right click on a class. Now browse "Refactoring => Code Rewriting => Rewrite Code but don't click on any of these items. You will have 3 menus. Now if you exit the last menu without returning to the previous one (make a loop from the right for example if you have enough place) and go back directly to the first one you'll see that it doesn't respond (it is like frozen).

I don't know if it is a bug or if it is intended but I find it strange as it is not how it is working on Windows nor Ubuntu for example.

So if it is indeed a bug, what I propose as a "fix" would be this:

Replace :

MenuItemMorph >> activateOwner Menu: evt
    "Activate our owner menu; e.g., pass control to it"
    owner ifNil:[^false]. "not applicable"
    (owner fullContainsPoint: evt position) ifFalse:[^false].
    owner activate: evt.
    ^true

by:

MenuItemMorph >> activateOwner Menu: evt

    | popUpOwner |

    owner ifNil: [^false].
    (owner fullContainsPoint: evt position) ifTrue: [
        owner activate: evt.
        ^true.
    ].

    popUpOwner := owner popUpOwner.
    [ popUpOwner ] whileNotNil: [
        (popUpOwner owner fullContainsPoint: evt position) ifTrue: [
            popUpOwner owner activate: evt.
            ^true.
        ]
        ifFalse: [
            popUpOwner := popUpOwner owner popUpOwner.
        ].
    ].
    ^false.

It should work with any number of submenus but i couldn't find anywhere in Pharo with more than 3 menus so i couldn't test it further.

Works good.

2) When you leave a submenu and quickly come back to its popUpOwner, the item in the submenu won't be deselected. So if you navigate a bit in the menu and then want to come back to this submenu, you won't be able to select the item by passing your mouse over it. It is not a big deal in 99.9% of the time as you will still be able to click on it but when this item is supposed to open a submenu it won't. You need to go to another item in the submenu and to come back.

I noticed that it happened because if you are leaving the submenu too quickly there is no "mouseLeave" event generated so the itemMenu is not deselected. Thus, as it is considered as selected, if you come back to it later a "mouseEnter" event will not trigger anything.

It is quite easy to reproduce with the same menu than for the 1) :
Right click on a class in a Nautilus browser then browse Refactoring => Code Rewriting.
Now if you quickly come back to Refactoring sometimes you'll see that Code Rewriting won't be deselected (it will still be blue after the 500ms time out). If it is the case you can go back on "Rename..." and then if you quickly come back to Refactoring => Code Rewriting, you won't be able to get the 3rd submenu.

I can reproduce this very easily but it is not really a problem because it only happens if you are fast with your mouse.

I did not try to fix it but I guess that reinitializing all the itemMenus to unselected when poping a menu could do the trick.

3) This one is mostly insignificant because it is quite hard to reproduce and doesn't trigger often at all. But sometimes when you quickly navigate between 3 menus (I have not been able to reproduce it with only 2 menus) when you want to go back to the first one it freezes and it doesn't handle the mouseOver events anymore (you can still click though).
This is not the same thing than the first point because here you correctly pass through the previous submenus to go to the first one.
I don't really know why this happens sometimes but I think it may be because the focus was not passed quickly enough between windows and one on the submenus gets deactivated and removed from the world wheras it still had the focus on him.

Anyway these 3 things are not really important but I just wanted to share what i found with you in case you think it is valid.

I find both difficult to reproduce, I can, but only on every ~ 10th attempt.

And you can always click on the menu or open a new one.

Cheers,

Matthieu

Matthieu

Re: Morphic menus

Yeah it is really no big deal. Just some minor things I noticed while working my way through all those morphics ;)

Le 21 mai 2015 21:10, "Nicolai Hess" <[hidden email]> a écrit :

2015-05-21 16:50 GMT+02:00 Matthieu Lacaton <[hidden email]>:
Hello everyone,

I had to understand how menus work in Morphic lately and I noticed some things :

1) When a menu has strictly more than 1 submenu active it cannot regain the focus if the mouse doesn't pass over the submenus first. It is a bit hard for me to explain so I will give you an example :
Open a Nautilus browser on any package and right click on a class. Now browse "Refactoring => Code Rewriting => Rewrite Code but don't click on any of these items. You will have 3 menus. Now if you exit the last menu without returning to the previous one (make a loop from the right for example if you have enough place) and go back directly to the first one you'll see that it doesn't respond (it is like frozen).

I don't know if it is a bug or if it is intended but I find it strange as it is not how it is working on Windows nor Ubuntu for example.

So if it is indeed a bug, what I propose as a "fix" would be this:

Replace :

MenuItemMorph >> activateOwner Menu: evt
    "Activate our owner menu; e.g., pass control to it"
    owner ifNil:[^false]. "not applicable"
    (owner fullContainsPoint: evt position) ifFalse:[^false].
    owner activate: evt.
    ^true

by:

MenuItemMorph >> activateOwner Menu: evt

    | popUpOwner |

    owner ifNil: [^false].
    (owner fullContainsPoint: evt position) ifTrue: [
        owner activate: evt.
        ^true.
    ].

    popUpOwner := owner popUpOwner.
    [ popUpOwner ] whileNotNil: [
        (popUpOwner owner fullContainsPoint: evt position) ifTrue: [
            popUpOwner owner activate: evt.
            ^true.
        ]
        ifFalse: [
            popUpOwner := popUpOwner owner popUpOwner.
        ].
    ].
    ^false.

It should work with any number of submenus but i couldn't find anywhere in Pharo with more than 3 menus so i couldn't test it further.

Works good.

2) When you leave a submenu and quickly come back to its popUpOwner, the item in the submenu won't be deselected. So if you navigate a bit in the menu and then want to come back to this submenu, you won't be able to select the item by passing your mouse over it. It is not a big deal in 99.9% of the time as you will still be able to click on it but when this item is supposed to open a submenu it won't. You need to go to another item in the submenu and to come back.

I noticed that it happened because if you are leaving the submenu too quickly there is no "mouseLeave" event generated so the itemMenu is not deselected. Thus, as it is considered as selected, if you come back to it later a "mouseEnter" event will not trigger anything.

It is quite easy to reproduce with the same menu than for the 1) :
Right click on a class in a Nautilus browser then browse Refactoring => Code Rewriting.
Now if you quickly come back to Refactoring sometimes you'll see that Code Rewriting won't be deselected (it will still be blue after the 500ms time out). If it is the case you can go back on "Rename..." and then if you quickly come back to Refactoring => Code Rewriting, you won't be able to get the 3rd submenu.

I can reproduce this very easily but it is not really a problem because it only happens if you are fast with your mouse.

I did not try to fix it but I guess that reinitializing all the itemMenus to unselected when poping a menu could do the trick.

3) This one is mostly insignificant because it is quite hard to reproduce and doesn't trigger often at all. But sometimes when you quickly navigate between 3 menus (I have not been able to reproduce it with only 2 menus) when you want to go back to the first one it freezes and it doesn't handle the mouseOver events anymore (you can still click though).
This is not the same thing than the first point because here you correctly pass through the previous submenus to go to the first one.
I don't really know why this happens sometimes but I think it may be because the focus was not passed quickly enough between windows and one on the submenus gets deactivated and removed from the world wheras it still had the focus on him.

Anyway these 3 things are not really important but I just wanted to share what i found with you in case you think it is valid.

I find both difficult to reproduce, I can, but only on every ~ 10th attempt.
And you can always click on the menu or open a new one.

Cheers,

Matthieu

stepharo

Re: Morphic menus

In reply to this post by Matthieu

Hi mathieu

can you open a bug entry?
and publish your solution.
Tx

Le 21/5/15 14:50, Matthieu Lacaton a écrit :

Hello everyone,

I had to understand how menus work in Morphic lately and I noticed some things :

1) When a menu has strictly more than 1 submenu active it cannot regain the focus if the mouse doesn't pass over the submenus first. It is a bit hard for me to explain so I will give you an example :

Open a Nautilus browser on any package and right click on a class. Now browse "Refactoring => Code Rewriting => Rewrite Code but don't click on any of these items. You will have 3 menus. Now if you exit the last menu without returning to the previous one (make a loop from the right for example if you have enough place) and go back directly to the first one you'll see that it doesn't respond (it is like frozen).

I don't know if it is a bug or if it is intended but I find it strange as it is not how it is working on Windows nor Ubuntu for example.

So if it is indeed a bug, what I propose as a "fix" would be this:

Replace :

MenuItemMorph >> activateOwner Menu: evt
    "Activate our owner menu; e.g., pass control to it"
    owner ifNil:[^false]. "not applicable"
    (owner fullContainsPoint: evt position) ifFalse:[^false].
    owner activate: evt.
    ^true

by:

MenuItemMorph >> activateOwner Menu: evt

    | popUpOwner |

    owner ifNil: [^false].

    (owner fullContainsPoint: evt position) ifTrue: [

        owner activate: evt.

        ^true.
    ].

    popUpOwner := owner popUpOwner.

    [ popUpOwner ] whileNotNil: [

        (popUpOwner owner fullContainsPoint: evt position) ifTrue: [

            popUpOwner owner activate: evt.

            ^true.
        ]

        ifFalse: [

            popUpOwner := popUpOwner owner popUpOwner.
        ].
    ].

    ^false.

It should work with any number of submenus but i couldn't find anywhere in Pharo with more than 3 menus so i couldn't test it further.

2) When you leave a submenu and quickly come back to its popUpOwner, the item in the submenu won't be deselected. So if you navigate a bit in the menu and then want to come back to this submenu, you won't be able to select the item by passing your mouse over it. It is not a big deal in 99.9% of the time as you will still be able to click on it but when this item is supposed to open a submenu it won't. You need to go to another item in the submenu and to come back.

I noticed that it happened because if you are leaving the submenu too quickly there is no "mouseLeave" event generated so the itemMenu is not deselected. Thus, as it is considered as selected, if you come back to it later a "mouseEnter" event will not trigger anything.

It is quite easy to reproduce with the same menu than for the 1) :

Right click on a class in a Nautilus browser then browse Refactoring => Code Rewriting.

Now if you quickly come back to Refactoring sometimes you'll see that Code Rewriting won't be deselected (it will still be blue after the 500ms time out). If it is the case you can go back on "Rename..." and then if you quickly come back to Refactoring => Code Rewriting, you won't be able to get the 3rd submenu.

I can reproduce this very easily but it is not really a problem because it only happens if you are fast with your mouse.

I did not try to fix it but I guess that reinitializing all the itemMenus to unselected when poping a menu could do the trick.

3) This one is mostly insignificant because it is quite hard to reproduce and doesn't trigger often at all. But sometimes when you quickly navigate between 3 menus (I have not been able to reproduce it with only 2 menus) when you want to go back to the first one it freezes and it doesn't handle the mouseOver events anymore (you can still click though).

This is not the same thing than the first point because here you correctly pass through the previous submenus to go to the first one.
I don't really know why this happens sometimes but I think it may be because the focus was not passed quickly enough between windows and one on the submenus gets deactivated and removed from the world wheras it still had the focus on him.

Anyway these 3 things are not really important but I just wanted to share what i found with you in case you think it is valid.

Cheers,

Matthieu

Matthieu

Re: Morphic menus

Sure, I've done it. I don't really know how fogbugz works so I assigned it to everyone :P

Matthieu

2015-05-22 13:00 GMT+02:00 stepharo <[hidden email]>:

Hi mathieu

can you open a bug entry?
and publish your solution.
Tx

Le 21/5/15 14:50, Matthieu Lacaton a écrit :

Hello everyone,

I had to understand how menus work in Morphic lately and I noticed some things :

1) When a menu has strictly more than 1 submenu active it cannot regain the focus if the mouse doesn't pass over the submenus first. It is a bit hard for me to explain so I will give you an example :

Open a Nautilus browser on any package and right click on a class. Now browse "Refactoring => Code Rewriting => Rewrite Code but don't click on any of these items. You will have 3 menus. Now if you exit the last menu without returning to the previous one (make a loop from the right for example if you have enough place) and go back directly to the first one you'll see that it doesn't respond (it is like frozen).

I don't know if it is a bug or if it is intended but I find it strange as it is not how it is working on Windows nor Ubuntu for example.

So if it is indeed a bug, what I propose as a "fix" would be this:

Replace :

MenuItemMorph >> activateOwner Menu: evt
    "Activate our owner menu; e.g., pass control to it"
    owner ifNil:[^false]. "not applicable"
    (owner fullContainsPoint: evt position) ifFalse:[^false].
    owner activate: evt.
    ^true

by:

MenuItemMorph >> activateOwner Menu: evt

    | popUpOwner |

    owner ifNil: [^false].

    (owner fullContainsPoint: evt position) ifTrue: [

        owner activate: evt.

        ^true.
    ].

    popUpOwner := owner popUpOwner.

    [ popUpOwner ] whileNotNil: [

        (popUpOwner owner fullContainsPoint: evt position) ifTrue: [

            popUpOwner owner activate: evt.

            ^true.
        ]

        ifFalse: [

            popUpOwner := popUpOwner owner popUpOwner.
        ].
    ].

    ^false.

It should work with any number of submenus but i couldn't find anywhere in Pharo with more than 3 menus so i couldn't test it further.

2) When you leave a submenu and quickly come back to its popUpOwner, the item in the submenu won't be deselected. So if you navigate a bit in the menu and then want to come back to this submenu, you won't be able to select the item by passing your mouse over it. It is not a big deal in 99.9% of the time as you will still be able to click on it but when this item is supposed to open a submenu it won't. You need to go to another item in the submenu and to come back.

I noticed that it happened because if you are leaving the submenu too quickly there is no "mouseLeave" event generated so the itemMenu is not deselected. Thus, as it is considered as selected, if you come back to it later a "mouseEnter" event will not trigger anything.

It is quite easy to reproduce with the same menu than for the 1) :

Right click on a class in a Nautilus browser then browse Refactoring => Code Rewriting.

Now if you quickly come back to Refactoring sometimes you'll see that Code Rewriting won't be deselected (it will still be blue after the 500ms time out). If it is the case you can go back on "Rename..." and then if you quickly come back to Refactoring => Code Rewriting, you won't be able to get the 3rd submenu.

I can reproduce this very easily but it is not really a problem because it only happens if you are fast with your mouse.

I did not try to fix it but I guess that reinitializing all the itemMenus to unselected when poping a menu could do the trick.

3) This one is mostly insignificant because it is quite hard to reproduce and doesn't trigger often at all. But sometimes when you quickly navigate between 3 menus (I have not been able to reproduce it with only 2 menus) when you want to go back to the first one it freezes and it doesn't handle the mouseOver events anymore (you can still click though).

This is not the same thing than the first point because here you correctly pass through the previous submenus to go to the first one.
I don't really know why this happens sometimes but I think it may be because the focus was not passed quickly enough between windows and one on the submenus gets deactivated and removed from the world wheras it still had the focus on him.

Anyway these 3 things are not really important but I just wanted to share what i found with you in case you think it is valid.

Cheers,

Matthieu

Ben Coman

Re: Morphic menus

2015-05-22 13:00 GMT+02:00 stepharo <[hidden email]>:

Hi mathieu

can you open a bug entry?
and publish your solution.
Tx

On Sun, May 24, 2015 at 10:30 PM, Matthieu Lacaton <[hidden email]> wrote:

Sure, I've done it. I don't really know how fogbugz works so I assigned it to everyone :P

Matthieu

Hi Matthieu, Its usual to respond with the URL of the issue :). This helps pull in collaborators and helps historical web searches link to the issue.

cheers -ben

Matthieu

Re: Morphic menus

Oh okay, sorry, i'm not used to it :/

Here it is : https://pharo.fogbugz.com/f/cases/15598#BugEvent.127858

Cheers,

Matthieu

2015-05-24 17:29 GMT+02:00 Ben Coman <[hidden email]>:

2015-05-22 13:00 GMT+02:00 stepharo <[hidden email]>:

Hi mathieu

can you open a bug entry?
and publish your solution.
Tx

On Sun, May 24, 2015 at 10:30 PM, Matthieu Lacaton <[hidden email]> wrote:
Sure, I've done it. I don't really know how fogbugz works so I assigned it to everyone :P

Matthieu

Hi Matthieu, Its usual to respond with the URL of the issue :). This helps pull in collaborators and helps historical web searches link to the issue.
cheers -ben

Sean P. DeNigris

Re: Morphic menus

Administrator

In reply to this post by Ben Coman

Ben Coman wrote

Its usual to respond with the URL of the issue :)

I'm working on making the issue workflow a bit more automatic. To make this a little easier, evaluate "Clipboard clipboardText: (PharoIssue number: 15598) creationNotification", which will give you a snippet to paste for the mailing list:
Issue 15598: Morphic - Can't go back directly to the first menu when more than 2 submenus are opened.
https://pharo.fogbugz.com/default.asp?15598

Cheers,
Sean

Ben Coman

Re: Morphic menus

On Mon, May 25, 2015 at 7:34 PM, Sean P. DeNigris <[hidden email]> wrote:

Ben Coman wrote
> Its usual to respond with the URL of the issue :)

I'm working on making the issue workflow a bit more automatic.

Cool initiative. I'd be interested in knowing more about its general architecture.

For a long time I've been musing on improving issue workflow using PharoLauncher such that:

1. One click opens a dialog to:

a. Type issue-number

b. Type build-number (default to latest)

c. Select image-naming-template

d. Select slice from the Inbox repository

2. Download build-number to the local-cache and create new image per image-naming-template

3. Run a command-line against the image to so that in the background it:

a. Opens Monitecello and Inbox Repository

b. Selects the slice and does the first click of <Merge> button.

4. Opens the image ready for review.

cheers -ben

To make this
a little easier, evaluate "Clipboard clipboardText: (PharoIssue number:
15598) creationNotification", which will give you a snippet to paste for the
mailing list: