-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Application menu bar #15893
Application menu bar #15893
Conversation
…n the DropdownView ecosystem to prevent breaking changes.
… obsolete check button view class.
…elow the menu bar.
Internal (ui): Implemented the MenuBarView component (and dependencies). Used the prototype in the ClassicEditor along with several example integrations.
Feature (block-quote): Added menu bar integration to the block quote package.
Internal (horizontal-line): Added menu bar integration. Related to #15894.
Internal (page-break): Added menu bar integration. Related to #15894.
Internal (remove-format): Added menu bar integration. Related to #15894.
…enu bar config normalization.
Internal (ui,editor-classic): Streamlined the menu bar config normalization. Made the feature an opt-in in the `ClassicEditor`. Related to #15894.
Internal (theme-lark): Fixed the spacing in buttons without icons.
Internal (core): Added menu bar entry in the a11y dialog.
…ermine correct behaviors of the menu bar in a localized editor.
Internal (ui): RTL support for the menu bar.
Internal (document-outline): Added Table of contents button in default menu bar structure. Internal (restricted-editing): Refactored the restricted editing buttons in the menu bar.
Internal (editor-decoupled): Add menu bar to decoupled editor. Related to #15894.
…s. (#16126) Internal (ui): Defined the final structure of the menu bar. Localized sub-menu labels.
Co-authored-by: Michał Remiszewski <[email protected]> Co-authored-by: Aleksander Nowodzinski <[email protected]> Co-authored-by: Michał Remiszewski <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went through the PR and left some documentation-related comments and other loose thoughts, that we don't need to improve unless you strongly agree.
But, there is one thing that I don't like and it is the number of MenuBar*
components that exist and need to be used to craft a UI component for menu bar. E.g. MenuBarMenuListItemView
seems like an unnecessary complication for a plugin developer. If the component is really needed, maybe we could at least hide it from the developer.
Instead, the way I see it is that we have a small, defined set of items that can end up in the menu bar lists. Contrary to the toolbar, we don't want flexibility here. We agree that not everything makes sense in the menu bar. So, as I said, we have small lists of components to choose from.
Instead of crafting the components from the building blocks, it would be better (and safer!) to just give the developers the components. AFAICS we have four components now:
- button -- a "leaf" in the menus structure, you click it and it makes an action and closes the menu bar, some of them are "toggles" (can be enabled, and have aria-checked attribute), this could be a parameter in the constructor,
- file button -- probably it must be a separate component from the regular button,
- sub-menu -- a button that opens a new menu, all I should care about is providing components for the menu, not creating the menu bar list view by hand and link it with other components (I mean things like event delegations),
- dropdown -- a button that opens an arbitrary view in a dropdown, for things like color picker or table insertion grid, all I should care about is to provide the view.
So, we should have four "top-level" classes to be used by a plugin developer, with precise parameters in constructors and standarized behaviors.
I know that it sounds easy but then may get complicated in the details, especially I believe focus handling and keystrokes handling may be difficult for the dropdown component. But we should strive for the above, we should make it easy for plugin developers to provide the components. Right now, if I were to provide such component, I would be all in fear that I forgot to set some property, bind some observable, delegate an event, etc. Basically it is impossible to create a correct component without copy pasting existing, similar one.
(PS. this would not be a breaking change - we can build it over the existing components and update integrations as we go, depending on how much time we have.)
@@ -120,35 +173,59 @@ export default class AlignmentUI extends Plugin { | |||
} | |||
|
|||
/** | |||
* Helper method for initializing the button and linking it with an appropriate command. | |||
* Creates a menu for all alignment options to use either in menu bar. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something is wrong with this line. "either" is unnecessary or you wanted to write something more here.
const listItemView = new MenuBarMenuListItemView( locale, menuView ); | ||
const buttonView = new MenuBarMenuListItemButtonView( locale ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do these two must be separate classes? Couldn't the button extend the list item view? I would lean towards limiting the number of different classes and wrapper-components. It seems like there's a lot of boilerplate to create when creating menu items, which are quite simple and limited by design (in contrary to toolbar components where we want to allow including anything).
* By default, a {@link module:ui/menubar/utils#DefaultMenuBarItems default set of items} is used that already includes | ||
* **all core editor features**. For you convenience, there are `config.menuBar.addItems` and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* By default, a {@link module:ui/menubar/utils#DefaultMenuBarItems default set of items} is used that already includes | |
* **all core editor features**. For you convenience, there are `config.menuBar.addItems` and | |
* By default, a {@link module:ui/menubar/utils#DefaultMenuBarItems default set of items} is used. It includes | |
* **all loaded official editor features**. For you convenience, there are `config.menuBar.addItems` and |
* * `menu` – A {@link module:ui/menubar/menubarview#MenuBarMenuDefinition definition of a menu} that should be added to | ||
* the menu bar, | ||
* * `group` – A {@link module:ui/menubar/menubarview#MenuBarMenuGroupDefinition definition of a button group} that should be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's change the order here so we will go from smallest to biggest component (or the other way). Right now it is just mixed.
* * `'end'` – Adds a top-level menu (e.g. "Format", "Insert", etc.) at the end of the menu bar, | ||
* * `'end:GROUP_OR_MENU'` – Adds a button/group at the end of the specific group/menu, | ||
* * `'after:BUTTON_OR_GROUP_OR_MENU'` – Adds a button/group/menu right after the specific button/group/menu, | ||
* * `'before:BUTTON_OR_GROUP_OR_MENU'` – Adds a button/group/menu right after the specific button/group/menu. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* * `'before:BUTTON_OR_GROUP_OR_MENU'` – Adds a button/group/menu right after the specific button/group/menu. | |
* * `'before:BUTTON_OR_GROUP_OR_MENU'` – Adds a button/group/menu right before the specific button/group/menu. |
* A menu {@link module:ui/menubar/menubarmenuview~MenuBarMenuView#buttonView} class. Buttons like this one | ||
* open both top-level bar menus as well as sub-menus. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* A menu {@link module:ui/menubar/menubarmenuview~MenuBarMenuView#buttonView} class. These buttons
* are used both for top-level bar menus as well as in sub-menus.
/** | ||
* Adding unsupported components to the {@link module:ui/menubar/menubarview~MenuBarView} is not possible. | ||
* | ||
* A component should be either a {@link module:ui/menubar/menubarmenuview~MenuBarMenuView} (sub-menu) or a | ||
* {@link module:ui/menubar/menubarmenulistitembuttonview~MenuBarMenuListItemButtonView} (button). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't mention file dialog button view -- is this on purpose?
/** | ||
* The name of the position of the {@link #panelView}, relative to the menu. | ||
* | ||
* **Note**: The value is updated each time the panel gets {@link #isOpen open}. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* **Note**: The value is updated each time the panel gets {@link #isOpen opened}.
|
||
/** | ||
* The names of the positions of the {@link module:ui/menubar/menubarmenupanelview~MenuBarMenuPanelView}. | ||
* | ||
* They are reflected as CSS class suffixes on the panel view element. | ||
*/ | ||
export type MenuBarMenuPanelPosition = 'se' | 'sw' | 'ne' | 'nw' | 'w' | 'e'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't we have these registered in a different place?
return buttonView; | ||
buttonView.extendTemplate( { | ||
attributes: { | ||
'aria-checked': buttonView.bindTemplate.to( 'isOn' ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this could be just default behavior of a button. But then isOn
would need to be able to take undefined
state.
Suggested merge commit message (convention)
Feature (ui,editor-classic,editor-decoupled): Implemented the application menu bar that contains various options and commands for controlling and navigating the editor. Closes #15894.
MINOR BREAKING CHANGE (upload): The
FileDialogButtonView
class has been moved fromckeditor5-upload
tockeditor5-ui
. Please update your import paths accordingly (was:import { FileDialogButtonView } from 'ckeditor5/src/upload.js';
, is:import { FileDialogButtonView } from 'ckeditor5/src/ui.js';
).MINOR BREAKING CHANGE (theme-lark): The default vertical spacing around
ButtonView
inListItemView
(--ck-list-button-padding
) has been reduced for better readability. This affects the presentation of various editor features that use this type of UI (headings, font size, font family, etc.). You can restore the previous value by setting--ck-list-button-padding: calc(.2 * var(--ck-line-height-base) * var(--ck-font-size-base)) calc(.4 * var(--ck-line-height-base) * var(--ck-font-size-base));
in your custom styles sheet.Additional information
Requires https://github.com/cksource/ckeditor5-commercial/pull/6072