[haiku-development] Re: BAboutWindow lifecycle
- From: John Scipione <jscipione@xxxxxxxxx>
- To: "haiku-development@xxxxxxxxxxxxx" <haiku-development@xxxxxxxxxxxxx>
- Date: Mon, 29 Apr 2013 16:25:30 -0400
On Mon, Apr 29, 2013 at 3:16 PM, <pulkomandy@xxxxxxxxxxxxx> wrote:
>
>> 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.
How is it okay? The app is not waiting on user input so a modal dialog
is wrong. Maybe excusable because it's supposedly short-lived but this
is just not the kind of tradeoff we should be making.
>> 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).
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.
>> 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 agree, it's not a great solution, but it's the lesser of two evils.
I'm employing you that if your going to update how it works, do it
right, don't take another shortcut and use a modal window, use a
BWindow, destroy it on close and inform the calling app, don't just
throw a modal window in the center of the screen every time, remember
the previous window position and put it back where it was, in short,
really do it right. I did this already for Deskbar preference
(listening to your objections there), Tracker preferences does it too,
and a few apps like Deskcalc remember their window positions as well,
there are code examples to look at, you don't have to reinvent the
wheel here.
> 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.
We've got some piecemeal solutions for a few apps here and there, we
don't have a general OS provided solution so it's up to the app
developer to do the work, sometimes they do, sometimes they don't.
It's quite frustrating when an app forgets where you put a window,
that's why Tracker keeps track of it's windows, that's an essential
bit of Fitt's Law, the computer should always remember where you put
things because spatial memory is found at a deeper level in the brain
than reason and logic.
Also windows tend to stack up in the middle of your screen and get
lost since so many apps put their windows there due to the easy
availability of methods for doing that and also you have to do work to
ensure that the window will be on screen if you want to put it
anywhere other than the center of the screen or the top left corner.
Unfortunately the OS doesn't provide any help here so we'll just have
to do the work ourselves in BAlertWindow, or, we can implement a
system provided solution and use that.
Or we can push the problem off, it's not critical, just an annoyance,
a paper cut.
Other related posts:
