A recent change was merged prematurely before
the server component was rolled out. This
will disable the change with some side-effects
but can be easily re-instated once 1.0.166 of
the server is deployed.
Change-Id: Idbd429a94e63cbe401b85698f82fe027d6212854
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8471
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
BPoseView no longer keeps directory type state on switch directory.
BContainerWindow gets the state from the pose view on demand instead.
Rename IsDesktopWindow() to IsDesktop() which has the same meaning as
everywhere else: the Desktop but not the one in a regular window.
Store this information in the fIsDesktop parameter in pose view and
set it one time on PoseView::AttachedToWindow().
Consolidate ParentIsRoot() logic into method and call it.
BContainerWindow updates:
* Remove isDeskWindow param from constructor, only usesLayout now.
Prefer Selection version inside Tracker, e.g. kDeleteSelection
Change-Id: Ib114585a235931e96cbdcc0de6d7b8f6e9bc20c3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8226
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The user rating summary should be calculated
on the server and not in the client and the
model should be factored out of the main
package model for later performance
improvements.
Change-Id: Ia2e4e5f9d98051ff3a64006c642fef8de9149c3f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8468
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
If we decide to use 32-bit paging but for some reason the bootloader
hasn't trimmed memory beyond 4GB, it's important that we do that here.
For PAE, it's more important, because we may be booting on a system
with more than 64 GB of RAM, but PAE can only address up to 36-bit
physical addresses, so we need to ignore anything beyond that.
May finally fix the rest of #19117.
According to humdinger, if automatic deletion of old queries
is working (which it should be), then "Clear history" isn't needed.
Instead, turn the "Recent queries" menu into an item that can open
the queries folder, where users can then delete or otherwise modify
the recent queries directly.
Otherwise we would delete them even if they'd been copied somewhere
else on the filesystem, which sounds like a terrible idea and
not at all what I (and I expect other users) would expect.
We don't need to write a message with a single entry, that's
just silly. And writing a message into this attribute breaks
the kAttrQueryLastChange BFS index, anyway.
(This reverts part of 9e875c1998b4123d18a647ff8809d36d8cc7f171.)
If the file in question is deleted while we are performing asynchronous
I/O, and there is nothing else left with a reference to it, then the
underlying vnode could wind up getting deleted from under us, since
the cache does not maintain a reference to the store unless there
are active mappings (areas) associated with the cache.
Should fix #19122. At least, I couldn't find any other places
that performed asynchronous I/O without properly acquiring and
releasing references to the underlying vnode besides this one.
If we don't, then new transfers could still be queued even after
we've put its USB ID, since it's usually accessed via Device.
May further help with #19180.
This adds support for a defacto standard mode for the Erase Display (CSI J) ANSI control sequence.
The mode is specified as "ESC 3J", and will clear the scrollback buffer of the terminal.
This will allow the "clear" and "tput clear" commands to behave the same as in other terminals,
such as XTerm and Konsole.
Change-Id: I2b1a3a005e430d4b8fe5220af26526b6400dfc7f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8464
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
The other spin-loop in this file is over a pointer, and cpu_wait
takes only 32-bit values at the moment. I'm not sure about the
semantics of running cpu_wait on only half a 64-bit value, so
leave that loop alone for the moment.
This wait() routine is called by cpu_wait(), which is what spinlocks
use in their critical loops. If there is no CPU idle module, then
cpu_wait() just calls arch_cpu_pause(). As "wait" is only enabled in
power-saving mode, we should do the same here to retain the same
behavior (and potentially save some power even in "high-performance" mode.)
Tested on bare metal; performance difference for a compile job
(while on battery) may be 5% lower, or that could just be noise.
This facility is used by the kernel to notify the low_resource manager
that it failed to allocate something. But if we are in (e.g.) CRITICAL
low-resource state and this method is used to notify that a large
allocation failed, we would previously revert to NOTE state, while
we should stay at CRITICAL.
* Add kDeleteSelection command alias in Commands.h, keep kDelete.
* Add kMoveSelectionToTrash and use it in place of kMoveToTrash.
- kMoveToTrash in kept in tracker_private.h for use outside.
* Create a new constant kRestoreSelectionFromTrash for Tracker.
- Move kRestoreFromTrash to tracker_private.h
Change-Id: I3cdefe97e8359fb53bacfc3319b046b051c6f7db
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8225
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
They were ignored and unused; and in fact can't be made to work
properly since the block_cache always operates on exactly block-sized
buffers, and doesn't have contiguous buffers of multiple blocks
to hand out at all.
No functional change intended.
This mostly reverts commit 19141f2110,
thus restoring most of the changes from 8b813adf6d.
However, we keep these ranges inside the kernel args ranges for now,
as they're used in the 32-bit non-PAE case at least.
Change-Id: I966d3269414dd02713cdda9852f5a4a212d85be5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8463
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This way, on systems with lots of RAM (> 100 GB) where the page array
will wind up taking > 1 GB, we don't consume all the available memory
below 4GB before even getting out of the early boot process.
When we run out of memory above 4GB, the "expand upwards" loop will
try expanding the previous ranges, and then the "expand downwards" loop
will expand the range starting at 4GB downwards if there's memory below.
So if the memory before 4GB is needed, we'll still allocate it.
Fixes #19117.
Change-Id: Ic20934ccf8ea7f6b1d4bff1af4a09cf1688147d2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8448
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
1. Only do low battery processing if the battery being queried is the
"virtual aggregate battery" (ID -1), this fixes the issue of spurious
and duplicated low battery warnings whenever the extended info panel is
open (and therefore multiple batteries are being individually queried).
2. Calculate the time remaining separately after adding up all the
individual battery values, this works around batteries which are not
currently in use returning -1 time_left which caused the aggregate to be
incorrect if the values from the driver interface are simply added as-is.
An example situation to illustrate item 2:
Battery 0 capacity: 20,000mWh
Battery 0 draw: 0mW
Battery 0 state: Unused
Battery 0 time_left: -1 (since it currently has zero draw on it, it has
"infinite time left" if looked at in isolation)
Battery 1 capacity: 20,000mWh
Battery 1 draw: 10,000mW
Battery 1 state: Discharging
Battery 1 time_left: 2 hours
If the time_lefts are added together (even if battery 0 is ignored for that
calculation), it'll show 2 hours left despite there being 40,000mWh of total
capacity for a 10,000mW draw. We now treat all batteries together as one large
one instead, calculating the draw/capacity on the totals which gives an
accurate number.
This fixes issues 2 and 3 in bug #19167.
Change-Id: I1b9a0c3dd47f917da86becfcfebed7b35b3422d4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8462
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
