Make palettes behave like sugar-toolkit.

[icarito]

They will close when clicking anywere else.

@llaske you may be interested in this one. Makes palettes less frustrating.

[icarito]

fixes #126

[AllenAby]

The function to close the palette seems to be correct, when the instance method is called on the palette object, it will become hidden upon clicking outside the palette

[walterbender]

Why is this done inside a timeout with value 0?

[sanatankc]

Is there something I can do. It was in GCI tasks.

[walterbender]

It would be good to have a clearer statement of what this patch does. And an answer to my earlier question.

[quozl]

I've reviewed;

• Palettes are hard to close #126
• Palettes setContent doesn't properly clear content before updating #128
• Update palette.js #130
• https://github.com/llaske/sugarizer/tree/dev copies of palette.js

I've tested the palette or tooltip hide response of GTK+ 2, GTK+ 3, and JavaScript toolkits using activities Moon, Chat, and Gears, on the Sugar desktop. Tooltips correctly hide, but I was not able to find an example of palettes in a JavaScript activity.

I think icarito was onto something, and a fix would be welcome, but as he has withdrawn it will be up to our other developers to champion the change, and work with @walterbender to get it merged.

So, @sanatankc or @ccr4b, can you give us some help;

• a test case of a JavaScript activity running on Sugar desktop that shows palettes not hiding when mouse leaves them,
• if the proposed patch fixes the problem,
• why the proposed patch implemented a fix using a timeout rather than immediate,
• any alternate patch.

[cheongsiuhong]

@quozl regarding your comments - I've done some testing regarding this fix by doing the following:

1. Setting up sugarizer's Moon.activity in sugar desktop.
2. Replacing the sugar-web library with the one from this repository.

As stated in #126, the journal palette does not close when the mouse moves outside nor when the mouse clicks outside the palette.

The fix implemented in this PR works as stated, and the palette closes when mouse clicks occur anywhere outside the palette. The fix works by adding click event listener when the palette is popped up; a click event would then trigger the palette close function.

Without the timeout, the click event would trigger the palette close function on the same click that opens the palette, and as a result the palette cannot open at all. The fix is fairly hacky though it does do its job, it is not clear if it is really needed. I've opened a few native sugar and sugarizer activities and it appears that palettes have the same behavior as described in #126; they do not close when the mouse moves or clicks outside them. I am not too sure if ALL native sugar activity palettes behave like this though, please do correct me if I'm wrong.

Otherwise, I would suggest that this palette behavior be left alone and the issues and pull request to be closed.

[quozl]

Interesting, thanks.

I've just tested Gears on Ubuntu 20.04, and #126 continues as you say.

Looking at how Python GTK activities behave;

• the activity icon when clicked resizes the canvas, shows a toolbar under the main toolbar, and the description button shows a palette. Both are not dismissed by moving the mouse or clicking outside the object.
• the activity icon when approached using mouse pointer shows a palette toolbar, and the description button shows a palette. Both are dismissed by moving the mouse or clicking outside the object.

Gears and sugar-web I guess does not support moving the mouse pointer into the object to activate. Only clicks will work?

[icarito]

Hi,
I'd forgotten about this PR.
I don't remember the precise circumstances at the time, but I do remember that by the time Walter asked, I'd forgotten what the timeout was for. Looking at the code right now it is not completely apparent to me either but @cheongsiuhong analysis seems right.

[icarito]

Looking at how Python GTK activities behave;

* the activity icon when clicked resizes the canvas, shows a toolbar under the main toolbar, and the description button shows a palette.  Both are not dismissed by moving the mouse or clicking outside the object.

* the activity icon when approached using mouse pointer shows a palette toolbar, and the description button shows a palette.  Both are dismissed by moving the mouse or clicking outside the object.

Gears and sugar-web I guess does not support moving the mouse pointer into the object to activate. Only clicks will work?

I'm not sure I understand what you are asking. I just went to try.sugarizer.org and tried Gears. Mouse pointer behaviour is: style change "on hover" (dark button) and the hover tooltip title. I observe the same with other activities. "click" is a fairly broad event that triggers on any pointer, I believe.

The reason I implemented this was for one thing consistency but also I observed frustration from our users here at home that the menus seemed to "stay on". I should've mentioned all this in the PR / commit message.

Regards and thanks @cheongsiuhong !

[quozl]

I'm not sure I understand what you are asking.

On Ubuntu 20.04 with Sugar 0.117 and Gears; on hover is style change and tooltip, as you say. But same platform using a Python GTK activity responds by opening the palette. The difference in response is unexpected, and I don't know which response is the right one to plan for in future.

[icarito]

Thanks for clearing it up. Right, that's a design decision. I have no opinion. El dom, 29 de mar de 2020 a las 21:57, James Cameron <[email protected]> escribió:

…

> I'm not sure I understand what you are asking. > On Ubuntu 20.04 with Sugar 0.117 and Gears; on hover is style change and tooltip, as you say. But same platform using a Python GTK activity responds by opening the palette. The difference in response is unexpected, and I don't know which response is the right one to plan for in future. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#129 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABQYSY3YKUKHDIOEYA3XWLRKARDBANCNFSM4D4AOPNQ>.

[quozl]

I expect as it would be a user experience breaking-change for Sugarizer, that hover won't be added. @llaske, please confirm you have no plans for this? Only reason I can think of is user experience similarity with Sugar, and that's not a requirement I foresee.

[cheongsiuhong]

Hi all, I'm currently experimenting on it but pop up on hover can be implemented by adding an event listener for "mouseover". Shall I open a pull-request and work it out from there?

edit: Also, this current implementation is bugged! If you were to click on the palette itself (to type the activity name, or something), it would close the palette! Probably not the intended behavior.

[quozl]

I expect implementing would be easy. It's the design and user experience issue that we must resolve first. I'll wait to hear from @llaske. Only a small group is interacting here. We could also widen the discussion to the mailing list, but if @llaske isn't interested, I don't think it would help to do so.

[cheongsiuhong]

Given that sugar-web for sugarizer has diverged quite a fair bit and is no longer similar to the one in this repository, implementing changes in both versions of sugar-web might be an issue.

However, I have managed to implement hover with just changes in palette.js. A diff of palette.js from both native sugar-web and sugarizer sugar-web shows that they are both still identical and thus implementing the fix in both versions should be trivial.

If @llaske is interested in making the change, I would be more than happy to provide the code.

In my opinion, since both sugar and sugarizer are mostly synonymous in their purpose and design concept, they should both adhere to a similar design with regards to the user experience as much as possible. However, I have only recently started to look into this project, so take what I say with a grain of salt.

@llaske , your input would be useful on this matter, as it could affect the course of future works on the sugar-web library.

[llaske]

Sugarizer targets not only computers, it targets also devices with touch screen.
So we can't rely on a "mouseover" event to change the state of a palette.So for being consistent between platforms supported by Sugarizer, I think it's better to wait for an explicit click/touch to open/close a palette.

[quozl]

Thanks. Same with Sugar; a palette opened with a click cannot be closed by mouseover, and vice versa.