Loop backwards if possible, if not, set a variable and use that instead.
There were a couple of instances where the loop style got changed from
for (int32 i = CountItems(); --i >= 0;)
to
for (int32 i = CountItems() - 1; i >= 0; i--) {
but should be functionally equivalent.
On MouseDown draw a diagonal arrow, on MouseUp complete the animation and
expand. If you hold down the button it will stay diagonal until you MouseUp
and either return to normal or animate and expand if over the arrow.
Reformatted ExpandoMenuBar.h and TeamMenuItem.h
Renamed fLastClickItem to fLastClickedItem
Added a DrawExpanderArrow() method
Renamed private InitData() method to _InitData() and moved it to the bottom
* Add ability for fSettings to pass on network
stats
* Show KB Sent / Received for interface
* Drop the wireless / wired tab name.
(we are going to need another tab for wifi)
* Add wifi network name to connection field
if interface is wifi.
... like BeOS R5. I looked in the commmit logs for this one and there wasn't really any
explination for why this got changed, so, I'm changing it back to the way it was in R5 which
is right arrow for unexpanded, down arrow for expanded. Please yell at me if this change
was intentional.
If you have expander turned on with expanded apps and you quickly remove teams with the VDG
you can remove a team not under your mouse pointer, instead you remote the team above. This
is because the window watcher thread hasn't updated yet so the TeamItemAtPoint() method
reads a window menu item instead of the team item. The solution is to lock the window
watcher thread and explicitly remove the window menu items in RemoveTeam().
This bug can be really bad if you accidentially VDG Tracker as your system gets hosed until
you restart Tracker or reboot.
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.
When mmap() is invoked without specifying address hint B_RANDOMIZED_ANY_ADDRESS
is used.
Otherwise, unless MAP_FIXED flag is set (which requires mmap() to return an area
positioned exactly at given address), B_RANDOMIZED_BASE_ADDRESS is used.
When forking a process team user data area is not cloned but a new one is
created instead. However, the new one has to be at exactly the same address
parent's team user data area is. When process is exec then team user data
area may be recreated at random position.
This patch also make sure that instances of struct user_thread in team user
data are each in separate cache line in order to prevent false sharing since
these data are very likely to be accessed simultaneously from threads executing
on different CPUs. This change however reduces the number of threads process
can create. It is fixed by reserving 512kB of address space in case team user
data area needs to grow.
