The websocket now notifies the ApiClient, on which several models and
items are listening, when the userData for an user has changed. The UI
on the qml side may automatically updates without any extra effort.
This also resolves a bug where videos didn't resume after +/- 3:40 due
to an integer overflow.
I finally got deserializing lists working. Exposing them to QML was not
a trivial task either. Note that I didn't do it the clean way. Nested
lists are not supported. But it works!
Because I got so frustarted at one point trying to implement things the
right way, I restructured the project to seperate the Sailfish code from
the Qt code and created a new, empty desktop project. The Qt code has
been transformed into a happy little library, to which the Sailfish OS
application links.
Note that QMake doesn't seem to strip the library for some reason.
* EpisodePage and FilmPage are now based off VideoPage, since they share a
lot of components in common.
* The overlay over the thumbnail in PlayToolbar is less obtrusive
* Cover shows now the title of the item, and total play time, if
applicable
* The resume playing section forces all delegates to be square.
* The Season page now uses a ListView instead of a ColumnView.
[Playback]: New: playback progress is reported to the Jellyfin server.
[Playback]: New: resume partly played items or start playing from the beginning if desired.
I also had to make some changes to the VideoPlayer, because the VideoHUD
got locked up when the player changed status from Buffering to Buffered
too quickly in succession, which occurs when trying to seek directly
after the application is able to.
Once again I couldn't stop myself from being sidetracked.
[Collections]: Added: allow specifying sort order (Ascending, Descending)
[General]: Improved: Added video fallback page to allow unknown video types to be played, although without extra metadata.
[General]: Improved: Added folder fallback, so unknown collection types are at least displayed without metadata.
Previously, Items were displayed in one page, named DetailPage.qml.
This page then would load a qml component, based on the page type. It
also contained some components common for each detail page, like
displaying the name of the item. This construction had as downside that
modifying the page properties, adding a pulley menu or basing the page
around a SilicaListview was not possible. So I already had created some
other pages.
The new construction uses a base page, named BaseDetailPage which does
set some common properties and handle the loading of the items, so that
that part does not have to be duplicated. Displaying the name of an item
was a very trivial thing to do, so duplicating that part across files
was not a problem. Anyway, the rest of the pages are now seperate, but
all have BaseDetailsPage as the root, so they can use the common
functionality by that page. Those subpages now can be based around
GridViews, Carrousels, have pully menus and so on. To determine to which
page to go to, based on the content type, a function named getPageUrl
has been added to Utils.js, which takes a content type as argument and
gives the page url back.
Apparently the Jellyfin server may include different fields in the
resposne depending on which SortOrder you use. This causes the model to
generate new roleNames when changing its sortOrder, but the QML part
does not know of this happening and there's no way of notifying the QML
part as far as I'm aware of (if so, let me know). So whenever new
generateFields() is called, it shouldn't reset its roleNames map and
recreate it anew, rather, just append the new roleNames to the current
map. If a model in QML wants to use information used in fields which are
added by changing SortOrder, please add those fields explicitly in
Fields.
* There is a basic collection page, allowing the user to browse through
collections. It has a sort function, that sort of works
* Item cards now show a bar indicating play time
* Item cards now have a black/white (depending on theme) shim, improving
readability.
* The resume watching section now actually loads items
* Pressing the logout button now brings the setup page up again
* Removing a server and readding one of which the hash of the address
has a higher value than the previous one does no longer cause the
application to request a login each time you open it.
* The method for deciding if the user is in setup has been changed. It
now checks if a page in the pageStack has the property _isSetupPage,
which works better than manually keeping track of state.
Features so far:
- Login is working, both on back-end and GUI-wise
- Saving and reusing login tokens is working
- The home page is mostly functional
- Show details can be received and displayed in a basic manner
Following features are taken into account, but have not been fully
implemented:
- Support for multiple accounts/servers
- Securely saving login tokens
Chris Josten