Skip to content
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

Merged
merged 164 commits into from
Apr 2, 2024
Merged

Application menu bar #15893

merged 164 commits into from
Apr 2, 2024

Conversation

oleq
Copy link
Member

@oleq oleq commented Feb 21, 2024

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 from ckeditor5-upload to ckeditor5-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 in ListItemView (--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

oleq and others added 30 commits January 29, 2024 16:25
…n the DropdownView ecosystem to prevent breaking changes.
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.
oleq and others added 24 commits March 28, 2024 11:01
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]>
@DawidKossowski DawidKossowski marked this pull request as ready for review April 2, 2024 17:20
@oleq oleq merged commit f072048 into master Apr 2, 2024
5 of 6 checks passed
@oleq oleq deleted the ck/app-menu-bar branch April 2, 2024 18:30
Copy link
Contributor

@scofalik scofalik left a 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.
Copy link
Contributor

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.

Comment on lines +199 to +200
const listItemView = new MenuBarMenuListItemView( locale, menuView );
const buttonView = new MenuBarMenuListItemButtonView( locale );
Copy link
Contributor

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).

Comment on lines +205 to +206
* 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* 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

Comment on lines +273 to +275
* * `menu` &ndash; A {@link module:ui/menubar/menubarview#MenuBarMenuDefinition definition of a menu} that should be added to
* the menu bar,
* * `group` &ndash; A {@link module:ui/menubar/menubarview#MenuBarMenuGroupDefinition definition of a button group} that should be
Copy link
Contributor

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'` &ndash; Adds a top-level menu (e.g. "Format", "Insert", etc.) at the end of the menu bar,
* * `'end:GROUP_OR_MENU'` &ndash; Adds a button/group at the end of the specific group/menu,
* * `'after:BUTTON_OR_GROUP_OR_MENU'` &ndash; Adds a button/group/menu right after the specific button/group/menu,
* * `'before:BUTTON_OR_GROUP_OR_MENU'` &ndash; Adds a button/group/menu right after the specific button/group/menu.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* * `'before:BUTTON_OR_GROUP_OR_MENU'` &ndash; Adds a button/group/menu right after the specific button/group/menu.
* * `'before:BUTTON_OR_GROUP_OR_MENU'` &ndash; Adds a button/group/menu right before the specific button/group/menu.

Comment on lines +19 to +20
* 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.
Copy link
Contributor

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.

Comment on lines +260 to +264
/**
* 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).
Copy link
Contributor

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}.
Copy link
Contributor

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}.

Comment on lines +102 to +108

/**
* 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';
Copy link
Contributor

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' )
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Application menu bar
4 participants