* Add a note about a workaround that can be used to run
test_app_server, which currently fails to load the right
library libbe_test.so. The bug should be fixed too, but
with this, it can at least be used until then.
The command to get the hub descriptor needs to be a class request and was incorrect causing a Stall error for the hub. The the driver does not handle a stall error yet, causing odd behavior.
Signed-off-by: Jérôme Duval <jerome.duval@gmail.com>
* Expects its config files in /boot/home/test_launch.
* Uses standard I/O, and is always in user mode.
* Also added test_launch_roster command that is able to talk to the test
server like it does to the real thing.
* Update repository file to hardlink_packages modified one.
* Add some basic process overview to directory.
* We don't normally document in paths, but this stuff is complex.
* Documentation improvements welcome.
* When opening the screenshot window for a package, set the window
size to the largest dimensions of all the screenshots of this
package. Prevents it from resizing/jumping around when browsing
through the images.
Call newly created BDeskbar methods to adjust default Zoom().
if auto-hide is turned on don't consider Deskbar's frame.
In vertical mode allow windows to zoom on top of Deskbar if
auto-raise or always on top is turned on.
Deskbar can take up a significant area so you can reclaim that
space by turning on auto-raise or always on top.
In horizontal mode ignore auto-raise and always on top settings,
don't allow windows to zoom on top of Deskbar even if these
settings are turned on.
Deskbar doesn't take up very much space and you don't want your
window to get cut-off at the bottom.
Add methods to get and set "Always on top", "Auto raise", and "auto hide"
which are all booleans which control aspects of the Deskbar window to
BDeskbar.
Set the bool to the default value initially. Check if sending the
message succeeds, if so check the reply which also fills out the bool.
Don't check to see if reply succeeded because the bool will only be
overwritten if it did.
Follow the BDeskbar convention Is...() for getter, Set...() for setter
e.g IsAlwaysOnTop() is the getter, SetAlwaysOnTop() is the setter.
Define new message constants to call the newly created methods.
Follow BDeskbar convention: 'gtla' is used for getter, 'stla' for setter.
g/s for getter/setter, tla is an all-lowercase code unique to each
getter/setter pair.
Copy/paste these message constants into BarApp.h unchanged. Replace four
letter codes with imported message constants in BarApp.cpp and
BarWindow.cpp. Much nicer than using bare codes.
The new BDeskbar methods are all handled by TBarApp. The getters send
back a reply message containing the bool while the setters fall through
to existing setter cases.
Zoom() takes up all Desktop area excluding the area
occupied by Deskbar. This is calculated using information
from the BDeskbar class.
Window zooms just as you'd expect -- it takes up fullscreen
minus area taken up by Deskbar. In vertical mode the zoom
area depends on the width of Deskbar, consequently Zoom()
is more space efficient in horizontal mode than vertical
mode because the window doesn't use the area below Deskbar.
If the zoom limits are smaller than the Desktop area, the
zoom area shrinks towards the center of the Desktop not
covered by Deskbar. This is slightly different behavior,
the window insets off-center following Deskbar.
In some scenarios zooming to the non-Deskbar area was too
restrictive. I made an exception that if there is enough
room above or below Deskbar i.e. a short window, then Zoom()
instead insets from the screen edge ignoring Deskbar. Apps
which meet this criteria include DriveSetup and Expander.
* Hashing semantics for the new build repositories are different than
the old ones, so update those (if the x86 build was not broken before
it is now...)
* OptionalPackages has been updated slightly (removed libtool and git_cvs
from the default images, as they are rarely used nowadays and would pull
in a bunch of dependencies we don't really care for either)
* Removed lib:libqrencode from Haiku package requires (qrencode_kdl is a
static library, the userland libqrencode is not used anywhere in the tree,
as far as I can tell)
* Fix build of JPEG2000 translator after update
* Decouple fluidsynth build machinery and remove from image now that it
is no longer used
* Update repository URL in Repositories preflet
x86 is unaffected, as already mentioned. This breaks the build,
but since this diff was large, I wanted to have the functionality
changes be clear, so they are in the next commit.
This is essentially the replacement for "jam upload-packages" --
it goes through a directory of packages (intended to be one made by
buildmaster), picks the packages out of it that are in the repository
file passed to it, and then hardlinks them to a second directory
as well as updates the repository file and creates a package_repo.
This is what was used to mass-modify the repository files which
will be updated in the next commit.
The packages that remain are only the ones used somewhere in Jam
(including ones off by default, e.g. Wonderbrush, Live555.)
The x86 repo is untouched as it is being phased out and has no buildmaster-
generated equivalent.
It was trying to use $(feature:U) outside of the loop where it is
actually set. Thanks to PulkoMandy for spotting the problem.
(How did this not break tons of stuff?)
* Initial support for displaying multiple screenshots for packages
which have more than one. Still rough and unfinished.
Screenshot window now has a toolbar with prev/next buttons and
a busy loading indicator. Switching through the screenshots works.
There's currently a server-side bug which makes all data turn up
15 times in the JSON file, so please don't report a bug about
HaikuDepot showing 15 or 30 screenshots available when it's really
just 1 or 2 :)
Still to be done: toolbar icons instead of text labels; better
handling of screenshot window resizing; maybe thumbnails of
screenshots and preloading other screenshots in the background.
Main window also needs a way to indicate that there are more
screenshots than the one thumbnail, needs some more thought about
how that might look.
This concludes my HaikuDepot commits from the coding sprint at
KDC 2017 Toulouse!
* The UI became unresponsive while the PackageListView was filled
with all the packages. This was especially apparent when using
the search function, which clears and refills the view with every
typed character.
* Add a new worker thread with the task of asynchronously filling the
PackageListView. When a new data model is adopted, we hand the
thread a copy of the visible package list. The worker thread then
goes through the list and sends the package infos via BMessage back
to the MainWindow, in batches of 20 infos per message. When the 20
entries were added, it acknowledges this to the worker thread which
will send the next 20 infos (so UI messages can get in between,
keeping it responsive). The lists also get a unique ID so that
model changes while the list is populating will invalidate
previously sent messages (and cause the worker thread to cancel
processing the outdated list).
* Search is much nicer to use this way, staying responsive and
listing packages while typing. Still not perfect since the
PackageListView is still cleared and refilled each time a character
is typed, instead of just narrowing down the already displayed
package set. But that's to be improved on another day...
* Same applies to filling FeaturedPackagesView btw
* Use a hash table to find PackageRows by package name in
PackageListView, instead of doing linear search over all rows.
Improves performance of populating the list, since every
AddPackage() checks if a row for the package already exists.
* Add new WorkStatusView which keeps the user informed about what's
happening. It's a status bar at the bottom of the window which
shows on the left side either a spinning barber pole (for
operations without a progress), or a progress bar (for download
progress). Next to that is a text view showing a descriptive
status text.
* Currently, it will notify of the following operations:
- Repository refresh (barber pole)
- Background packet actions, like preparation of install or uninstall
(barber pole)
- Package downloads, including downloads of dependencies (progress
bar). Status text indicates the name of the package currently
being downloaded (if any), and how many more packages are queued
for download after it (if any).
* Hooks into PackageListView to be notified of package status changes
(such as becoming pending or download progress)
* When the package currently being downloaded is also selected in the
list view, the user sees the progress bar in WorkStatusView
as well as the one in the PackageInfoView, which is redundant. This
still needs a good solution...
* Add a new event "ConfirmedChanges" to PackageProgressListener. It
triggers when a package action was confirmed by the user and is
about to be run. This can be used to e.g. get a full list of
packages about to be installed (i.e. including dependencies)
right before the process of fetching/installing them is started.
* Add a handler for it which looks at PackagesToActivate and sets
all their PackageInfo states to pending (so now, when installing
a package, its dependencies immediately become pending as well).
* When a view is used with the layout system, its initial frame rect
was set to (0, 0, 0, 0), which is a BRect covering 1 pixel in the
top left corner of the window.
Since this a valid rect, it can cause "badly behaved" views to
trigger redraws of themselves and other views during the layout
process, which is ultimately the reason for the HaikuDepot UI
freezing while populating with packages.
The misbehaving view in this case is BTextView. When in read-only
mode, since commit e27a53b2, its GetHeightForWidth() implementation
causes the view to resize (really resizing, not just simulating a
resize) and thus it invalidates itself. This is broken behaviour,
and needs to be fixed in BTextView. Since GetHeightForWidth() is
called during the layout process, all the not-yet-layouted views
have a frame of (0, 0, 0, 0). The invalidation of just the one
BTextView in the layout then hits *all* new views that are being
layouted (because they all occupy the same one pixel in the
corner), and they all get redrawn.
Many view Draw() implementations ignore the update rect, so work
is being done. And even if not, this can cause a lot of traffic
on the app_server link. In a test case with HaikuDepot's
FeaturedPackagesView, adding 300 rows (each containing a BTextView,
among other views) in quick succession caused over 6 million
commands to travel over the app_server link, completely freezing
the UI for a long time.
* The actual problem here is in BTextView::GetHeightForWidth() and
must be fixed there.
However we also put in an extra-fix here because it never makes
sense anyway to try and draw a view that has not yet been layouted.
So we set the initial BView frame to an invalid rect
(0, 0, -1, -1), which will suppress any actual updating, even
when the view actively invalidates itself, as long it doesn't
have a size yet. (The dirty region will always end up empty
then).
* Fixes HaikuDepot UI freezing during package population (caused by
above described behaviour from BTextViews in FeaturedPackagesView).
Might improve performance in other applications using BTextView
with layouting as well.
* Fix use-after-free in the auto-generated JSON listener code (was
calling method of instance after 'delete this')
Will also submit a patch for the code generation script in the
haikudepotserver repo so it won't get lost -- this is just a
temporary fix-up until then.
* Fixes some random occasional crashes
* BarberPole view for indicating that the application is busy while
the amount of work is not known
* Flat looks with scrolling color stripes. Number of stripes and their
colors are freely configurable, so you could add a whole rainbow of
colors to endlessly scroll through if you like.
* When SystemProfiler::_MaybeNotifyProfilerThreadLocked() is called
and the conditions are right, it will lock the thread's scheduler
spinlock and unblock it. Internally, the unblock will enqueue the
thread into the run queue, which causes a ThreadEnqueuedInRunQueue
event for SystemProfiler. Since the conditions haven't changed, it
now went into _MaybeNotifyProfilerThreadLocked again (this time
from the profiler thread context). In there, it will try to lock
the profiler thread's scheduling spinlock, which is already locked
by the other thread (which is firmly sleeping). Deadlock, KDL.
* Before unblocking the profiler thread, unset fWaitingProfilerThread
so that further events will not try to unblock it again.
* Performance: on incoming package update messages, don't setup
all data in the PackageView from scratch again; instead, only
update the parts which were actually changed
