Previously, all packages on the image, both activated and unactivated,
were in $systemPackages, so if a package actually in /system/packages
had a dependency in the Installer optional package area, the dependency
checking would see no problem but the generated image would be broken.
Now, packages going into /system/packages are treated separately
from those going elsewhere, and error checks added so the above
condition will not occur.
(I ran into this while working on the build-package upgrade
in the following commits.)
No need to pull in e.g. "libpng16" explicitly when the appropriate
libpng version will automatically get selected by get_package_dependencies
at image build time.
I did however remove ctags altogether; nothing in the base install
uses it, so there's no reason to have it.
The views for prominent and list packages were both
getting mouse click events and they were both sending
the "package changed" to the MainWindow which, with
the two queued messages, ended up in a feedback loop
constantly oscillating between the two packages from
the two views. This problem is resolved in this
commit by stopping one of the views processing the
events if it is hidden -- because it is not the
selected tab.
Resolves#15884
Change-Id: I38f75baba26b26183fd0cd1a6909e404f9f37b9b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2498
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts commit 7ba52abdd3.
Reason for revert: Broke the build due to undeclared symbols.
Change-Id: If726d1f71a336f98428037dad2acfdaf961f1a84
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2497
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Only in the specific case of:
- Generation 2 or 3 hardware (with a limited panel fitter)
- No EDID is found (so we have no idea about timing limits)
- A VBT is found (so we know the native resolution of the LCD panel)
Only in this case, restrict available resolutions to the ones not larger
than the VBT mode. Larger resolutions don't work and result in a black
screen.
In all other cases, we should normally figure out appropriate
resolutions from the EDID limits and our well-known modes list.
Change-Id: I3bba9f53b92c4c647e0d644fa0181f6fe96d1fc4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2235
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is the final contribution to #15368
* Tried to share more documentation in the various BLayoutBuilder classes
* Add missing GridView, GroupView, SpaceLayoutItem
* Also added AbstractLayoutItem, but hide the actual documentation behind
an `INTERNAL` conditional block. This block identifier can be used to
document parts of the API, to then hide them during a regular Doxygen run.
* Do some cleanup on other layout classes; add missing members, etc.
* The actual generated BLayoutBuilder::* html is a mess. I should investigate
this at a later time. Especially the copied members seem to mix type
definitions with member documentation. It is odd. Not unlikely to be a
Doxygen bug.
* The general documentation for the layout system could use an overhaul as
well, but this is for later.
Change-Id: I6db9ef105b4ae6de0f1ebb917f86f8b1c0d4ea2e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2491
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This patch makes "UnitTester BNode" pass.
Several tests which attempt to create or access a directory entry that
exceeds the maximum length assume that B_NAME_TOO_LONG status will be
returned, since that is what BeOS does. When constructing a BNode with
a path like "/tmp/some really long filename larger than 256
characters...", the vfs eventually calls bfs_lookup() which calls
BPlusTree::Find(). In the case of a really long entry, Find() returns
B_BAD_VALUE.
This patch just changes BPlusTree::Find to return the more specific
error that matches BeOS.
Additionally this patch fixes some assertions in NodeTest. BeOS seems
to have been missing some error checking code in the initialization of
BNode, specifically with BNode(Directory*, const char*) and the
equivalent SetTo method. If you provide an empty string for the child
entry name to either of those, B_OK will be returned. But either way
you initialize the object, when you try to use it, like with
BNode::GetAttrInfo(), you'll get B_BAD_VALUE.
This just changes any assertions for this situation to expect
B_ENTRY_NOT_FOUND, which is the actual initialization error Haiku
sets.
This and the change to bfs resolves many assertions the following
storage tests:
* TestCaller BFile::Init Test 1
* TestCaller BFile::Init Test 2
* TestCaller BNode::Init Test1
* TestCaller BNode::Init Test2
* TestCaller BSymLink::Init Test 1
* TestCaller BSymLink::Init Test 2
Change-Id: I8598352aa341ffcab9f7bc3e6740ae1cb3dbab8c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2490
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Note that for this to work well, the child views in the tabs must
propagate MouseDown events up for these buttons.
Change-Id: I503d7203cb20e6ba85bd0d7e1cfaed988e3cf17b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2207
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The code in input_server was pretty much all set for this, but there was
no way to configure the extra buttons. Add them to the mouse view in
Input preferences (up to 5 buttons are handled now)
Define a new B_MOUSE_BUTTON(n) macro to generate the bitmask for a given
button (numbered from 1).
Change-Id: I9091082277937d89b08464ff474e7bbb5db82401
Reviewed-on: https://review.haiku-os.org/c/haiku/+/180
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
I make some changes in the wacom input server to solve the bug mentioned above. I don't have wacom and unable to buy it duw to COVID-19.
Can anyone please test the code.
Change-Id: I27a7353cafd495f89d7ba7f8a6f4fa7e8abc86e1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2448
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Some text displayed was not using the system
standard colors.
Resolves#11689
Change-Id: Ia415a32f47dff6aa86d343d1acc154527300e924
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2493
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
BeOS didn't support transparent views. As documented in the Be Book,
SetViewColor(B_TRANSPARENT_COLOR) only effect is to not fill the
invalidated areas with the view color before calling Draw() (it avoids
flickering, especially when combined with B_FULL_UPDATE_ON_RESIZE).
A previous change made B_TRANSPARENT_COLOR actually make the view
transparent (that is, additionally to the above, the underlying view is
drawn before the transparent children), but it creates compatibility
issues.
In order to keep the API compatible with BeOS, the new behavior is now
enabled explicitly using the B_TRANSPARENT_VIEW flag. This also opens
for future developments like allowing a view color with an alpha
channel (not supported yet).
Adjust programs that require transparent views.
Fixes#15744, #15745.
Helps with #15645.
Change-Id: I529574ea23db0a23579521b263bc8d572775e35a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2275
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Cleans up the code around tab-switching and
also improves some logic around inserting
packages into the list of 'prominent'
packages by using a binary search.
If Haiku is installed into an environment with no
networking then it won't be able to talk to HDS
and so won't know which packages are promoted.
In this case switch the user to the "all packages"
tab so they are not shown a blank panel by default.
Relates to #14675, #14927
Change-Id: I14dd3be4af09a98245ddd0a9704bd8d53ed64a53
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2478
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The user might have changed their authentication details
on the server and the client won't detect this until
they go to do something. Instead, if possible, check
this as the client starts. Also check that the user has
agreed to the current user usage conditions.
As a side-effect this generalizes the logic for process
coordination in the main window and also fixes some bugs
in the main window's progress display as the application
starts.
Relates to #15209
Change-Id: I4c9620648819ecd14fb095e4cb2c66fe7b2a0920
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2467
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This adds documentation for BCardView, BCardLayout and BLayoutBuilder::Cards.
There is also a bit of cleanup for the BSplitView documentation.
It also makes explicit when a developer passes an invalid argument to
BCardLayout::SetVisibleItem(), by making that a debugger() call.
Change-Id: I17ac52cc773bb76c4f81beaa76f72af62a9e10f4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2460
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
System dependencies and kernel interface code has been added.
Change-Id: I770ad6b906ca41d4d84d374cea209e22149fd727
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2344
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
It seems clear that the architectural designs of rpmalloc are
just not suited for us in the "corner-cases", and probably never
will be.
After R1/beta2, I'll investigate switching us to musl's mallocng,
which is explicitly designed as a system allocator and has much
lower overall memory usage than even glibc's default allocator.
This received 84% on the forums, so it seems pretty uncontroversial
to enable it by default.
No other option received 70% or more, so I'll leave Humdinger to
decide what the other changes to the defaults should be based
on whatever threshold is decided upon...
wpa_supplicant needs to be rebuilt
against it and then this needs to be tested.
Added some FIXMEs to keep track of places I'm not sure if we need to
change anything.
Fixes#14805
Change-Id: I6379dc32b772289960afbfb362365a542a986983
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2225
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Scroll bars should look and work identically to before on
HaikuControlLook.
Add DrawScrollBarButton() and DrawScrollBarThumb() and
DrawScrollBarBorder() methods. These methods are used to draw scroll
bars in a generic way so that they can be drawn differently by alternative
control look's (e.g. BeControlLook). Also it gives us back drawing of
scroll bar knobs. However the knob setting is not exposed in the
interface in this commit.
These methods are in addition to the 2 existing DrawScrollBarBackground()
methods that draw the scroll bar background. One draws the area above and
below the thumb and the other is called by the first to actually draw the
area.
The rest of the drawing besides the backgrounds was being done in
BScrollBar before. To draw the scroll bar arrows and thumb we were recyling
other ControlLook methods, while this worked well enough on HaikuControlLook
it wasn't flexible enough for alternative control looks.
DrawScrollBarButton() is used to draw the four scroll buttons and is
typically (so far) used in combination with DrawArrowShape().
DrawScrollBarThumb() draws the scroll bar thumb.
DrawScrollBarBorder() draws a 1px border around the entire scroll bar,
potentially B_KEYBOARD_NAVIGATION_COLOR if focused (although this is
feature not currently used.)
Draw unscrollable scroll bars as if they were disabled including the
buttons with their arrow shapes, background, and thumb.
Add FBC backwords compatibility macros in ControlLook.cpp
Change-Id: I9237c5ce45d17d674785111d51de951e5686306b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/351
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
In hrev53944 selection is cleared if text view lose focus, but it
don't work properly in StyledEdit, causing clearing selection when
menu is opened. Clear selection on lose focus is needed for text controls,
so when you click on another text control, previosly focused text
control should clear selection. This behavior is working in BeOS, so
some investigation is required.
Fixes#15810.
Change-Id: Ie104fc1d7e76c2cd2b97d3a0462856fe70cccbbf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2355
Reviewed-by: Stefano Ceccherini <stefano.ceccherini@gmail.com>
they should be compatible for I2C I/O
Change-Id: Ifc2bed29813403ef845ca60c9cc22187e2cacc88
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2469
Reviewed-by: X512 <danger_mail@list.ru>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
busses/i2c needs to be probed also for acpi devices
Change-Id: Ib75b6e8db27361e395560d069dcbf136571b7a8e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2463
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
