... cancelling the normal item truncation behavior.
This funcationality comes from BeOS R5, we need to reproduce it for
backwards compat. KeymapSwitcher depends on it at least.
Minimum width is 20px, was set in last commit, comes from BeOS R5.
We use these constants in both MenuField.cpp and BMCPrivate.cpp
Incorporate kMarginWidth into kPopUpIndicatorWidth.
A small code simplication in FrameResized() along with replacing bare numbers
with magic constants.
* the Virtio PCI bus driver exposes a Virtio controller to the Virtio bus manager,
which in turn exposes a Virtio device consumed by Virtio drivers. Drivers follow the
new driver model.
* virtio_block handles Virtio block devices under disk/virtual/virtio_block/x/raw.
* Here is the Qemu command line option for Virtio disk devices:
-drive file=haiku.image,if=virtio
* the PCI bus driver currently supports only legacy interrupts (no MSI(-X) yet).
* There is room for improvements in the bus manager:
- it notifies the host for each queued request, which isn't optimal.
- transfer descriptors should probably be simply preallocated (they are nicely
leaked at the moment).
- indirect descriptors are not supported yet.
and in the block driver:
- get the id of the disk.
- implements flushing the cache.
- improves dma restrictions.
- do_io() should use a page for header descriptors instead of malloc(), which
could cross boundaries.
* The device manager tries to guess the driver based on the PCI device type, this
implies having to declare the "busses/virtio" path for each possible type
provided by Virtio. Thus future driver additions might require patching the device
manager.
* virtio.h is still private, the API is subject to changes.
* virtio_pci.h, virtio_blk.h, virtio_ring.h are copied unchanged from FreeBSD.
* Switch bash, debugger, less, telnet[d] and top apps to use termcap
functionality provided by ncurses lib instead of GNU libtermcap.so;
* NetBSD version of tput utility replaced with ncurses' one. Fixes#9606;
* terminfo database is provided as mandatory package installed during
building target system;
* Remove libtermcap module. The termcap database source and
corresponding build rules are not removed to provide backward compatibility -
until all optional packages will be rebuild on upcoming system version
using terminfo. Note that gcc2 builds may require to provide termcap a bit
longer in the sake of binary compatibility with R5 era apps.
* If at least one image is either B_HAIKU_ABI_GCC_2_ANCIENT or
B_HAIKU_ABI_GCC_2_BEOS almost all areas are marked as executable.
* B_EXECUTE_AREA and B_STACK_AREA are made public. The former is enforced since
the introduction of DEP and apps need it to correctly set area protection.
The latter is currently needed only to recognize stack areas and fix their
protection in compatibility mode, but may also be useful if an app wants
to use sigaltstack from POSIX API.
* Factor out the code to add some data to the about window, with a header and a content under it
* Make this method public so it's possible to add custom entries in an about box
* If the method is called with only the header or only the content, the text is added non-bold and non-indented (like the description entry*).
* Make the header text bold. I'm not sure it looks that good, after all. Thoughts ?
Remove no longer needed header includes, most that I recently added
a few that were already there but just aren't needed anymore. Don't
use BPrivate::MenuPrivate namespace.
Just a few commits ago I moved the label truncation code out of
BMenuItem and into BMCMenuBar because the truncation had to happen
outside of BMenuItem. Turns out, that wasn't true so I'm moving the
label truncation back into BMenuItem and removing the _DrawItems()
method from BMCMenuBar.
Note that the code is not a copy of what was there before, but, the
updated version I created for BMCMenuBar. The main difference is that
I use menuPrivate.Padding() instead of GetItemMargins() and I always
use the width of the parent menu frame instead of using fBounds even
if the state is not MENU_STATE_CLOSED. These are changes needed for
BMCMenuBar but should work just as well for a regular BMenu.
...instead of in BMenuItem and remove the truncation code from BMenuItem.
The label truncation code cannot work in BMenuItem because the super
menu helpfully resizes itself to fit the menu item. So, instead we do the label
truncation in BMCPrivate making sure that BMenuItem there can't expand the
BMCMenuBar because we set the width to fMenuField->_MenuBarWidth()
explicity.
Note that this only truncates the label in BMCMenuField, i.e. the label inside
the menufield, it does nothing to the labels of the menu items in the attached
BMenu or BPopUpMenu which is exactly what we want.
Was passing !fixedSize into the view flags of BMenuBar, which made no sense.
Stop doing that, set fixedSize to true instead.
Remove the fixedSize parameter from this contructor, it's too late for that.
In some cases, BStringColumn wouldn't properly detect that an update was
needed, and would consequently fail to truncate a string as needed with
a column resize.
* Set its type to B_MODAL_WINDO, and also set B_NOT_MOVABLE
* Since this removes the window tab, add an "Ok" button to close the window
* Remove the GetWindow mess and just use it as any regular window
* Adjust all callers again
The AlertPosition method doesn't seem to work right, the window pops up
offset to the right. I also noticed that some of our calls to BAboutWindow
are actually not reacable because we removed Abutrequested from the apps.
Maybe we should clean them up (locale preflet and activity monitor are examples)
More annoying is the fact that opening a modal window from a deskbar replicant
is modal against the whole deskbar. Not sure what to do about that.
- debug_create_symbol_lookup_context() now takes an image ID
parameter that can optionally be used to restrict the symbols
it gathers to only those of the targeted image rather than the
entire team, allowing for significantly more lightweight usage
when the desired image is known. The previous behavior can still
be obtained if desired by passing -1 as said ID.
- Adjust callers.
... back to their previous void returning roles. AlertPosition() is used instead to
check that an alert fits within the sides of the screen and all that.
Also add another CenterOnScreen() method that takes a Screen ID
so you can center a window on another monitor that the one it is currently on
(theoretically someday anyway).
...to position alert's and open/save dialogs nicely inside of the parent window,
or if that is unavailable, the screen frame.
AlertPosition() is private (for now) but BAlert and BFilePanel are BWindow's friends so
BWindow allows those classes to touch it's privates.
BAboutWindow returned false in QuitRequested in order to hide instead of closing.
Not only this keeps a BLooper running for a rarely used window, but it also
prevents quitting an application in the window was not destroyed first.
* Remove aforementioned QuitRequested method,
* Add a static GetWindow method that returns the existing about window, if there
is one, or creates one if there is not. A boolean can be set to tell the caller
what happened,
* Adjust all callers to use that new method, instead of managing the window themselves.
* These methods now return the new point after centering.
* But more importantly CenterIn() does some new adjustments to keep the window
position inside the screen edge. If you pass the screen frame into CenterIn()
it skips these adjustments.
- Instead of implicitly registering and unregistering a service
instance on construction/destruction, DefaultNotificationService
now exports explicit Register()/Unregister() calls, which subclasses
are expected to call when they're ready.
- Adjust all implementing subclasses. Resolves an issue with deadlocks
when booting a DEBUG=1 build.
In sake of consistency with other Windows CP encodings:
* print_name is expanded to "Windows Central European (CP 1250)";
* B_MS_WINDOWS_1250_CONVERSION id looks like should be added into UTF8.h;
* mime_name set to NULL as other windows codepages have. That prevents
at least from duplicating too much 1250's in the Terminal, Mail and
StyledEdit encodings menus.
Currently there are two generators. The fast one is the same one the scheduler
is using. The standard one is the same algorithm libroot's rand() uses. Should
there be a need for more cryptographically PRNG MD4 or MD5 might be a good
candidates.
This address specification is actually not needed since PIC images can be
located anywhere. Only their size is restriced but that is the compiler and
linker concern. Thanks to Alex Smith for pointing that out.
Improve the unicode character processing and classifying routines by
wrapping up the UChar32 procedures from ICU. That fixes functional
regression introduced in hrev38017 and allows to fix East Asian Width
problems int the Temrinal.
This means the B_COLOR_WHICH_COUNT goes from being a public constant to a
private one. It sill looks like a public constant starting with a B_ though.
I hope that's not a big deal. Too bad we can't get the count of an enum.
This fixes a maintainance problem where you have to update this otherwise
unrelated file to keep it in sync whenever you add a color constant.
I've added a B_COLOR_WHICH_COUNT constant to the color_which enum which should
be updated to point to the newest color constants as new ones are added. I
reworked ServerReadOnlyMemory to use this constant instead of using to the
current largest color constant directly. If you use B_COLOR_WHICH_COUNT to
refer to a color in your code expect to get unpredictable and nonsensical
results. Most likely you'll get an undefined result which will return black
but don't depend on it.
The net effect of this is that ServerReadOnlyMemory doesn't need to be updated
anymore when new color constants are introduced but will continue to produce
correct results.
Eliminate kNumColors constant, replace it with B_COLOR_WHICH_COUNT
This allows you to change the scrollbar thumb color in Appearance preferences.
The default color is 216, 216, 216 so the scroll bar thumb looks the same by
default. Perhaps someday this can be updated to something a bit more colorful.
On some 64 bit architectures program and library images have to be mapped in
the lower 2 GB of the address space (due to instruction pointer relative
addressing). Address specification B_RANDOMIZED_IMAGE_ADDRESS ensures that
created area satisfies that requirement.
Placing commpage and team user data somewhere at the top of the user accessible
virtual address space prevents these areas from conflicting with elf images
that require to be mapped at exact address (in most cases: runtime_loader).
This patch introduces randomization of commpage position. From now on commpage
table contains offsets from begining to of the commpage to the particular
commpage entry. Similary addresses of symbols in ELF memory image "commpage"
are just offsets from the begining of the commpage.
This patch also updates KDL so that commpage entries are recognized and shown
correctly in stack trace. An update of Debugger is yet to be done.
Set execute disable bit for any page that belongs to area with neither
B_EXECUTE_AREA nor B_KERNEL_EXECUTE_AREA set.
In order to take advanage of NX bit in 32 bit protected mode PAE must be
enabled. Thus, from now on it is also enabled when the CPU supports NX bit.
vm_page_fault() takes additional argument which indicates whether page fault
was caused by an illegal instruction fetch.
x86_userspace_thread_exit() is a stub originally placed at the bottom of
each thread user stack that ensures any thread invokes exit_thread() upon
returning from its main higher level function.
Putting anything that is expected to be executed on a stack causes problems
when implementing data execution prevention. Code of x86_userspace_thread_exit()
is now moved to commpage which seems to be much more appropriate place for it.
Randomized equivalent of B_ANY_ADDRESS. When a free space is found (as in
B_ANY_ADDRESS) the base adress is then randomized using _RandomizeAddress
pretty much like it is done in B_RANDOMIZED_BASE_ADDRESS.
B_RAND_BASE_ADDRESS is basically B_BASE_ADDRESS with non-deterministic created
area's base address.
Initial start address is randomized and then the algorithm looks for a large
enough free space in the interval [randomized start, end]. If it fails then
the search is repeated in the interval [original start, randomized start]. In
case it also fails the algorithm falls back to B_ANY_ADDRESS
(B_RANDOMIZED_ANY_ADDRESS when it is implemented) just like B_BASE_ADDRESS does.
Randomization range is limited by kMaxRandomize and kMaxInitialRandomize.
Inside the page randomization of initial user stack pointer is not only a part
of ASLR implementation but also a performance improvement that helps
eliminating aligned 64 kB data access.
Minimal user stack size is increased to 8 kB in order to ensure that regardless
of initial stack pointer value there is still enough space on stack.
* If we have a configured network, then we always try to connect to it
as soon as the interface has been brought up.
* If we don't have a configured network and are auto configuring, we
use the AutoconfigLooper to also do initial auto joins.
* Before issuing auto joins we need to wait for scan results to come
in, so we watch for corresponding messages.
For now auto joining is a one shot attempt as the infrastructure to
properly tell reasons for scans apart is not yet there.
This allows to reuse BMessenger objects for different targets, or to
recheck validity after initial creation. With that one can use the same
BMessenger after launching an application that was previously not found
valid for example.
The physical memory map area was not included in the kernel virtual
address space range (it was below KERNEL_BASE). This caused problems
if an I/O operation took place on physical memory mapped there (the
bad address error seen in #9547 was occurring in lock_memory_etc()).
Changed KERNEL_BASE and KERNEL_SIZE to cover the area and add a null
area that covers all of it. Also changed X86VMTranslationMap64Bit to
handle large pages in Query(), as the physical map area uses large
pages.
* This parses the reported CPU name, and tries to translate it to a normal
and concise identifier.
* For example, it will translate "AMD FX(tm)-8320 Eight-core Processor" into
"FX™ 8320" or "Dual Core AMD Opteron(tm) Processor 275 HE" into
"Opteron™ 275 HE".
* This means we can remove AMD strings for those models for which this
function produces useful results.
* Make pointer style consistent, const char* name instead of const char *name.
* Lots of parameter renaming.
* in parameters don't get anything special, just font, or length instead of
inFont, inLength.
* out parameters get a leading _ so *outWidth becomes *_width for example.
* We don't detail private function in the Haiku book and this class has a bunch
so keep the documentation in the file but use regular comments instead.
* Normalize the parameter names between cpp file and header.
* Some minor whitespace fixes.
No functional change intended.
* Replace {Set|Remove}MasterKey() by generic {Set|Remove}UnlockKey()
that works on a keyring.
* Implement {Set|Remove}MasterUnlockKey() on top of that.
* Rename the commands and constants accrodingly.
* Implement setting and removing keyring unlock keys.
As there aren't any more generic meta data containers inside BKey,
there's no real way to distinguish different instances with the same
identifiers. This may be added later, for example the same index system
as used in BMessage could apply.
The application access concept is on the keyring level only for now.
Generally it probably would get pretty complicated and therefore harder
to use when application access needs to be granted on a per key basis.
The type is relevant and required as it determines the type of the
handed in key. The purpose however isn't actually needed and rather
inconvenient to get by depending on the situation.
* The keystore backend will (at least for the time being) reside in a
separate server. This one can be reached via normal messaging, so use
a BMessenger for sending key messages.
* Move the message constants from RegistrarDefs.h into a new
KeyStoreDefs.h that also contains the server signature.
* Update the message constants to reflect the new situation.
* Add all relevant message constants.
* Implement the messaging to send/retrieve key info.
* Implement _Flatten/_Unflatten for sending flat BKey objects.
* Remove application list from BKey, the key can't only differ by
allowed applications as the identifiers would still collide, so the
comparison isn't needed to uniquely identify the key. The applications
can be enumerated via the BKeyStore instead.
* Modified the API greatly to be based on BKey* instead of BPassword*.
* Added BKeyPurpose and used it instead of BKeyType. It is supposed to
indicate the purpose of a key so that an app can look up keys on a
more granular level. The BKeyType on the other hand actually
identifies the type (i.e. subclass of BKey) so an app knows how to
handle a given key or may only enumerate/use keys it is compatible
with.
* Made everything based on a raw data buffer for now, only BPasswordKey
is implemented yet which stores the (0 terminated) string into that
data buffer.
* Removed the additional data BMessage as I don't yet see where it fits
in. While I could imagine adding meta data to a key may be nice it
might be an interoperability concern when keys are shared by
different apps.
* Moved the app functions to the keystore as per the TODO, but not sure
how to actually implement them.
With this commit every class in the storage kit is now documented
in the Haiku book!
Thanks to Ingo, Axel, Vincent Dominguez, Tyler Dauwalder, and
everyone who helped document these classes.
Rene Gollent