Hi @mickaelistria
How about this ? (On Mac)

@mickaelistria,
Nice sight into realizing that, the current dialog box is assymetrical and gives an unfinished appearence.
Plus the border radius is inconsistent for all the upper and lower corners.
Good call!

@SougandhS, Thanks for that!
I think you understood exactly what the issue required. The dialogue box is balanced and well sized.
I was wondering though if the screenshot you provided was for a dark screen mode beacuse i believe maintaining the current light mode as primary good for now.

I was wondering though if the screenshot you provided was for a dark screen mode beacuse i believe maintaining the current light mode as primary good for now.

I have this weird issue on mac that child eclipse does not render other themes fully other than dark.

I'll raise PR for current change 👍

Do we have style guidelines for such as thing?

https://learn.microsoft.com/en-us/windows/apps/design/controls/dialogs-and-flyouts/dialogs

I've never seen a dialog with centered text and I question whether that's really better or easier to read.

-1. I don't like that new layout at all. Also consider message dialogs with icons. Plus there's a high risk that this breaks a lot of message dialogs with a custom area or other customizations. (If not "breaks", at least "makes them look inconsistent".)

Please don't do this.

Looking at UI recommendations and habits from various OS, such a dialog would seem more consistent with the current state of art.

Can you please provide some links to this recommendations and habits? And can you show what the "current state of art" is?

Another version without text centered

cc
@BeckerWdf
@tomaswolf
@SougandhS
@merks is right about dialogues not having centered text. It is evident in all the dialogue boxes we get all over having right aligned text.

Also, If we were to borrow ideas from the Dialogue Controls guidelines as suggested by @merks ,

1. "The "do it" action button(s) should appear as the leftmost buttons. The safe, nondestructive action should appear as the rightmost button."

• Which means even in our case, "Save" should appear as the leftmost button while "Don't Save" or 'Cancel' should appear as the rightmost button.

2. "Use specific responses to the main instruction or content as button text. An example is, "Do you want to allow AppName to access your location?", followed by "Allow" and "Block" buttons. Specific responses can be understood more quickly, resulting in efficient decision making."

• My question would be, what is the difference between "Don't Save" and "Cancel"? As both buttons seem to be doing the same thing which is forfeiting the action being called for.

I think a little more clarification on these subjects can help validate or solve the issue.

I should note though that different platforms have different conventions. E.g, the order of OK/Cancel is different on different platforms...

The 3 reference documents (that I think every Platform UI stakeholder needs to have as bookmark) are

• https://learn.microsoft.com/en-us/windows/apps/design/controls/dialogs-and-flyouts/dialogs
• https://developer.gnome.org/hig/patterns/feedback/dialogs.html
• https://developer.apple.com/design/human-interface-guidelines/alerts

The first one aligns left, while the 2 other ones do center. So there is no input to build a consensus. Let's be conservative here, and just start by saving the space without really touching the alignment.

FWIW, the order of buttons is not much related to the initial discussion. If someone wishes to discuss this further, I'd recommend opening a separate issue.

I just did this search:
https://github.com/search?q=repo%3Aeclipse-platform%2Feclipse.platform.ui%20MINIMUM_MESSAGE_AREA_WIDTH&type=code

I see that MINIMUM_MESSAGE_AREA_WIDTH is used in multiple dialogs. And even is API.
Should all of these should be adapted?

I see that MINIMUM_MESSAGE_AREA_WIDTH is used in multiple dialogs. And even is API.

That wouldn't hurt in theory, but because compilers inline constant values in consumers' bytecode, it's considered a breaking API change to change a constant value for primitive or string types. There are many consumers of this constant into the wild: https://github.com/search?q=MINIMUM_MESSAGE_AREA_WIDTH+language%3AJava&type=code&l=Java , which would either get the new value or not depending on the version of JFace in their target-platform when compiling... But changing it would for sure update the MessageDialog as it's compiled simultaneously.
The benefit of changing the method implementation just as proposed in the attached PR is that it's a method and the value can be overridden if anyone wants to do it; it's not a breaking change and it's not affecting consumers of this API variable.