109427 - Directory viewer should employ link navigation toolbar

Status: RESOLVED EXPIRED

(SeaMonkey :: UI Design, enhancement)

Description

[Ben Bucksch (:BenB)]

The XUL directory viewer in the main Navigator window should make use of the
<link> navigation toolbar. "Up" would be esp. useful, but the others (Top,
Frist, Prev, Next, Last sibling) should be supported, too.

Comment 1

[sairuh (rarely reading bugmail)]

->bbaetz

Comment 2

[Bradley Baetz (:bbaetz)]

Up would be useful, and I'll do that when I rewrite the xul viewer next
milestone. I think its mentioned in one of the bugs - do a search on all xpapps
bugs assigned to me for 0.9.7 (They're not very well categorised, and I will go
through and wontfix some of them next week).

What would top (or any of the others) mean, though? top being the top level
directory I could sort of see, but what is "next"?

I may have to play with this a bit, if <html:link> doesn't work.

Theres an RFE somewhere to do this for html, too.

Comment 3

[Ben Bucksch (:BenB)]

> What would top (or any of the others) mean, though? top being the top level
> directory I could sort of see, but what is "next"?

Up: Next higher directory not yet displayed. Corrent directory stays open.
Top: file system root. / on Unix, list of drives on Windows.
Next: Logically, this would be the next sibling directory (i.e. the next
directory contained within the same parent directory as the current dir). Not
sure, how useful that would be.
Prev, First, Last: like Next.

> Theres an RFE somewhere to do this for html, too.

huh? (It workes for webpages already.)

Comment 4

[Ben Bucksch (:BenB)]

> Top: [...] / on Unix

"Top" is the same as "Home" in Mozilla. Maybe use ~ on Unix?

(This is a good example, where top != home.)

Comment 5

[Bradley Baetz (:bbaetz)]

The XUL viewer isn't only for file:///. Its just off by default for ftp/gopher.

>Up: Next higher directory not yet displayed. Corrent directory stays open.

Yep. Thats easy.

>Top: file system root. / on Unix, list of drives on Windows.

Well, I can take you to a given file uri. I'll probaby just recurse up the
nsIFile list until parent is null.

CAn I use the link toolbar to give a list of parent urls, ie for
ftp://ftp.m.o/pub/foo/bar/, I have ftp://ftp.m.o/pub/foo/, ftp://ftp.m.o/pub/
and ftp://ftp.m.o/. Thats sort of what mpt suggested for the html view (with
each directory being a different link), but the ui was different, because the
htext would only be displayed once. Not sure if its worth it, though.

>Next: Logically, this would be the next sibling directory (i.e. the next
>directory contained within the same parent directory as the current dir). Not
>sure, how useful that would be.
>Prev, First, Last: like Next.

I'm not sure either. What if there isn't a next directory (ie its the last one
in the list)? Would we have to fetch the parent dir before displaying the actual
dir, just to check if its there? This could also be slow if the parent dir is
something like /home, with lots of entries.

I don't think that these are worth it, given the perf issues (which may be
minor) + code complexity, + how useful a feature it actually is, and how often
it would be used.

Feel free to convince me otherwise, and give an example of when you'd want it.

>> Theres an RFE somewhere to do this for html, too.
>huh? (It workes for webpages already.)

I meant the html dir listing.

Comment 6

[Ben Bucksch (:BenB)]

> Well, I can take you to a given file uri.

<file:///>? (If we want the root.)
> CAn I use the link toolbar to give a list of parent urls, ie for
> ftp://ftp.m.o/pub/foo/bar/, I have ftp://ftp.m.o/pub/foo/, ftp://ftp.m.o/pub/
> and ftp://ftp.m.o/. 

No idea, how to do it with the link toolbar.

> What if there isn't a next directory (ie its the last one in the list)?

Then there's no <link rel="next">, in which case the Next button will be disabled.

[Next etc.]
> I don't think that these are worth it

Might be.

> example of when you'd want it

It was more for completeness.

Comment 7

[Bradley Baetz (:bbaetz)]

>> What if there isn't a next directory (ie its the last one in the list)?
> Then there's no <link rel="next">, in which case the Next button will be disabled.

But that requries prefetching of the parent directory.

>> example of when you'd want it
> It was more for completeness.

Fair enough.

Comment 8

[Bradley Baetz (:bbaetz)]

Given the <tree>-><listbox> changes, which mean that <tree> will become
<outliner> automatically (and my current time constraints), I'm going to push
this off for the moment. 0.9.8 is out for me, so that means 0.9.9

The bugs being changed this way either require <outliner> support, or would be a
lot easier with such support

Comment 9

[Bradley Baetz (:bbaetz)]

OK, moving all XUL dirviewer bugs to post 1.0. I don't want to be doing this,
but there are only so many hours in the day. These will be taken earlier if
someone submits a patch, or I find time.

Comment 10

[Bradley Baetz (:bbaetz)]

Following the roadmap, 1.0.1 is a maintenance release, so pushing off features
(xul direviewer) to 1.1

Comment 11

[Bradley Baetz (:bbaetz)]

xul dirviewer bugs -> 1.2. I have no time..

Comment 12

[Marshall Savage]

When you get to this in v1.2, could you also change the display of file sizes in
FTP directories to show the actual number of bytes rather than the number of
binary kilobytes?  Example:  NOT 636032 KB  BUT 651,296,768  (651.296.768 in
Europe).  They look like different files but they are really the same one.  This
cost me hours yesterday.  I.E.6 & my FTP program do this.  

Comment 13

[Bradley Baetz (:bbaetz)]

Thats a separate bug (two, actually) which are already filed.

Comment 14

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 15

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 16

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 17

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420