* Add special handling for reading the BEOS:TYPE attribute to supply
on-the-fly fake MIME types for FUSE module filesystems, the same
way it's done in our FAT and NTFS FS modules
* Reuse the mime_ext_table which we already have and put it into a
shared location so we don't get further extra copies of it
* Implement reading extended file attributes in FUSE modules,
using getxattr()
getxattr() is a quite limited API, not allowing to specify a read
offset. So we read in the entire attribute value into a buffer and
store in the cookie. This shouldn't be a problem memory-wise, since
xattr implementions usually have limitations regarding attribute size
anyway, so it'll rarely be more than a few kilobytes.
* Writing, renaming, and removing attributes is not yet implemented
* Add a way for a FUSE module to supply Haiku-specific extensions.
This allows it to integrate better with Haiku while only requiring
minimal changes on the FUSE module itself.
* For now, there is only one extension: another function pointer for
"get_fs_info", which lets the FUSE module fill in an fs_info struct.
FUSE provides no good way to otherwise communicate extra information,
such as the volume flags (e.g. B_FS_IS_SHARED).
* A FUSE module can signal that it supports the Haiku extensions by
a) defining HAS_HAIKU_FUSE_EXTENSIONS before including the fuse
headers
b) setting the global variable gHasHaikuFuseExtensions to 1 in
its initialization
Otherwise, the Haiku extensions are completely invisible to the
FUSE module.
These are made from the sticker "haiku-sticker-3.5x2".
Quick preview at http://img.ctrlv.in/img/17/02/27/58b425e23a6fb.png
A "Haiku" text layer and a 1-pixel frame are on separate layers,
that are set invisible. Not sure if we should always show the "Haiku".
Looks better without in my opinion, but depending on where it'll be
used, showing the text may be desired...
When used for small logos, like 64px, simple scaling might not cut
it, and the yellow and orange "hills" need to be made wider.
A recreation of the sticker designed by Jorge G. Mare in 2010.
Copyright 2010 Haiku Inc. Released under a CreativeCommons Attribution, Noncommercial, Share Alike license.Designed by Jorge G. Mare (koki@haikuzone.net)
As closest approximation to the font, I used FuturaExtended.
We should come up with a better motto than "Inspired by the BeOS".
One layer holds the reverse side with the QR code.
* Remove duplicated code
* Add new feature flag field introduced with Ryzen
* Add a few missing Intel cache descriptors
* Don't show 80000007 on Intel. Reserved.
* Clean up language to not show "AMD" flags on Intel
...to find files with .pdb extension
Code was subtly wrong in 2 cases:
1) File that ended in pdb but not an extension e.g. filepdb
erroneously included
2) File that ended in .PDB or other case erroneously skipped
Better do a recheck on 32 bit first, my old checks from a few
months ago doesn't seem valid anymore.
This reverts commit 7212666f4a36fcd7d04e19676128df38ef4fdcdd.
Even on 32 bit machines the default is to use 64 bit addresses
because of PAE. Haiku currently forces 32 bit addresses which
probably should be fixed.
See achaiku.h: define ACPI_32BIT_PHYSICAL_ADDRESS
This corrects hrev50847. Turns out we need 8 lines for normal
files and symlinks, not 7. Fixes #13308.
The "Opens with:" label used the decreased font size set in
src/kits/tracker/InfoWindow.cpp:894. Increase font size by 2 again
for the label.
This reverts commit 945566ff43583e4f8102b4440c88f53dae775cb4.
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.
* When --host-only is used, HAIKU_*ARCH is undefined.
* Various architecture variables are undefined resulting
in architecture dependant code paths getting called
recursively.
(blah/Jamfile loads blah//Jamfile vs blah/x86/Jamfile)
* Another option is setting HAIKU_*ARCH to the host arch
if undefined, but that might have unintended impacts.
