Even when BDirectWindow is used, the back buffer data can be copied to
the front buffer. This happens when resizing or moving the window, and
when moving the cursor above it.
Since Charts does not touch the whole window when redrawing (it only
erases previous stars and draws new ones) this led to the last frame
drawn on the back buffer to stay visible until stars erased it.
Clearing the back buffer view with the current "sapce color" makes this
much less visible.
Fixes#96.
* It seems hex floats are not allowed in C++.
* I will fix this more cleanly, but it needs another rebuild of the gcc2
package. Until then, this lets haiku compile.
* They will be updated by a cron job once per day.
This improves the reproducability of non-current builds, as the ID-files
will no longer change over time.
* Increase sniffing rule priority to 0.251, otherwise files are detected
as text/plain (for anything lower than 0.25)
* Add sniffing pattern for utf-16 xml.
* this provides parity with the gcc_x86_syslibs packages, so
that special handling isn't required for the gcc4hybrid
builds when a recipe depends on libstdc++ (e.g. haikuwebkit)
Locking the GL context from a GLView subclass constructor can't work, as
it isn't ready yet. Move the initial setup to AttachedToWindow instead.
Fixes#8898, #10469.
* After testing the previous fix, I found that Flurry would crash again
because of a stack overflow in Mesa. This new package fixes that other
issue, so Flurry runs again.
* GLife and Gravity are still crashing, however. I'll debug these next.
The screensaver add-ons are properly linked against libGL. The libGL
code tries to load the swrast add-on. But this fails because the
BGLRenderer constructor (which is provided by libGL) is not found.
It seems that when loading an add-on, libraries linked to by other
add-ons (and not the app itself) are not searched to resolve symbols. To
avoid this issue, we now link ScreenSaver and screen_blanker to libGL,
so the GL renderer add-on can find it.
Fixes#10206
These errors do not necessarily need to be reported to the user via alerts.
They are more of an indication that HaikuDepot needs to be smarter when
figuring out what package actions to present at all.
BDragger use some tricks to draw as a partially transparent view, it
calls the parent Draw method, then draws a partially transparent bitmap
over the resulting drawing.
This only works if the parent does somthing in the dragger area. In case
it doesn't, first fill the dragger with the parent view color, so there
is at least "something" in those pixels.
Fixes#5906.
* We archive views using "managed" archives, and the children are not
attached in the BView(BMessage*) constructor, but later. So it's not
possible to find the target and scrollbars in the constructor of
BScrollView.
* Make BScrollView override AllUnarchived and find the target and
scrollbars again there. The code is slightly different as there is no
guarantee that the first child will be the target in that case. The
existing code in the constructor is preserved for non-managed archives.
* When opening .hpkg files, shows just the PackageInfoView in a smaller
window.
* PackageInfo constructor with BPackageInfo argument
* Default pkg icon has a single instance only. Before, there would be another
instance for each repository refresh.
TODO:
* Install button on single package view is non functional
* Probably needs to do someting different when opening .hpkg from an
installed packages folder (show the regular list and focus that package?).
* The filter view and list view are still constructed for the single package
mode.
* ...
PackageFileHeapWriter::_UnwriteLastPartialChunk() used ReadData() to
extract the last partial chunk into the pending buffer. This indirectly
calls PackageFileHeapWriter::ReadAndDecompressChunk(), which assumes
data past the last full chunk to come from the pending data buffer.
Since the pending data buffer is not filled in at that point, the call
to ReadAndDecompressChunk() simply did nothing, leaving the object with
a correctly sized but completely nulled pending data buffer. The last
partial chunk of a package would therefore always get corrupted when
updating a package.
Fixes#11306 that provided a reduced test case that happened to corrupt
the only chunk of a package, nulling the .PackageInfo and therefore
making the error more obvious as subsequent parsing of the info failed.
UpdateText must return a pointer to a fixed buffer, whcih BString.String
isn't, if the sctring is modified.
Copy the data to a char* we can use as a fixed position buffer.
This was removed in hrev17147, because our implementation of BMenuItem
does not uses it anymore. However, we must keep it in order to properly
unarchive BMenuFields that were archived in BeOS.
One application that was crashing because of this is VNCViewer.
* Instead of parsing the pattern everytime Format() is called, parse it
only once when the object is created.
* Adjust all callers to make use of the feature and reuse the instance
as much as possible. This also allows calling B_TRANSLATE only once
instead of everytime the formatting needs to be done. We use either a
static instance (when the message pattern is constant) or a field (when
it is not known to be constant).
* Since the BMessageFormat instances are now reused, add locking to
avoid race conditions (ICU itself is thread safe, but the format pattern
is recreated when the locale is changed)
