[haiku-development] Re: BAboutWindow lifecycle
- From: pulkomandy@xxxxxxxxxxxxx
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 29 Apr 2013 22:59:12 +0200
> > 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.
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.
> 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.
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.
This will also make things easier to manage as there will be no need to
duplicate the AboutRequested code everywhere. I'll go with a static method in
BAboutWindow (BAboutWindow::Show() or something similar) to handle this, and
let the window be destroyed every time.
> > 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.
We agree on that. I'm not sure this can be done at the system level because
we have no link between a window and the file on disk it's showing. So, I'm
going to call for putting this in the HIG and bug programmers until they
follow it. Sample code could help as well. Anyway, this is unrelated to my
problem.
So, I'm going for the following solution :
- Have BAboutWindow close as a regular window instead of hiding
- Have a static method in BAboutWindow to show it, that either makes an
existing about window visible, or creates a new one
- Modify all apps and BApplication to call that new static method to manage
their about boxes
If there is a need for later changes, they can be done in the factored out
static method, once for everyone.
--
Adrien.
Other related posts:
