disabling notifications is a new thing - though not sure that should have to do with this mode - more like;y disable them if you have a fullscreen window... ? so something in the notification settings.

a limited time for presentation mode seems better. you need to keepin mind:

1. what happens when you log out - does presentation mode get disabled entirely thus any timers are killed off? or does the mode dontinue where it left off next login,. this was part of the problem of presentation mode. it continues forever AND no visual indication it's on without hunting through menus and you waste time trying to figure out why.
2. if e just restarts (not logout/exit) then should the timer pick up where it left off when e restarts? it probably should
3. why not just a single slider with XXX mins for presentation mode max time - reality is most uses would be for... a presentation or a limited use. 30mins. 1h, 5hrs. 24hrs ... some slider for that should be enough perhaps up to a max of 24h. reminders are going to be less annoying that just some maximum timeout when it goes and turns itself off
4. why do you need this? most software like for video playback or presentations when doing a presentation suspends the screensaver anyway (xscreensaver extension allows any client to suspend it...). what does not do this these days that is worth talking about? especially with "disable blanking for fullscreen windows" which kind of covers all of that.. ?

1. what happens when you log out - does presentation mode get disabled entirely thus any timers are killed off? or does the mode dontinue where it left off next login,. this was part of the problem of presentation mode. it continues forever AND no visual indication it's on without hunting through menus and you waste time trying to figure out why.

I've left it enabled accidentally in the past and the login notification that Presentation Mode was on was sufficient. The visual indication would ideally be a recurring reminder.

2. if e just restarts (not logout/exit) then should the timer pick up where it left off when e restarts? it probably should

This seems fine. A restart should probably also display the same notification as logging in if Presentation Mode is on.

3. why not just a single slider with XXX mins for presentation mode max time - reality is most uses would be for... a presentation or a limited use. 30mins. 1h, 5hrs. 24hrs ... some slider for that should be enough perhaps up to a max of 24h. reminders are going to be less annoying that just some maximum timeout when it goes and turns itself off

Edited the task to try to be clearer. The intention was always a single slider.

4. why do you need this? most software like for video playback or presentations when doing a presentation suspends the screensaver anyway (xscreensaver extension allows any client to suspend it...). what does not do this these days that is worth talking about? especially with "disable blanking for fullscreen windows" which kind of covers all of that.. ?

There are tons of applications I make use of unfortunately that do not have a fullscreen option and therefore do not trigger this setting. (I have also noticed that switching virtual desktops or Alt-Tabbing through fullscreen windows also does not keep this setting active. It seems to only take effect on a window that was triggered to fullscreen and kept in focus.) Having a manual override to disable notifications for a meeting or screen sharing session was also a killer feature, more so in this world of hop-on/hop-off Zoom/Slack/Teams calls. An additional use case would be busy days (e.g. long coding sessions) where I've used Presentation Mode as a sort of DND (thank you key bindings), resulting in no disruptions or blanking for that duration. Fumbling through settings in lieu of quick and frequent toggles diminishes the overall desktop experience.

well you can set any window to be full-screen you know... it's in the menu and ctrl+alt+f toggles it... :) so ... i'd like to know how this is not sufficient? you know you can set up keybindings to toggle screen blanking on/off - there are actions for it... :)

well you can set any window to be full-screen you know... it's in the menu and ctrl+alt+f toggles it... :) so ...

This still doesn't address working with multiple windows or the applications that simply do not play nice with window decorations. I also mentioned already the issue with switching focus and fullscreen windows/applications and blanking still being triggered unless intervened. (I can reduplicate this fairly easily.)

i'd like to know how this is not sufficient? you know you can set up keybindings to toggle screen blanking on/off - there are actions for it... :)

That's what I was referring to, but that's just blanking. That does not include the notifications component that Presentation Mode does. Having multiple key bindings in lieu of one is also not the best user experience.

@raster Just checking in to see if you had any other updates.

One other regressive addendum (let me know if it should be a different issue), but the sounds effects since 0.25.0 where E is restarted or external power is modified, would it be possible to disable them while also in Presentation Mode (or provide settings for such in the dialog)? I have not yet compiled the absolute latest version so apologies if this issue has already been addressed. It's another challenge during presentations or prolonged screen sharing sessions.

(I did a cursory glance through the source for possible audio files that I could remove/modify the next time I compile, but I couldn't find anything there either.)

This still doesn't address working with multiple windows or the applications that simply do not play nice with window decorations.

what apps/windows can you not just set to fullscreen? fullscreen windows have no decoration as such so it shouldn't matter?

I also mentioned already the issue with switching focus and fullscreen windows/applications and blanking still being triggered unless intervened.

Well that'd be a bug - not a reason to add back a whole feature. A reason to fix that bug. :)

That does not include the notifications component that Presentation Mode does.

That is true - it did hide less important notifications, thought these days apps like browsers don't even use system notifications... it looks like at some point e needs to try detect these browser notification windows and do something special about them.

One other regressive addendum (let me know if it should be a different issue), but the sounds effects since 0.25.0 where E is restarted or external power is modified

These are created by the theme. theme decides to make a sound when some event happens. These sounds belong to "virtual channels" based on the kind of sound and elementary_config has a tab to be able to mute them. it's easy enough. They do exist for a reason. e.g. you boot and you know your boot is done if you are off doing other things. the sounds made on power plug/unplug are incredibly important to alert you to having lost (or gained) your power instead of mysteriously suddenly discovering you are on 50% battery because your power plug was loose or someone tripped over your power cord to your laptop unplugging it while you worked. The init splash sound is pretty irrelevant to presentation mode as you are not busy being in this mode when you start e (it's on e start not on any restart at any time). the power sounds are incredibly important. imagine you lose power half way through a presentation and then 10 mins before the end you machine goes dead because your battery ran out. you had no idea because your system didn't make a sound AND didn't pop up a notification AND some app was full screen hiding any battery indicators. The sounds exit to alert you to a pretty important thing - your power was removed (and also handy when digging around for a power socket that works you plug in and hear the sound knowing the socket works without having to go back and look at your machine to see it's working).

so yes - they can be muted. i would not do it by default for the reasons above.

so question now is - are you planning on doing anything here or are you more trying to convince me to do this and re-dd this back?

Apologies for the delayed response. I've started a new role and I have been busy with on-boarding.

what apps/windows can you not just set to fullscreen? fullscreen windows have no decoration as such so it shouldn't matter?

There are a few classes of applications in particular that do not respect window management. Java applets are some of the worst. If you need a specific example, I can point to a project or two on GitHub. But this argument sidesteps the fact that setting a window fullscreen is just a workaround for missing functionality. Across multiple displays, the fullscreen application is not honored as well. It is simply extremely buggy and unreliable.

Well that'd be a bug - not a reason to add back a whole feature. A reason to fix that bug. :)

If it's a simple bug to fix, so be it. I am a fan of whatever leads to less friction.

That is true - it did hide less important notifications, thought these days apps like browsers don't even use system notifications... it looks like at some point e needs to try detect these browser notification windows and do something special about them.

It seems like this is a concession of missing functionality that directly impacts the user experience. Personally, I don't enable browser notifications so the built-in OSD was a bigger deal for me.

These are created by the theme. theme decides to make a sound when some event happens. These sounds belong to "virtual channels" based on the kind of sound and elementary_config has a tab to be able to mute them. it's easy enough.

All my years of using E and I'm embarrassed to say this is a new discovery. It's simply not an application I've used or configured in depth. It absolutely addresses the problem easily enough.

They do exist for a reason. e.g. you boot and you know your boot is done if you are off doing other things.

the sounds made on power plug/unplug are incredibly important to alert you to having lost (or gained) your power instead of mysteriously suddenly discovering you are on 50% battery because your power plug was loose or someone tripped over your power cord to your laptop unplugging it while you worked.

imagine you lose power half way through a presentation and then 10 mins before the end you machine goes dead because your battery ran out. you had no idea because your system didn't make a sound AND didn't pop up a notification AND some app was full screen hiding any battery indicators.

The sounds exit to alert you to a pretty important thing - your power was removed (and also handy when digging around for a power socket that works you plug in and hear the sound knowing the socket works without having to go back and look at your machine to see it's working).

so yes - they can be muted. i would not do it by default for the reasons above.

There are a litany of cases presented here for scenarios for which the default sound settings should be left the way they are. My issue with this logic is that you could make the same list of one-off arguments for why Presentation Mode should not have been removed (or why it should be re-added). This is just an application of an inconsistent mindset.

so question now is - are you planning on doing anything here or are you more trying to convince me to do this and re-dd this back?

I've been contemplating this myself. I've been compiling my E desktop from source for the last decade plus but this latest friction has been a catalyst of sorts. I already know I do not have the time or inclination to fork or manage said fork. I have a Cinnamon DE configuration that has most of the functionality I need and enough core functionality to serve as a daily driver. (There is even a module with two toggles in the applet: one that can inhibit the screensaver and one that can inhibit notifications and they are mutually independent of each other. 😉 ) Thank you for being an excellent steward of this project through the years.

There are a few classes of applications in particular that do not respect window management. Java applets are some of the worst. If you need a specific example, I can point to a project or two on GitHub.

I'd like to see that - a java app that can't go full-screen (sensibly).

But this argument sidesteps the fact that setting a window full-screen is just a workaround for missing functionality.

It at least covers most cases for this as you'd normally want this when consuming a game or a movie on the couch etc.

Across multiple displays, the full-screen application is not honored as well. It is simply extremely buggy and unreliable.

How so? I full-screen e.g. games regularly... on my left screen. full-screen is by definition on one screen (in e). it works exactly as I'd expect it to... ?

If it's a simple bug to fix, so be it. I am a fan of whatever leads to less friction.

I think I already did... :)

It seems like this is a concession of missing functionality that directly impacts the user experience. Personally, I don't enable browser notifications so the built-in OSD was a bigger deal for me.

It certainly needed improvements but after many "my screen doesn't blank" complaints I've seen and pointing them to presentation mode then the "ooh damn" moments... I chose to remove one of the offenders (there are more - steam itself is one - it forces the screen to stop blanking g entirely as long as it runs - if you have a game or not running). Having something that "just works" in the right situations is the better path, thus my "why doesn't full-screen work for you here?". Perhaps presentation mode needs to always show some indicator on the screen overlayed so you can click it (but this then negates optimizations of turning compositing off as you no longer can). Perhaps one or more of the gadgets should display this mode in some way? Perhaps the mode needed to be moved to the main menu out of a deep sub-menu ... perhaps it needed the timeout like you mentioned (it auto disabled after X hours). I'd rather have this solved as automatically as possible without a mode being needed at all. Reality is E has far too much config for its own good. People complain of bugs I never see - they often end up being in untested options/combinations of config etc. - I'd rather have config only if it really is needed or if it's very trivial in terms of interaction.

There are a litany of cases presented here for scenarios for which the default sound settings should be left the way they are. My issue with this logic is that you could make the same

Well This sound was ADDED because of actual problems - losing battery and not knowing why (you got unplugged). I noticed on macos it makes these sounds by default. To me that is a vote for "this is useful" and thus isn't there. It is mutable as a general thing of "shut up and stop making sounds". If it should be umbilically tied to a presentation mode - that i am not so sure about. to me it's a very key message to the user that something has happened they need to be aware of - like a high priority notification that presentation mode allowed to be displayed before. My point was that presentation mode existed for the its NAME. It was created at a time when things like libreoffice did not suspend screen banking or other such tools also did not to work around that. That over time has changed and the need has waned, but if the argument is that you are giving a presentation then you ABSOLUTELY want alerts on "power loss" when you are at a strange location (some university lectern/theater or conference - i've given 100's of presentations at these events) as you don't know how it works well - you're in a rush and you might not plug things in right and you certainly don't want to run out of battery part way through your presentation. you often are in the audience seating writing your final slides on battery assuming you'll have reliable power for your presentation... my argument is based on decades of doing this. given where e is at now it will make that sound unless i mute these classes of sounds. that they should be auto-muted in presentation mode - if there was one, then this is not something to mute. a battery popup telling you gained or lost power also should always display for similar reasons. there are other ways to silence these if you have some usage scenario that requires the system have none of these, but being tied to presentation mode? probably not.

list of one-off arguments for why Presentation Mode should not have been removed (or why it should be re-added). This is just an application of an inconsistent mindset.

Actually ... someone else made a much better argument for presentation mode - on #e irc. they used multiple apps and were referring to photos and cad drawings over multiple apps and wanted to basically toggle off locking of the screen but not blanking. the apps would not auto-disable anything and no full-screen is involved. so there isn't a sensible way to know that there is a need to suspend blanking. your "no notifications" is another smaller issue but as i mentioned - it's becoming increasingly less useful given how browsers are just not using system notifications anymore and that's probably now 95% of the notifications i see (chrome or thunderbird). that leads me to the problem now of probably having to teach e about these notification popup windows as part of the notification subsystem so e can block them or force them to specific locations etc. etc. before then possibly considering some other options more like "display notifications in fullscreen [X] none [ ] critical [ ] normal [ ] low" and "chrome, firefox, thunderbird app generated notifications handled as [ ] critical [X] normal [ ] low" etc. ... so fullscreen will silence whatever notifications you want it to automatically. full-screen SHOULD work. some apps do like to explicitly toggle their full-screen modes themselves or sometimes respond to focus by minimizing their windows if full-screened etc. and this is more apps trying to force some specific usage scenario they believe i.e. right (often copied from windows) rather than just leaving it to the system (wm) to deal with it. either way i've been hearing slowly people complaining that this was removed. the complaints on removal seem to be equal to the volume of this mode having problems ... so i might bring it back. if i do i'd rather bring it back with LESS problems. i'd rather solve things in other ways so the mode is needed less.

I've been contemplating this myself. I've been compiling my E desktop from source for the last decade plus but this latest friction has been a catalyst of sorts. I already know I do not have the time or inclination to fork or manage said fork.

you don't have to maintain a fork. you need to have a discussion on the issue. as you can see - i am listening. i am not going to bring back something because one person complains a bit. if there are cogent arguments (and i admitted the suspending of notifications is one and above there was a much more serious argument for the mode on IRC), i'm listening. i'd rather not just bring it back exactly as is and end up in the same problem loop. i'd rather solve it. if full-screen state of a window is not a good proxy for such a mode, i'd like to know why as that saves a user having to toggle it at all. in some cases you may need it still.

what i was wondering is if i add it to my todo and get to it as some time or let you do it. no sense both of us doing it in 2 different ways in parallel. it almost smelled like you wanted to do it and thus i asked. but if you're going to use cinnamon then i know you won't do it so my question is answered. :)

Well This sound was ADDED because of actual problems - losing battery and not knowing why (you got unplugged)

I agree on the purpose. You pointed out the elementary_config and it is fully configurable. On my laptops with E, I always add a battery module to every shelf/display exactly for the low power warnings/indications, along with a battery gadget on the desktop for good measure.

and that's probably now 95% of the notifications i see

So this might be some of the disconnect here. 100% of my notifications are OSD from the OS. I have no notifications from the browser precisely for the same reasoning, due to how they override the nature of the system.

you don't have to maintain a fork. you need to have a discussion on the issue. as you can see - i am listening. i am not going to bring back something because one person complains a bit. if there are cogent arguments (and i admitted the suspending of notifications is one and above there was a much more serious argument for the mode on IRC), i'm listening. i'd rather not just bring it back exactly as is and end up in the same problem loop. i'd rather solve it. if full-screen state of a window is not a good proxy for such a mode, i'd like to know why as that saves a user having to toggle it at all. in some cases you may need it still.

what i was wondering is if i add it to my todo and get to it as some time or let you do it. no sense both of us doing it in 2 different ways in parallel. it almost smelled like you wanted to do it and thus i asked. but if you're going to use cinnamon then i know you won't do it so my question is answered. :)

I greatly appreciate it. My C is rusty and between the on-boarding and the full nature of the role, it would be some time before I could even think of dedicating myself to it. This is the main obstacle to my ability to contribute code immediately. What makes sense for E is likely some module that could be added to the shelf, either manually or automatically added to something like the tray if Presentation Mode were enabled without it. The name in itself can/should maybe be changed but the functionality is something that I (albeit anecdotally) think more people would value as an option rather than not. "Inhibit Power Management" or something less wordier maybe. :D

As you mentioned, a module is likely the best approach. I've attached screenshots of the functionality from Cinnamon's DE. There are no options, but there are tons of flexible possibilities.

I mentioned Cinnamon fit most but not all of my needs. The main challenges with Cinnamon today for me are that it lacks a configurable pager (even with all of the extensions) and workspace navigation/configuration across multiple displays is wildly inflexible (a drawback of being forked from GNOME 3), but E handles both of these situations extremely well out of the box. The configuration options are why I've been with E for the last decade plus, especially the flexibility in setting key bindings. (Why no one else has allowed for more key binding flexibility still baffles me but I digress.) I opted for Cinnamon because it fit most of my immediate needs. GNOME, MATE, KDE, and countless others do not. My options as of today are E or Cinnamon. When the time comes down the road, I do anticipate that I will develop what needs to be developed to fill whatever gaps I might have. While I might end up on #e (I haven't been on IRC in years), I don't want to keep an open task in the backlog unless I have a plan of action though. ;)

I am open to more conversation about the topic as well especially since I think it can benefit others. I can work on articulating the exact issues I encountered and arguments in favor of the functionality until then.

So this might be some of the disconnect here. 100% of my notifications are OSD from the OS. I have no notifications from the browser precisely for the same reasoning, due to how they override the nature of the system.

but there is no other way to get notifications e.g. for a reply to your reddit post (other than emails). thunderbird's "system notifications" option doesn't use system notifications -p it always uses thunderbird's own notifications thus it's these or no notifications at all. browsers don't support system notifications. if they did - i'd see them. this all applies for electron apps too as they are browsers... :)

i had a look into the notifications and ... they are worse than i thought/hoped. they are override-redirect windows bypassing the wm. this means at best e can refuse to composite them but they will create boxes stealing input from other apps etc. ... i'm going to put this back on the shelf as a "aaaargh" moment.

"Inhibit Power Management" or something less wordier maybe. :D

I don't like that as that also implies other things like stop cpu from down-clocking, keep gpu in a high performance state and so on... but naming aside perhaps it should be a mode and that mode is in settings somewhere as to what options it toggles on and off like blanking, locking, notifications etc. with a timeout attached for how long you can be in that mode before returning to normal. perhaps this smells to me more of a wider mode-switching system than just presentation mode where it can toggle lots of settings. technically you could get what you want with different profiles... but it'd change ALL your e config wholesale - just switch profiles while running to something else... and back. :) one profile just has notifications off and blanking off etc. etc. ... :) a bit brute-force but definitely does the job. so i need to think about this some more but i'm beginning to think a whole mode system is the way to go. this then allows for "game mode", "night time reading mode", "presentation mode" etc. - it can handle what you want and more (just have to allow the mode system to change a wider set of config...).

but there is no other way to get notifications e.g. for a reply to your reddit post (other than emails). thunderbird's "system notifications" option doesn't use system notifications -p it always uses thunderbird's own notifications thus it's these or no notifications at all. browsers don't support system notifications. if they did - i'd see them. this all applies for electron apps too as they are browsers... :)

i had a look into the notifications and ... they are worse than i thought/hoped. they are override-redirect windows bypassing the wm. this means at best e can refuse to composite them but they will create boxes stealing input from other apps etc. ... i'm going to put this back on the shelf as a "aaaargh" moment.

Agreed. I have a few workarounds precisely for these. I use KDE Connect which does respect native OSD. (There's actually a bug here where too many notifications cause E to crash, easily repeatable if one of my devices with Wi-Fi turned off has it turned on and starts receiving a flood of notifications.) For Thunderbird specifically, I used to use an extension that would redirect the notifications to OSD but it's no longer compatible with the latest builds so I've just gone without. (Thunderbird is just RSS for me anyways so I check in often enough.)

So I've worked around the awful browser notification subsystem by essentially duplicating them on mobile natively and routing those back to my workstation.

I don't like that as that also implies other things like stop cpu from down-clocking, keep gpu in a high performance state and so on... but naming aside perhaps it should be a mode and that mode is in settings somewhere as to what options it toggles on and off like blanking, locking, notifications etc. with a timeout attached for how long you can be in that mode before returning to normal. perhaps this smells to me more of a wider mode-switching system than just presentation mode where it can toggle lots of settings. technically you could get what you want with different profiles... but it'd change ALL your e config wholesale - just switch profiles while running to something else... and back. :) one profile just has notifications off and blanking off etc. etc. ... :) a bit brute-force but definitely does the job. so i need to think about this some more but i'm beginning to think a whole mode system is the way to go. this then allows for "game mode", "night time reading mode", "presentation mode" etc. - it can handle what you want and more (just have to allow the mode system to change a wider set of config...).

Maybe "Inhibit Blanking" along with "Inhibit Notifications" and so on. Naming them with a purpose beyond the direct function might recreate the same problem from before. ;)
As long as there's key binding options for each setting, it's got my vote. :D

I'll probably circle around to the IRC channel. It feels like some constructive conversations can be had.

there's actually a bug here where too many notifications cause E to crash

I'd love to either have an easy way to reproduce or backtraces (with ASAN builds)...

Either way - you are suffering the thunderbird problem too. Either have its own native notifications or none. :)

I'll probably circle around to the IRC channel. It feels like some constructive conversations can be had.

They can be. :) disagreements happen and I won't always be convinced and maybe I will hold out for a better way. I'm beginning to think of having a whole mode system rather than a single hardcoded "presentation mode". I'm mulling it over in my brain. How should it work api/code wise. data structures. what should they hold. what should code do/behave like? What should be presented to the user? etc.

I'd love to either have an easy way to reproduce or backtraces (with ASAN builds)...

1. If you have an Android device, install KDE Connect and configure your machine to receive the notifications.
2. Once that's working, disable Wi-Fi on the Android device (for however long it takes for a deep backlog of notifications to be queued).
3. Enable Wi-Fi on the Android device. Notifications will start flooding in. After a certain amount of notification volume (minimum 30 or so), the notification manager in E will be overwhelmed and E will crash. (Setting the notification OSD to a 10 second timeout is one way to get decent count of notification volume.) After restarting E, notifications keep streaming in, but do not consistently trigger consecutive crashes.

I'm mulling it over in my brain. How should it work api/code wise. data structures. what should they hold. what should code do/behave like? What should be presented to the user? etc.

I was busy setting up gitea to replace phab and gitolite... phab will eventually die so for now this conversation is working through ideas :) it's not a ticket that will actually really exist long-term. (git.enlightenment.org now is gitea).

If you have an Android device, install KDE Connect and configure your machine to receive the notifications.

I'd have to run the KDE Connect counterpart service then. This is something that i'll need to revisit in future but it is really annoying and users will suffer too and telling everyone to "use kde connect" to work around it isn't really a viable solution that scales :) If I can have e actively hide or kill off these windows when found... then yes or these apps need to start playing nice, but that means messing with override-redirect windows if i have e battle the app which is going to just be a fight and ugly.

This is another feature that I liked a lot. If there is something actively running that is inhibiting any functionality, the process name is available. (For this example, I had a video streaming in Brave,

This would only work for the situation an app is using a specific dbus protocol to inhibit or something KDE or gnome specific. If they do what steam does for example and actually disable DPMS - you have no idea who did it. The XServer does - but not e. this isn't shown. It's just a x protocol request. yu can disable blanking with just the xset command which runs and goes away once not running anymore even Xorg doesn't know. Same situation with the screensaver suspend request that is part of the screenaver extension. I can only assume brave is using some kde/gnome specific dbus service things ... not sure it's something in systemd/logind as i dont think there is an inhibit.

a quick search:

https://stackoverflow.com/questions/17478532/powermanagement-inhibit-works-with-dbus-python-but-not-dbus-send

so something gnome or kde invented somewhere... not a normal wm thing. e has no such service, thus it can't tell you who asked to inhibit as above. and apps can still use the above to request inhibiting too (mess with dpms/blanking in xorg directly or x screensaver suspending which is the better way as your request to suspend dies with your client connection to xorg automatically and works on everything).