* This indicates the view will manage whatever scrollbars are targeted
to it.
* Use _B_RESERVED7_ for this. It's been RESERVED since BeOS R5
(I guess it was probably something on some older BeOS version?)
and we don't really care about BeOS R4 ABI compatibility, so
that should be fine.
* Update BScrollView to not touch BScrollBar range/proportion
when the target view has this set.
* Update BListView to set this flag, always.
Fixes#14871.
Change-Id: I17027f3b63ef28da1e735c5393593496c415dce3
Reviewed-on: https://review.haiku-os.org/c/998
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Since we know what size the target view is / wants to be, we can automatically
set the range, steps, and proportion trivially. In non-layout mode, we retain
the old behavior. Applications or views that need custom scrolling behavior almost
certainly will be using BScrollBars directly and not this, so this should not be
"wasted computation" in pretty much any case.
Greatly improves the appearance and UX of the default case of a layouted
view inside a BScrollView.
Change-Id: Ia6ff6ee14df96799c579e15d274fd4c849675577
Reviewed-on: https://review.haiku-os.org/c/892
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
These methods and fields are missing from the R4 and R5 Be Book, but are
mentionned in the R4 release notes and present in the R5 headers.
Change-Id: I4de8298449bd66e0ee7fe0b52690552916314123
Reviewed-on: https://review.haiku-os.org/820
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
I need this to use loopers in WebKit, which spawns threads and expects
to be able to turn them into event loops later on.
This is the pattern already used in BApplication, we may as well make it
available elsewhere.
Change-Id: I5939ca89d33cb3bcc92567b302c2038d976af598
Reviewed-on: https://review.haiku-os.org/735
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This fixes the (intermittently) crashing test added in the previous commit,
and should also fix#12024 and #14348.
Note that this is a slight behavioral departure from BeOS, though since
BeOS crashed when this was done previously, it shouldn't cause any
other problems.
Change-Id: I90b6132ff7741b8d6cb601375a9b11fc3ffacb40
Reviewed-on: https://review.haiku-os.org/541
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The cached top coordinate of each BListItem isn't updated when you
change the height of the item, leading to confusing highlighting and
incorrect mouse clicks. Rather than fixing it, this just documents a
workaround or two to force an update of the cached coordinates.
I've updated the docs to match the current BMailComponent, documented
new functions, and cleaned up the MailComponent.h file to at least
somewhat match our coding style.
First in a series (there are 3 more old API docs on the Mail Kit in that
"Public API" folder.)
- Delete the introduction from the kits list page, as it is already
under locale_intro.
- Update the description in locale_intro.
- Since the locale kit now lives in libbe, delete the paragraph about
libraries from the intro, and move the still relevant part about
liblocalestub to the catalog translation macros description in
Catalog.dox.
- Strength is now set once, instead of at each comparison, to improve
performance and fix potential locking issues
- Add a way to enable "numeric" collation (aka "natural order")
There is no DATA directory in BeOS, and its FindDir() doesn't implement
it. No need for a confusing backwards compatibility to something that
doesn't exist (had my hopes up, was going to move some non-executable
files from AddOns to Data in a program that works in BeOS and Haiku).
The removed enum label doesn't change the directory_which enum order
or count, as it was aliasing the value of another existing enum label
(B_SYSTEM_DATA_DIRECTORY).
Fixes#13470
Signed-off-by: Axel Dörfler <axeld@pinc-software.de>
This reverts commit 945566ff43.
As discussed on the mailing lists and with Humdinger off-list:
* The general design concensus tends slightly towards DejaVu, as metrics
of DejaVu look much better (DejaVu 12 and Noto 13 are roughly the same size,
but Noto has much wider margins with that)
* While Noto does have a wider set of fonts with support for lots of
different languages, DejaVu actually has built-in support for more
Unicode languages (the default Noto has, as far as I can tell, only
Latin/Greek/Cyrillic [2416 glyphs], while DejaVu also has Armenian, Georgian,
and a few other scripts too [5119 glyphs].)
* The worse rendering of DejaVu appears to have been somewhat rectified by
disabling the average-based subpixel filter in app_server.
This mostly reverts commit 75b219d35a.
The changes to the image URLs in Alert.dox are still needed, so I
didn't revert those.
As per discussion on the mailing list and IRC.
Since the "Layout" group is a member of the "Interface" group,
Doxygen automatically adds the "Interface" group to all pages
in the "Layout" group, meaning that having an explicit "ingroup Interface"
created duplicate group tags.
Surprisingly, after disabling the new Markdown support in the Doxyfile,
everything else pretty much worked out of the box. Only a number of CSS
changes were needed to adapt.
I wonder why nobody ever did this back in 2012 when 1.8 first came out...
