[haiku-development] Re: BAboutWindow lifecycle

  • From: John Scipione <jscipione@xxxxxxxxx>
  • To: "haiku-development@xxxxxxxxxxxxx" <haiku-development@xxxxxxxxxxxxx>
  • Date: Mon, 29 Apr 2013 18:03:45 -0400

On Mon, Apr 29, 2013 at 4:59 PM,  <pulkomandy@xxxxxxxxxxxxx> wrote:
> The about window is very close to a BAlert, even if it isn't one anymore. You
> don't want to keep it open, you don't want it to hide under other windows.

Why shouldn't a BAboutWindow be a regular BWindow that you can keep
open or hide under other windows? BAlert's suck as about boxes,
they're just used because they're easy.

>> The question is, where do we want to put the complexity, in the hands
>> of the BAboutBox class programmer or in the hands of the user? Modal
>> windows should be used for modal actions and this action is NOT modal,
>> there's no reason to block the app to show an about dialog! It's
>> really not that much work either and I'd much rather deal with an
>> extra looper hanging around or some extra message passing than block
>> the entire app needlessly.
> The extra looper is definitely a bad thing. It shows to the user in
> ProcessController, wastes memory (not only a thread stack, but also anything
> that could be in the window such as the icon bitmap). All this for a window
> that will very unlikely get shown twice during app lifetime. Not a memory
> leak, but not far from it.

You're coming at this from a abstract standpoint, the memory used
isn't that much but the practical downsides of using a BAlert-style
about box are very real.

> Anyway, you're right on the point that the complexity should be in the hands
> of BAboutWindow developer. Right now, it is in the application developer
> hands (having to know that this window don't get deleted, that he has to show
> it, move it to the current workspace if needed, etc). All of this should be
> done in BAboutWindow. If we really don't want it to be modal, then it should
> be a Singleton like Axel suggested, and do the work by itself without any
> supporting code at BApplication side.

If we can get the benefits of a shallow interface like BAlert without
the downsides of modality I say great, but I don't see how that's
possible. How does making the window a Singleton work?

What might be a good solution is to make BAboutWindow work both ways,
a modal version that works like BAlert with a similar interface and
tradeoffs and a non-modal version that works like I suggested above.
The non-modal version can be used by the base system apps, while the
modal version can be used in BApplication::AboutRequested().

Other related posts: