132109 - Download Manager should have a menubar

Status: RESOLVED FIXED

(SeaMonkey :: Download & File Handling, enhancement, P1)

Description

[Christian :Biesinger (don't email me, ping me on IRC)]

Every other Mozilla window has a menubar, only the Download Manager misses one. 
This is bad because a) You can't start other components from the Download
Manager and b) it's inconsistent

Comment 1

[Greg L.]

I agree.
I think this menu should be kinda like the JavaScript console menu bar (minimal
number of items). And I also think that there should be a menu for the currently
selected download containing all the elements suggested in bug 132019

Comment 2

[Ian Pottinger]

adding self to cc list

Comment 3

[Mike Lee]

Well I disagree, kind of. Right now its not possible, but I wish download
manager can appear in a tab. (way too many windows alread) If we do have menu
bar, that would look pretty rediclous. I wouldn't mind the menubar if an option
not to display it is offered.

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

Mike, eh, I suppose only very few users will want to do that... every Mozilla
window currently has a menubar which is not hidable, so why make an exception
for download manager?

Comment 5

[Blake Ross]

*** This bug has been marked as a duplicate of 132027 ***

Comment 6

[Hixie (not reading bugmail)]

VERIFIED DUPLICATE

Comment 7

[:deanis74]

Bug 132027 was resolved for the Mac only.  Should this xp bug be re-opened?

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

reopening, since bug 132027 is mac-only, and this is XP.

if you don't want this on all platforms, WONTFIX it, though bug 132027 comment
45 sounds like you do want that.

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

I'll work on this.

conversation between timeless and me about which menus should be present:
<timeless> i'd say file, edit, view, tools, window, help
<biesi> last three with obvious content...
<timeless> Edit could have delete, cut, copy, paste, perhaps reload, properties
and preferences
<biesi> Reload? What would that do?
<timeless> although you could argue that properties would go in file or view, i
don't care
<timeless> re<down>load
* biesi finds properties in Edit just fine
<timeless> ok
<timeless> view would probably do collumn choosing/sorting
<timeless> file might have very few items
<timeless> open would be one of them
<biesi> Open? What would that do? Add a new download or open a downloaded one?
<biesi> s/one/file/
* timeless notes that file>open and file>close wouldn't relate to eachother =o
<timeless> the open the selected item(s)
<timeless> file>new download
<timeless> i think that's all i can think of
<timeless> actually
<timeless> forget file>close
<timeless> file>hide
<timeless> erm file>hide download manager
<biesi> hm
<biesi> if that's even possible
<timeless> not your problem
<timeless> however i can tell you it will be
<biesi> "not my problem"? why do you think I asked?
<timeless> people complain about losing their downloads when they close the last
window
<timeless> so there's a bug talking about making the download manager
hide/minimize to tray instead of leaving 0 windows
<timeless> the actual activities that the last item in the menu do aren't really
significant to the person who makes the menus
<timeless> your last item will do the same thing as if someone clicks the [x]

Comment 10

[:deanis74]

re<down>load would go in the File menu, not Edit.  I would think that Properties
would go in File as well, but based on the Bookmarks window it would go in Edit.

Comment 11

[Alex Bishop]

> I would think that Properties would go in File as well, but based on the
> Bookmarks window it would go in Edit.

The Properties dialogue for bookmarks actually allows you to edit the bookmark.
This isn't the case for Download Manager files, so I think the Properties item
should be in the File menu (after all, it's giving you the properties of the
selected file).

CC'ing mpt because his Download Manager spec had a menu bar
<http://www.mozilla.org/projects/ui/navigator/downloads/#menus>.

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

looks like I'm going to implement mpt's spec

Comment 13

[timeless]

in explorer properties while you can't make many changes, you can make a few, 
in an ideal world, properties belong in the object menu which is not the edit 
menu. (In explorer, the object is a 'file', which is why things magically work 
-- in MacOSX the first menu for bookmarks could be 'Bookmark' and then you 
would have bookmark>properties [well, actually get info, but ...])

For now we just need to be consistent, even if we're consistently wrong.

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

timeless, I don't get your point. Are you suggesting renaming "File" to "Download"?

Comment 15

[Christian :Biesinger (don't email me, ping me on IRC)]

download properties require the disclosure widget. marking dependency.

Comment 16

[Christian :Biesinger (don't email me, ping me on IRC)]

1.1b is out...

Comment 17

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch

implements many, but far from all parts of mpt's spec
but it does implement a menubar with the most important features, which is what
this bug is about. I don't want to make the patch even larger.

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

I have learned that UI patches are not wanted in this project. reassigning to
default owner.

Comment 19

[Hixie (not reading bugmail)]

As I understand it, the module owner only wants a fully fledged menu bar on Mac.
It would be nice if that had been mentioned when a patch was submitted, but...

Comment 20

[Sören 'Chucker' Kuklau (gone)]

biesi: You say that the patch does not implement the *whole* spec. Is it still
at a point that makes it somewhat "finished"?

Comment 21

[Christian :Biesinger (don't email me, ping me on IRC)]

um, I suppose. though it still doesn't implement resume support.

Comment 22

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 205802 has been marked as a duplicate of this bug. ***

Comment 23

[[e-mail]]

Comment on attachment 93924 [details] [diff] [review]
patch

>     key = "Mac";
>+    var propsLabel = bundle.getString("propertiesLabelMac");
>+    document.getElementById("menu_properties").setAttribute("label", propsLabel);
IMHO you should apply the showInShellLabel code to the properties menuitem.

>     case "cmd_showinshell":
>+    case "cmd_copy":
Putting this here makes the comment confusing.
>       // some apps like kazaa/morpheus let you "preview" in-progress downloads because
>       // that's possible for movies and music. for now, just disable indiscriminately.
>       return selectionCount == 1;

>     case "cmd_selectAll":
>-      return gDownloadView.view.rowCount != selectionCount;
>+      return gDownloadView.view.rowCount > 0;
What's with this change?

>     default:
>       return false;
>     }
>+    return false;
If this is to fix a spurious JS warning about not always returning a value then
I think that's been fixed if not then please remove the default clause.

>+    case "cmd_copy":
>+      if (navigator.platform.indexOf("Mac") != -1) {
>+        file = getFileForItem(getSelectedItem());
>+	gClipboardHelper.copyString(file.leafName);
>+      }
>+      else
>+        gClipboardHelper.copyString(getSelectedItem().id);
>+      break;
Does getFileForItem not work on the Mac?

>+    if (col.getAttribute("hidden") == "true")
if (col.hidden)

>+  var id = menuitem.getAttribute("id");
>+  id = id.substring(5, id.length);
var id = menuitem.id.substr(5); will do here.

>+  if (theCol.getAttribute("hidden") == "true")
>+    theCol.removeAttribute("hidden");
>+  else
>+    theCol.setAttribute("hidden", "true");
The hidden attribute is persisted so removing the attribute won't work.
Use theCol.setAttribute("hidden", !theCol.hidden);

>-<?xul-overlay href="chrome://communicator/content/tasksOverlay.xul"?>
>+<?xul-overlay href="chrome://communicator/content/tasksOverlay.xul"?>
??

>+    <key id="key_stop" command="cmd_cancel" keycode="VK_ESCAPE"/>
>+    <!-- the key_stop_mac key will be enabled on mac only -->
>+    <key id="key_stop_mac" command="cmd_cancel" key="." modifiers="accel"/>
Perhaps it would be better to use the platformDialogOverlay to pull in these
key(s)?

>+function download() {
>+  window.opener.saveURL(urlField.value);
>+}
Would be nice to persist the value in a pref too.

>Index: resources/locale/en-US/downloadmanager.ent
.dtd, surely?

Comment 24

[Hiro]

*** Bug 275569 has been marked as a duplicate of this bug. ***

Comment 25

[Christian Eyrich]

Fixed in SeaMonkey 2 supposedly by bug 472001.