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

Optimize reply placeholder width #1119

Closed
eloquence opened this issue Jun 26, 2020 · 5 comments
Closed

Optimize reply placeholder width #1119

eloquence opened this issue Jun 26, 2020 · 5 comments
Labels
bug Something isn't working ux

Comments

@eloquence
Copy link
Member

eloquence commented Jun 26, 2020

This screenshot shows how, at a lower widow size (which will be supported once #1103 is merged), the "Compose a reply to" placeholder can be truncated for long source designations (the full codename is organizational implementation).

Screenshot from 2020-06-26 14-42-40

We should elide those codenames (#1120), but we should also optimize the width of the placeholder, which appears to currently be cut off where the "Send" button begins, even though it is always rendered above it.

@eloquence eloquence added enhancement New feature or request ux labels Jun 26, 2020
@eloquence eloquence added bug Something isn't working and removed enhancement New feature or request labels Aug 4, 2020
@eloquence
Copy link
Member Author

Unfortunately I don't see a simple way to avoid this issue. This screenshot illustrates the problem:

reply-layout

The textbox takes up as much space as is available, and the placeholder text is a child object of the text box. The only reasonable solution I see is to try to force the placeholder text to float on top of the textbox, instead of having it be layouted as a child object. That may add too much complexity to be worthwhile, and eliding the placeholder text (#1120) seems to get us bigger bang for the buck.

@ninavizz
Copy link
Member

ninavizz commented Aug 15, 2020

I'm also not keen on what looks like a tabled layout, with the airplane in its own column?
Does QT do z-axis type layering of objects?

(...she says, keenly watching the hardworking dev team hold it together as to not wither in tears of frustration after having spent scores of hours just trying to work within QTs constraints so that it does not implode)

@eloquence
Copy link
Member Author

eloquence commented Aug 20, 2020

There are a few different strategies Allie and I have discussed for this, but for now we're deferring it in favor of #1120. It would still be nice to eventually solve to get those extra pixels, provided it doesn't add significant technical debt/complexity.

@eloquence
Copy link
Member Author

With #1145 merged, upon consideration, I'd nominate to close this; the "..." abbreviation should give us enough space and looks sufficiently polished, IMO.

@eloquence
Copy link
Member Author

Closing per above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working ux
Projects
None yet
Development

No branches or pull requests

2 participants