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

Implement hiding on fullscreen #472

Merged
merged 11 commits into from
Feb 25, 2018
Merged

Conversation

bebehei
Copy link
Member

@bebehei bebehei commented Jan 6, 2018

Implements a rule to hide specific notifications on fullscreen

Fixes #142

@bebehei
Copy link
Member Author

bebehei commented Jan 12, 2018

@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.

@bebehei
Copy link
Member Author

bebehei commented Jan 13, 2018

@tsipinakis I've also taken the best of two worlds. I added a field in the enum to optionally also push the notifications back.

@bebehei
Copy link
Member Author

bebehei commented Feb 16, 2018

I guess, I've hit a bug when processing XEvents. Under some circumstances, some notifications get delayed until a new one or a focus change happens.

I'll investigate further, but I've got a hunch, that the last change in the dropgtk PRs about ignoring specific PropertyChange events is ignoring the event in too much cases.

edit: resolved

@bebehei bebehei force-pushed the fullscreen branch 3 times, most recently from ee59879 to eca7949 Compare February 21, 2018 10:10
@bebehei
Copy link
Member Author

bebehei commented Feb 21, 2018

Note for myself: When merging together with #475, it'll fail building. (and #491, it'll fail building. This needs a change in the for the queue_* methods, which get an additional parameter fullscreen. edit: resolved)

@bebehei bebehei force-pushed the fullscreen branch 2 times, most recently from ddf3cf2 to 8b56253 Compare February 24, 2018 18:26
@bebehei
Copy link
Member Author

bebehei commented Feb 24, 2018

I guess, I've hit a bug when processing XEvents. Under some circumstances, some notifications get delayed until a new one or a focus change happens.

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 xctx.cur_screen. Further details in the commit.

@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.

@tsipinakis
Copy link
Member

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.

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.

Copy link
Member

@tsipinakis tsipinakis left a 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.

@@ -9,6 +9,12 @@

#define DUNST_NOTIF_MAX_CHARS 5000

enum BehaviorFS {
Copy link
Member

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.

Copy link
Member Author

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;
Copy link
Member

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?

Copy link
Member Author

@bebehei bebehei Feb 25, 2018

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.

Copy link
Member Author

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);
Copy link
Member

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)
Copy link
Member

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 :/

Copy link
Member Author

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.
@bebehei bebehei merged commit f80e6fc into dunst-project:master Feb 25, 2018
@bebehei bebehei deleted the fullscreen branch March 15, 2018 13:30
karlicoss pushed a commit to karlicoss/dunst that referenced this pull request Mar 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants