Add a column to the table to show the publish
date. Also add text on the featured packages
view to show the publish date. Supports
sorting.
Fixes#13006
Change-Id: I19d9bc5bf7f44b5673c2ade5d00de8fdadbe1b06
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4649
Reviewed-by: humdinger <humdingerb@gmail.com>
Reviewed-by: Andrew Lindesay <apl@lindesay.co.nz>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The upcoming change to use zstd by default will make the -z no-argument
variant obsolete, so instead we need to support passing "zstd" or "zlib"
to actually indicate the compression method we want to use.
BZstdCompressionAlgorithm already has these #ifdefs and will
return error codes appropriately if built without libzstd,
so we do not need to check again inside the Package Kit.
This should not break the no-zstd build (well, it is broken
somewhat right now anyway, but this will not break it further),
and it simplifies logic somewhat.
This way, we get the user's environment variables, and so should
input_server, which is started by app_server.
This should, after 6 years, fix#12534. We may need to revisit this
when/if we add multiuser support, but that is a problem for another day.
Change-Id: I04698306bc68a585acd232e9f9d29c50bc170a1f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4506
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Refactors so that we look for a codec subsystem ID, then the
Audio Function Group subsystem ID if not found.
* Moves the order around a bit so that the quirks are set early
enough.
* Also adds a quirk for MacBookAir 6,2, allows speakers to work.
Change-Id: I4c64f96936a82a5d7187d86d8558f28516fd4ecb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4654
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
We still do not know if the accelerant buffers are graphics memory or not,
but in my testing (on the VESA driver), the only time I could get _CopyRect
to be called was where the buffer was in fact not graphics memory.
So that should provide a performance improvement there.
On the other end of things, this should resolve unaligned video memory
access problems on RISCV, and potentially other platforms, as gfxcpy32
did not attempt to align pointers; it should also improve performance
as memcpy will usually be faster than our custom gfxcpy here.
Most of this code has not been touched since 2006 or so.
Change-Id: I40b0345c5d47f2b45acafb14f03fd3a24d2042a8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4315
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
It just causes confusion and is wrong in the case where double buffering
status changed during the object lifetime.
Change-Id: Ia1a9ae3f5a1b1b7d521b79c7d1c7be92cef60a06
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4633
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
libtermcap was deprecated in favor of terminfo in 2013; the library was
removed then, and this file was only left because not all optional
packages had yet been rebuilt against ncurses. Well, that has now
long been completed, and indeed all applications continue to function
even after removing /etc/termcap.
In case any legacy applications that I have missed still do need it,
it should be provided by HaikuPorts and not Haiku itself.
These are better here than in my bash history...
Change-Id: Iab8940f4efed950e26a8bad29cb8954464270e8f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4645
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
On Sparc Openboot, we get allocated a stack of only 8 kilobytes, and
each called function costs at least 176 bytes for the stack frame.
This means we need to be more careful than usual about stack usage. Move
some large-ish allocations off the stack by either making them static,
or allocated dynamically.
Add a compiler flag to error on functions which use too much stack. The
threshold is at 1023 bytes, because that's what allowed me to find the
two functions that were causing a stack overflow (open_from and
_ParseActivatedPackagesFile)
Change-Id: Ia0d13a9247e1a3fff4ce654bdffd6edb16e7cbc7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2371
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
These are helper functions for long double math. On sparc there is no
hardware implementation of long double instructions, and the ABI defines
these methods which must be part of the C library. GCC calls the methods
directly in its generated code.
They were already added to libroot, but they also need to be in the
stub, which is used during bootstrapping to link mpfr (during the
target gcc build).
I put these in a separate file because I assume the generation of the
stubs file from the real libroot.so will usually not be run on sparc,
and will not include these symbols otherwise. This may become a problem
if libroot for different architectures starts to diverge further.
Change-Id: I6070394c685fee35b3dc12a507f5a6271571b993
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4636
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This way it becomes much easier to write multiple console implementations
in one bootloader.
Tested for bios_ia32 and efi.
Change-Id: I67134f5c3de109b15d46898864ba7f51c6592afc
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4642
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Most importantly include zstd, which is a new requirement for the
bootstrap build.
Change-Id: I981401e7d70fb7e1befaf7fc37f2fddc6d7e327d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4635
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This is an internal ICU library, used by their command line tools only.
libbe (or anything in Haiku sources) does not need to link to it.
Change-Id: Id322572c6833c225d5501a7e9520dd3dc82934f8
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4634
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Delete dropped out networks.
* Add in newly discovered networks.
* Add static (aka class) compare method to WirelessNetworkMenuItem
that is used to sort items by signal strength descending.
Add == operator to wireless_network struct to determine if
existing items have a known network attached.
Remove the non-network items from the menu, save them, sort
network menu items, then add non-network items back into the
menu.
Update NetworkStatus preflet to use same compare method as Network
preflet. signal_strength_compare function had a bool return value
instead of int which worked to sort items the first time, but does
not work on successive compares.
By not deleting and recreating the menu items each Pulse(),
the Network preflet no longer crashes on update. The menu flashes
on update still but doesn't crash.
Fixes#12024
Change-Id: Ie5b22cea4e66350b9c5df8e3b8de266ede50ad6d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4243
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
... methods which call the respective methods in BList.
These convinience methods allow you to sort a menu of menu items
via a compare function, swap two menu items, or move a menu item
to a new index. Update items layout if menu is open.
Previously there was no easy way to rearrange menu items in a menu.
Change-Id: Ice3d6e5404e895196d8bd32d696dce7c55bd72d4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4296
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The other Atheros drivers are "atheros813x" and "atheroswifi",
so renaming this one (which is the oldest of the set) to match
the other two makes sense.
This is the driver for Intel's new line of desktop-class ethernet
controllers, from FreeBSD. Not yet included in the builds as it
is untested.
Part of #17212.
Now that there is also a "tap" driver in here, and the WiFi drivers
are also in a subdirectory, moving the physical ethernet device drivers
to a subdirectory also makes sense.
(Briefly) discussed on the mailing lists.
