Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#374 closed defect (fixed)

color chooser behaves differently than the rest of the menus

Reported by: sascha_silbe Owned by: benzea
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: design Version: Git as of bugdate
Severity: Unspecified Keywords:
Cc: benzea, tomeu, erikos Distribution/OS: Unspecified
Bug Status: Unconfirmed


The color chooser opens on right click or delay, unlike all other menu items I've tested, which react to left click instead.
That's confusing.

Change History (7)

comment:1 Changed 12 years ago by sascha_silbe

  • Component changed from sugar-toolkit to design

After discussion with erikos on IRC, it actually seems not to be as different as I originally thought.
First delay will bring up the tooltip, like it does for other menu buttons (where right click does the same). Second delay / right click will bring up the actual color chooser. None of the other menu buttons I've seen so far had additional capabilities and the xo figure in the home view behaves the same.
OTOH, both the other existing "chooser" menu items (e.g. drop down list, table) and the rest of the menu buttons react to left click, while the color chooser doesn't do anything on left click.

Personally, I'd expect left click to activate the color chooser. But that might simply be a matter of being conditioned to left click as primary means of activation.

As a last (and probably least important) point I'd like to note that depending on right click (even if just to reduce the delay, as delays can get quite annoying) will increase the effort needed to port Sugar to touchscreens. Don't known whether or not Sugarlabs cares about that.

comment:2 Changed 12 years ago by erikos

  • Owner changed from benzea to eben
  • Status changed from new to assigned

comment:3 Changed 12 years ago by eben

  • Cc benzea tomeu erikos added

Ah, that's bad! That's what I get for not having a chance to actually test it. =)

The color chooser is what we (the designers) have been referring to as a "palette button." The button serves the sole purpose of revealing the associated palette. As such, the primary action of a palette button should be to reveal the palette on left click, and hide it on a second click (just like most menus). For consistency, right-click can be redundant and serve the same function.

Another way to think of this is as a dialog. Sugar, for the most part, avoids dialog windows. It does so, in many cases, by attaching the dialog to a button in the form of a palette. Some buttons use palettes for secondary adjustments and configuration—contextual settings, so to speak—but palette buttons simply serve to reveal the information in the palette.

We have a design for this which includes the automatic addition of a little gray downward pointing arrow to the right of the button to indicate the difference in function, but that hasn't been implemented yet. Likely, we'll just subclass ToolButton as PaletteToolButton and wrap it so as to add the arrow, but keep the API otherwise the same. benzea, do you have any input in this area, or is a basic subclass all we need?

comment:4 Changed 12 years ago by benzea

I think the problem is that the secondary palette is not revield immediately if the show_palette function is called with immediately=True.

comment:5 Changed 12 years ago by eben

  • Owner changed from eben to benzea

Actually, I think the confusing aspect of the API is that you need to specify both immediate=True and state=SECONDARY. Otherwise, only the primary palette is revealed. Note sugar/graphics/ in the right-click function; we know this works since right click reveals the secondary palette immediately as desired.

comment:6 Changed 12 years ago by benzea

  • Resolution set to fixed
  • Status changed from assigned to closed

Ah, thanks Eben. I did not know about the state=SECONDARY thing. I have added code to do the popup/popdown correctly now.

About the little arrow for these kind of palettes. I am not sure how to best do that. I guess just drawing an arrow after the children could work fine.

comment:7 Changed 12 years ago by sascha_silbe

Works as expected now, thanks!

Note: See TracTickets for help on using tickets.