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

Double click on text layer to set width and height to auto #4602

Open
myfunnyandy opened this issue May 20, 2024 · 6 comments
Open

Double click on text layer to set width and height to auto #4602

myfunnyandy opened this issue May 20, 2024 · 6 comments

Comments

@myfunnyandy
Copy link
Contributor

myfunnyandy commented May 20, 2024

Is your feature request related to a problem? Please describe.

Text layers have 3 types of resizing properties: Fixed size, Auto width, and Auto height (see notation 8 at "Text options"). Switching among them is a fairly common option, but you can only do it by clicking their buttons on the design sidebar. We can allow a faster and more intuitive way to perform this action by clicking certain areas of the text bounding box.

image

Describe the solution you'd like.

At a selected text layer:

  • Double-click on the right side of the bounding to set the resize setting to auto-width.
  • Double-click on the bottom side of the bounding box to set the resize setting to auto-height.
@SimplyPhy
Copy link

SimplyPhy commented May 22, 2024

Furthermore, the default behavior in browsers is for text elements (whether wrapped, inline, or block) to fill the height of any element they're contained within. You have to go out of your way to prevent this behavior. Therefore, I recommend that text in Penpot to share this behavior (i.e. what's being called "auto-height").

It's unexpected for text not to fill the space it's confined to vertically. That's what led me to discover and comment on this issue.

Screen.Recording.2024-05-22.at.5.00.39.PM.mov

@jdittrich
Copy link

As-is they would need to know both that they can double click and that double clicks in different regions lead to different behaviors. How about providing some overlay icons as triggers for that behavior? This way, users could discover the feature and could guess what it does.

Here one quickly mocked up variant, trigger regions (size), the feedback on hover and the icon can be adjusted as needed.

a mocked up screenshot, showing a selected textbox with a frame indicating the selection; next to the left and bottom side is an icon indicating auto resize in that direction can be triggered by clicking the icon

@myfunnyandy
Copy link
Contributor Author

myfunnyandy commented Jun 5, 2024

@jdittrich I think this kind of feedback for this probably-non-intuitive interaction seems extremely useful for discoverability, it would be great to include it in the implementation.

@SimplyPhy
Copy link

SimplyPhy commented Jun 6, 2024

As-is they would need to know both that they can double click and that double clicks in different regions lead to different behaviors

@jdittrich love your idea for the reused iconography! That said, if for whatever reason the inclusion of your idea would lead to a delay in resolving the overarching issue with text field resizing in Penpot, I would encourage the team to fix the real more impactful issues first. Likewise, the icons could very well be bloat in practice. Most of the time when resizing text fields, Penpot ought to dynamically respond with the correct functionality; always showing icons to indicate otherwise invisible "double click" functionality could potentially be unnecessary and undesirable. For example, imagine moving your cursor along a table with lots of text fields, and they all have these icons appear all over the place as you hover.

Here's how Figma handles this situation, which I believe is very functional (possibly the icons could be an enhancement, but that's not clear to me).:

Screenshot.000040.mp4

As you can see, the text field sizing properties automatically update relative to what you do with the text, both resizing and double clicking.

@jdittrich
Copy link

jdittrich commented Jun 7, 2024

I would encourage the team to fix the real issues first

I would not distinguish between a "real" issues of speed and "not real" issues of usability here.

For example, imagine moving your cursor along a table with lots of text fields, and they all have these icons appear all over the place as you hover.

Like the selection outline and handlers, icons would only need to appear when selecting a text frame and not on hover.

@SimplyPhy
Copy link

SimplyPhy commented Jun 7, 2024

I would encourage the team to fix the real issues first

I would not distinguish between a "real" issues of speed and "not real" issues of usability here.

Understood, though I believe the mistake here is my use of the word "real". I should have said "more impactful". Adjusted my comment to clarify the intended message.

For example, imagine moving your cursor along a table with lots of text fields, and they all have these icons appear all over the place as you hover.

Like the selection outline and handlers, icons would only need to appear when selecting a text frame and not on hover.

Oh gotcha, nice.

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

No branches or pull requests

3 participants