emojis for mouse buttons?

Philippe Verdy via Unicode unicode at unicode.org
Wed Jan 1 09:24:36 CST 2020

this is user's settings; the OS and softwares will automatically adapt to
these settings to display the proper label or icon, as well they'll be able
to document them accordingly.
Primary/secondary/ternary buttons are not used, even in the OS itself (the
mouse drivers will remap the internal events when configuring the mouse for
left-hand). If needed (when they want to document the difference for
right-hand or left-hand, they will change the label, icon or character;
there's no reason to not use the left vs. right indication of the button
for the mouse buttons (I think it's definitely better to force applications
to change the character accordingly; usually "left click" is just named
"click" (not "primary click"), but "right click" is used everywhere (may be
contextually changed to "left click where appropriate to document the
left-hand behavior).
Also I do not advocate a glyph limited to a mouse, the character being
encoded as well if it shows a square touchpad. And the wired vs. wireless
is not relevant here as we just want to be able to conventiently document
key mappings used by applications and present them the same way as other
keys on a keyboard (even iof the keyboard is virtual on a tactile screen).
Those that want a real mouse and real wired or wireless distinction or
touchpad, do not need a distinction of clicked buttons, and they already
have characters encoded for them including for emojis, but these are NOT
usable to document key mappings that are so frequently needed in apps (e.g.
menus showing shortcuts) and their documentation.

Le mer. 1 janv. 2020 à 16:08, John W Kennedy <john.w.kennedy at gmail.com> a
écrit :

> As I have already said, this will not do. Mouses do not have “left” and
> “right” buttons; they have “primary” buttons, which may be on the left or
> right, and “secondary” buttons, which may be on the right or left. If this
> goes through, users with left-handed mouse setups will curse you forever.
> --
> John W. Kennedy
> "Compact is becoming contract,
> Man only earns and pays."
>  -- Charles Williams.  "Bors to Elayne:  On the King's Coins"
> > On Jan 1, 2020, at 6:43 AM, Marius Spix via Unicode <unicode at unicode.org>
> wrote:
> >
> > Cecause the middle button of many mice is a scroll button, I think, we
> > need five different characters:
> >
> > LEFT MOUSE BUTTON CLICK (mouse with left button black)
> > MIDDLE MOUSE BUTTON CLICK (mouse with middle button black)
> > RIGHT MOUSE BUTTON CLICK (mouse with right button black)
> > MOUSE SCROLL UP (mouse with middle button black and white triangle
> > pointing up inside)
> > MOUSE SCROLL DOWN (mouse with middle button black and white triangle
> > pointing down inside)
> >
> > These characters are pretty useful in software manuals, training
> > materials and user interfaces.
> >
> > Happy New Year,
> >
> > Marius
> >
> >
> >
> >> On Tue, 31 Dec 2019 23:04:39 +0100
> >> Philippe Verdy via Unicode <unicode at unicode.org> WROTE:
> >>
> >> Playing with the fiolling of the middle cell to mean a double click
> >> is a bad idea, it would be better to add one or two rounded borders
> >> separated from the button, or simply display two icons in sequence
> >> for a double click).
> >>
> >> Note that the glyphs do not necessarily have to show a mouse, it
> >> could as well be a square with its lower third part split into two or
> >> three squares, like a touchpad (see the notification icons displayed
> >> by Synaptics touchpad drivers). The same rounded borders could also
> >> mean the number of clicks. As well, if a ouse is represented, it may
> >> or may not have a wire.
> >>
> >> Emoji-styles could use more realistic 3D-like rendering with extra
> >> shadows...
> >>
> >> Le mar. 31 déc. 2019 à 22:16, wjgo_10009 at btinternet.com via Unicode <
> >> unicode at unicode.org> a écrit :
> >>
> >>> How about the following.
> >>>
> >>> A filled upper cell to mean click,
> >>>
> >>> a filled upper cell and a filled middle cell to mean double click,
> >>>
> >> Note that clicking and maintaining the button is just like the
> >> convention of using "+" after a key modifier before the actual key
> >> (both key may be styled separately to decorate their glyphs into a
> >> keycap, but such styling should not be applied in the distinctive
> >> glyph; there may also be emoji sequences to combine an anonymous
> >> keycap base emoji with the following characters, using joiner
> >> controls, but this is more difficult for keys whose labels are texts
> >> made of multiple letters like "End" or words like "Print Screen",
> >> after a possible Unicode symbol for keys like Page Up, Home, End,
> >> NumLock; styling the text offers better option and accessibility even
> >> if symbols are used and a whole translatable string is surrounded by
> >> deocrating styles to create a visual keycap).
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20200101/3de763d2/attachment.html>

More information about the Unicode mailing list