Handle resize events [Feature request #196] #197
Conversation
LemonBoy
left a comment
LemonBoy
left a comment
There was a problem hiding this comment.
Not to sure about this as we do some trickery during the setup phase wrt the geometry and the monitor chains.
| NET_WM_STATE, | ||
| NET_WM_STATE_STICKY, | ||
| NET_WM_STATE_ABOVE, | ||
| }; |
There was a problem hiding this comment.
Let's just add a NET_WM_ATOM_MAX to avoid the sizeof/sizeof repeated twice.
| void | ||
| create_pixmap (monitor_t *mon) | ||
| { | ||
| if (mon->pixmap) { |
| notify_ev = (xcb_configure_notify_event_t *)ev; | ||
|
|
||
| for (monitor_t *mon = monhead; mon; mon = mon->next) { | ||
| if (mon->window != notify_ev->window) |
There was a problem hiding this comment.
Once the matching window is processed you can terminate the loop.
| update_ewmh_atoms (void) | ||
| { | ||
| // Only desktops that support EWMH should continue | ||
| if (!atom_list[0]) |
| bw = mon->width = notify_ev->width; | ||
| bh = notify_ev->height; | ||
|
|
||
| create_pixmap(mon); // Xorg doesn't allow resizing pixmaps, so we create a new one |
There was a problem hiding this comment.
Put the comment above the code so that the lines are not too long.
|
Indeed, this solution would make more sense if bar geometries were not dinamically set by default. Particularly, it feels a bit hackish as some agreed in #163, maybe a sane approach would be to split the bar in two scripts, keeping only the manual geometry logic set by Anyway, should this PR be closed? I don't feel that it makes sense too, at the current state of the project. |
|
Any updates on this? |
2 participants
Implements resize events handling as requested in #196.