[haiku-development] Re: Set a custom icon for a BAlert

  • From: John Scipione <jscipione@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 1 Aug 2012 16:15:01 -0400

On Wed, Aug 1, 2012 at 3:35 PM, Ryan Leavengood <leavengood@xxxxxxxxx> wrote:
> On Wed, Aug 1, 2012 at 3:16 PM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
>>
>> 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.
>
> Fair enough, I'm convinced. Especially if we can still provide some
> niceties for application authors to more easily make good about boxes
> (such as the custom icons described here.)

I'm not completely convinced, but mostly :) Okay, the version is still
relevant info for an About dialog as is copyright info. Although I'll
admit that isn't really too much. I'm very glad that I asked this
question because I had no idea there was a movement to get rid of
about dialogs in system apps.

>> 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.

Sounds like a good plan... for R2 :)

> Or maybe just add a constructor for the case of having no icon at
> construction time (or no type really in this case.) Then the setters
> for whatever was actually wanted could be used without the wasteful
> overhead of setting up an icon at construction time which would be
> quickly replaced.
>
> Actually looking at the code one can achieve the above by passing
> B_EMPTY_ALERT for the type.
>
> So maybe for this we really just need an icon getter and setter added to 
> BAlert.

In any case, I'd really like to create a nice class for 3rd party devs
to use for about dialogs. I've already started doing this to
BAboutWindow class. What I'll do is modify that class to not use
BAlert side-stepping this problem. I can still implement methods to
get and set the icon of BAlert dialog later on, but I won't add a new
constructor.

Thanks for the feedback,
John Scipione

Other related posts: