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

Allow disabling resize handles when using resize buttons #7579

Closed
jodator opened this issue Jul 8, 2020 · 5 comments · Fixed by #7654
Closed

Allow disabling resize handles when using resize buttons #7579

jodator opened this issue Jul 8, 2020 · 5 comments · Fixed by #7654
Assignees
Labels
package:image type:improvement This issue reports a possible enhancement of an existing feature.

Comments

@jodator
Copy link
Contributor

jodator commented Jul 8, 2020

Provide a description of the task

The ImageResize plugin was refactored to common glue plugin that requires:

  • ImageResizeEditing - for command and image resize handles
  •  ImageResizeUI - for dropdown and buttons

However, we've identified that not everybody would like to have buttons and resize handles and it would be nice to configure ImageResizeEditing feature so that handles are optional (as opt-out to have backward compatibility if possible).

I can see two options:

  1. Split the ImageResizeEditing to two - but the question remains how to name the resulting plugins (and how to keep backward compatibility for previous ImageResize plugin - or introduce breaking change.
  2. Use configuration option, ie: config.imageResizeHandles: false (or similar).
@jodator jodator added the type:improvement This issue reports a possible enhancement of an existing feature. label Jul 8, 2020
@jodator jodator self-assigned this Jul 8, 2020
@Reinmar
Copy link
Member

Reinmar commented Jul 8, 2020

What about this:

ImageResize: requires = [ ImageResizeEditing, ImageResizeHandles, ImageResizeButtons ]

Right now, you enable ImageResize and that will still work.

If you'll want buttons only – you'll load ImageResizeEditing + ImageResizeButtons

If you'll want handles only – you'll load ImageResizeEditing + ImageResizeHandles

Do I miss something?

@jodator
Copy link
Contributor Author

jodator commented Jul 8, 2020

Do I miss something?

No, this is also a way to go. I like the naming, so probably it is a way to go :)

@jodator jodator assigned panr and unassigned jodator Jul 13, 2020
@jodator jodator added this to the iteration 34 milestone Jul 13, 2020
@panr
Copy link
Contributor

panr commented Jul 16, 2020

@Reinmar your granular approach is OK, but IMHO it'd be nice to have the opt-out option (config.imageResizeHandles: false) for handles as well if someone is already using the ImageResize plugin. I think it's convenient. Or is it too much?

@jodator
Copy link
Contributor Author

jodator commented Jul 16, 2020

Or is it too much?

We tend to have less config options if possible so configuring (opting-out) by plugins configuration in build would be OK.

@Reinmar
Copy link
Member

Reinmar commented Jul 21, 2020

We tend to have less config options if possible so configuring (opting-out) by plugins configuration in build would be OK.

Exactly.

jodator added a commit that referenced this issue Jul 23, 2020
Other (image): Allow to configure `ImageResize` in a more granular way. For example, by combining `ImageResizeEditing` with `ImageResizeHandles` or `ImageResizeButtons` to resize image by handles or by image toolbar UI components (dropdown or standalone buttons) respectively. Closes #7579.

Docs (image): Add a new section to feature documentation for the `Image` plugin about disabling image resize handles.

Internal (image): Separate `ImageResizeHandles` plugin from the `ImageResizeEditing`.

Tests (image): Refactor unit tests for `ImageResizeHandles` and `ImageResizeEditing`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
package:image type:improvement This issue reports a possible enhancement of an existing feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants