Activate download window when starting a download. Fixes #9575.
BGradient: don't allow out of bounds stops. * They crash app_server if you try to use them, which is not a good idea. * we could clamp them to 0/255, but reporting the error to the user seems better.
Consider the following code used to create a stripped pattern using a BGradient:
gradient.AddColor(black, 0); gradient.AddColor(black, 127); gradient.AddColor(white, 127); gradient.AddColor(white, 255);
In ConvertToScreenForDrawing, the gradient stops will be sorted using BList.Sort. The sorting algorithm is not stable, so the two middle stops may be swapped. There are two ways to fix this:
- Implement a stable sorting algorithm (http://en.wikipedia.org/wiki/Category:Stable_sorts)
- Remove the AddColorStop method index parameter and use code similar to AddColor to find the proper index, or make that method private. This would allow BGradient to keep the list sorted, and remove the need for sorting it later. The method is used only in app_server (for reading the gradient data from app_server link) and when unarchiving a gradient.
What is the preferred solution?
Currently, HAIKU_BOOT_BOARD is given to Jam using the -s command line switch. There are problems with that:
- The build tools, which are built with configure, are currently specific to each board, or at least CPU core version.
- Jam invokes itself during the build, and does not forward the option.
- Changing this between two builds in the same dir doesn't work, because the compiler flags given for each board are incompatible.
Move the HAIKU_BOOOT_BOARD definition to configure-time to fix these problems.
Configure the ARM compiler to default to Cortex-A8 Ideally, we would only need to set this in build/jam/board/*, but the flags set there are not passed to the build of packages. The default is using some early ARM variant, for which gcc lacks some more atomic operations and emits calls to helper functions we don't implement. Setting the default architecture avoids this, as all packages will now be built to target the Cortex-A8. Also set the proper VFP version in BeagleBoard config file. Note this breaks the Verdex and Pi builds, but ARMv7 is what we should focus on for now. We can try to make older archs work after finishing the m68k port.
Correct gcc_bootstrap versions. * Referring to a gcc_bootstrap version that actually exists improves the bootstrap insofar as it will no longer try to build gcc_bootstrap every time.
Disable multilib for the ARM compiler build. * This avoids mixup of the soft/hard float libs * It also means we can use the hard-float libs for targets that supports it * Again, we could introduce an arm_softfp compiler for targets that don't have floating point support, with a different gcc build.