[haiku-development] Re: BAboutWindow lifecycle

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 30 Apr 2013 10:34:09 +0200 (CEST)

On April 29, 2013 at 10:25 PM John Scipione <jscipione@xxxxxxxxx> wrote:
> > 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.

How is it a tradeoff when there is no point at all to keep this window open?
Making non-modal about windows is not just wasted effort, it's also completely
superfluous.
You'll probably never look at them, especially when they are generated
automatically, there is not much to look for, anyway.
Do you have a single reason to keep it open while you are working with the
application? I mean a different reason from "because we can".

> I agree, it's not a great solution, but it's the lesser of two evils.

Not sure what the other evil is, actually, but I can't agree.

> 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.

This is right only from your very own POV. Making the about window store its
window position is just another useless feature IMO.
That doesn't make you or me right. It's both just our opinion.

> 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.

As has been said numerous times on this list, doing this for preferences windows
is pretty much pointless, if not counter productive.
Why should I or the system remember where I closed this window last, maybe half
a year or 5 years ago?
If it's temporary for the current session I could see some sense in this, but a
persistent storage really does not make any sense whatsoever IMO.
Again, just because you feel it's right not a good argument.

> 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.

With the current API, it's impossible to come up with a satisfactory solution.
You would need some way to have a persistent key to identify the window.

>
> 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.

Please reread Fitts' law: http://en.wikipedia.org/wiki/Fitts's_law
It has nothing to do with that.

> [...], 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.

Yes, that's true, but that's not Fitts' law :-)
It's just the reason Tracker works the way it does by default.

> 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
[...]

It's not just accidental that new windows usually open in the center of the
screen. The center of the screen is also the center of your attention.
And while it's often useful and helpful to have document windows to remember
their position, it's probably almost as often superfluous or even annoying. For
example, I often move a window to a place where it isn't covered by another
window I need to type in, and keep the other document as reference. As soon as
that main window is gone, there is no reason to leave that other document there.
There is no way the system can know this. It's always a tradeoff.

> Or we can push the problem off, it's not critical, just an annoyance,
> a paper cut.

There is not a general solution. There are cases where it does make sense, and
there are lots of cases where it doesn't.

Bye,
   Axel.

Other related posts: