Icons and separators not shown in contextual menu

[demarey]

In PL, commands define icons and belong to group.
They should be displayed in contextual menu

[estebanlm]

separators is an issue... icons are not, I removed them by design (not cool to show icons in menus, in current UIs... it makes them feel cluttered)

[astares]

@estebanlm

I think this "cluttered" is related to your own personal style and preference. In most UI systems (Win, Linux, Mac, ...) you will definitely find icons in context menues:

Also Wikipedia article says:
"On some user interfaces, context menu items are accompanied by icons for quicker recognition upon navigation"

If Pharo does not want to look like an alien it should support icons in context menus (maybe with a setting to hide them for people who think it is cluttering the UI)

[estebanlm]

1. most of those icons are applications, not actions.
2. most of those menus confirm, not refute, my point. They look messy.
3. exception would be as always mac, but they have millions to pay for icon/menu design we don't (I see they just have some icons, not a lot, same design that ubuntu is taking).

in conclusion, I stay in my design decision :P
anyway to remove the clean menus and go back to a messy (and ugly, because our icons are not designed for our specifics) is easy, tomorrow I will send the line to touch.

EDIT: Extending my point of view, here, I want to argue that most of the times, a lot of icons produces the contrary of "quick recognition" : as they are too many, very often they confuse more than they help. Said that, I would not be contrary to let some particular actions with icons, but they are not mandatory (and there be a clear criteria)

[Ducasse]

@estebanlm this is a belief.
This is latest safari and we are talking about actions. Icons help. Now when I asked lusy to design icons she did it for nothing and I spent hours with her. But they were not flat enough.
Now if you want icons thales guys have all the icons of ant.design and more.

[Ducasse]

https://github.com/ant-design/ant-design-icons

For Pharo: https://github.com/OpenSmock/Iconography
Material design and ant icons.

GitHub

GitHub - ant-design/ant-design-icons: ⭐ Ant Design SVG Icons

⭐ Ant Design SVG Icons. Contribute to ant-design/ant-design-icons development by creating an account on GitHub.

GitHub

GitHub - OpenSmock/Iconography: Use icons libraries (Material Design, Ant Design) in your project : Import, manage, get and store.

Use icons libraries (Material Design, Ant Design) in your project : Import, manage, get and store. - OpenSmock/Iconography

[estebanlm]

is not a problem of icons, this ones (I know them, you know) are nice but still not designed for us: they are general purpose icons and as all of them, they start to fail when you want some specific tasks icons...

and even then, they still do not fulfill the problem than icons and menus require design, is not just "add icons, they will be better".

in design of UI world there are two schools (bah, there are several, but 2 in the extremes) :
one says a clean interface is easier to understand than a charged one. This is the design of the first days of mac (now is changing, again... it has done it several times), Gnome and other UIs.
the other says the opposite: they want detail at maximum so charged is not a problem.

of course, you can have nice results with both sides of the coin... but there is a catch: implement the second is a lot more resource intensive than the first one.

So, I prefer the first school, not just because for me, the less charged the better, and also I do not want to spend (not just me, any of us) an amount of time we do not have to have a good second approach (charged), I think this is our better solution.

So yes... this is a belief... but thinking the other is a belief too.

I am trying to choose the best solution with our constraints and the new PL GTK already implements the "clear UI" design, so not putting icons in the menu will not make the UI suffer but look coherent (and coherence is also a UI tip).

said that, I am not against any icons, I think some actions (specially the ones that open windows/panels that can be identified with them) are good: just no time to work on them now and we can always add them later.

[estebanlm]

Here’s a clear, comparative summary (made with the help of you-know-what 😜 ) of the three most common Human Interface Guidelines (Apple / Windows / GNOME), what they say about menus & icons, and why some exceptions exist (like Safari).

This is the “mental model” designers actually use :

The three philosophies at a glance

Platform	Default stance on icons in menus	Philosophy
macOS (Apple)	Discouraged	Stability & muscle memory
Windows (Microsoft)	Encouraged	Recognition & discoverability
GNOME	Strongly discouraged	Semantic clarity & minimalism

1. Apple (macOS HIG)

Apple

What Apple says

• Menus are primarily textual
• Icons are exceptions, not defaults
• Icons may appear only when they improve recognition
• Menu bar menus should generally be icon-free
• Icons must be:
  • Template (monochrome)
  • Meaningful
  • Consistent
  • Non-decorative

Why Apple is strict

• macOS users rely heavily on:
  • Keyboard shortcuts
  • Text scanning
  • Long-term muscle memory
• Menus are treated as a stable command vocabulary
• Visual noise is considered harmful in menus

Why Safari is allowed to bend the rules

Safari is:

• A first-party, system-defining app
• A reference implementation
• A place where Apple tests patterns before documenting them
• (this is what they say...)

Safari’s menu icons:

• Mirror toolbar icons
• Represent already-learned concepts
• Are tightly controlled and sparse

Key Apple rule (implicit):

System apps may explore patterns; third-party apps should wait for the HIG.

So Safari doesn’t “break” the HIG — it defines (possibly) its future edges.

2. Microsoft (Windows / Fluent Design)

Microsoft
Fluent Design System

What Microsoft says

• Icons in menus are normal and recommended
• Especially encouraged in:
  • Context menus
  • Frequently used commands
  • Destructive or important actions
• Icons should:
  • Improve recognition
  • Match toolbar/ribbon icons
  • Be consistent

Why Microsoft encourages icons

• Windows prioritizes:
  • Visual scanning
  • Discoverability
  • Mouse, touch, and pen usage
• Large, heterogeneous user base
• Less reliance on keyboard-only workflows

Menus are seen as action palettes (and they are often just a menu representation of a ribbon), not just command lists.

Exceptions?

Windows doesn’t really need them — icons are already first-class.
The rule is consistency, not restraint.

3. GNOME (GNOME HIG)

GNOME
GNOME Human Interface Guidelines

What GNOME says

• Menus should be:
  • Simple
  • Textual
  • Uncluttered
• Icons in menus are strongly discouraged
• Menus are for experienced users
• Icons belong on:
  • Buttons
  • Toolbars
  • Header bars

GNOME is even stricter than Apple.

Why GNOME is so strict

• Strong focus on:
  • Accessibility
  • Localization
  • Semantic clarity
• Menus are considered structural UI, not visual UI
• Icons are seen as:
  • Redundant
  • Ambiguous
  • Often decorative

Exceptions?

Very rare.
Only when:

• The icon is universally understood (e.g. cut&paste, print actions...)
• The command is extremely common
• The entire menu is consistent

In practice: almost never.

Why these three differ so much

Platform	Core UX belief
Apple	“Menus are muscle memory”
Microsoft	“Menus should be easy to recognize at a glance”
GNOME	“Menus are semantic tools”

Safari-style exceptions exist only where:

• The platform owner controls the full UX
• The app defines platform behavior
• The pattern may later become official

That’s true for Safari, Finder, Explorer — never for random apps.

Practical takeaway

• If you’re designing for macOS or GNOME:
  → Text-only menus are the safest and most native choice
• If you’re designing for Windows:
  → Icons in menus are expected and often beneficial
  • If you see Apple “breaking” its own rules:
    → It’s usually probing the future, not contradicting itself

One-sentence summary

Windows treats menus as visual action lists; macOS treats them as textual command vocabularies; GNOME treats them as semantic tools — and only Apple’s own apps are allowed to stretch the rules to evolve the system.

[estebanlm]

... so, I tend to stick with mac and even gnome HIG, again for practical reasons:

• Designing and using icons is hard, time consuming and often they do not actually help.
• we design applications (the pharo launcher, pharo itself) for programmers... and thinking on long term usage
  • the muscle memory becomes important
  • how they tend to interact with menus? do they rely more on keyboard or mouse... ? do they need to explore -which is a casual usage of the menus- or they tend to learn once, then adopt ?
  • when you are using a tool (and a menu) all the time, less visual charge finishes being better than a charged visual charge: is more mentally relaxing.
  • At the end, I think we can make a better work avoiding superfluous icons

[guillep]

Be careful, generative AI just told me that the Nintendo Switch 2 is a fake :P (JOKE! Don't take me seriously)

[svenvc]

@estebanlm you do know that in the latest macOS (26), menu icons were added (but most people hate them, mostly because they are unclear) ?

Also, in may applications, half of them are missing or not used.

[estebanlm]

Yes, I know... but I am quoting this: https://developer.apple.com/design/human-interface-guidelines/menus#Icons

**Don’t display an icon if you can’t find one that clearly represents the menu item. ** Not all menu items need an icon. Be careful when adding icons for custom menu items to avoid confusion with other existing actions, and don’t add icons just for the sake of ornamentation."

I think those HIG are good, and is a shame if apple itself decides to not to stick with them, but this is their decision . I do have
and I stated it before the insights of why I think we should stick with their HIG.

Apple Developer Documentation

Menus | Apple Developer Documentation

A menu reveals its options when people interact with it, making it a space-efficient way to present commands in your app or game.

[svenvc]

https://tonsky.me/blog/tahoe-icons/

One fun fact is that apparently Apple's Pro apps do not follow many of the recent changes, even though they were just updated.

I agree with the points that menu icons are not really necessary, are often confusing, are hard to make clear and thus are not easy to 'just add'.

tonsky.me

It’s hard to justify Tahoe icons

Looking at the first principles of icon design—and how Apple failed to apply all of them in macOS Tahoe

[estebanlm]

https://tonsky.me/blog/tahoe-icons/

what a good read, thanks for it :)

tonsky.me

It’s hard to justify Tahoe icons

Looking at the first principles of icon design—and how Apple failed to apply all of them in macOS Tahoe