MilesRdz
commented
11 years ago This would be a feature request...
Open swiftgeek opened 11 years ago
MilesRdz
commented
11 years ago This would be a feature request...
swiftgeek
commented
11 years ago It will break something that steam used to do for a long time. (Now it could do it much better, making it awesome and a must-have while playing any game — even those outside steam store ;) ) It's a bug request ;)
Also this http://www.urbandictionary.com/define.php?term=bugging (# 2) Bugging users is in some way a purpose of notification systems :P
MrSchism
commented
11 years ago Miles is correct: for the sake of bug reporting, this is a feature request... and a lengthy one at that.
BurritoBazooka
commented
11 years ago edit2: This comment was meant for #2503, which is the opposite of this.
Out of all of these points, I most strongly agree with the one about libnotify. Better integration with the desktop would be nice, but is not essential in my mind. I think libnotify is a good start on that, and I think the least likely to create new bugs since it's pretty easy to do (you can make a notification now in bash with
notify-send 'Glados says:' 'I saw a deer today.' && aplay ~/.steam/steam/friends/message.wav) On my system, it even does queueing with other apps. I can customize its position and appearance.
Thanks to John Drinkwater for pointing me to this request from the Steam forums.
edit: added sound and a few more words
flying-sheep
commented
11 years ago to transfer my main points from the duplicate bug:
WhyNotHugo
commented
11 years ago The description for the issue confuses me. It looks like the reporter's intention is the opposite of #2503; instead of having steam use the existing notifications, it sounds as if the intention is for steam to DISPLAY system notifications using it's own overlay (overriding the existing notification daemon?). If this interpretations of this issue is correct, it's an awful idea.
BurritoBazooka
commented
11 years ago I think your interpretation is correct, @hobarrera (I didn't realise that at first... Just followed @johndrinkwater's lead) but I don't think it's such a bad idea. If you're playing games in full screen, chances are (for me, anyway) that the system's notification daemon doesn't display notifications to you in-game. What you would expect is for notifications to appear in the overlay, as they do for Steam. Steam Overlay* can act as a notification daemon in its own right.
*(the thing you shift+tab to in-game is the same thing that displays Steam chat notifications in-game)
The idea, I think, isn't for Steam to display all notifications, only when the overlay is active in-game.
Until this point, I have used my phone as a second screen while playing games, but I don't see why this is a bad idea for end users.
The concept in #2503 (if both are implemented) would then be used when games aren't running full screen.
swiftgeek
commented
11 years ago My idea was to have two 'routines' (I described this in issue message, but maybe distinction wasn't clear enough)
One for Big Picture/SteamBox/GameOverlay - providing own 'daemon' that listens to dbus (beacause normal/sane notification daemons doesn't work there, and so we now don't see notifications from IM/whatever while in game)
And second one for desktop use (no game running fullscreen, just regular steam client) - which would just shove notifications to the existing (running) notification daemon - ways to implement described by @flying-sheep in point 3
@BurritoBazooka : at least on Linux "Steam Overlay" is contained within gameoverlay*.so ;)
Again if anyone is interested in adding this feature - You need to remember about edge case - people are also using 'alt-tab' or similar - so checking if game with gameoverlay(if it's running at all) has a focus on current workspace is also needed
@flying-sheep : actually… OS X has growl, not bundled but it's being commonly used (even by adobe) - it's licensed on BSD so it has even less troubles ;)
WhyNotHugo
commented
11 years ago @BurritoBazooka: My notifications daemon displays my notifications just fine. It's actually steam which is broken IMHO, since it's the only app ignoring my environment. Overriding the system's notification daemons isn't very friendly, I usually want apps to integrate INTO my environment, not to replace parts of it. The notifications specs is quite complicated to re-implement the daemon.
Also, what happens if the game is minimized? What happens to interactive notifications (I haven't seen notifications with buttons on steam).
@swiftgeek Implementing the server side would mean killing the already-running notification daemon somehow, and inhibiting it if it's launched through dbus by someone else.
Growl is not commonly part of the OS. notification-daemon is present in most popular DEs, and all officially supported distributions.
swiftgeek
commented
11 years ago @hobarrera • Growl - Then do a poll for OS X - they might not even know that they are using it -.- . It's as common as notification daemon on linux. Steam can gather those statistics pretty easily… • inhibiting notifyd - why would You inhibit something that doesn't work at all at that moment (fullscreen game/steambox/big picture/etc) - the only thing that it requires is using dbus directly • minimized game - i mentioned this already, read please -.- . It's just one of many edge cases, it isn't something unnatural to programmer -.- • notifyd specs - It isn't THAT complicated and You don't need to implement all of it (at least for some time, it would be not nice to leave just the basic support) • ignoring env - my issue is all about fitting in existing env not replacing stuff -.-. It takes just few seconds to add settings for your case when your partially insane notification daemon is running (why insane? eg. imagine watching movie with family fullscreen and being dunno sexted)
WhyNotHugo
commented
11 years ago @swiftgeek xfce4-notifyd works fine with steam games, and I can see it's notifications on top of the game. If it does not work for you, you should file a bug report, but it's not broken ATM. Different implementations may vary, but you should not assume they're all broken.
But basic support isn't enough. My phone calls come in through an asterisk box, and I answer/decline them though a notification. If steam overrides by notifications (already a bad idea), I can no longer answer phone calls while playing steam! That's just too unaccetable! Other running applications may send important interactive notifications. If steam decides to override my environment and replace my nofitication daemon, it can't offer LESS funcionality, because that is, in essence, breaking my environment.
Notifications are shown on top of any application. If your media player inhibits them, that's your edge case, not a default.
Steam is an application, fitting into the env means it should behave as such regarding the notifications specs. Re-implementing the server-side is not how other applications behave. Fitting in is behaving like the rest, and using the existing setup without replacing unrelated items. This request is as out-of-scope as #2636.
swiftgeek
commented
11 years ago Please distinguish regular part of the spec from crazy broken hackerish. And i'm using xfce4's and e18++ notifyd deamons.
2nd paragraph - if You would read then You would know that it would be possible!
3rd - that assumption would be not only highly inconvenient also highly insecure. Spec is good
4rd All apps wanting to use notifyd have to implement protocol one way or another. Seriously stop trolling this issue, pretty please. Again notifyd spec is good and this proposal isn't against either it or currently running notifyd :< . I'm not hired by Valve and i wont fork it to show You that it really will also fit into your env!
The only thing that i don't know at this particular moment is how to implement edge cases on wayland… that's all !
BurritoBazooka
commented
11 years ago Please focus on making or refuting points regarding the request instead of attacking people or demanding things from them. I don't see any trolling going on from @hobarrera's side.
swiftgeek
commented
11 years ago @BurritoBazooka if he isn't trolling this issue then it's my job to teach everyone about specs step-by-step and attaching quote from any standard to every sentence in which i'm mentioning them, also providing mock-up codes to prove stated points? I would understand this if this would be an opensource project
BurritoBazooka
commented
11 years ago Yes, as a matter of fact. If not, just say it's not a part of the spec, and leave it be. You don't need to use emoticons to express your attitude towards him, or say that he is trolling (edit: check out his coding experience, I wouldn't say he's a troll. Also, it's abnormal for trolls to be using their real names), or tell him to read things again.
It's up to Valve anyway.
swiftgeek
commented
11 years ago If i did that i would make 99% of the implementation job for this issue - this is why it would be ok only for OpenSource IMO - if it wouldn't get into mainline i would just fork it :<
And many devs are trolling, for various reasons
Until Valve says anything i obviously wont write any code / quote exact parts of X11/notifyd specs
BurritoBazooka
commented
11 years ago I found the spec. Actions are specified and one suggested implementation is buttons.
edit: Yeah, my main hangup wasn't about you not being verbose about what you wanted to say, just that it had an attitude attached.
flying-sheep
commented
11 years ago So let me get this straight: this feature request is called “integration with system notifications”
This integration can go both ways:
The first one isn't mentioned in this feature request's description, but due to #2503 being marked as duplicate, either this one should be treated as meta request for both, or #2503 should be reopened, and this one renamed to be more specific to its description.
swiftgeek
commented
11 years ago Those are two parts of implementation, not pick one It's all about using https://developer.gnome.org/notification-spec/
"The first one isn't mentioned in this feature request's description" It didn't require that much of explanation as for GameOverlay (notice horizontal line and one sentence below)
flying-sheep
commented
11 years ago Sure, my comment is just clarification and organizational: what this report is about and how we could organize both of its parts (as separate ones or combined)
I'm for renaming this one and reopening #2503. Then they can be fixed/wontfix’ed separately.
swiftgeek
commented
11 years ago But they need to be considered at the same time, otherwise we may get slightly incompatible solutions.
I'm not in favor of 1 because it can't provide as much features as GameOverlay
WhyNotHugo
commented
11 years ago 3rd - that assumption would be not only highly inconvenient also highly insecure. Spec is good
Huh? There's no real network communication, that's just insane!
4rd All apps wanting to use notifyd have to implement protocol one way or another.
I agree, but I belive that all applications should implement the client part. Users will pick the notification daemon they prefer (or their DE will provide one that integrates nicely).
- We can change the spec slightly to get notification daemons run more properly on fullscreen apps (Then i guess you could change urgency levels that can be displayed via game properties/application itself). Then we can just get rid of in-steam notifications all together - but then steambox will be 'slightly' worse environment. I have no idea at this moment where/how API should be extended (It should allow changing minimal urgency level, and changing position of notification from application being currently focused && fullscreen)
Steambox can implement it's own notification daemon, no need for it to tied into the same application.
- Steam can just use notification api from the client side while in desktop mode/when possible (Windowing issues on /3rd party games/ && X11)
If some notification daemon has issues with specific software, those issues need to be fixed (either by the daemon, or the game, whichever is faulty). Replacing one of the two for ALL users isn't the proper solution.
- Steam can implement both
I see little point in this. Linux users already have a notification daemon running, why should some random application re-implement that? Imagine if everyone else did this. Desktop integration would totally dissaprear.
@flying-sheep
integrate notifications into steam (overlay) – by providing a second daemon (which is only feasible if the spec allows for more than one daemon to handle notifications without inhibiting each other)
I don't think the spec allow that (though it has been a while since I read it). However, why do you belive that a client application should implement it's daemon and override the currently running one? There's not real justification to that.
swiftgeek
commented
11 years ago Huh? There's no real network communication, that's just insane!
3rd paragraph
Notifications are shown on top of any application. If your media player inhibits them, that's your edge case, not a default.
That »any« would be both inconvenient and insecure. But luckily spec is different
I see little point in this. Linux users already have a notification daemon running, why should some random application re-implement that? Imagine if everyone else did this. Desktop integration would totally dissaprear.
There is no real integration on fullscreen, especially games. It's no longer env it's just one app with completely different layout. And again it's your point i don't see a problem with you (un)checking some checkbox in settings. There are many various types of games and in FPS You usually want to just know that there was notification at all and hide in game and then finally check full notifications 'history' via Shift+Tab. Implementing this on notifyd side is currently nearly impossible on X11 and completely solved for wayland, but it still would require spec change
And windowing issues are issues of only X11 - a land where there is a magic concept of everything being a window!
WhyNotHugo
commented
11 years ago Please, elaborate how notifications being displayed are insecure. Unless you're being IM'd confidential information and playing a game in a public space, there's no security breach. And that's just a [very] ridiculous scenario.
There is no real integration on fullscreen, especially games. It's no longer env it's just one app with completely different layout. And again it's your point i don't see a problem with you (un)checking some checkbox in settings. There are many various types of games and in FPS You usually want to just know that there was notification at all and hide in game and then finally check full notifications 'history' via Shift+Tab. Implementing this on notifyd side is currently nearly impossible on X11 and completely solved for wayland, but it still would require spec change.
Some nofitications daemons have this feature (I belive KDE, but I may be mistaken). It's not steam's job to replace desktop components that users MAY want to behave differently.
If you really need this behaviour, please, contribute to your notification daemon of choice, but don't attempt to make STEAM a notification daemon. This way, you can have any singular behaviour you may want, without altering the desktop of every single user that wants to use steam.
MrSchism
commented
10 years ago I'd like to weigh in here.
I use xfce and I can verify that most notifications come through while in full screen (I haven't gone in depth to see if I've missed any, so I can't say with absolute certainty).
That being said, I'd prefer a steam overlay notification in full screen because it's less intrusive. Consider, if you will, my scenario:
I'm playing a game -- FTL for example -- on my netbook. While it runs very well, there are controls in the lower-right corner. A Steam notification is easier to dismiss (visually, not necessarily functionally) than, say, a VLC notification. Worse than a VLC notification is a flash crash (it is a netbook; Chromium on the HumbleBundle site in the background while playing FTL can easily cause Flash to suffer). Crashed Flash notifications are large and, in many instances, white with black text, contrasting sharply with the game experience.
I think that @swiftgeek was largely right. If we could determine that a game with overlay was not just focused, but full-screen, it would definitely make for a less jarring experience. It would become a matter of being able to control which notifications were displayed, reliable determination of overlay and focus, and reliable generation of the notifications while, at the same time, appropriately handling the ones presented by the system's notification daemon.
Reliably... and without any relatively significant (as in, relative to previous functionality) increase in resource consumption.
WhyNotHugo
commented
10 years ago @MrSchism Slightly off-topic, but still relevant: Are you sure the flash-crash notifications are also shown by xfce4-notifyd? AFAIK, there's no way for a single notification to have a different colour scheme.
On a more relevant side; I think that "easier to dismiss" is arguable. xfce's notifications can be dismissed by right clicking any part of it. From what I've steam notifications have an extremely small "x" in a corner that needs to be clicked, so I belive that's more of a challenge.
I must say though, after enough thought, maybe a steam-notifyd would be good: a separete applicaiton that can integrate into steam, but run MANUALLY by those users who prefer steam over their current desktop (I get a feeling that such a program would be needed for SteamOS as well).
Since it's a notification daemon, we can also satify #2503 and have steam a notification client for those who like their desktop as it is now.
MrSchism
commented
10 years ago Like I said, I meant dismissed visually, not functionally. I can largely ignore a popup that follows with the other pop-ups that I'll inevitably get.
The stark white ones that the system generates (the flash ones are harder for me to ignore due to size, not color difference from other notifications) are really disruptive and often even distorted to some degree (often dimmed, hazy, and slow due to the graphics).
gangelop
commented
10 years ago Consider this:
This is how skype does it
The main advantage here is that steam can maintain it's custom, cross-platform, consistent behavior and design philosophy, while at the same time satisfying users who desire a more granular control over the pornographic direction of their environment.
I understand that this is not a complete solution and that ideally there should be one correct approach, which works by default, everywhere.
But still, this I think would be fairly simple to implement (compared to the other proposals) and it would enable us to solve our end of the issue, in our various configurations and environments.
WhyNotHugo
commented
10 years ago +1 to @lathan simple, yet elegant solution.
suptimal
commented
9 years ago +1 any progress?
Binero
commented
9 years ago I second @blendi-93, any progress?
suptimal
commented
9 years ago devs pls. ;)
gangelop
commented
9 years ago Recently I noticed, dota 2 sends you a notification with libnotify when the matchmaking has found a match. :+1:
suptimal
commented
9 years ago y, using it for auto accept (dust + xdotools + bdpc )
jurf
commented
9 years ago +1, with the new GNOME notification system this would be great.
p3lim
commented
8 years ago +1
The current notifications don't even work properly (for me atleast), only showing the title and not the message.
YtvwlD
commented
8 years ago +1
JoshuaMurphynz
commented
8 years ago I know that 'notify-send' can be used on the Linux side On 11 Jan 2016 00:47, "Niklas" notifications@github.com wrote:
+1
— Reply to this email directly or view it on GitHub https://github.com/ValveSoftware/steam-for-linux/issues/46#issuecomment-170337814 .
MarcosCosmos
commented
6 years ago As someone with a heavily customized environment, including customized notification scripts/behavior, I'd like to weigh in a little bit. Most of this is not new information, but the thread has been complicated, so it can take a while to get to the bottom of things.
As I understand it there are a few different ideas floating around in this thread (4 if you count @gangelop's contribution, but to me those ideas are valid independently):
First of all, in case anyone was still wondering, these are features that cannot be enabled by default. Any conceivable way of doing so would either: break consistency of steam's current behavior, break the consistency of system notification behavior, or even risk breaking system notifications entirely. But that doesn't mean they aren't worthwhile features.
This is straightforward, it would disable steam's custom notifications and instead send notifications out to the system's existing server/daemon. This would be the easiest idea to implement.
To Be Clear: This is not and should not in any way be dependent on any of the other ideas, it should be spec-compliant and behave like any other program. The other idea(s) must be considerate of the existence of other notification servers, so there is no conflict.
slash
displaying system notifications in »»»game overlay«««
This can be done. However!
(beacause normal/sane notification daemons doesn't work there, and so we now don't see notifications from IM/whatever while in game)
This is incorrect (or at least outdated information). The problem isn't an edge case, I suspect it would be fairly common - at least today. Consider streamers (yes Linux streamers exist, but it's just an example), borderless-window mode, and anyone with a dual-monitor setup. Regardless of whether or not notifications show up in full-screen, the following problems are still present:
Consequently for some (possibly many) users doing this naively would lead to duplicate notifications.
To Be Clear: It is perfectly possible for Valve to provide a full, always-on, notification server that supports the overlay etc.
It would essentially be a new notification server which is integrated with steam and is therefore able to be respond to the state of steam/game windows. Users could opt to use this instead of their existing notification service, in the same way that they enable/switch between any other notification server.
IMO this is a nice idea, in light of Big Picture Mode.
Unfortunately this is probably outside of Steam's control.
The following is an excerpt from https://developer.gnome.org/notification-spec/ under the heading "Basic Design":
In order to ensure that multiple notifications can easily be displayed at once, and to provide a convenient implementation, all notifications are controlled by a single session-scoped service which exposes a D-BUS interface.
Ergo there can only be one notification server running at a time.
Under this assumption, implementing conditional interception of notifications requires wrapping sandbox-hacks around 3rd-party notification servers to intercept/override their I/O, or killing and re-starting them on-the-fly.
Now, if the first two ideas are implemented, someone outside of Valve could theoretically implement a wrapper, and it may even work most-of-the-time. However, it cannot be guaranteed not to cause problems for the existing server, so it would have to be a use-at-your-own risk. It should not come from Valve IMHO.
I think this should be split into three separate feature requests for each idea valuable in their own right, including @gangelop's contribution.
It is not necessary to implement them in an integrated fashion since they should just comply with the Libnotify spec where applicable. Also, it seems that calling them "integrate with system notifications" and keeping them in the same thread/request has caused too much confusion.
As has been stated, this one could be modified to specialise to something like "Add an Integrated Libnotify Server to Steam", and #2503 could be reopened and clarified to something like "Use an Existing Libnotify Server For Steam Notifications".
When necessary, the main two ideas can "combined" with a notification settings menu similar to the following options:
JaneSmith
commented
6 years ago Using The System/Libnotify System For Steam Notifications
This is straightforward, it would disable steam's custom notifications and instead send notifications out to the system's existing server/daemon. This would be the easiest idea to implement.
I've wanted this for a long time. I have a Steam chat window open all day, every day, and it's very irksome that it uses its own non-standard notifications in the bottom-right corner of the screen, instead of standard Gnome notifications at the top of the screen. Even worse, the notifications just disappear after a few seconds instead of persisting, so if I'm not looking when they appear, I'll have no idea there was ever a notification at all. With Gnome, on the other hand, I would be able to check my notifications later on. As a result, I have to constantly check back on the chat window manually to see if I've had any new messages, which reduces my productivity.
hjri
commented
6 years ago my current workaround is to use web version https://steamcommunity.com/chat/ which uses browser-provided desktop notifications, not so sure about chrome but firefox uses system's own notification system (i.e. same as notify-send). It also helps with browsers having fcitx support #3255. The only downside is that for some insane reason steam voice chat refuses to work on firefox, but since i use mumble that's not as much of a problem.
JaneSmith
commented
6 years ago Thanks for the tip. I guess that's a decent workaround.
HelmicNewciv
commented
5 years ago Just commenting that by default Steam's notifications pop over other notifications and over the tastkbar, which is stupid and annoying and I hate it. It won't do things like show the notification on my phone with KDE Connect. It won't respect my quiet hours, it won't do any of the things I want my notifications to do, I can't go through a list of any notifications I missed. A lot of the same issues exist in WIndows too.
Odzinic
commented
3 years ago +1 would really appreciate this feature. I hate missing messages from my friends.
rodrigo-ceccato
commented
3 years ago +1 would really appreciate this feature
aMerryElk
commented
3 years ago +1 would really appreciate this feature
A6GibKm
commented
2 years ago I want to point out that in the case the client is using the GApplication api, then doing notifications does not require any external library, but can be done via g_application_send_notification.
The problem with libnotify is that it relies in the org.freedesktop.Notifications interface which is sandbox-unfriendly, rather than using org.freedesktop.portal.Notification when inside a sandbox. The GNotification api, takes all of this into account and does not add an extra dependency.
WhyNotHugo
commented
2 years ago @A6GibKm Is Steam actually using GTK? I have an impression they're not, since gtk3 supports Wayland (and scaling) natively, whereas Steam doesn't.
A6GibKm
commented
2 years ago Given the errors I see on the app, it seems so. Note that gtk3 supports wayland, but only when using their widgets, which I think is not the case here.
K4LCIFER
commented
1 year ago This would be such a good feature to add.
Please add support for displaying system notifications in »»»game overlay««« AFAIK This could be reused https://github.com/halhen/statnot Please take advantage of the linux environment ;)
Shortly saying without additional mock-ups, etc GameOverlay should have: • Possibility to group notification from the same app (i just guess that this is doable) • Relative time (eg. "5 minutes ago") • Possibility to limit number / time interval history shown in [shift]+[tab] overlay (by default nothing should be shown there, since we don't want to break steam's "visual compatibility")
Real things that will work / improve user experience while gaming due to this "bug" introduction: • Possibility to see volume/brightness percentage while changing it via shortcuts • See incoming messages from other IMs / e-mails • See warning when battery drops dead • See warning when connections is lost
Also steam's own notification (that exist during non-playing time) should be done by integration with libnotify - which is heavily described on ArchWiki https://wiki.archlinux.org/index.php/Libnotify.