With the Tracker thread code in shared now it is possible to use the same
trick for the expanders in Deskbar to open and close in a separate thread
that we use in Tracker. See Find Panel and Info window for examples
of the code being used in Tracker.
Also eliminates the fClickedExpander variable and allow you to expand with any
mouse button.
Hopefully fixes#9676
...while mouse is down on a menufield
This makes it so that you can't open 2 menufields simultaneously
by clicking and holding the right mouse button on one menufield while
clicking a second with the the left mouse button opening it.
This matches the behavior on BeOS R5.
Should help with #6408 comment:9
Instead of listing all the objects we want from the libgcc archive
we just make a copy of it and remove those we don't want, and link
to it.
This should allow returning MAXLINE in jam to a sane value.
* Increase general allocation alignment from 4 to 8 byte. That was even
incorrect.
* Use a splay tree instead of a singly linked list to manage the free
chunks. That increases the size of the per-chunk structure to manage
the free chunks, i.e. the of minimally allocatable memory size (from
align(sizeof(void*)) to align(3 * sizeof(void*))), but make finding
and inserting chunks much faster.
Fixes#10063 respectively improves the situation significantly.
* Remove the BUrlRequest class, which was only delegating work to
BUrlProtocol and subclasses
* Rename BUrlProtocol to BUrlRequest, and BUrlRequestHttp to BHttpRequest
* Creating a request is now done through the BUrlProtocolRoster. For
now there is just a static MakeRequest method, this will be completed
when we get to actually allowing add-ons to provide different request
handlers.
This allows cleanup of the API for requests:
* Remove the universal SetOption method with constants, and have
dedicated setters for each protocol option.
* Setters can now have multiple parameters, for example you can give
BHTTPRequest a BDataIO and a known size
* In this case, the BHttpRequest will not use HTTP chunked transfers,
which were always used before and made most servers unhappy (tested and
failed with lighttpd, google accounts and github).
- While building the installed package list, resolve the dependencies
of the OS packages. Flag the resulting list as protected so as
to disallow uninstallation of them in addition to the OS packages.
A hpkg will be created locally, which contains the firmwares. This hpkg will
be copied to system. IIRC, the firmware must live in their respective
subdirectories.
To note, once the approve_license flags are implemented on the end-user
applicacation side, the Intel ipw2100 and Intel ipw2200 could be moved
to a separate package. However (and IIRC) the Broadcom involves using a closed
binary blob, that should not become a pre-made package.
README.iwlwifi-3945-ucode and LICENSE.iwlwifi-3945-ucode were mistakenly marked
as an executable. Was uncertain if iwlwifi-3945-2.ucode should or should not
be marked as an executable and was unchanged.
- A package can potentially be installed in more than one location. As
such, track all of them on PackageInfo (not yet exposed/used).
- Rather than attempting to use location, check the package's flags to
see if it's a system package. If so, disallow deinstallation. Not quite
complete yet though, as we still needs to also resolve the deps of any
system package, and likewise disallow removal of those.
- If a package was installed, but didn't have a corresponding remote
repository package, it would have been missed in the list. Detect these
and create a special local depot object to house them, so they also make
their way into the visible package list.
Thanks to diver for reporting the discrepancy.
- Since the package list is built lazily in the background, the list of
depots won't actually be available immediately at construction time.
Defer building the menu for both that and the categority list until the
model has actually been populated.
This makes package management operations that require a repository cache
immediately usable (even offline). Also makes sense for the
update-{all,packages} build profile actions, since those update the
repository config which would otherwise no longer match a potentially
existing cache.
... before copying the new contents to the image. This caters to the
typical use case of updating an existing Haiku, making manual
intervention to get the new packages activated unnecessary. The downside
is that manually added packages will be removed as well.
Should already have been done back when the semantics for the
B_COMMON_*DIRECTORY constants was changed.
Currently old and new version behave the same. So this is just a
contingency measure ATM.
Ingo Weinhold