The type of the widgets is already a Button so there's no need in
repeating that in the struct field.
Also remove some type annotations since the compiler can infer them
from the type of the struct fields.
I strongly believe that these do not belong there and should be moved
elsewhere. But for the time being and prototyping they are "good enough".
People most of the time tend to import from an OPML file only on the first
use of the App. Then the functionality sits there and is never used again.
That's why I think import should be moved into a preferences dialogs and
have the empty view suggest the action.
Exporting OPML files is also not that common, I also believe this should be
moved into a preference dialog instead of the hamburger menu.
When you just update/replace the widget there is no need for an animation
to occur. Thus why animations where broken before. This commit is not ideal
as it makes it the responsibility of the caller to declare valid(UX wise)
transitions.
This code is ugly and terrible but it works™. Previsously when a download
would finish it would refresh all the views. Now the if the widget get's
into the Donwloading state, it will setup a callback that will check
periodicly if it's still downloading and update the widget state when
the episode stops downloading.
This commit reimplements support for the empty view in the ShowStack.
The current structure is the following:
* A Content stack which holds the HomeStack and the ShowStack.
It's what is used in the headerbar StackSwitcher.
* The HomeStack is composed of the HomeView and an EmptyView.
* The ShowStack is composed of the PopulatedStack and an EmptyView.
* The PopulatedStack is composed of the ShowsView and the ShowWidget
currently. An AboutEpisode widget is planned to be added here also.
This removes the empty widget from the ShowStack. The plan is
to have a ShowsView which will be the parent of ShowStack and
an Empty Widget. Then make ShowStack have only valid populated
states of ShowsPopulate, ShowWidget and AboutEpisodeWidget later.
For now the methods are private and migth not be neccesarry,
but it will be much easier to manipulate the stack from outside
with this API if it's needed and the methods are made public.
Since gtk Widgets are not Send, and the callbacks all run in the gtk
main loop, it *should* not be possible that 2 things try to access the
same widget at the same time.
It was only used to call the podcast.id() method. This allows EpisodeViewWidget
to be created whithout the need for a call to the database to get a Podcst
Object for each widget.
Jordan Petridis
Ivan Augusto