Looks good to me. Thanks!

Looks nice to me too! You could probably use icons in a lot of those buttons - that could help to emphasise the informational elements of the popover.

I guess Pause and Stop icons would be universally-recognizable.

To be honest I think there are way too many buttons there. I'm not against obsoleting the downloads bar per se (even though, in my recollection, it's only been introduced recently) but it is much more straightforward than this design, which is more like trying to be a complete download manager instead of a web browser.

Trying to be constructive: 
- Open file isn't necessary: Web opens downloaded files by default, which is nice
- Delete file isn't necessary, we have Files for that (see Show in folder)
- Show in folder is good, but since we only have one download folder, one instance of the button suffices.
- Completed downloads can just "expire" from the list once they no longer fit on the size of the widget
- I would just have one Cancel button per download, and one "Wipe / Clear" button that empties the entire downloads list (for privacy reasons).
- Pause buttons aren't necessary. If people are doing such large downloads they need to be able to pause them individually, they should be using bittorrent or similar anyway.

Created attachment 312110 [details]
Downloads GUI mockup v2

Changelog:

Modified 'Download' Button progress indicator to match GTK progress indicador.
Changed some buttons to be similar to Files's Files Operations Dialog.
Removed unneeded actions and informations.
Changed 'Completed Downloads' behavior.

Note that we don't support pausing/resuming downloads. I like the mockups, and when I saw the new nautilus file operations progress UI, I thought something similar could be done with the ephy downloads. This has the same problem of the current UI regarding scalability, this is much better because it grows vertically, but a huge popover wouldn't look that good either. So, I think we should try to fit as much downloads as possible in the minimum space, I would probably remove the global progress, the icon already provides a global progress feedback even if it's not so detailed. And also because of the scalability, I think this is great to replace the current downloads bar, but we still need an about:downloads handler. The popover could have two buttons: open downloads and open downloads folder. But for now this is a huge improvement over the current downloads bar, so about:downloads shouldn't block this at all.

(In reply to Carlos Garcia Campos from comment #6)

> This has the same
> problem of the current UI regarding scalability, this is much better because
> it grows vertically, but a huge popover wouldn't look that good either.

It should be scrollable.

> So, I think we should try to fit as much downloads as possible in the minimum
> space, I would probably remove the global progress, the icon already
> provides a global progress feedback even if it's not so detailed.

I did. Look mockup v2.

> And also
> because of the scalability, I think this is great to replace the current
> downloads bar [...]

That's the idea.

> [...] but we still need an about:downloads handler. The popover
> could have two buttons: open downloads and open downloads folder. But for
> now this is a huge improvement over the current downloads bar, so
> about:downloads shouldn't block this at all.

> Note that we don't support pausing/resuming downloads.

I was thinking:

How about a service, that knows how to download everything, and can be consumed by other applications?

Would be something like the GNOME Transfers, but headless. So:

- Web could use it to manage Torrent downloads.
- Files could use it to show this same 'Downloads in Progress' Widget as Web.
- Transmission could use it to manage HTTP downloads (and serve as a Full UI to download management).
- Shell could use it to show a warning about downloads in progress on Shutdown/Logoff.
- All of the 'clients' would share the same 'engine'.
- All of the 'clients' would show the same downloads.
- And more...

(In reply to Diogo Campos from comment #7)

> How about a service, that knows how to download everything, and can be
> consumed by other applications?
> 
> Would be something like the GNOME Transfers, but headless. So:
> 
> - Web could use it to manage Torrent downloads.
> - Files could use it to show this same 'Downloads in Progress' Widget as Web.
> - Transmission could use it to manage HTTP downloads (and serve as a Full UI
> to download management).
> - Shell could use it to show a warning about downloads in progress on
> Shutdown/Logoff.
> - All of the 'clients' would share the same 'engine'.
> - All of the 'clients' would show the same downloads.
> - And more...

IIRC someone spent a whole Summer of Code on this, but the result never went into production.

The new mockup is much better, btw!

(In reply to Diogo Campos from comment #5)
> Created attachment 312110 [details]
> Downloads GUI mockup v2

Looks nice! I think you can probably simplify it more, though! The headings don't seem necessary. You can already see that there are two active downloads, for example, so why restate that same information?

Likewise, maybe the best way to present a completed download is simply a progress bar that is filled?

A hint: a repeated visual pattern is easier to read than varied layouts.

Created attachment 312131 [details]
Downloads GUI mockup v3

Changelog:

Defined the behavior of the 'Downloads Button'.
Declared that the widget can be scrolled.
Removed unnecessary headings.
Squeezed remaining informations a bit more.
Moved 'Open Download Folder' button to the top of the widget and pinned it there.

Created attachment 312477 [details]
Screenshot

I've started to play with this. This is a screenshot of what I have so far, there are still many things to do, and a I'll need designer who knows how to deal with the CSS and pixels, but the main functionality is there. There's an action button, that allows you to cancel the download when it's active, or to open it in the container folder when it has finished. The thing is how to implement the open action. The current UI does it when clicking on the main button, or using the popup menu. How could we do it now? I thought about making the filename label a button, for example, but it wouldn't be obvious it's clickable (unless we don't use a flat button, but then it wouldn't look good, probably). Ideas are welcome. Some more comments about differences with the mockups and the current code as well:

 * In the current UI, downloads are closed (removed from the downloads bar) when an action is done (open or open in container folder). That's mainly because of the scalability limitation. Now, only cancelled downloads are removed form the list. We should probably add a global button to clear the downloads list, and maybe a way to also remove individual downloads from the list.

 * I'm using a open in folder button for every download instead of a global open downloads because the current open in folder action is very convenient. It opens nautilus and the downloaded file is already selected, so you don't need to find the download in the folder.

 * The list only tracks the downloads started in the session, like we currently do. Showing all the files in the downloads folder as completed downloads is not a good idea for several reasons. The folder might be shared with other browsers, so we would see downloads that are not ours. The list could be too long initially, with content hidden. Privacy might also be exposed somehow if there's something in the downloads dir that doesn't belong to ephy (I use /tmp as downloads folder, for example).

I think that's all.

It looks great.

(In reply to Carlos Garcia Campos from comment #12)
> There's
> an action button, that allows you to cancel the download when it's active,
> or to open it in the container folder when it has finished. The thing is how
> to implement the open action. The current UI does it when clicking on the
> main button, or using the popup menu. How could we do it now? I thought
> about making the filename label a button, for example, but it wouldn't be
> obvious it's clickable (unless we don't use a flat button, but then it
> wouldn't look good, probably). Ideas are welcome.

Get rid of the open in current folder functionality, and make the open button simply open the file?

> Some more comments about
> differences with the mockups and the current code as well:
> 
>  * In the current UI, downloads are closed (removed from the downloads bar)
> when an action is done (open or open in container folder). That's mainly
> because of the scalability limitation. Now, only cancelled downloads are
> removed form the list. We should probably add a global button to clear the
> downloads list, and maybe a way to also remove individual downloads from the
> list.

Maybe we would not need those buttons, at least not as much, if we sort the list into ongoing and completed downloads. Ongoing downloads are always on top, and when a download finishes, it moves to the top of the completed downloads.

(In reply to Michael Catanzaro from comment #13)
> It looks great.
> 
> (In reply to Carlos Garcia Campos from comment #12)
> > There's
> > an action button, that allows you to cancel the download when it's active,
> > or to open it in the container folder when it has finished. The thing is how
> > to implement the open action. The current UI does it when clicking on the
> > main button, or using the popup menu. How could we do it now? I thought
> > about making the filename label a button, for example, but it wouldn't be
> > obvious it's clickable (unless we don't use a flat button, but then it
> > wouldn't look good, probably). Ideas are welcome.
> 
> Get rid of the open in current folder functionality, and make the open
> button simply open the file?

No, open in folder is what allows us to not add other features. For example, "open with", you can open nautilus and do whatever nautilus can do with the file. For the same reason we don't ask what to do with a download anymore, it's always downloaded to the configured folder, and then you can do whatever you want. The open functionality is just a convenient shortcut for open in folder and double click, based on the fact that opening the download is the most common operation.

> > Some more comments about
> > differences with the mockups and the current code as well:
> > 
> >  * In the current UI, downloads are closed (removed from the downloads bar)
> > when an action is done (open or open in container folder). That's mainly
> > because of the scalability limitation. Now, only cancelled downloads are
> > removed form the list. We should probably add a global button to clear the
> > downloads list, and maybe a way to also remove individual downloads from the
> > list.
> 
> Maybe we would not need those buttons, at least not as much, if we sort the
> list into ongoing and completed downloads. Ongoing downloads are always on
> top, and when a download finishes, it moves to the top of the completed
> downloads.

I thought about that too, but then I realized that, at least for me, it's important to keep the order in which the downloads were requested. We also avoid dancing when multiple downloads start to finish, things that are visible can become hidden, etc.

Created attachment 312527 [details]
Downloads GUI mockup v4

Changelog:

Added two buttons, one state, and some information.
Changed 'Completed Downloads' behavior.

Comment on attachment 312527 [details]
Downloads GUI mockup v4

I don't think that remove icon is very recognizable... it probably needs to be the x icon. You could use a square (stop) icon to cancel an ongoing download?

(In reply to Michael Catanzaro from comment #16)
> I don't think that remove icon is very recognizable...

Yeah, they are just ugly-handmade-placeholder icons. Must be replaced. I'm not familiar with the 'GNOME Icon Set'.

> it probably needs to
> be the x icon. You could use a square (stop) icon to cancel an ongoing
> download?

Makes sense. And is consistent with the Nautilus's files progress dialog.

You can 'sudo dnf install gtk3-devel' and then run gtk3-icon-browser

(In reply to Michael Catanzaro from comment #18)
> You can 'sudo dnf install gtk3-devel' and then run gtk3-icon-browser

Cool, thanks.

(In reply to Michael Catanzaro from comment #16)
> Comment on attachment 312527 [details]
> Downloads GUI mockup v4
> 
> I don't think that remove icon is very recognizable... it probably needs to
> be the x icon. You could use a square (stop) icon to cancel an ongoing
> download?

I disagree. We are not stopping, but canceling the download, and it also has the effect of removing the download from the list, I wouldn't expect a stopped download was removed from the list. That's why I'm using the X (close) icon, which is consistent with nautilus. The remove icon should be the - (minus) one, I think, making it clear that we are removing it from the list, but not deleting the downloaded file at all.

(In reply to Diogo Campos from comment #17)
> (In reply to Michael Catanzaro from comment #16)
> > I don't think that remove icon is very recognizable...
> 
> Yeah, they are just ugly-handmade-placeholder icons. Must be replaced. I'm
> not familiar with the 'GNOME Icon Set'.
> 
> > it probably needs to
> > be the x icon. You could use a square (stop) icon to cancel an ongoing
> > download?
> 
> Makes sense. And is consistent with the Nautilus's files progress dialog.

In nautilus the X icon cancels the operation, it doesn't removes it from the list.

(In reply to Diogo Campos from comment #15)
> Created attachment 312527 [details]
> Downloads GUI mockup v4
> 
> Changelog:
> 
> Added two buttons, one state, and some information.
> Changed 'Completed Downloads' behavior.

Thanks for the updated mockup. I'm still not sure about having two sections, completed and ongoing downloads, I usually schedule several downloads and the same time and then I process them. What I expect in that case is that the order of the list is the order in which I requested the downloads, not what it finished first. We also avoid the dancing of the downloads when something completes. 
And regarding the popup when there aren't downloads, I forgot to mention that the downloads icon is initially hidden. It's revealed when the first download starts (we will add a needs-attention thing) and hidden again when the list is empty. Again, this is consistent with nautilus.

(In reply to Carlos Garcia Campos from comment #21)
> (In reply to Diogo Campos from comment #17)
> > Makes sense. And is consistent with the Nautilus's files progress dialog.
> 
> In nautilus the X icon cancels the operation, it doesn't removes it from the
> list.

Oops, my bad. You're right.

Created attachment 312561 [details]
Screenshot with open action and clear button

What about something like this? I've added a title with the clear button, that removes completed or failed downloads from the list. And for completed downloads there's a second button with the open action.

What I don't like about the two icons is that the popover grows horizontally when the first download finishes. We could simply add any additional actions to a context menu, that way we could allow to remove individual downloads from the list and other actions like copy url address.

Maybe we could use a GtkListBox that would make the whole download widget activatable to do the open action. Not sure about the performance of GtkListBox, though

Created attachment 312568 [details]
Downloads GUI mockup v4 (more options)

(In reply to Diogo Campos from comment #27)
> Created attachment 312568 [details]
> Downloads GUI mockup v4 (more options)

To be clear: this is just a bunch of elements/options put together and visually organized.
Carlos can pick the ones that makes sense to him, if any.
Until now, I'm just against keeping the progress bar in the completed downloads.

(In reply to Carlos Garcia Campos from comment #26)
> Maybe we could use a GtkListBox that would make the whole download widget
> activatable to do the open action. Not sure about the performance of
> GtkListBox, though

I wouldn't worry about performance. If it works for a list of every keyboard layout or every locale, it can work to list the stuff you've downloaded since you last closed the browser....

mcatanzaro:  aday: https://bug755382.bugzilla-attachments.gnome.org/attachment.cgi?id=312561 <-- Thoughts (Epiphany downloads bar replacement)?
nacho__:  mcatanzaro, in firefox you have a button to show the downloads folder
nacho__:  I mean to show all the downloads
mcatanzaro:  nacho__: One of those buttons along the sides does that (it's a per-download button since it also selects the download in nautilus)
mcatanzaro:  tbh I am not sure which open button does that, and which actually opens the file, though D:
nacho__:  mcatanzaro, so what if you have 100 downloads? you will just put a scrollbar there?
nacho__:  it is not very easy to navigate them though
grawity:  you mean "Show All Downloads", which opens Firefox's "Places" window?
mclasen:  ...need resizable popovers...
mcatanzaro:  nacho__: Yeah, it would have a scrollbar, but we don't need to optimize for 100 downloads, because normal people close their web browsers every once in a while
– jrb has joined the room
nacho__:  mcatanzaro, just a way to quickly go to the folder in nautilus I guess
mcatanzaro:  And the current downloads bar can only handle about 5 downloads (depending on the length of the filename) before the browser starts requiring ridiculous amounts of horizontal space. :p
mclasen:  mcatanzaro: maybe making the icon on the left a button would avoid the 'which of the circular buttons opens the file, and which opens the folder?' confusion
mcatanzaro:  Maybe, or making the whole row a button... Carlos was thinking about using GtkListBox....

Created attachment 312574 [details]
Screenshot using a GtkLisBox

Also removing the progressbar on completion

This certainly should have been done before. Anyway, better late than never:

# Downloads GUI Goals

## Primary goals (actions):

- Show/Hide list of downloads (of the current session, or of all sessions?).
- Start a download.
- Pause/Continue a download.
- Cancel/Restart a download.
- Pause/Continue all downloads.
- Cancel/Restart all downloads.

## Primary goals (informations):

- List of downloads should adapt and behave well to any amount of downloads.
- Show status of a download.
    - Started.
        - Amount completed.
        - Remaining time.
    - Paused.
        - Amount completed.
    - Canceled.
    - Completed.
- Show status of all started downloads.
        - Amount completed.
        - Remaining time.
- Easily differentiate between statuses.

## Secondary goals (actions):

- Open a completed download.
    - With App 'X'.
    - With App 'Y'.
    - With App 'Z'.
- Move a completed download.
- Delete a completed download.
- Show a completed download in the file manager.

Let me know what you think.

(In reply to Diogo Campos from comment #32)
> This certainly should have been done before. Anyway, better late than never:
> 
> # Downloads GUI Goals
> 
> ## Primary goals (actions):
> 
> - Show/Hide list of downloads (of the current session, or of all sessions?).

We only track downloads of current session. If we ever track downloads persistently, it should be part of the history, I think, and it would use a different UI.

> - Start a download.
> - Pause/Continue a download.

Not supported by WebKit (yet).

> - Cancel/Restart a download.

I'm not sure about this. Why would you want to cancel and restart the same download? I guess you can click again on the downloads link to restart it?

> - Pause/Continue all downloads.

Not supported by WebKit (yet).

> - Cancel/Restart all downloads.

Not sure about this either.

> ## Primary goals (informations):
> 
> - List of downloads should adapt and behave well to any amount of downloads.
> - Show status of a download.
>     - Started.
>         - Amount completed.
>         - Remaining time.
>     - Paused.
>         - Amount completed.

Not supported by WebKit (yet).

>     - Canceled.

In the current code cancelled downloads are removed from the list, we are interested in downloads that are active (to see the progress), completed (to perform an action) or failed (to know what happened).

>     - Completed.
> - Show status of all started downloads.
>         - Amount completed.
>         - Remaining time.
> - Easily differentiate between statuses.
> 
> ## Secondary goals (actions):
> 
> - Open a completed download.
>     - With App 'X'.
>     - With App 'Y'.
>     - With App 'Z'.
> - Move a completed download.
> - Delete a completed download.
> - Show a completed download in the file manager.

This last option allows you to do all others (and more), and nautilus does it much better than us. That's why open in containing folder is the main action together with opening the downloaded file (in the default app).

> Let me know what you think.

Created attachment 312750 [details]
Screenshot progress icon

I've added the progress icon, similar to the nautilus one, but using an arrow instead of a pie chart. I'll clean up the code and submit patches (or a branch) so that everybody can try it out.

Branch wip/downloads created

https://git.gnome.org/browse/epiphany/log/?h=wip/downloads

Please, let me know any issues you find. I think there aren't regressions in terms of functionality compared to the current code. Work left to do is mainly design stuff that I don't know how to do:

 - Add CSS code to implement the need attention for the downloads button.
 - Check all the pixels I hardcoded (margins, paddings, spacings, etc.). Most of them are copied from nautilus.
 - Make the GtkListBox background the same color than the popover.
 - Improve the popover header, the downloads title and clear button.
 - Any other suggestions would also be welcome, of course.

Looks good.

The Clear button should be insensitive if no inactive downloads are present.

(In reply to Michael Catanzaro from comment #36)
> Looks good.
> 
> The Clear button should be insensitive if no inactive downloads are present.

Fixed in the branch

If nobody objects I'll merge the branch in master soon. We can improve the design details afterwards in master.

Go for it

Merged

At least, this adds "gtk_label_set_xalign" which bumps ephy deps to GTK 3.16

(In reply to Carlos Garcia Campos from comment #38)
> If nobody objects I'll merge the branch in master soon. We can improve the
> design details afterwards in master.

And in other bugs.

(In reply to Andres Gomez from comment #41)
> At least, this adds "gtk_label_set_xalign" which bumps ephy deps to GTK 3.16

Thanks for noticing; I will fix the requirement in configure.ac.

(In reply to Michael Catanzaro from comment #42)
> And in other bugs.

Well, the idea was that these bugs would be "live/continuous/rolling/etc" (especially because of all of the "picked, linked and monitored dependencies")...

But closing is also ok for me; of course.

(In reply to Diogo Campos from comment #43) 
> Well, the idea was that these bugs would be "live/continuous/rolling/etc"
> (especially because of all of the "picked, linked and monitored
> dependencies")...
> 
> But closing is also ok for me; of course.

Please, just file a new bug if you want other things changed. :)

I think adding dependencies on all related bugs was only helpful in that it helps us determine what bugs can be obsoleted now.