[haiku-development] Re: Negative insets and BScroll{Bar|View}
- From: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 26 Aug 2015 10:47:55 +0200
Hi,
Am 26.08.2015 um 10:27 schrieb Axel Dörfler:
I'd like to hear your opinion about using negative insets to, for
example, cut off the border in BScrollViews to neatly align them with
the window borders.
This method is already used in our sources.
However, the B_USE_DEFAULT_SPACING and friends are in the range of -2 to
-7, so this method currently only works for using -1 (ie. a fancy border
cannot be cut this way, as done in the current Mail application -- which
does not yet use the layout API, though).
So, this boils down to either change the constants to something less
likely to clash with real use cases, or to forbid negative insets
altogether.
The latter would require either adding specialized layouts for this case
that do the same, or probably worse, some heuristics that automatically
align scrollbars/views when they are adjacent the window borders in the
current layout classes.
The former would break binary compatibility (which is still acceptable
at this point IMO, and will only cause visual breakage).
Comments welcome.
I've found it visually appealing to merge borders where the opportunity
presented itself. At the same time, I found the methods by which this is
accomplished messy and error-prone. In a perfect world, the knowledge of
appearance and whether something should be merged, or more precisely,
whether a visual element in one part of the interface already performs
the same function as a visual element in an adjacent part of the
interface, would be completely up to the theme.
I know that is not what you asked for, but the real problem is likely
how we construct interfaces in the first place. Borders and separators
should probably be their own interface elements, and not part of the
appearance of widgets. Then an "interface optimizer" (which would be
part of the theme implementation) could eliminate duplicated
border/separator elements. This is completely different to how its done
now, and in fact different to all APIs I know. So a kludge that just
improves the status quo a little (option 1) and solves your problem is
fine by me. Your Option 2 I don't like so much, since it doesn't really
solve the problem (knowlegde is wrongly placed), as I tried to outline
above.
Best regards,
-Stephan
Other related posts:
