Show the summary instead of the version. The layout still sucks, but I will
have to implement some kind of row/flow BLayout to get what I initially had
in mind. Another TODO is to highlight the clicked item somehow.
* Rework existing package listener mechanism to report any interesting
changes. Listen for prominence changes in addition to package state.
* Add featured packages to the FeaturedPackagesView when their prominence
is retrived, and also in _AdoptModel().
* In _AdoptModel(), show the featured packages view when no search filters
are active and installed packages are not shown either. Otherwise show
the list of all packages matching the current filtering.
...into MessagePackageListener and OnePackageMessagePackageListener.
The first one doesn't know which package(s) it's listening to. But it
can filter the change notifications now and only react to certain changes.
The second one knows which package it's listening to.
Not yet visible. But the package list area in the main window has a card
layout now and a second (hidden) page for featured packages. Which packages
are visible there will depend on the prominence value from the web-app
and other parameters later (suggestions based on packages already installed
and user-ratings). At the moment, there is no mechanism for updating the
package list when package info is retrieved asynchronously, even from the
cache. Also, the view should switch to the list when searching and perhaps
in other situations as well, like selecting a category or when no packages
would be featured. And clicking featured packages does not yet select them in
the info area...
Currently a vertically scrollable container for views which are similar
to the title area in the package info view (and share most code, but it
will diverge later on). Untested and not yet used.
Package contents are scanned to find deskbar links. If a package has less
than four links, they will be offered in separate "Open <link name>" buttons
in the package info area. Usually, this results in one button to open the
main application from the package. If the heuristic proves to be not good
enough, this could be improved of course.
Note that double clicking a .hpkg in one of the packages folders will
not yet have a sensible result. I think it should open the regular
HaikuDepot with the full packages list, default to show installed packages
only and pre-select the package that was double clicked. It would be tricky
however if more than one installed package file is opened at once.
The idea is to parse packages for Deskbar links and offer to "open" them
once they are installed. The added functionality is not yet complete and
will eventually figure out the file system location of a package and parse
the contents. I am mainly pushing this since my git-foo is limited and
I want to push the fix for the discovered deadlock.
When the package list was refreshed while package info was still being
pulled from the web app, calling Model::Clear() with the model lock already
held could lead to a dead-lock: The package populator could block on the
model lock to update information, while StopPopulatingAllPackages() waited
for the thread to exit, but held the lock that the thread was blocking on.
So call StopPopulatingAllPackages() before grabbing the lock and calling
Clear() in MainWindow::_RefreshPackageList().
And move the (new) checkmarks into the Options menu. This makes them less
easy to discover, but cleans up the UI, especially since the options to show
development and source code packages are not very important for most users.
There is now a right-aligned second menu bar for the account management.
The menu label is what was previously shown underneath the search terms field.
The menu items have moved from the Tools menu into the new user menu. This
means the login/logout functionality is directly available where the login
info is shown in the UI when you click it.
* Give the PackageManager either the package name, or the path to a local
.hpkg package to Install().
* Implement Warn() to at least print something to the command line. Change
the TODO to show the warning to the user instead.
Consequently always register it with the solver in Init(). This solves the
problem that it made a difference at which time Init() is called. Init() is
called at the beginning of Install() and Uninstall(), but HaikuDepot was
calling it before that for other reasons. A second call to Init() will exit
early. If local package files were added to the PackageManager instance,
the local repository was created lazily, but because Init() did not run a
second time, the local repository was not registered with the solver. Now
it already is, since it is no longer created on demand, but always.
These errors do not necessarily need to be reported to the user via alerts.
They are more of an indication that HaikuDepot needs to be smarter when
figuring out what package actions to present at all.
* When opening .hpkg files, shows just the PackageInfoView in a smaller
window.
* PackageInfo constructor with BPackageInfo argument
* Default pkg icon has a single instance only. Before, there would be another
instance for each repository refresh.
TODO:
* Install button on single package view is non functional
* Probably needs to do someting different when opening .hpkg from an
installed packages folder (show the regular list and focus that package?).
* The filter view and list view are still constructed for the single package
mode.
* ...
The web service currently only synchronizes with HaikuPorts. Packages
from 3rd party repositories which were added by the user cannot be rated.
Also, use a warning alert for errors in the UserLoginWindow and
RatePackageWindow.
* There is now a flow of logging in or creating an account before being
able to rate a package and the user is not yet logged in. The
UserLoginWindow stores an "on success" BMessenger and BMessage which are
send after the alert which confirms successful login or account creation.
This is used to make the RatePackageWindow show once logged in successfully.
* The HTTP Basic authentication never worked. BHttpRequest.SetUserName()
and SetPassword() have no effect at all, unless there is a
BHttpAuthentication set for the given URL on the BUrlContext. This part
of the services API isn't very intuitive, yet.
* UpdateUserRating() forgot to append the "filter" array which specifies
to the web app which fields of the rating are updated by the request.
... in WebAppInterface. Both types of requests fail at the moment.
Creating a rating failes due to invalid authentication (I thought I am doing
it correctly), updating fails with a NullPointerException on the server.
... if there is one and fills the RatePackageWindow UI accordingly.
This will allow a user to edit her earlier rating for a given package.
The button labels will need to be adjusted. Uploading a rating still not
implemented.
* Store the username in the app settings. The password was already stored
in the keyring. Restore the username upon next launch.
* Display the logged in user in the main window.
* Added "Log out" menu entry.
* When the password could not be retrieved from the keyring (also because
the user rejects the keyring dialog), unset the username.
* Allow unsetting the username by passing an empty name.
For the time being, there is a limited amount of supported languages
when creating accounts, reflect this in the UI and use a BMenuField.
Creating accounts with other languages fails, the error reporting was
not ideal and could be improved. The server responded with "object not found",
which was reported in the alert, but the response actually contains the
object which was not found (NaturalLanguageCode).
* Added TODO to retrieve the list from the web-app, there is already an
API for it. For now, the hard-coded list matches the web-app's and the
next change in this regard will be to support any known language.
* Make the list accessible.
At the moment, the web-app has a defined, limited set of supported languages
for translations. JSON requests fail when asking for an unsupported language
code. For the time being, force the language code to be in the supported set.
... completely untested and premature. The idea is that after a successful
login with the web-app, the password used is stored in the keyring. Then
HaikuDepot will restore just last the used username on next launch and retrieve
the password from the keyring. One could also register multiple accounts in
HaikuDepot and switch between them.
UserLoginWindow:
* Focus nickname text field on tab switches
* Implement testing the login info, the web-app replies with a token, if
valid. It could be used for Token Bearer authorization of requests, but
this is not used yet. Instead the username and password are set on the
Model. Also after creating a new account successfully.
Model:
* Use a member instance of WebAppInterface. Set the preferred language
and the login-info only once.
The accounts are created for real, but the information is not yet stored.
Nothing which would need it is currently implemented, like rating packages.
It is recommended to create accounts with a valid email address. Otherwise
the password cannot be reset, and it will need to be soon, since there
is a small change to the password storage in the pipe.
The error response from the service is parsed and presented
to the user, when the account could not be created. However, other checks
before contacting the server are not performed, like if the two passphrases
actually match.
The UserLoginWindow now has the concept of a running worker thread, and
while it runs, the UI controls (except Cancel) are disabled.
* Increase the RAM limit to 128K per screenshot
* Reduce retrieved size to 320 pixel wide
* Don't expect to be able to read the stream in one call,
read it in 4K chunks.
* Print some errors in this code-path to stderr.
* The categories and other filter options are orthogonal. Don't
force the user to choose between real categories and for example
"installed" or "available" in the same drop-down. I've removed
(for now) the Options main menu. There are now four small check-marks
below the filtering drop-downs: Available, Installed, Development and
Source Code. These enable showing the respective packages in the list
view. Only "Available" is checked by default. This changes the default
behavior to show only not-yet-installed packages. This change puts
the filtering options in one place, the showing of development or
source code packages is not "hidden somewhere else" anymore. I am not
so happy with the additional row, however, I am also thinking about
using icons instead of the checkmarks.
* Fixed finding the suitable package translation for summary and
description. For example, WonderBrush now has a German translation.
Stephan Aßmus