[haiku-development] Re: The ways of Reboot. Acknowledge or not?
- From: "Michael Phipps" <michael.phipps@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 01 May 2009 20:22:14 -0400
>From: "Ryan Leavengood" [leavengood@xxxxxxxxx]
>The one addition there (that may be later in the discussion) is not to
>bother having flags on apps to indicate they want to be notified, and
>just having reasonable default handlers in BApplication to ignore
>these messages.
Yes, or even what Axeld said - allow the B_MESSAGE_NOT_UNDERSTOOD to serve.
>> At least I don't see any real points of failures - you would just need
>> some housekeeping as you say.
>
>Conceptually it seems simpler to just have the broadcast, though as
>long as crashing apps are handled properly it may not be so bad with
>the approach you described. It also seems less error prone to have a
>handler that can check current state to see if the screensaver (or
>other PM event) can go on, rather than have code to disable and enable
>it in various places. Though I suppose bugs can come up in either
>case, either an app not turning things back on when it should, or one
>with a logic bug in the broadcast handler that always says "no, don't
>start the screensaver."
A nice feature (if everyone agrees) would be to "enhance" BApplication
with a bool that is a simple "allow screensaver". It would make this very easy
to use.
The implementation would even be pretty simple - just reply to the message with
a
value of fAllowScreenSaver. That would take up a reserved slot, though. :-/
Stupid
fragile base classes...
>Yeah this isn't an event the user is waiting on. Also I don't see why
>apps would take a long time to respond, it should just be a simple
>matter of "is a video playing", or "is a full screen presentation
>running", etc. The broadcast would probably best be done
>synchronously, so a slow app could mess things up.
Or you set a low time out (1 second). Any non-responses are no responses.
>> From an application POV, though, I guess Ryan's solution could be
>> actually easier to handle, but also less flexible as it would require
>> your app to have at least one looper running (that knows about the
>> action that should prevent a power management action). That would make
>> it impossible for tools like wget to use that feature. OTOH, I don't
>> know how bad that would really be :-)
>
>My thoughts were to always send these messages to applications and
>have the handler code in BApplication and subclasses. Though I suppose
>it might be smart to allow other loopers to subscribe. But indeed
>either way some sort of BLooper needs to be around, and your solution
>would probably be usable by any program. So that is definitely a +1
>there. Another option is a hybrid solution where programs like wget
>can just call into an API and BApplications receive broadcasts :)
I don't see why wget or any other command line app would want to know. Those
apps would have the same issues with B_QUIT_REQUESTED and maybe others.
>I'm not that invested in my broadcast idea, I just want whatever is
>the simplest, most elegant and least error prone. Also if we ever get
>Flash and Flash video then that must definitely be tied into this! I
>always have problems with screensavers on other systems when watching
>long Google Videos or YouTube playlists. It is very annoying.
I think that it is a good and very Be-like suggestion. +1. :-)
Other related posts:
