603bb1c...
by
Joaquim Rocha <email address hidden>
Go to the overview mode by default before activation
The overview mode is the default one but was only being set when the
user opens GNOME Software (even if it was already running). This patch
sets that mode right after the loading is finished on start up, as a
consequence, the start up is a bit slower, but the user sees the
overview right away which makes it looks faster.
9dbfd0e...
by
Joaquim Rocha <email address hidden>
Do not go back into the loading state
When GNOME Software is launched with a CLI option like --details or
--install, and the user clicks the back button in the UI, it should
not go back to the loading mode. Instead, it should go to the overview
mode.
050c0b8...
by
Joaquim Rocha <email address hidden>
Fix app creation from the plugin loader
Plugins like the Flatpak one use their own specialized type of GsApp.
However, when apps are created using the plugin-loader's app creation
function, they will be regular GsApps and thus incompatible with the
mentioned plugins.
In order to fix this, this patch first creates the GsApp as usually,
then it checks if a plugin wants to adopt it, and if there's one that
does, it will re-create the app using the plugin's app creation function
instead. This is not very efficient but with the current architecture
design, we need to do it like this.
67b6f6e...
by
Joaquim Rocha <email address hidden>
Activate certain actions only after the loading-state finishes
Some of the CLI options (like --details and --install) need the plugins
to have loaded the info about their apps, that is, they need the
loading-state to be finished before they do anything that uses apps.
This patch accomplishes that by separating the mentioned actions into
a different map, and setting up "wrapper" actions in the application
instead. Whenever these wrapper actions are called, they will call the
real ones after loading-state is finished, or right-away if it is
already finished.
1e1152f...
by
Joaquim Rocha <email address hidden>
Call the UI initialization on start up
Since all the options already initialize the UI, and have to make sure
that this is called only once, then it makes the code easier and more
readable if we just move the UI initialization inside the "startup"
method of GNOME Software's GApplication. This way we skip having to
keep track of whether it's been done (because the startup method occurs
only once) and skip having to call the same function in every "action
activated" callback.
3c6bb0d...
by
Joaquim Rocha <email address hidden>
Set the loading state when initializing the UI
The loading-state is necessary to make sure that plugins are correctly
refreshed when GNOME Software is launched, as it is in refresh time that
usually plugins load their app catalogs and other resources needed
during their regular use.
However, currently only the normal activation (on CLI options) of the
GNOME Software is calling this loading-state. As a result, options
like --details and --install are not working.
To fix that, these changes move the call for the loading-state to the
function that intializes the UI. Since all of the CLI options initialize
the UI, then we make sure that the loading-state is called for every
option.
