RFC: adding notification/attention/info bar to wx?
Vadim Zeitlin
In the few last wx applications I was working on I used what I called a
"notification area" and what seems to be more commonly called "attention
bar", i.e. a small transient control near the top (or the bottom) of the
main window showing some message to the user and maybe providing a button
or two, e.g. https://www.sfefcu.org/images/ffpopup1.jpg. Maybe it's also
the same as "info bar" (http://en.wikipedia.org/wiki/Infobar). In any case,
I hope you see what I mean and maybe even see why I like it so much:
showing messages in a non-modal bar like this is much less intrusive than
showing message boxes and also looks nicer.
So I wonder if it would be a good idea to add support for this directly to
wx. It's not difficult to implement this but it's not that simple neither,
at least if you want to use ShowWithEffect() to show it as this involves
playing with sizers to free the space for the bar first and then sliding it
into this space later.
FWIW the immediate trigger for asking this question is that I'd like to
use something like this in wxPreviewFrame to show warnings about the
printout class such as wxHtmlPrintout warning about printout not fitting
into page horizontally.
Assuming there is broad support for (or at least absence of opposition to)
addition of this to wx, I have several questions:
0. What name would people prefer? I like wxNotificationBar myself but if
wxAttentionBar or wxInfoBar would be deemed easier to find for wx users
I could live with them too (although in this case I strongly prefer the
latter, wxAttentionBar doesn't appeal to me).
1. My existing implementation(s) only work when the top frame uses sizer
for layout. I think it's not a big limitation but if there was demand
for using it with e.g. a single child, it could be added too. Although
then we'd need some way to tell it whether it should go to the top or
to the bottom while with the sizer you'd just put it wherever you wanted
it to appear.
2. My idea for the API of this class is a bit like wxCollapsiblePane, i.e.
it will have a sub-window which could contain any other controls. I'd
provide a wxTextNotificationBar subclass for simple text notifications
(the "Close" button will always be present, I don't think it makes sense
to not let the user close this bar). What do you think?
3. There are many, many things to customize in this class, from the
background colour (I hard code c8ffff for now which is definitely not
right, I'd welcome better ideas) to the icon to use for the closing
button. I'd like to keep this pretty simple for now as I think this
class would be more useful if it were immediately usable without too
much tweaking but if people have additional idea about what they'd like
to see in it, I'd be interested in hearing them (without promising to
implement all of them).
Thanks in advance for your ideas!
VZ
Werner F. Bruhin
> Hello,
>
> In the few last wx applications I was working on I used what I called a
> "notification area" and what seems to be more commonly called "attention
> bar", i.e. a small transient control near the top (or the bottom) of the
> main window showing some message to the user and maybe providing a button
> or two, e.g. https://www.sfefcu.org/images/ffpopup1.jpg. Maybe it's also
> the same as "info bar" (http://en.wikipedia.org/wiki/Infobar). In any case,
> I hope you see what I mean and maybe even see why I like it so much:
> showing messages in a non-modal bar like this is much less intrusive than
> showing message boxes and also looks nicer.
>
> So I wonder if it would be a good idea to add support for this directly to
> wx. It's not difficult to implement this but it's not that simple neither,
> at least if you want to use ShowWithEffect() to show it as this involves
> playing with sizers to free the space for the bar first and then sliding it
> into this space later.
>
> FWIW the immediate trigger for asking this question is that I'd like to
> use something like this in wxPreviewFrame to show warnings about the
> printout class such as wxHtmlPrintout warning about printout not fitting
> into page horizontally.
>
>
> Assuming there is broad support for (or at least absence of opposition to)
> addition of this to wx, I have several questions:
>
> 0. What name would people prefer? I like wxNotificationBar myself but if
> wxAttentionBar or wxInfoBar would be deemed easier to find for wx users
> I could live with them too (although in this case I strongly prefer the
> latter, wxAttentionBar doesn't appeal to me).
>
InfoBar +1
NotificationBar +0
AttentionBar -1
> 1. My existing implementation(s) only work when the top frame uses sizer
> for layout. I think it's not a big limitation but if there was demand
> for using it with e.g. a single child, it could be added too. Although
> then we'd need some way to tell it whether it should go to the top or
> to the bottom while with the sizer you'd just put it wherever you wanted
> it to appear.
>
fine with me.
> 2. My idea for the API of this class is a bit like wxCollapsiblePane, i.e.
> it will have a sub-window which could contain any other controls. I'd
> provide a wxTextNotificationBar subclass for simple text notifications
> (the "Close" button will always be present, I don't think it makes sense
> to not let the user close this bar). What do you think?
>
> 3. There are many, many things to customize in this class, from the
> background colour (I hard code c8ffff for now which is definitely not
> right, I'd welcome better ideas) to the icon to use for the closing
> button. I'd like to keep this pretty simple for now as I think this
> class would be more useful if it were immediately usable without too
> much tweaking but if people have additional idea about what they'd like
> to see in it, I'd be interested in hearing them (without promising to
> implement all of them).
>
easily changed.
Werner
Vaclav Slavik
> background colour (I hard code c8ffff for now which is definitely
> not right, I'd welcome better ideas)
I use wxSYS_COLOUR_INFOBK, this (IIRC) matches Firefox on Windows and
GTK+. On OS X, it would be best to match it too, because it's the only
widespread implementation there [that I'm aware of] -- see attached
screenshot.
Vaclav
Julian Smart
Vadim Zeitlin wrote:
> Hello,
>
> In the few last wx applications I was working on I used what I called a
> "notification area" and what seems to be more commonly called "attention
> bar", i.e. a small transient control near the top (or the bottom) of the
> main window showing some message to the user and maybe providing a button
> or two, e.g. https://www.sfefcu.org/images/ffpopup1.jpg. Maybe it's also
> the same as "info bar" (http://en.wikipedia.org/wiki/Infobar). In any case,
> I hope you see what I mean and maybe even see why I like it so much:
> showing messages in a non-modal bar like this is much less intrusive than
> showing message boxes and also looks nicer.
>
I also think this will be an excellent thing to provide in wxWidgets.
> 0. What name would people prefer? I like wxNotificationBar myself but if
> wxAttentionBar or wxInfoBar would be deemed easier to find for wx users
> I could live with them too (although in this case I strongly prefer the
> latter, wxAttentionBar doesn't appeal to me).
>
I like wxInfoBar.
> 1. My existing implementation(s) only work when the top frame uses sizer
> for layout. I think it's not a big limitation but if there was demand
> for using it with e.g. a single child, it could be added too. Although
> then we'd need some way to tell it whether it should go to the top or
> to the bottom while with the sizer you'd just put it wherever you wanted
> it to appear.
>
I definitely would not like to see this class restricted to a particular
context, i.e. frames. It would make it very hard create a component that
can be used in a number of different scenarios, such as creating a web
browser control that could be added to any window. I'd be happy to see
derived classes that would make it work easily in particular contexts,
of course, such as a frame with a sizer. The bar can generate a close
event that can be used by the frame-specific class to hide the bar via
sizer calls.
> 2. My idea for the API of this class is a bit like wxCollapsiblePane, i.e.
> it will have a sub-window which could contain any other controls. I'd
> provide a wxTextNotificationBar subclass for simple text notifications
> (the "Close" button will always be present, I don't think it makes sense
> to not let the user close this bar). What do you think?
>
I wonder if occasionally you might want to make it more modal, i.e. you
have to respond and not close it. I don't think it would add much to the
API to hide or disable the close button.
Anyway, it sounds very useful and will encourage better UIs. Looking
forward to it!
Thanks,
Julian
Peter Most
>
> So I wonder if it would be a good idea to add support for this directly to
> wx. It's not difficult to implement this but it's not that simple neither,
> at least if you want to use ShowWithEffect() to show it as this involves
> playing with sizers to free the space for the bar first and then sliding it
> into this space later.
>
IMHO everything what makes wxWidgets more attractive is a good idea :-)
Regards Peter
Jeff Tupper
> ...
> In the few last wx applications I was working on I used what I called a
> "notification area" and what seems to be more commonly called "attention
> bar", i.e. a small transient control near the top (or the bottom) of the
> main window showing some message to the user and maybe providing a button
> I hope you see what I mean and maybe even see why I like it so much:
> showing messages in a non-modal bar like this is much less intrusive than
> showing message boxes and also looks nicer.
>
> 0. What name would people prefer? I like wxNotificationBar myself but if
> wxAttentionBar or wxInfoBar would be deemed easier to find for wx users
> I could live with them too (although in this case I strongly prefer the
> latter, wxAttentionBar doesn't appeal to me).
included button may carry out some action other than simply dismissing
the window).
wxNotificationBar: +1, although perhaps a bit long (wxNotice?)
wxAttentionBar: -1, if we wanted the user's attention, wouldn't a
dialog be preferable? (My initial reason for -1 here is, though, that
a bit of googling seemed to show people using this for a buttonless
header with a different background.)
Since it seems to be a partial replacement for dialogs, wxDialogBar
seems to be another possibility but perhaps users will think it fits
in a wxDialog.
If the close button were optional and the window slides out by
default, perhaps wxSlideXXX is another option. (If the close button is
always present and enabled, that would strengthen the case for using
"Info" in the class name, however.)
Btw, where is "attention bar" used? Since Vaclav used it in his
firefox png, I tried the following searches:
'firefox "attention bar"' : 1,030 results
'firefox "notification bar"' : 40,800 results
'firefox "info bar"' : 20,300 results (a fair % of the first-page
results don't refer to the topic at hand though, instead to things
like the status bar)
Also, a question: is "Bar" the right suffix for wx? (There are a bunch
of "bars" that don't take controls.) Would "Pane" or "Panel" be better
as a suffix?
Vadim Zeitlin
JT> wxInfoBar: -1, as its not necessarily purely informational (as an
JT> included button may carry out some action other than simply dismissing
JT> the window).
True, it's not purely informational but it's _mostly_ informational. And
this is the shortest name which does count in its favour.
JT> wxNotificationBar: +1, although perhaps a bit long (wxNotice?)
I'd be glad to go with this one but so far there seems to be slight
preference for wxInfoBar... Let's wait if there are any more opinions.
JT> Since it seems to be a partial replacement for dialogs, wxDialogBar
JT> seems to be another possibility but perhaps users will think it fits
JT> in a wxDialog.
Yes, for me wxDialogBar implies a connection with wxDialog and there is
none here.
JT> If the close button were optional and the window slides out by
JT> default, perhaps wxSlideXXX is another option. (If the close button is
JT> always present and enabled, that would strengthen the case for using
JT> "Info" in the class name, however.)
Yes, I think it will be always present and enabled. As I said, I don't see
any reason to not allow the user to close this notification.
JT> Btw, where is "attention bar" used?
No idea, I'm not familiar with this term neither and can't find any
authoritative references to it (of course, I don't know if you count
http://en.wikipedia.org/wiki/Infobar authoritative...)
JT> Also, a question: is "Bar" the right suffix for wx?
Yes, I'm pretty sure about this one. It's rather similar to wxStatusBar
for example.
Regards,
VZ
Vadim Zeitlin
JS> > 1. My existing implementation(s) only work when the top frame uses sizer
JS> > for layout. I think it's not a big limitation but if there was demand
JS> > for using it with e.g. a single child, it could be added too. Although
JS> > then we'd need some way to tell it whether it should go to the top or
JS> > to the bottom while with the sizer you'd just put it wherever you wanted
JS> > it to appear.
JS> >
JS> I definitely would not like to see this class restricted to a particular
JS> context, i.e. frames. It would make it very hard create a component that
JS> can be used in a number of different scenarios, such as creating a web
JS> browser control that could be added to any window. I'd be happy to see
JS> derived classes that would make it work easily in particular contexts,
JS> of course, such as a frame with a sizer. The bar can generate a close
JS> event that can be used by the frame-specific class to hide the bar via
JS> sizer calls.
I guess the "frame" (well, wxTLW) part is not really important, as long as
its parent uses a sizer for layout it shouldn't matter if it's a frame or
panel. It might still need to change the size of the containing window when
it pops up if it's not currently big enough to show it (but this could be
disabled with a flag similar to wxCP_NO_TLW_RESIZE).
JS> > 2. My idea for the API of this class is a bit like wxCollapsiblePane, i.e.
JS> > it will have a sub-window which could contain any other controls. I'd
JS> > provide a wxTextNotificationBar subclass for simple text notifications
JS> > (the "Close" button will always be present, I don't think it makes sense
JS> > to not let the user close this bar). What do you think?
JS> >
JS> I wonder if occasionally you might want to make it more modal, i.e. you
JS> have to respond and not close it.
I don't see at all why would you use this control in such case. A modal
dialog would be much better IMO, user will be very confused if he can't do
anything else until he dismisses an innocently looking bar. Or did I
misunderstand you?
Thanks,
VZ
Robert Roebling
Vadim Zeitlin wrote:
> True, it's not purely informational but it's _mostly_ informational.
I agree
+1 wxInfoBar
Vadim Zeitlin
RR> Vadim Zeitlin wrote:
RR>
RR> > True, it's not purely informational but it's mostly informational.
RR>
RR> I agree
RR>
RR> +1 wxInfoBar
Ok, considering that both Julian, Robert and Wikipedia like this one, this
is what it will be called. Now that this most vexing problem is solved, I
have high hopes for quickly implementing the control itself :-)
Thanks!
VZ
Jeff Tupper
> On Mon, 27 Jul 2009 20:44:40 -0400 Julian Smart <jul...@anthemion.co.uk> wrote:
> JS> have to respond and not close it.
>
> I don't see at all why would you use this control in such case. A modal
> dialog would be much better IMO, user will be very confused if he can't do
> anything else until he dismisses an innocently looking bar. Or did I
> misunderstand you?
By "more modal" I think he just meant that you'd have to push a button
in the bar to get it to go away --- you couldn't just push a close
box. (As could be the case for a notification that required you to
choose between alternative actions for which there was no reasonable
default.)
Jeff Tupper
>
> JT> Also, a question: is "Bar" the right suffix for wx?
>
> Yes, I'm pretty sure about this one. It's rather similar to wxStatusBar
> for example.
it? Given the somewhat confusing nature of windows, controls, panels,
and sizers, beginners might appreciate a uniform naming convention
that spells out what sort of things a widget can contain / manage.
Peter Most
> RR> +1 wxInfoBar
>
> Ok, considering that both Julian, Robert and Wikipedia like this one, this
> is what it will be called. Now that this most vexing problem is solved, I
> have high hopes for quickly implementing the control itself :-)
>
Even though you've already made up your mind I still wanted to suggest a
different name. Looking at your example from FireFox it looks more like a
banner across the page, so maybe InfoBanner might be a more appropriate name?
Regards Peter
Vadim Zeitlin
PM> Hi Vadim,
PM>
PM> > RR> +1 wxInfoBar
PM> >
PM> > Ok, considering that both Julian, Robert and Wikipedia like this one, this
PM> > is what it will be called. Now that this most vexing problem is solved, I
PM> > have high hopes for quickly implementing the control itself :-)
PM> >
PM> Even though you've already made up your mind I still wanted to suggest a
PM> different name. Looking at your example from FireFox it looks more like a
PM> banner across the page, so maybe InfoBanner might be a more appropriate name?
No, sorry, I really do want to have "Bar" suffix for it as it's similar to
other "Bar" classes.
Regards,
VZ
Vadim Zeitlin
JT> On Jul 28, 5:32 am, Vadim Zeitlin <va...@wxwidgets.org> wrote:
JT> > On Mon, 27 Jul 2009 23:54:55 -0700 (PDT) Jeff Tupper <tupperli...@gmail.com> wrote:
JT> >
JT> > JT> Also, a question: is "Bar" the right suffix for wx?
JT> >
JT> > Yes, I'm pretty sure about this one. It's rather similar to wxStatusBar
JT> > for example.
JT>
JT> wxStatusBar doesn't let users insert arbitrary controls though, does
JT> it?
It does allow you to do it, see the statbar sample.
JT> Given the somewhat confusing nature of windows, controls, panels,
JT> and sizers, beginners might appreciate a uniform naming convention
JT> that spells out what sort of things a widget can contain / manage.
It's way too late for this in wx (FWIW it's one of the difficult problems
to solve even for wxTNG, at least I could never find a satisfactory
hierarchy for it, but that's another story...).
Regards,
VZ
Peter Most
> other "Bar" classes.
>
wxInfoBannerBar?
Regards Peter
Vadim Zeitlin
PM> > No, sorry, I really do want to have "Bar" suffix for it as it's similar to
PM> > other "Bar" classes.
PM> >
PM> wxBannerBar?
PM> wxInfoBannerBar?
This is too alliterative, really. IMO wxInfoBar is not bad and the fact
that it's mentioned by Wikipedia increases the probability that people know
what it is.
Regards,
VZ
Vadim Zeitlin
VZ> On Tue, 28 Jul 2009 22:14:25 +0200 Peter Most <Peter...@gmx.de> wrote:
VZ>
VZ> PM> > No, sorry, I really do want to have "Bar" suffix for it as it's similar to
VZ> PM> > other "Bar" classes.
VZ> PM> >
VZ> PM> wxBannerBar?
VZ> PM> wxInfoBannerBar?
VZ>
VZ> This is too alliterative, really. IMO wxInfoBar is not bad and the fact
VZ> that it's mentioned by Wikipedia increases the probability that people know
VZ> what it is.
Just to finally close this discussion: I've just realized that this is
really the only choice because the only platform which has a native
equivalent of this is GTK+ with its GtkInfoBar (which might explain the
fact that Robert voted for wxInfoBar...). Unfortunately it's only in
2.18 which is not even in Debian unstable yet so I can't test it easily but
it certainly looks like the same thing, see
http://library.gnome.org/devel/gtk/unstable/GtkInfoBar.html
and 2 screenshots:
http://people.freedesktop.org/~david/palimpsest-progress.png
http://people.freedesktop.org/~david/palimpsest-spinner.png
I won't be writing a native version of this for now as, once again, I
can't really test it but I'll keep the native GTK+ API in mind and I think
it will be easily possible to do it in the future.
Regards,
VZ
Jeff Tupper
>
> JT> wxStatusBar doesn't let users insert arbitrary controls though, does
> JT> it?
>
> It does allow you to do it, see the statbar sample.
wxStatusBar yet.
Eric Jensen
i'm very curious to see how you're going to implement the
"slide-in/out" effect without heavy flickering. I tried something like
that some time ago and failed miserably and just decided to just
hide/show the panels i was trying to "slide in".
Eric.
Vadim Zeitlin
EJ> i'm very curious to see how you're going to implement the
EJ> "slide-in/out" effect without heavy flickering. I tried something like
EJ> that some time ago and failed miserably and just decided to just
EJ> hide/show the panels i was trying to "slide in".
You will be able to look at the code once I check it in but basically you
need to reserve space for the window before showing it with effect. I.e. it
must expand into an empty area and not on top of another window which would
indeed be visually unpleasant.
Regards,
VZ