[haiku-commits] Re: r43053 - haiku/trunk/src/servers/mail
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Wed, 02 Nov 2011 09:17:22 +0100
Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> a écrit :
> On 11/01/2011 04:37 PM, Adrien Destugues wrote:
> > "Axel Dörfler"<axeld@xxxxxxxxxxxxxxxx> a écrit :
> > I'm not yet sure about it. At least, the mail daemon opens quite a
> > few
> > notification windows (even if it shouldn't), and that makes it
> > rather
> > annoying when they are not movable and not closable (and bigger
> > than
> > they were before).
> > 2/3 long copy operations in tracker would waste screen space the
> > same
> > way, without any way to discard them (at best you can fold them).
>
> To me that sounds like good enough reason to improve our notifications
> to make it actually usable for these tasks.
> That's actually something I wanted to work on during BeGeistert, but
> I
> figured I should be able to read mail again under Haiku first :-)
That's the plan eventually :)
I'm in the process of merging a patch from plfiorini, that wasn't
applied because of the UI changes I made. There are some changes to the
API with it, and some cleanup. I wanted to get it in trunk before
messing with it even more.
It also brings layout kit to the notification window, which may help
with adding arbitrary views.
btw, the "dozen of notification" problem for mail is now fixed. We get
one per account for progress report, and one for "x new messages" when
it's done.
>
> What I imagine would be that such notifications are only visible for
> a
> short amount by default (the user may change those settings), and
> then
> be moved into a notification icon in the Deskbar, when you hover that
> one (or maybe just click on it, hovering might become annoying),
> you'll
> see all current ongoing progress notifications.
Would that replace the mail replicant ?
> You mean you like to revert your changes again? In that case, could
> you
> make it just #ifdef'd out, so one can put it back in easily?
No, reuse the existing setting to manage the new notification windows.
Its now done.
> Well, as I said, there is also the new mail notifier add-on. But that
> could probably be removed completely, and the functionality could be
> moved into the daemon, if still needed.
Not sure, I don't know the code much. Depends if we want to have other
ways to notify stuff, but I don't think that's a good idea. Rather make
only one, but one that feels right :)
Add-ons can be kept for funnier things like driving blinkenlights ...
>
> > I think the error notices may be moved here too. But for these I'd
> > like
> > to remove the timeout and make sure the user sees and closes them.
>
> Yes, I would add an error or warning type of notification for this,
> as well.
They exist already.
> In any case, I would like to be able to use embedded views in there
> as
> well, for example, a notification could provide a link to a website,
> a
> button to launch some application, or show the cover art of the song
> currently played along with a button to skip that song. WebPositive
> could directly allow to open a downloaded archive. That sort of
> thing.
It's possible to setup an application to lauch on clicking a
notification (with associated argv), or to set a file (then opened with
its preferred app).
Still, adding custom BViews would be nice, if only for pause/stop
buttons.
Another thing I'd like to rework is the progress bar. It's only
possible to use it as a percentage indicator, while BStatusBar can do
more. A SetMaxProgress() feels missing.
--
Adrien.
Other related posts: