... with the replicant tray below the menu bar.
Deskbar now has four modes:
1. vertical mini-mode (old mini-mode)
2. horizontal mini-mode (new mini-mode, was vertical)
3. vertical expando-mode (default)
4. horizonal expando-mode
Horizontal mini-mode gets the corner, then it switches to vertical
mini-mode above or below that, then to vertical expando-mode after
that. Horizontal expando mode is in center-screen top and bottom.
Clock vertical centering simplification.
Change-Id: I216008c20feb28f793693046792bbcfdf1e703e3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3146
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Without it, the device can't operate at all. Whether or not this is
enabled already is firmware dependent. It was off under QEMU when used
with "-soundhw ac97" and this makes the driver work there.
Fixes#10551 where the syslog shows that this can also happen on real
hardware that is otherwise fully configured.
The BGradient class is a bit strange as it can store any gradient on its
own, butonly the subclasses allow to set some of the fields.
In the asignment operator, the non-base data (which is in an union) was
not copied over.
More importantly, the missing copy constructor led to the default
implementation being used, and BList (used for the color stops) was
being copied using its default copy constructor, resulting in the two
BGradient (original and copy) poinitng to the same stops data. Heap
corruption resulted whenever one of them was deleted.
Having a working copy ocnstructor fixes this. The alternative is making
the copy constructor private or protected to make sure gradients are not
copied, since normally you'd copy only the subclasses, preserving the
C++ type. However there is nothing enforcing that, and manipulating a
BGradient copied from a subclass works just fine.
Change-Id: I28e733eb8a2970b76ae623eabb75ef8435f508af
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3144
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The level parameter in the CopyEngine::CollectCopyInfo() and
CopyEngine::Copy() methods was introduced in hrev30395 to allow the CopyEngine
to decide which directories should be copied. Since then, this
class has been rewritten and it is no longer necessary for that purpose.
This change refactors the CopyEngine and removes the
level parameter from the class interface. Furthermore, it was broken to begin
with; it was passed as reference to the internal recursive _Copy() and
_CollectCopyInfo() methods, meaning they acted like a global counter. The
global counter was increased at the beginning and decreased at the end of those
methods. Execution could terminate early though, leaving the level counter out
of sync with the recursion level.
There is one use of the level parameter, namely in the
WorkerThread::EntryFilter::ShouldClobberFolder() method, but the use of the
parameter was wrong (it would have been at level 3 at the point of the check,
not level 2) and the logic is functional without the level check.
Change-Id: Id92ef89b015e9b1185bde061273f61e492664bce
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3139
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
This was removed in hrev33708 when enabling the "double click to raise"
feature. It results in all clicks after the first one just raising the
team again.
Fixes#8471
Change-Id: I2c7a7bd25401900ee22f6bb953d055e28670776e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3108
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Preserve passed in text rect in fTextRext (unless in layout)
and create an internal version fAlignedTextRect which is used
in place of fTextRect. fAlignedTextRext is aligned to fit the
text rect bounds and grows to fit. fAlignedTextRect always grows
vertically but only grows horizontally if wrap is off.
Left-aligned text view's grow right, right-aligned ones grow left,
and center center aligned ones grow out.
Set fTextRect to bounds in _DoLayout().
Reduce left and right padding inside text views from full label
spacing to half label spacing. Unify padding between BTextControl
and BTextView.
Fixing padding also fixes right and center-aligned BTextViews.
Undo extra scrolling for non-left text views from hrev24130 fixing
a scrolling left and right with mouse bug when it shouldn't.
Replace max_c and min_c with std::max and std::min respectively.
Remove scrolling from one instance of BTextView::SetText as it
produced undesired results while editing a scrolled text view.
Set text rect in BTextControl::DoLayout() and ScreenSaver
PreviewView::AddPreview().
Don't add padding if BTextView::SetInsets() is called. Set insets
to 0 in Tracker "Edit name" setting which prevents default padding
from being added. This is so that when you rename a file in Tracker
the TextView appears on top of the file name text with no padding.
80 char limit fixes.
Fixes#1651#12608#13796#15189#15688
Change-Id: I8c6106effc612f49aff374f29742471628b5df86
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3054
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
There is no point in computing line breaks for a 10px wide text view and
it takes a long time because it needs a lot of linebreaks. The view
eventually gets laid out properly.
This may cause regressions, the TODO here is very old and I don't know
to which "other parts of the code" it refers. Possibly they were
rewritten, possibly not. In any case, there is no point in keeping this
nonsense initial text rect computation, it's better to fix the actual
problems.
Fixes#5582 (which was not locale-related, after all)
If be_app is not running yet, trying to lock it may easily end up in a
deadlock.
Fixes#2105
However, as a result of this, when this situation happens, the
translator roster will not be node monitoring added/removed translators.
This was already the case if BTranslatorRoster::Default was called
before BApplication constructor, now it's also the case if called inside
the BApplication constructor or from another thread before it finished
running.
Maybe BTranslatorRoster should try to register itself later on if it
detects this. But it's acceptable to have the app not monitor
translators, because adding and removing translators isn't a very common
occurence and restarting the app to get it to notice them is probably
ok.
Remove the InstallerInitScript (it does nothing) and the
InstallerFinishScript (it does too many things). Instead implement the
finishing directly in Installer. Separate writing the bootsector, so
that the "write bootsector" menu writes only the bootsector.
Fixes#16303
- libicule and libiculx do not exist anymore in newer ICU versions
(harfbuzz replaces them), but we didn't actually use them, so remove
them from the build feature and from the package dependencies
- Add namespace usage marcos since the newer ICU packages put ICU things
in a namespace, making it easier to have multiple versions of ICU used
side by side.
No functional change intended, but this makes it possible to build the
code with either ICU 57 (for gcc2) or 66 (for other architectures).
Reserved areas don't have the name field initialized, so explicitly
print "reserved" instead.
Change-Id: I26bcfcb8facb8b5df11a58074506e96a41943e31
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2847
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This makes the output of the aspace KDL command more useful as it shows
reserved and free ranges in addition to areas.
Change-Id: Id6353820b7c040fce6bfc3297c1b34adb1c9bb99
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2846
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It allows an application to signal that it no longer needs the data in
the given address range and the underlying pages can be discarded and
reused elsewhere. This is finer grained than working with full areas
or mappings at a time and enables unmapping sections of partially used
mappings without giving up its address space.
Compared with punching holes into a mapping by "mapping over" with
PROT_NONE and MAP_NORESERVE, this has the obvious advantage of not
producing a lot of unused extra areas and saves the corresponding
resources. It is also a lot "lighter" of an operation than cutting
existing areas.
This introduces madvise() alongside the existing posix_madvise() to
allow for OS specific extensions. The constants for both functions are
aliased, the POSIX_MADV_* being a subset of the MADV_* ones without the
non-POSIX extensions. Internally posix_madvise() simply calls madvise().
MADV_FREE is commonly supported in other OSes with various subtle
semantic differences as to when pages are actually freed/cleared and how
or whether the pages are counted against the memory use of a process.
In the variant implemented here, pages are always immediately discarded
and memory counting is not altered. This behaviour should be considered
an implementation detail and may be altered later. The actual unmap and
discard could for example be delayed until pages are needed elsewhere to
reduce overhead in case of repeated discarding and remapping.
Note that MADV_FREE doesn't really align with the rest of the madvise()
API as it works like a command (i.e. discard these pages) and does not
add an attribute to the pages in the given range (i.e. mark these pages
for quick access from now on). As such, an MADV_FREE does not need to be
undone by setting a different advice later on, unlike how the other
flags work. This discrepancy may be the reason why it is not part of
POSIX.
Change-Id: Icc093379125a43e465dc4409d8f5ae0f64e107e0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2844
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Pages in the given range are unmapped and freed without getting written
back anywhere. It can be used whenever a caller does not care about the
data in the given range anymore and wants to reduce page pressure.
Change-Id: I8bcce68fab278efef710d3714677e1d463504a56
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2843
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The limit was set when creating limits.h back in hrev88. It seems to be
used only in glob(). The limit is quite low by today standards and
prevents building icu 67.
I guess the liit was put at 32K because that's what BeOS did, but I see
no reason to keep it that way.
Change-Id: I74f95d9b56891dd90c79b7ced35ca8d1ec81d6ab
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3117
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* efi-app-x86_64 is a undocumented legacy compatibility
target from the early days of EFI.
* This opens the door to native arm,arm64 loaders without
the gnu-efi 'fake pe' stubs in the future.
* This change also clairifies what's happening within the
undocumented efi-app-x86_64
* Future as in binutils fixing these:
https://sourceware.org/bugzilla/show_bug.cgi?id=26206https://sourceware.org/bugzilla/show_bug.cgi?id=26218
Change-Id: I60b4a4f5ceb36059033debbe6bf5b01928d6b223
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3016
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
The label to be truncated was copied into a fixed width buffer without
taking the null byte into account which would make
BFont::GetTruncatedStrings() read out of bounds when the name got long
enough. The output strings were also not allocated with the required
extra space for the ellipsis which would possibly have caused the
output to overflow.
Since the goal is to truncate a single string, remove the entire
temporary extra allocations and simplify to use BFont::TruncateString()
directly, which avoids both problems by being BString based.
Change-Id: Ib57430faf6f706c705497191000ee9686441857e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3116
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The name retrieved from GetName() on BTextEncoding is owned by that
instance which goes out of scope when identify_text() returns. A const
char pointer to it can therefore not be used as an output variable. Use
a BString instead which ensures an appropriate reference is acquired.
Change-Id: Ib87fc9879d29e927bb41d1a9165ca7599b74a3bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3115
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The panic is continuable, but moving on with the free will overrun the
array and corrupt memory.
Change-Id: I9a5849a40158042150a25740ca57d711aee872bf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3114
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
If the vector is assigned to a CPU it means that the assignment
structure is still referenced from the CPU side and must not be reset.
This can happen when an interrupt vector is freed that still has a
handler installed, i.e. when the order of removing the handler and
freeing the vector is reversed.
Change-Id: Ib2dc5fa8f95a28b36e8f150dc8f16236ca4b2275
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3113
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Freeing an interrupt vector that still has handlers is not allowed.
Change-Id: If2f256e5288c7a61b7e23bdb202f259f5b67b7ae
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3112
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The old buffer info was not initialized so would possibly contain bogus
initial content.
Since the introduction of the TimeComputer, the old buffer info was not
used to update the timesource data and the only remaining use was for
keeping track of the previous cycle number.
Replace the old buffer info by just the old cycle number and initialize
that.
Change-Id: I8be5a17f086a9f81f9b8fd0629e10460518f3d8c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3111
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: I82465c3002cbf58fad79b9621074cafd8fbd16e5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3106
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Abstacts the list of supported languages into
the LanguageModel class preventing use of
List. Also; fix a few cases where newer
logging techniques may have caused incorrect
logic flow.
Relates To #15534
Change-Id: I144fe4788abdaf0d93e53eeabc97b3f7aa2ec710
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3085
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
