#2948 closed enhancement (fixed)
Add additional View Changes button to top of page history
Reported by: | anonymous | Owned by: | Jonas Borgström |
---|---|---|---|
Priority: | normal | Milestone: | 0.10 |
Component: | wiki system | Version: | 0.9.4 |
Severity: | trivial | Keywords: | |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
The Page History page for some wiki pages can get fairly long. It would be nice to have an additional View Changes button at the top of the page if the number of revs is greater than say 15. That way the most common function to view the last changes can be made without scrolling to the bottom of the page. For an example of a long history page see:
http://projects.edgewall.com/trac/wiki/TracInstall?action=history
Attachments (0)
Change History (6)
comment:1 by , 19 years ago
Milestone: | 0.9.5 → 0.10 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:2 by , 19 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I don't agree with the change in [2812]. The view changes button should always be made available regardless of the number of changes. If someone really needs this then maybe a configuration option should be created so that an admin could set the threshold and the default could be set to 0 so the button is always displayed.
The original intention of this ticket was not to hide the view changes button but to add an additional one at the top of the page when there are many entries to improve the user experience on these pages. Currently a page with many changes would require a user to either scroll to the bottom of the page, hit the page down key many times, or use a shortcut to jump to the bottom of the page and then press the view changes button to view the last changes.
comment:3 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
… and that is exactly what is implemented in trunk. The button at the top gets hidden when there are less than 15 changes, the one at the bottom is always visible.
comment:4 by , 19 years ago
Actually it's the top button which is always visible, and the bottom one which is added if there are more than 10 changes. But either way, I think this corresponds to what is wanted here.
comment:5 by , 19 years ago
sorry. I missed the second entry while reviewing the code as I expected the bottom one would be always be available since buttons tend to be at the bottom of pages in Trac. I guess these things happen when you make assumptions. Next time I'll look closer at the code.
comment:6 by , 19 years ago
My motivation for keeping the top button instead of the bottom one was that:
- even for small screen size you'd get at least one button visible by default
- you usually want to diff between recent revisions, so having the view changes button close to those minimizes your mouse mileage …
This is already implemented in trunk ([2812]).