When the `_onGetProjectsFirstPageFinished` is reached, the pagination manager already contains the correct pagination metadata and links, so calling `clear()` there resets them giving the impression that there is no next page.
This commit fixed that by calling the `clear()` function should when the search filter is applied, instead.
CURA-8009
When checking whether the user is allowed to create a new library project, we need to retrieve the **private** (aka non-shared) projects that are linked to the user's account. If the user has reached the maximum private projects, then they are no longer allowed to create new ones.
**Note**: We need to set the `pagination_manager` to `None` when doing this get request, or else the next/previous links of the pagination will become mixed up with the pagination links of the list of projects shown to the user, corrupting them and creating the wrong "get more projects" link.
CURA-8112
When the tooltip text is too long and the tooltip width ends up being longer than the window it is supposed to be drawn into, the tooltip is not drawn at all. This commit fixed that by allowing the tooltip width of the ActionButton to be changed within QML, limiting it to a certain size that fits the purpose.
CURA-8112
Instead of letting users go through the project creation process only to get rejected with a "subscription limits reached" message, now the "New Library project" button is being replaced with an "Upgrade plan" button when the maximum allowed projects have been reached for the specific amount. The button is accompanied by a tooltip that explains the situation to the user. Once clicked, the user is redirected to the subscriptions page.
CURA-8112
Instead of using the default of 5 pixels, we should use this element from the theme to match the margin around the page.
Contributes to issue CURA-8009.
Because this item is in a layout, the height gets overridden. We should use the preferredHeight, or the one it defaults to, implicitHeight.
Contributes to issue CURA-8009.
This adds an option to the TextField element to show an icon on the left side in the text field. The icon remains visible when the user types in something (it's not part of the placeholder string).
Then we use that optional icon for the search bar in the Digital Library.
Contributes to issue CURA-8009.
This is the standard style for text fields in Cura. The spacing around the search icon is customised with the best approximation I could get using a simple string of placeholderText.
Contributes to issue CURA-8009.
Most people should be able to type 5 characters per second. And those that can't will just have to see it refresh after every stroke.
Contributes to issue CURA-8009.
Otherwise when we refresh the project list after searching it would put the new results at the end. That's not what we want.
Contributes to issue CURA-8009.
This passes the filter on to the API call and causes the API call, so that we only get the projects that the user searched for.
Contributes to issue CURA-8009.
Seems to work fine.
The pyqtSignal is not technically necessary unless we display this filter in the interface anywhere. We don't currently. If the signal is not present it would complain about non-notifyable properties. And making it a slot instead of a signal seems a bit unintuitive to me in how the field is being used.
Contributes to issue CURA-8009.
Users with an account and an UM printer should have some basic access to the Digital Library. To this end, and to remain future proof, the online team has made an extension to its API so now feature budgets can be gauge. At the moment it's only checked wether the user has any access to personal projects at all. If so, the interface shows Digital Library functionality. Known issue: Removing the last printer from DF while still logged in leaves the DL access in the Cura interface until logged out or Cura restarted. Additionally, I think the response for a logged in user without any printer from the API is just 'data = empty list' instead of everything set to False and 0 (which should be the case as they're all listed as required fields in their docs ... maybe I'm missing something). In any case, the code as is now can handle that as well.
CURA-8138
We want to keep it this way so people can still make plugins work for older versions of Cura, like 3.6, where the 'api' field with just a single major version, instead of the 'supported_sdk_versions', which can be either a version-string like '7.6.0' or a list of version strings.