[haiku-development] Re: BAboutWindow lifecycle
- From: pulkomandy@xxxxxxxxxxxxx
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 29 Apr 2013 21:16:48 +0200
> I really don't want the about box to be modal since that blocks the
> app, but if you wanted to go that way it would be pretty easy to do
> using BAlert as a base class instead of BWindow. Making the about box
> modal blocks the calling app which is less than ideal.
Well, you don't need to keep the about box open while you do other things
with the app, so having it modal sounds ok to me. You don't need to use
BAlert for modal windows, there's a window flag for that.
I don't like modal windows much, but I think BAboutWindow falls in the case
where it's ok to do that.
>
> The reason that I hid the about box when the window is closed instead
> of destroying the object is because if I were to destroy the window
> the reference to the about box in the calling app would then point to
> freed memory and thus would crash the app next time the variable is
> referenced say to check if it's NULL. I basically used hiding as a way
> to take a shortcut around this problem.
>
> But, there is a solution to this problem. The about box needs to send
> a message back to the original app (and maybe wait for a reply just to
> be sure) on close so that the calling app can set it's about window
> reference to NULL.
That's getting quite complicated. If you make the about box modal, then it
will stay on top and be destroyed when you close it. There is no need for the
app to keep a reference to it. This is more in line with the Be API design
(the window is a thread, it has its own life).
> Unfortunately this is only a partial solution because it doesn't
> address some of the other side effects we get from hiding instead of
> destroying the window. For instance the about window will no longer
> remember it's position but that functionality can be added on.
Keeping the window open is NOT the right way to do that. It means you're
having a thread running in the background, and wastes a lot of resources (not
much for a single window, but adds up quite fast if all windows in all apps
work this way). BWindow takes a BRect as an argument, and it's easy enough to
save the window position on closing if you want to.
I think it isn't useful to do that for every window in the system, however.
It's nice to do it for document windows, and in this case you can save the
position as an attribute to the document itself (this is what StyledEdit, Pe,
Tracker, ... do). For "floating" windows (preflets, alerts, about boxes), the
best way to go is either one of :
- Fixed position
- Relative to parent window
There are other cases such as Terminal and Web+. These are not (always)
document-based. For these, saving the window position makes sense. But this
works only on closing/reopening the application, the window don't get hidden.
The other special case is our preflet windows. I believe it's ok to center
these on screen.
--
Adrien.
Other related posts:
