-
Notifications
You must be signed in to change notification settings - Fork 342
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
Implement hiding on fullscreen #472
Conversation
@tsipinakis I've reworked it now, like we have discussed it in IRC. Only new notifications will get delayed and already drawn ones will still get displayed further. This makes processing of timeouts easier. Previously, when switching between fullscreen and normal, timeouts started always from 0. |
@tsipinakis I've also taken the best of two worlds. I added a field in the enum to optionally also push the notifications back. |
edit: resolved |
ee59879
to
eca7949
Compare
ddf3cf2
to
8b56253
Compare
So, I finally found a reproducible event to test it and I had been able to debug and fix it. While debugging, I also found another small issue with the handling of @tsipinakis I'd kindly request your review. Off-Topic: Something about coveralls: On Travis Job 678.2, coveralls failed with a segfault. I have no clue, why this happened, but this is very spooky, we should investigate this. I can give an all-clear for this PR. The actual commit got amended is therefore not in this PR anymore. But it should be still alerting, that coveralls can fail for some reason and I'd actually would like to know why. |
This is not new it's been happening since we started using coveralls and I haven't been able to figure out why. In any case it doesn't affect much since the gcc build still reports results. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd normally drop reviews like this as it's working perfectly and there are no relevant issues with the code but submitted anyway since @bebehei prodded me to.
src/notification.h
Outdated
@@ -9,6 +9,12 @@ | |||
|
|||
#define DUNST_NOTIF_MAX_CHARS 5000 | |||
|
|||
enum BehaviorFS { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no official style guide (I'll get to writing it soon) but camel_case is preferred for structs functions and enums.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd normally drop reviews like this as it's working perfectly and there are no relevant issues with the code but submitted anyway since @bebehei prodded me to.
This is exactly the reason, why I wanted to get a nitpicky review. One of the things, I dislike about dunst is the hard inconsistency of specific things (like typenames). Because even I fail for myself to stick to one schema.
GList *iter = g_queue_peek_head_link(waiting); | ||
while (iter) { | ||
notification *n = iter->data; | ||
GList *nextiter = iter->next; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[nitpick] Is there a reason for having nextiter
var rather than directly referring to iter->next
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Must be an older relict of the times, when I wanted to replace all queue iterations with two pointers and a for loop.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, at the point when you move the notification from waiting
to displayed
, iter->next
becomes invalid.
src/x11/x.c
Outdated
LOG_D("Processing event: %s\n", xevent_type_to_string(ev.type)); | ||
const char *typename = xevent_type_to_string(ev.type); | ||
if (typename) | ||
LOG_D("XEvent: processing '%s'", typename); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can avoid having to use if logic for a simple debug log (which I dislike) by changing the statement to
LOG_D("XEvent: processing '%d: %s'", ev.type, typename);
and update xevent_type_to_string
to return "Unknown" on an unkown event.
src/x11/x.c
Outdated
@@ -69,6 +69,48 @@ static void setopacity(Window win, unsigned long opacity); | |||
static void x_handle_click(XEvent ev); | |||
static void x_win_setup(void); | |||
|
|||
/* see x.h */ | |||
const char *xevent_type_to_string(int type) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about having this monster of a function just to log a debug message :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We definitely can remove it. It was just super useful while debugging and I left it in on purpose. I wanted to know, what you think about it.
The PropertyNotify handling has been changed in the dropgtk branch to ignore XEvents, when redrawing was unnecessary. But when the fullscreen state of a window changes, we can't ignore the event, because it didn't change the screen. Additionally, there had been a mistake in the handling of the cur_screen: The xctx.cur_screen field will only get updated, when the application is visible and gets redrawn. Therefore, when a PropertyNotify event arrived while the application had been hidden and the screens do not match anymore, wake_up() will be called albeit being unnecessary. Calling x_win_draw() when the screens change is also the preferable solution over wake_up(), as there is nothing subject to change in the queues when the displays change.
Implement hiding on fullscreen
Implements a rule to hide specific notifications on fullscreen
Fixes #142