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

Let us set max width. *feature request* #69

Open
freed00m opened this issue Oct 1, 2018 · 12 comments · May be fixed by #509
Open

Let us set max width. *feature request* #69

freed00m opened this issue Oct 1, 2018 · 12 comments · May be fixed by #509

Comments

@freed00m
Copy link

freed00m commented Oct 1, 2018

Hi,

I use both long and short notification in terms of line lenght. I can set width but that's looking ugly for short notification.

See screenshot of what I mean, or maybe honoring the line break and calculate the lenght of the longest line?

2018-10-01-232102_grim
2018-10-01-232201_grim

@vilhalmer
Copy link
Collaborator

Hmm. A max-width option would also imply that we'd need min-width, and have width override both of them if it is specified, which is adding quite a bit of complexity to the configuration. I don't think we want width to behave like height in this case, where it is implicitly a maximum. Having both the width and the height flexible also creates complications. How do you decide which direction to expand first?

Once #46 is fixed, you'll be able to specify width by matching on the application sending the notification or similar, would this be sufficient?

@vilhalmer
Copy link
Collaborator

Ping since #46 is closed.

@Babadabupi
Copy link

Another idea might be to allow notifications to shrink, instead of having a fixed width. This way you could then set the width to eg. 500 or more, and still have smaller notifications displayed nicely without much whitespace.

@freed00m
Copy link
Author

freed00m commented Mar 3, 2019

@vilhalmer OK, so what about it not being a px dimension but a character count length? Then you would expand till, you reach the defined int parameter and then you would force a breakline.

max-line-chars ?

@Gigg1ty I don't get it, you just described the behavior that would be achieved by working max-width :D

@emersion
Copy link
Owner

emersion commented Mar 3, 2019

max-line-chars

Not a fan of this. Doesn't play well with non-monospace fonts, duplicates functionality.

@Babadabupi
Copy link

@freed00m Um, i guess you are right 😅 But my thinking was that a min-width would not really be required this way, as notifications could be allowed to be as short as a single character.

@freed00m
Copy link
Author

freed00m commented Mar 3, 2019

@emersion that's true.
Ignoring all the arabic ligature weirdness where two characters are often shorter than single one. Is there a way to get font's character px length? I think dunst just uses some pango font width as reference and hopes every other font fits more or less.

@ghost
Copy link

ghost commented Jul 20, 2020

Can we introduce a shrink option in mako like @Gigg1ty suggested? Let the width and height implementation remain as it is.

@nagy135
Copy link

nagy135 commented Nov 8, 2021

Ideal would be something like dunst has, width = (20,300) where it is either (min,max) pair like this or single digit if you want fixed width, but me personally would be satisfied with just shrinking

@nnuel
Copy link

nnuel commented Jan 27, 2022

Yes, I too would be happy to have shrinking for the width parameter and the normal setting of width. So 300 and then anything lower gets shrunk like it would with height.

@apprehensions
Copy link

Will this be implemented someday?

@sudoharun
Copy link

I'm also looking forward to the day this gets implemented.

apprehensions added a commit to apprehensions/mako that referenced this issue Mar 22, 2024
@apprehensions apprehensions linked a pull request Mar 22, 2024 that will close this issue
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 a pull request may close this issue.

8 participants