Have redundant 'action triggers' / controls on long pages

[michael@…]

For projects with a long list of milestones, it would be helpful if there was an 'add' link at the bottom of the page as well as at the top. This allows someone who has scrolled down to check what the last milestone is to click and add the next one without scrolling back up'

[Christopher Lenz]

The current trunk (and 0.9b1) doesn't actually have a link at the top, it provides a button at the bottom of the milestone list. As you say, this placement probably makes more sense.

However, I have the feeling that what you're really requesting is redundancy in controls, i.e. to have the action triggers both at the bottom and the top of any listing-style page. If we do this, it should be done consistently throughout Trac, and I think it'd be a good idea.

Those redundant controls should however only be rendered after the list has passed a certain threshhold, I think. For a list with one or two items (or even an empty list), putting the same buttons both above and below the list will look pretty ugly, and might be confusing. So I don't think this should really be on the plate for 0.9.

[sid]

Replying to cmlenz:

However, I have the feeling that what you're really requesting is redundancy in controls, i.e. to have the action triggers both at the bottom and the top of any listing-style page. If we do this, it should be done consistently throughout Trac, and I think it'd be a good idea.

Those redundant controls should however only be rendered after the list has passed a certain threshhold, I think. For a list with one or two items (or even an empty list), putting the same buttons both above and below the list will look pretty ugly, and might be confusing.

This would be great to have.

[sid]

#2758 has been marked as duplicate of this ticket. It requests controls at top and bottom of ticket pages for "next" and "previous" links when using custom queries.

[Christian Boos]

#2626 and #4395 were marked as duplicate.

[Christian Boos]

Well, it might not be always easy to detect what's a "long" page and what is not.

For listing like pages (e.g. TracBrowser, the history views), the count of rows can be a good indicator. For wiki pages, it can't be decided easily (e.g. think about a single line [[Image(big_image.jpg)]]).

A different approach might be the solution: do everything in Javascript, where it should be possible on the client side to detect if the page has a scrollbar to start with (i.e. that would be a "big" page) and then duplicate the "action triggers" at the top or bottom of the page. For that, we'd need to define appropriate ids or classes where we can find the original triggers and where we have to copy them.

[Christian Boos]

#8236 was closed as duplicate of this ticket.

[Christian Boos]

#9000 was closed as duplicate of this ticket

[Christian Boos]

Milestone 1.0 deleted

[Remy Blank]

Refocusing.

[florian.strauss@…]

Is there a solution when you want the buttons on top of each wiki site?

[ales.horak@…]

It is possible to add a button at right top of each wiki page via the HTML templates:

1. add templates_dir = templates/ to the [inherit] section of trac.ini
2. copy the default wiki_view.html from Trac (e.g. in Ubuntu linux from /usr/lib/python2.7/dist-packages/trac/wiki/templates/wiki_view.html) to the templates subdirectory in your site's trac environment
3. edit the copy of wiki_view.html - before <div class="wikipage searchable" insert:

   <!-- extra Edit button on top -->
   <py:with vars="delete_perm = 'WIKI_DELETE' in perm(page.resource);
                rename_perm = 'WIKI_RENAME' in perm(page.resource)">
   <py:if test="modify_perm or create_perm or delete_perm">
     <div class="buttons" style="float:right;z-index:10;position:absolute;right:0;">
       <py:if test="modify_perm or create_perm">
         <form method="get" action="${href.wiki(page.name)}" id="modifypage">
           <div>
             <input type="hidden" name="action" value="edit" />
             <py:choose>
               <py:when test="is_not_latest and modify_perm">
                 <input type="hidden" name="version" value="${page.version}"/>
                 <input type="submit" value="${_('Revert to this version')}"/>
               </py:when>
               <py:when test="page.exists and modify_perm">
                 <input type="submit" value="${_('Edit this page')}"/>
               </py:when>
             </py:choose>
           </div>
         </form>
       </py:if>
     </div>
   </py:if>
   </py:with>