[haiku-development] Re: Set a custom icon for a BAlert
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 01 Aug 2012 21:16:43 +0200
John Scipione wrote:
> On Wed, Aug 1, 2012 at 2:35 PM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> > Ryan Leavengood wrote:
> >> On Wed, Aug 1, 2012 at 8:53 AM, François Revol <revol@xxxxxxx> wrote:
> >> > On 01/08/2012 13:40, John Scipione wrote:
> >> >> Now, I could create a custom AboutWindow class (there already is one
> >> >> in fact) and reproduce BAlert there with the extra icon functionality
> >> >> instead, but, I can see how being able to set the icon on an alert
> >> >> dialog could be useful in other situations.
> >> >>
> >> >> Any objections to me adding this feature?
> >> >
> >> > I thought we were removing about boxes...
> >>
> >> Yes I believe at one point there was discussion of that, but frankly I
> >> think it is a bad idea. Sure in some cases about boxes are just a
> >> hard-to-maintain list of who worked on it, but they can and should
> >> also provide some other useful information. BApplication has an entire
> >> method dedicated to showing the about box so I think not having them
> >> in included Haiku applications is bad form.
> >
> > FWIW I disagree for reasons already discussed at length in an older thread.
>
> Reading the linked thread, I don't really understand why we should get
> rid of About Dialogs in system apps, but we should get rid of Authors
> names from the about dialogs.
Humdinger summed it up already: All information you'd display in the about box
are already in the system about box. So there's little point in having one in
the first place.
> > Regarding the API extension, that would be OK IMO, though generally I find
> > that this kind of extension scales better by providing setter methods
> > instead.
>
> Most of the time I agree with you here... although this seems like a
> special case because you either want to specify a constant like
> B_IDEA_ICON or a bitmap to the constructor but not both. The SetIcon()
> method would happen after the fact.
As I wrote, I think it would be OK in this case, mainly because the interface
kit isn't made for eternity anyway. The argument why one wouldn't want to do
this in this case either would be since one, there are other thinkable
alternatives one could pass -- e.g. a BPicture or some animated object (for
which we don't have a class yet) -- so with the same reasoning one would
already need 4 constructor versions. And two, earlier or later there will be
other orthogonal options. Just making one up: a tooltip, for which a string
version and a generic BToolTip* version would be needed. That would result in 8
combinations already. So at some point one has to give up anyway and stop
adding constructor versions.
A cool alternative would be to provide a specific parameter class for each
parameter for which different alternatives exist. The parameter class would
have a non-explicit constructor for each alternative parameter type. So in the
end you'd only need one main class constructor and the user could pass in any
combination of parameter types. It's quite a bit of additional work though.
CU, Ingo
Other related posts:
