This safes a HasGlyphs() call which would convert the whole string to glyph
codes and look each of the glyphs up in the cache entry, just to do the same
again during the loop where they are actually used. Instead we now simply switch
to the write lock and look up the fallback entry when hitting the first uncached
glyph. This benefits the normal case of having all glyphs cached without any
drawbacks.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40186 a95241bf-73f2-0310-859d-f6bbb57e9c96
- list of translators for his work on complete Belarusian translation;
- list of contributors for his work on internationalization of LaunchBox,
PowerStatus and ProcessController applications and following preflets:
DataTranslations, E-Mail, Notifications, Screen, ScreenSaver, Time.
2) Corrected the name of Russian translator Rodastahm Islamov on his request.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40185 a95241bf-73f2-0310-859d-f6bbb57e9c96
- some parts were updated by Michael Bulash during work on last GCI task;
- "bootman" was renamed to "bootmanager" - it's translation was moved correspondently.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40184 a95241bf-73f2-0310-859d-f6bbb57e9c96
when the Tracker window is closed. Tested with normal navigation and
slideshows.
Axel's excellent navigation classes code made this pretty easy.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40180 a95241bf-73f2-0310-859d-f6bbb57e9c96
ShowImageWindow using a BMessageRunner.
* Note, this is completely untested, as it turns out my Haiku installation on
this box is too old to run it. It compiles, at least, and shouldn't break
anything else.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40178 a95241bf-73f2-0310-859d-f6bbb57e9c96
This bug only happens for bitmaps with unusual lengths (often the last blockgroup block bitmap) and which happen to be full.
Should fix#7074.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40175 a95241bf-73f2-0310-859d-f6bbb57e9c96
1. If the glyph is cached, return it, as before.
2. Try to find a glyph in the fallback font, as before.
3. Check for ignorable characters as per Unicode and cache and return a zero
width glyph (rendering as completely invisible).
4. Reset to the original font.
5. Check for whitespace as per Unicode and cache and return the normal space
glyph.
6. If there still is no valid glyphIndex, continue with index 0 which caches
and returns the usual "missing glyph box".
This implements the Unicode suggestions on how to handle missing glyphs and
closes#7077.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40174 a95241bf-73f2-0310-859d-f6bbb57e9c96
drive.
* Do not change the wizard buttons after they have been updated already due to
the selection when building the UI.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40173 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The code used continue to restart the loop when encountering a missing glyph,
but in that case the index wouldn't be incremented, meaning the consumers
would received the same index for ConsumeEmptyGlphy() and ConsumeGlyph() and
at the end there was not necessarily a call for every index, resulting in
uninitialized array elements for GetHasGlyphs, GetEdges, GetEscapements and
GetBoundingBoxes.
* Since the advance values were not reset in case of a missing glyph but still
added for the next char, the coordinates the consumers would get were advanced
by the advance values of the glyph preceeding the missing glyph(s). This made
StringWidth return wrong widths.
* The loop end condition was skipped by the continue as well, which would have
resulted in overruns when there were problematic chars at the end of a string.
Fixes#7075 where the uninitialized array elements caused random truncation
errors. The problematic character in this case is a tab, that has no glyph as
it is a dynamic spacer. Previously this was resolved to the "missing glyph"
(the box) which had a width.
I find it highly problematic not to fall back to such a glyph, because there is
no real way to see that you're using a font that has missing glyphs. Instead
those are simply collapsed to nothing with this change (instead of being
random). This whole problem is only brought up by not guaranteeing that there
always is a glyph as was the case before where a missing glyph was replaced by
the box.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40172 a95241bf-73f2-0310-859d-f6bbb57e9c96
(where the BIOS loads the stage1 part to).
* Therefore, I moved the BIOS drive to the stack, and now the boot menu finally
actually works.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40167 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added TODO about merging AssembleNasm with AssembleYasmBin rules.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40159 a95241bf-73f2-0310-859d-f6bbb57e9c96
again, and will also drop into debugger if broken again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40155 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added a comment to LegacyBootMenu.cpp on how to conveniently test the boot
manager, and its menu.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40151 a95241bf-73f2-0310-859d-f6bbb57e9c96
as when the boot menu entry has a 0 BIOS drive. This allows the boot loader to
be installed on any drive.
* Implemented BootDrive class, and changed LegacyBootMenu the way it should
work now. Installing the boot menu should now work again, and the first time
while installing Haiku.
* Removed MakeArray.cpp - we already have such a tool in our repository.
* Build BootLoader.h automatically during the build process - the only
disadvantage is that you can only build it on x86 now (but other systems
don't use this boot loader, anyway).
* In general, the BootManager is prepared to handle different kinds of boot
menus; one only needs to write a class BootMenu implementation for this to
work - and have the possibility to choose between different menus, if there
are more than one per platform/partitioning system.
* Renamed quite a few methods.
* Automatic whitespace cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40149 a95241bf-73f2-0310-859d-f6bbb57e9c96
Scale to fit now keeps the aspect ratio by cutting horizontally or vertically.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40144 a95241bf-73f2-0310-859d-f6bbb57e9c96
* BitmapBlock::FindMarked/FindUnmarked() tried to find a free bit
at the end of a full bitmap. This fixes#7069.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40143 a95241bf-73f2-0310-859d-f6bbb57e9c96
by forcing openAnyway and creating a clickToOpen rect if there is not one.
Should fix#7022 and maybe others. Partially based on the patch from #7022 and
Travis Reed's patch from the mailing list discussion in December.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40142 a95241bf-73f2-0310-859d-f6bbb57e9c96
Similar changes should be made in other applications. I may try doing so
with a script (and manual review of course.)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40136 a95241bf-73f2-0310-859d-f6bbb57e9c96
