[haiku-commits] Re: haiku: hrev45528 - src/apps/stylededit
- From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Wed, 24 Apr 2013 20:51:14 +0200
Am 24/04/2013 20:14, schrieb John Scipione:
On Sat, Apr 20, 2013 at 5:57 PM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
Is your screen that large that this makes that much sense?
My screen is 1920x1080 and that's small now-a-days but even at
1024x768 this makes sense I think. It groups the alert with the window
that it affects, Fitt's law and all that.
With warnings, and error messages, you may want to put them far away
from you mouse so that you get a chance to read it before clicking it
away ;-)
Apart from that, having a default location for all alerts also has a
certain appeal.
Anyway, when you do it, please do it right: there should be either a utility
method, or a method in BWindow that does the job for you, and also takes
care about the result being off screen. You don't want to repeat this
everywhere.
I'm not sure if it makes sense to put this in BWindow, the utility
method, were I to add one, would go in BAlert and BFilePanel since you
need a parent Window to center the alert or open/save dialog into.
It's a common method, just like BWindow::CenterIn(), CenterOnScreen(). A
Center{In|Over|Whatever}(BWindow*) would fit right in there.
Why do you think only those pretty much "final" (in the Java sense)
classes should have that, but not a normal window? If it's something we
want to endorse, we should make it as easy as possible to let 3rd party
developers make use of it.
Also, don't just do this in one application. Either all or none of them.
It only makes sense to do this on a per application basis because this
only makes sense for "document-based" apps, what other applications in
the base system could use this treatment?
Actually, most apps are document based, even Tracker.
Bye,
Axel.
Other related posts:
