Dunst: Redesigning the window geometry/dimension settings

Created on 15 Jul 2017  路  15Comments  路  Source: dunst-project/dunst

As mentioned in a comment in #335, a lot of the current display settings are built on top of each-other in a confusing way e.g. the height part of the geometry is actually number of notifications to be displayed, notification_height is the pixel height, or the confusion between width, dynamic width and shrink which takes some close reading of the documentation to understand the difference.

We should

  • [ ] Compile a list of use cases we should account for (feel free to post yours if it's not that well supported, or not supported at all)
  • [ ] Create a list of changes so that the end result is an intuitive configuration experience while not sacrificing any of the currently available functionality

As it stands, geometry is probably the most complicated part of the config since there are a lot of corner cases one might not predict. For example, if the width is omitted the message expands to cover the whole screen but if it's 0 it's considered dynamic and expands to the longest message.

After looking at the current implementation I came up with the following proposal:

Replace geometry shrink, notification_height with the following

  • minimum_width: The minimum pixel width for the notification as described in #335
  • minimum_height: The equivalent of notification_height
    If any of the minimum_* settings is zero, it is considered dynamic and will be shortened as needed.
  • maximum_width: The maximum width in pixels for the notification, when that limit is reached it will either be wrapped, or ellipsized according to word_wrap
  • maximum_height: The maximum height in pixels for the notification, after that limit is reached any further text is cut and ellipsized.
  • origin: A setting that can be set to topleft, bottomleft, middle, topright and bottomright corresponding to the location that the notification will be drawn at. middle would also account for the notification window length to account for proper centering as described in #233
  • offset_horizontal: The offset in pixels from the origin in the horizontal axis, can be positive (to the left) or negative (to the right
  • offset_vertical: As with offset_horizontal but in the vertical axis.
  • notification_limit: The maximum number of notification that will be displayed at any one time (equivalent to geometry's height setting)

Another important point to consider to account for backwards compatibility with the previous settings if possible to provide the best experience for downstream users.

This is a very rough draft at this point and unclear whether any of this is going to move forward. I would love to hear some opinions on this, and more suggestions if you think there is a better way or I missed something.

Feature graphics

Most helpful comment

That's actually a very good idea that can also be expanded to cover offset:

offset = -20, 10 # 20 pixels to the left, 10 down
offset = 20 # 20 pixels to the right
offset = 0, -10 # 10 pixels up

Taking that into account the settings we need to add are the following:

  • width
  • height
  • origin
  • offset
  • notification_limit

All 15 comments

I'd rather have a single width which takes up to two values:

width = 50, 100 #  min, max, respectively
width = 50  # fixed size (eg min = max = 50).

As for origin, I'd also make it a two-word:

origin = top left
origin = top right
origin = top center
origin = middle left
origin = middle right
# etc

I feel like this makes everything a bit more concise and readable.

That's actually a very good idea that can also be expanded to cover offset:

offset = -20, 10 # 20 pixels to the left, 10 down
offset = 20 # 20 pixels to the right
offset = 0, -10 # 10 pixels up

Taking that into account the settings we need to add are the following:

  • width
  • height
  • origin
  • offset
  • notification_limit

As @Eizen mentioned on IRC, position might be a better name instead of origin.

Is there an ETA for this feature?

@kopsi ETA?

@Kopsi Not currently, we're still in the refactoring stage. But the usual open-source mantra applies, anyone is welcome to implement this if they want to see it merged sooner.

Thanks for the answer. Sadly I lack the skill for such an implementation.

All I want is the ability to center messages.

@bugeats try to build & use dunst from this branch: https://github.com/dunst-project/dunst/tree/centering

@bugeats try to build & use dunst from this branch: https://github.com/dunst-project/dunst/tree/centering

Is that branch going to be merged any time soon?

@jzbor Merging that branch is blocked on this issue (specifically the origin setting). I don't want to merge a new option that's just going to be deprecated later.

I can't read well if my use case would be adressed by this :
I would like a big fat warning that takes the major part of the screen for specific case (out of battery for instance) because I'm sometimes too focused I don't pay enough attention to usual critical warnings.

In other words, coul this settings be dynamically changed ?

As it stands right now, dunst cannot display multiple notification widows. This means that it's currently not possible to display some notifications in a big window in the middle of the screen and others in a small window in the top right.
I would recommend you to set critical notifications to not disappear by setting timeout = 0. That way you won't miss them at least.

Regarding this thread, I have some input for easy implementation on the wayland side. In wayland the notifications are positioned with anchors. You can set an anchor for each side. If you want to position a notification in the top right, you anchor top and right. If you want to position in the top-center, you anchor top, left and right. The origin notation like in https://github.com/dunst-project/dunst/issues/336#issuecomment-315530706 would make a lot of sense then.
The rest of the positioning is done with offsets from those anchors. The only difference from the suggestions above is that the offsets in wayland are always positive, and I'm not sure you can offset horizontally if you anchor both left and right.

I'm looking to implement this with the new settings code. There's a few that could be improved:

  • The way offset works now is inconsistent with the way width and height work. offset is horizontal, vertical and width is minimum, maximum. I think that would lead to confusion. We could make it horizontal x vertical.
  • The notation for width and height are not quite intuitive. I propose to make it (min, max), even though that would make it a bit harder to parse.
  • The origin is proposed as a space-separated list. I would make it a comma-separated list for consistency.
  • Origin can be more than two words. If you say left, right the notification will be in the center. (works the same as wayland positioners).

So a summary for the current proposal:

  • width: (min, max) or (size) or size
  • height: (min, max) or (size) or size
  • origin: left, top or left, right or top, left, right
  • offset: horizontal x vertical
  • notification_limit: 123
width = (40, 70)
height = (0, 80)
origin = top, right
offset = 100x10 # 100 from the right, 10 from the top. No negative values allowed
notification_limit = 0 # unlimited notifications, given they fit in the height

EDIT:
The setting height might also be confused with a potential notification_height (see https://github.com/dunst-project/dunst/issues/625)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

progandy picture progandy  路  6Comments

bebehei picture bebehei  路  4Comments

ahjstone picture ahjstone  路  4Comments

adihrustic picture adihrustic  路  3Comments

knopwob picture knopwob  路  5Comments