Go to the FreeLists Home Page Home Signup Help Login
 



[haiku-development] || [Date Prev] [05-2007 Date Index] [Date Next] || [Thread Prev] [05-2007 Thread Index] [Thread Next]

[haiku-development] Re: Notification Server?

  • From: "Ryan Leavengood" <leavengood@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 24 May 2007 10:21:27 -0400
Wow, little did I know this seemingly simple concept would cause so
much discussion. But that seems to be the norm these days in this
community, which is good since it means people care about Haiku and
where it is going.

Believe it or not, I'm not that "married" to this concept. I won't be
upset or bothered if the consensus is that it should not be done. In
other words, I'm willing to hear arguments against it without
excessive bias.

Neils, I get what you are saying. As a developer I know all about
"getting in the zone" or flow of my work, and I hate being interrupted
when I'm in that place. But I'm not always working. There are times
when I appreciate being notified that I have new email, or that a
download is finished, and most importantly a reminder about a meeting
since unlike yourself I'm not always checking the time. Actually even
when I'm working in the zone I still need to know about that meeting,
so a somewhat distracting notification is something I would actually
NEED. While a slight change in the display of the deskbar time might
alert you about the impending meeting, it won't work for me. Maybe I'm
just not as organized, or maybe I just get super focused when working,
but either way, your solution won't work for me.

So my point is, while I appreciate your thoughts about user
interaction and wanting to minimize interruptions, it seems you are
biased toward your own behaviors and attitudes and therefore ignore
what other different users might want or need.

I'm also concerned that your ideas about implementing specific
application-dependent notifications will result in a lot of
inconsistency. One of the main reasons I suggested this idea was that
so Haiku could provide a consistent (and hopefully well implemented)
way for any and all applications to notify the users about events. I
would find it annoying if I had to keep an eye on a certain Deskbar
replicant to see new email, and then keep an eye on the time to know
about meetings, and then keep an eye on my IM window to see when my
coworker Joe logs in, who I have to ask a question. That seems a whole
lot more distracting that just noticing little notification windows
when they pop up.

So what I suggest is the following: the notification system can be run
in push or pull mode. In push mode, the notification windows will be
shown. In pull mode, they won't, and the user will need to actively
check a "notification log" to see what notifications have been sent.
Even in push mode the notification log will still store the sent
notifications, allowing the user to review previous notifications or
see ones they may have missed. The notification log can be kept in
memory on a LiveCD or read-only medium, and on a writable system the
notifications will be stored as files with special attributes under
~/config/notifications (as suggested by Jonas.)

If you never want to see the pop-up notification windows, you can just
always keep the app in pull mode and you won't ever see them. When you
reach a stopping point in your work you can take a quick look at the
notification log to see if there is anything of interest. In addition
to the total push/pull mode option, there will be further filtering
options to enable some notifications to be "pushed" while others are
only put in the log.

I think this is a reasonable solution.

Also in regards to Michael's comments, I agree that a full-on server
is not really needed. I was considering putting the notification
window part of this in the app_server, since from there the display of
the window is under total control, so for example it can be shown on
top without stealing the focus.

Regards,
Ryan





[ Home | Signup | Help | Login | Archives | Lists ]

All trademarks and copyrights within the FreeLists archives are owned by their respective owners.
Everything else ©2007 Avenir Technologies, LLC.