[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:
