Closed marcosnils closed 4 years ago
dunst can send a _NET_ACTIVE_WINDOW client message¹ with source 2 (pager). This should focus the workspace if necessary. It will not work for scratchpad windows, though.
¹ https://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472702304
dunst can send a _NET_ACTIVE_WINDOW client message¹ with source 2 (pager). This should focus the workspace if necessary. It will not work for scratchpad windows, though.
:heart_eyes: @tsipinakis does it make sense to add this feature to dunst
? Is that something you'd be interested in merging?
As I said dunst-project/dunst#671, this is something the sender does (aka the browser in your case), not the notification daemon. We don't even have a reference to the window that the notification is relevant to - just have a dbus address to respond.
In your report you mentioned chrome but given I've observed the same behaviour with Firefox, which is open source I used that to do a very basic dig on what's happening.
The best I could find is that the action is defined in nsAlertsIconListener::ShowAlert
, and then when dunst responds that it was chosen this callback is called.
That's about where I'd stopped, for a codebase as big as a browser some serious code spelunking is needed to actually trace why it doesn't update the active window when it's not in a visible workspace.
Perhaps opening a bug on the firefox/chrome bug tracker would be a better option to solve this one.
@Airblader Isn't there a way to tell i3 to switch to an urgent workspace whenever the event is coming from dmenu / rofi? Can't that be done in using the window behavior configuration?
On Thu, Nov 07, 2019 at 04:21:49AM -0800, Marcos Nils wrote:
@Airblader Isn't there a way to tell i3 to switch to an urgent workspace whenever the event is coming from dmenu / rofi? Can't that be done in using the window behavior configuration?
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/i3/i3/issues/3860#issuecomment-551057220
Please don't @mention me on github conversations.
Of course bugfixes for dmenu are welcome. Please send them to the suckless mailinglist, on IRC or by private e-mail.
Thanks,
-- Kind regards, Hiltjo
Of course bugfixes for dmenu are welcome. Please send them to the suckless mailinglist, on IRC or by private e-mail.
Open source is hard.. wish we could have gotten more help from this comment. Still no idea where this could be changed to provide a better experience and achieve the desired result. If maintainers don't provide proper guidance on understanding how things work, it's difficult for us (willing contributors) to contribute. :disappointed:
Isn't there a way to tell i3 to switch to an urgent workspace whenever the event is coming from dmenu / rofi?
There is https://i3wm.org/docs/userguide.html#focus_on_window_activation for windows being activated, but this is not window-specific. You can also do for_window [urgent=latest] focus
and of course combine that with further window-specific criteria. There is nothing along the lines of "if it comes from dunst", though.
I'll close this issue since I'm not seeing anything actionable on our side (there are protocols that allow that, the browser indirection is not an issue with i3), but of course if there are further questions we can discuss them here either way.
Open source is hard.. wish we could have gotten more help from this comment.
I think they just dislike GitHub / Microsoft and want to avoid the platform. You can probably just write to the suckless mailing list if you have further questions. :-)
I'm submitting a…
Original issue here: https://github.com/dunst-project/dunst/issues/671
Summoning several smart people asking for insights about how this actually works. I'm totally open to implement this, it's just I don't know where's the proper place to look. @tsipinakis @hiltjo
Current Behavior
The usual workflow is that an application like Slack / Chrome triggers a
notify-event
notification indunst
and after opening the context menu (either using dunst, rofi, etc) there's usually an option called#View <window>
to switch to that window. Whenever you execute that action, if the target window is located in a different workspace, i3 won't switch to it automatically but mark it as urgent instead. I'm aware that I can bind a key to jump to the latest urgent workspace, I'm tying to find a way to avoid having to do that manually through another bind.Desired Behavior
Given the situation described above, I'd love to configure i3 somehow to automatically switch workspaces
Environment
Output of
i3 --moreversion 2>&-
: