[haiku-commits] Re: BRANCH looncraz-github.setviewuicolor [5636ce989d00] src/kits/interface
- From: looncraz <looncraz@xxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Mon, 26 Oct 2015 10:07:44 -0500
On 10/26/2015 08:34, Stephan Aßmus wrote:
Am 26.10.2015 um 13:51 schrieb looncraz:
I can't be 100% sure what Axel would be suggesting as an alternative,
but he is completely right that you do something in a method that you
should not be doing there. This method has a purpose and is named
accordingly. Writing code like this is just bad, sorry. What you
probably need to do instead is to write a separate method, call it
_InitTopViewColors() or similar, and call it at the place where you
need to call it, but probably not from within SetLayout(). Instead,
call it where the BWindow itself calls SetLayout(), for example. I am
pretty sure that in the case where BWindow::SetLayout() is called
again at a later time, you should not have to set the top view colors
again, too.
I agree completely, believe me, but the problem is BLayoutBuilder calls
BWindow::SetLayout. There is literally no other place to do this that
works (though doing this in BView::SetLayout is certainly an option,
BWindow already dictates the top view's color upon its creation, so this
seemed more natural). If I move this into BView, then it would seem to
make more sense to set the top view color only within BView (not really
sure why BWindow does it anyway, it's just setting the color it already
should have...).
I thought about adding BView::AdoptSystemColors() to go along with
AdoptParentColors(), you think that would be better?
Another alternative I've wondered about is just to default every
window's top view to the standard system colors. I don't know of a
single application where that would result in any issues. It might even
be safe to default every BView to system colors. There are quite a few
advantages to being the default state, only backwards compatibility
being any concern.
--The loon
Other related posts:
