The 160x120 preview size is a bad choice, because it makes XRoger crash
in an infinite recursion when trying to draw bezier arcs with custom
code (instead of using the BeAPI for that).
Use 120x90, just like BeOS, to maximise compatibility and avoid such
problems.
Fixes#10601.
* Use a BGroupLayout with insets to make space for the monitor drawing
* Don't put the "no preview available" inside the view passed to
screensavers, this could confuse them
* Have the actual preview area (not including borders) be 160x120
This reverts 0fb019bbf2. Making the window
a BDirectWindow isn't a good idea, especially if you want things other
than a direct rendering view in it. Moreover, this is completely
unneeded as GL works just as well in non-direct mode.
DirectDraw is called only in direct drawing mode (BDirectWindow). Our GL
kit also works fine (but slower) in indirect mode (standard BWindow, GL
stuff rendered offscreen then blitted). However, for this to work we
need the screensavers to actually do something. Use the
BScreenSaver::Draw method, which is called in either case.
This makes it possible to use indirect mode for the preview of GL
screensavers. The performance isn't really a problem on the very small
preview (160x200 pixels).
Fixes GLife and Gravity. Flurry still crashes Mesa.
- When walking through and querying volumes for a missing source file,
store the error and report it back in the completion message rather
than exiting the query worker. Otherwise, if something went wrong
with the queries, it'd potentially occur that we'd never prompt the
user to locate the file, as the UI would never be notified that
the background work was complete.
* Use integers for x and y coordinates in the draw loop, too
* Simplify _GetCell by using the return value of vterm_screen_get_cell
to detect out of bounds access, instead of testing for that manually.
* From now on, the gcc-specific system libraries (libgcc, libsupc++ and
libstdc++) are provided by separate packages built along with gcc:
- gcc_syslibs contains the shared libraries (libgcc_s.so, libsupc++.so and
libstdc++.so)
- gcc_syslibs_devel contains the static libraries and both c++ and gcc
headers
The shared libraries now make proper use of symbol versioning and there
are version-specific symlinks
* The buildsystem has been adjusted to no longer use the libraries and
headers from the cross-compiler, but use the ones provided by the
above-mentioned packages. The only exception is that the 32-bit libraries
required for the bootloader of the x86_64 architecture are still taken
from the cross-compiler.
* This stage builds the gcc packages to get the shared syslibs, which
only requires the Haiku glue code.
* Add separate declaration section for stage0 packages to
HaikuPortsCross repository files.
* For the bootstrap_stage0 platform, fall back to the gcc headers
provided by the cross-compiler.
* No longer apply somewhat crude mechanism for converting a package name
into a corresponding port name - haikuporter by now supports package
names directly.
This fixes a problem when trying to pass 'gcc_syslibs_devel' to
haikuporter, which only ever saw 'gcc_syslibs'.
* <stubbed>libroot.so is a shared library which contains all the symbols
from libroot, but without any code. This library will be required by
the (to be introduced) stage0 of the bootstrap process, in order to
be able to link the shared gcc syslibs (libstdc++.so, libsupc++.so
and libgcc_s.so).
* Drop unused variables from build system that refer to the system
libraries.
* Drop unused lists of libgcc objects.
* Drop no longer used variables from configuration script.
* Remove no longer needed building of kernel-libgcc and -libsupc++ from
build_cross_tools_gcc4, only the boot-specific (32-bit) libs are
built for a x86_64 target.
* Explicitly disable threads and TLS support when building the cross
compiler, as the only libraries that are used by Haiku's build system
is the 32-bit libgcc and libsupc++ for the bootloader on x86_64 (and
for that neither is wanted).
* The new libstdc++.so contains program headers of type PT_RELRO (for
making segments read-only after relocation). While the actual feature
has not been implemented, the runtime_loader should now silently
accept (and ignore) those program headers.
* Instead of faking libstdc++.so from libstdc++.a, use libstdc++.so
from the gcc_syslibs build feature for everything except x86_gcc2.
* Use libgcc_s.so from the gcc_syslibs build feature for everything but
x86_gcc2 (which still carries libgcc as part of libroot.so).
* Drop filtering of libgcc objects for libroot, as that is no longer
necessary since we're only using libgcc-as-single-object for libroot
with x86_gcc2, where the filtered object file doesn't exist. Should
the objects that used to be filtered cause any problems as part of
libgcc_s.so, we can always filter them as part of the gcc build.
* Use libsupc++.so from the gcc_syslibs build feature for everything but
x86_gcc2.
* Adjust all Jamfiles accordingly.
* Deactivate building of faked libstdc++.so for non-x86-gcc2. For
x86_gcc2, we still build libstdc++.so from the sources in the Haiku
source tree as part of the Haiku build .
* Put gcc_syslibs package onto the image, when needed.
provided in the gcc_syslibs_devel build feature for building Haiku.
* Simplify declaration of c++ and gcc headers for the legacy compiler -
in the end we always use the ones living by our source tree anyway.
* Fix a couple of missing local declarations for jam variables, which
were necessary to avoid a build problem with strace. There are
probably more bugs like these hiding in our build system files, but
I'm saving the fix for those to the next commit.
* Add new gcc packages to the HaikuPorts (x86*-)repositories.
* Drawn as "inverse video" for now.
* Should use VTerm state to get the cursor shape (rect, underline or
left line)
* Should also handle blinking if enabled, and visibility.
As pointed by Ingo, using a float here is useless because we want each
line to be the same integer number of pixels. Now thigs are drawn
properly and the view has the exact same size as Terminal's one (tested
with font sizes 10 and 18, so different leading values don't seem to be
a problem).
Thanks for reviewing!
Also use finddir instead of hardcoded paths for drivers and locale
catalog helper rules.
Fixes#11115. Thanks to Waddlesplash and Puckipedia for investigating
the issue.
* Set the background color in AttachedToWindow to avoid white lines in
initial drawing,
* Fix computation of font size again so lines don't overlap.
Note: lines are apparently spaced 1px less than in Terminal. But they
don't seem to touch or overlap each other in SerialConnect.
