Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move progress tab into channel list #938

Closed
wants to merge 1 commit into from

Conversation

Johennes
Copy link
Contributor

As discussed in #878, this eliminates the top-level GtkNotebook and
moves the "Progress" tab into a dedicated item in the channel list.

Eliminating the notebook gives slightly more vertical space to the
content which is beneficial when using gpodder on mobile devices. In
addition, without the wrapping notebook it'll get easier to implement
an adaptive UI that dynamically switches between the left, right and
both panes in the future.

The progress status previously shown in parentheses in the tab title
was moved into the tree view row's subtitle. The proxying of the
progress item in the channel list follows the existing approach used
for the "All episodes" item.

Here is a screenshot of how the UI looks with this PR applied:

progress

Please note that this is my first meaningful PR for gpodder so I probably did quite a few things wrong. I'd be very grateful for candid feedback and thorough testing. 馃檪

<property name="scrollable">False</property>
<property name="enable_popup">False</property>
<signal handler="on_wNotebook_switch_page" name="switch_page"/>
<child>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I intentionally didn't change the indentation on any existing lines to not bloat the diff and keep it easy to rebase. I can re-indent everything before this gets merged.

@elelay
Copy link
Member

elelay commented Dec 29, 2020

Reusing the episode list area for progress is neat.
I don't like to access it via an item in the podcast list: progress is not a channel nor an agregation (All episodes).

Do you use the toolbar on your phone? If so, maybe a button there would make more sense.
If not, what about a widget below / replacing the Refresh button?

@Johennes
Copy link
Contributor Author

Do you use the toolbar on your phone? If so, maybe a button there would make more sense.

I think I only enabled the toolbar for testing in the screenshot. I most likely would not want to use it on a mobile screen because it doesn't scale well (meaning it'd need scrolling or some overflow menu concept when there are too many items inside of it). Also, part of the reason for eliminating the notebook was to free up some vertical space which the toolbar would eat away again. 馃槄

If not, what about a widget below / replacing the Refresh button?

That actually sounds like a good idea to me. We could add a "Progress" button below "Check for new episodes" and make it open the progress UI in the right pane. That would also avoid the hacks to get the progress item into the channel list. The only thing to figure out would be where to show the status (e.g. "1 active"). That was the original motivation for putting it into the channel list because there we can just use the row's subtitle.

@elelay
Copy link
Member

elelay commented Dec 29, 2020

Also, part of the reason for eliminating the notebook was to free up some vertical space which the toolbar would eat away again.

totally agree but t was worth a shot ;-). Some phone apps do propose small icons on top as a means of navigation overcast.

The only thing to figure out would be where to show the status (e.g. "1 active")

maybe download icon + "progress" if nothing going on and download icon + "1 active" if something going on ? or badges + tooltip ?

@Johennes
Copy link
Contributor Author

Ok, I switched things around so that the progress pane is activated via a dedicated button in the lower left.

progress

Gtk doesn't seem to have a stock download icon so I left the button label in the form "Progress (1 active)" for a start. I'm not sure if depending on the language we might run into horizontal size problems here.

When you said "badges", were you thinking of GtkNumerableIcon?

@auouymous
Copy link
Member

I don't agree with putting progress in the toolbar because it wouldn't be visible for anyone not using the toolbar (desktop or mobile). And everything in the toolbar can be accessed from elsewhere in the UI.

Does a button increase its height if the text doesn't fit, such as "Progress (1 active, 1 queued, 1 failed)"? My channel list is even narrower than the one in the screenshot, and would fill or overflow the button with only two status types. Maybe put the status in a label above or below the progress button, and hide it when empty.

I don't know which location would be better, but the progress button+label could also sit above the channel list. It would be in the same location it currently is to avoid upsetting anyone who actually uses it much. And would move it away from the update button to avoid upsetting anyone who clicks it a lot and now has to dodge a new button down there. But the update button does change to a progress bar when updating feeds, and having both "progress" widgets together makes sense. Or it might cause confusion having them together when someone sees the feed update progress bar and clicks the progress button next to it to see why the bar has stalled on a feed. The status message might also contain previous failures causing the user to think a feed has failed during update. Maybe rename it to "Episode Progress"?

Does the update button have an icon? The progress tab didn't have an icon, no reason the button needs one.

@Johennes
Copy link
Contributor Author

Does a button increase its height if the text doesn't fit, such as "Progress (1 active, 1 queued, 1 failed)"? My channel list is even narrower than the one in the screenshot, and would fill or overflow the button with only two status types. Maybe put the status in a label above or below the progress button, and hide it when empty.

Out of the box, the button seems to just grow horizontally as the label gets longer. It looks like it's possible to access the label inside the button to adjust wrapping and justification though. We could achieve a subtitle effect like this:

subtitle

I'm not sure if it'd feel odd when the button height suddenly grows though. Maybe a separate label below the button, also with small font, would be better than putting it into the button?

I don't know which location would be better, but the progress button+label could also sit above the channel list. It would be in the same location it currently is to avoid upsetting anyone who actually uses it much. And would move it away from the update button to avoid upsetting anyone who clicks it a lot and now has to dodge a new button down there.

Hm, that's an interesting idea. Personally I feel like having the progress button above the channel list would give it too much prominence. It might also feel a bit unintuitive to have one button at the top, one at the bottom and the scrollable list between them. On the plus side, this would nicely separate the two buttons though. Here's how it would look:

ontop

I think I'm leaning towards having the "Progress" button in the bottom and the optional status in a separate small label below it. What do you folks think?

@tpikonen
Copy link
Contributor

I liked the first concept ('Progress' in the channel list) in this PR the best. Clicking a left pane item controls what is shown in the right pane, so IMO it's not so bad to have the item for showing download progress there.

As for the rest of the concepts, giving the largest button in UI to one of the least used features (at least for me) seems silly. But, unless this can be put only in the menu, there probably has to be a button.

I also don't like the title 'Progress'. 'Active downloads' or just 'Downloads' would be better. Or maybe 'Download progress' as a compromise :)

@Johennes
Copy link
Contributor Author

I also don't like the title 'Progress'. 'Active downloads' or just 'Downloads' would be better. Or maybe 'Download progress' as a compromise :)

Yeah, I personally find "Progress" a little irritating as well because that almost sounds like listening progress. "Download progress" could be a good compromise if we want to keep some resemblance to the tab title but just "Downloads" might be enough because the "progress" aspect becomes apparent through the 1 active, ... label.

@auouymous
Copy link
Member

"Download progress" makes sense, and a status label would probably look nicer than a taller button, especially on a theme were the button background isn't the same color as the window.

Someone mentioned this before, but the button should probably open a dialog instead of opening in the right pane. The update button opens a dialog when there is something to download, and it makes sense for the progress button to do the same. It also avoids squishing the progress widgets into a narrower right pane.

@auouymous
Copy link
Member

"Downloads" might be enough because the "progress" aspect becomes apparent through the 1 active, ... label.

What about when there is no status message...

I liked the first concept ('Progress' in the channel list) in this PR the best.

That was a bad idea I didn't put much thought into. Right now my gpodder has no episodes and is displaying a "No podcasts" label in place of the channel list. The progress item (and the settings on the progress page) wouldn't be accessible when there are no episodes.

As discussed in gpodder#878, this eliminates the top-level GtkNotebook and
moves the "Progress" tab into the right pane. Switching between the
episodes pane and the progress pane is achieved via a dedicated button
at the bottom of the left pane.

Eliminating the notebook gives slightly more vertical space to the
content which is beneficial when using gpodder on mobile devices. In
addition, without the wrapping notebook it'll get easier to implement
an adaptive UI that dynamically switches between the left, right and
both panes in the future.
@tpikonen
Copy link
Contributor

tpikonen commented Jan 1, 2021

The latest version looks and works fine, but I would agree with @auouymous that if there is a button to open the download progress, it should open into a separate non-modal dialog. I think there should also be a menu entry in the 'Podcasts' menu, after 'Download new episodes'.

@Johennes
Copy link
Contributor Author

Johennes commented Jan 1, 2021

I like the dialog idea, too. Will need some more time to put this together because it'll require a few things to be disentangled.

@auouymous
Copy link
Member

@elelay Are you okay with this before @Johennes spends more time moving the progress tab to a dialog?

@elelay
Copy link
Member

elelay commented Jan 5, 2021

First a reminder that Progress is also showing Sync to device tasks, hence the generic name.

It's a good point that progress area is made smaller by only having the episode area.
What about keeping the notebook but hiding tabs (equivalent to using to a GtkStack)?

Now how do we navigate? Here is a suggestion using the toolbar:
in_toolbar
I added two toggle buttons in the beginning of the toolbar to control which tab is shown.

Maybe we could go with only the Progress button.
single_button

Also I've tried shortening the Progress status by using arrow, exclamation mark, dots and color. The full status would be in a tooltip.

What about people hiding the toolbar? Then we add a button to the left pane as proposed.

@auouymous
Copy link
Member

Sounds good to me. The notebook has a border and margin, is it possible to hide that?

@elelay
Copy link
Member

elelay commented Jan 5, 2021

Sounds good to me. The notebook has a border and margin, is it possible to hide that?

switching to a GtkStack will do this.

@Johennes
Copy link
Contributor Author

Johennes commented Jan 5, 2021

What about keeping the notebook but hiding tabs (equivalent to using to a GtkStack)?

Hm, that could work as well. We could maybe integrate the button to switch to the progress view into the header bar (when it's shown) so that you can switch without the toolbar on mobile.

@elelay seems like you may have this change in a POC state locally already? Do you want to take this over entirely or would you want me to make those changes in this PR?

@elelay
Copy link
Member

elelay commented Jan 5, 2021

@Johennes I've pushed the POC as poc-no-tabs but it's not ready yet. Feel free to experiment on it or merge with your branch for the progress button, visible when no toolbar.

Still open questions:

  • shall we remove the Podcasts button (needs self.toolShowPodcasts.set_active(page_num == 0) commented out in main.py)?
  • how to return from downloads if toolbar is hidden (add a button to the left of rate limiting?)?
  • should show tabs be an option in the view menu?

@auouymous
Copy link
Member

Placing the progress button in header bar would also work, as long as it hides when toolbar is visible and it is in the lower left corner of header bar. Moving it away from lower left corner would put it in an inconsistent location with the other options.

Does a GtkStack have tabs or would the show tabs option change it to a GtkNotebook?

Getting out of the progress page is a bit of an issue. A back or podcasts button would work but placing it at the bottom is not a common UI choice. Placing the "back" button at the top would waste vertical space, at least for "normal" mode, headerbar/toolbar could replace the progress button with a back button, and show tabs wouldn't need the button. This seems like a mess and it might be better to just open a dialog, and not have a show tabs open.

@Johennes
Copy link
Contributor Author

One thing I just realized is that we didn't only want to eliminate the notebook to save the vertical space that the tab titles occupy but also because it didn't seem to play well with the "Leaflet" widget in libhandy. The leaflet is like an adaptive stack. It shows both widgets (podcast list and details) when there is enough space and only one of them when the window is too narrow.

@thp
Copy link
Member

thp commented Jan 15, 2021

GNOME3 applications with CSD/Header Bar do have "tab buttons" in the header bar, which might be an option that would fit well:

@Johennes
Copy link
Contributor Author

Discarding this since the adaptive branch is now available in this repository (see #878).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants