Opened 16 years ago
Last modified 9 years ago
#8135 new enhancement
[PATCH] Prev, Query, Next links at bottom of ticket page
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | low | Milestone: | next-major-releases |
| Component: | ticket system | Version: | 0.13dev |
| Severity: | normal | Keywords: | tickets, templates, customize patch |
| Cc: | bavison@…, franz.mayer@… | Branch: | |
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
When you're viewing a ticket after selecting it from some report/query, there are usually three links at the top of the page saying (roughly):
- Previous ticket
- Back to Query
- Next ticket
Is there some way to have these links repeated at the bottom of the page? When updating tickets, most of the work happens at the bottom of the page and it's a pain to keep scrolling to the bottom to do the work, then to the top to click "Next ticket" then back to the bottom again…
I tried looking around for some HTML templates that I can edit to achieve this but I got as far as finding that the changes I need to make are probably in ticket/web_ui.py before calling it a day.
Can I request this feature be added? Also, if there is a quick hack I can make to my existing (trac 0.11.3) install, I'm all ears…
Ta.
Attachments (1)
Change History (21)
comment:1 by , 16 years ago
| Component: | web frontend → general |
|---|
comment:2 by , 16 years ago
This sounds a bit like I need to RTFM the site template stuff and try to get my head around it… if that's the case, then you probably can close this ticket. I hint at the kind of site.html template I would need (e.g. for a default trac install with my tweak) would be very much appreciated.
comment:3 by , 16 years ago
Well, I've tried RTFM but it's hardly an enlightening experience. Here's the best I could think of - remember I don't understand a word of this Genshi stuff and close to zero python…
<py:choose test="req.environ['PATH_INFO'].find('/ticket/') >= 0"> <py:when test="True"> <div py:match="div[@class='buttons']" py:attrs="select('@*')"> ${select('*')} <div py:match="div[@id='ctxtnav' and @class='nav']" py:attrs="select('@*')"> ${select('*')} </div> </div> ${select('*|text()')} </py:when> <py:otherwise> <p>Flibble, wibble</p> ${select('*|text()')} </py:otherwise> </py:choose>
which didn't work of course. So I got even more desparate…
<py:choose test="req.environ['PATH_INFO'].find('/ticket/') >= 0"> <py:when test="True"> <py:with vars="myvar = select('@*')"> <div py:match="div[@class='buttons']" py:attrs="select('@*')"> ${select('*')} <div py:match="div[@id='ctxtnav' and @class='nav']" py:attrs="myvar"> ${select('*')} </div> </div> </py:with> ${select('*|text()')} </py:when> <py:otherwise> <p>Flibble, wibble</p> ${select('*|text()')} </py:otherwise> </py:choose>
which also doesn't work. I just don't understand what the select() stuff does, the text() thing, why my myvar variable always seems to contain nothing - I basically don't have a clue what's going on because it all looks magic.
Answers from the enlightened, please.
comment:4 by , 16 years ago
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
Yeah, you're all over the place with those attempts. It doesn't need to be nearly so involved. Here's what I did:
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:py="http://genshi.edgewall.org/" py:strip=""> <py:if test="context and context.resource.realm == 'ticket' and context.resource.id"> <py:match path="//div[@id='main']" once="true"> <div py:attrs="select('@*')"> ${select('*|text()')} <div id="ctxtnav2" class="nav"> ${select('div[@id="ctxtnav"]/*')} </div> </div> </py:match> </py:if> </html>
It gives the second context nav an id of "ctxtnav2" so you can add the appropriate stylings for it in your site.css.
Otherwise, if you want to better understand Genshi I'd encourage you to post your questions on the Genshi mailing list.
comment:5 by , 16 years ago
Thanks for your help. Sorry to bang on about this one - I have one last dumb question: where would you put that fragment - e.g. which file?
comment:6 by , 16 years ago
That would go in <path_to_env>/templates/site.html. See hTracInterfaceCustomization#SiteAppearance if you haven't already—it also gives an example of how to include your own stylesheet.
follow-up: 8 comment:7 by , 13 years ago
| Cc: | added |
|---|---|
| Component: | general → ticket system |
| Keywords: | patch added |
| Milestone: | → 0.13 |
| Resolution: | worksforme |
| Status: | closed → reopened |
| Summary: | Prev, Query, Next links at top of ticket page → [PATCH] Prev, Query, Next links at buttom of ticket page |
| Version: | none → 0.13dev |
IMO this is a nice little enhencement, which does not hurt. So why not include it in Trac standard? The provided patch is a slightly adjusted copy of ctxtnav-div in theme.html.
follow-up: 9 comment:8 by , 13 years ago
Replying to franz.mayer@…:
IMO this is a nice little enhencement, which does not hurt. So why not include it in Trac standard?
Because we already have too many links cropping up everywhere. If we were to always duplicate the contextual navigation ones, this would only be getting worse, especially on pages with a small height where you'd see both the (same) top and bottom links.
We could perhaps instead search for ways to make those links always reachable? (JIRA like?)
follow-up: 10 comment:9 by , 13 years ago
Replying to cboos:
Because we already have too many links cropping up everywhere. If we were to always duplicate the contextual navigation ones, this would only be getting worse, especially on pages with a small height where you'd see both the (same) top and bottom links.
Yes, this is probably the nicest way for users.
We could perhaps instead search for ways to make those links always reachable? (JIRA like?)
I don't know what you mean with "JIRA like" (tried Jira Sandbox but could not find any "always reachable links").
But I played a little around with fixed menus and here's some hack for fixing mainnav and ctxtnav on top of browser page (see http://limpid.nl/lab/css/fixed/header and stackoverflow entry for CSS details):
#mainnav { background-color: #ffffff; position:fixed; top:0; width:100%; z-index:100; margin-top: 0px; padding-top:0px; } #ctxtnav { background-color: #ffffff; position: fixed; top:1.2em; width:100%; z-index:100; margin-top: 0px; padding-top:0px; }
I tried above hack on my test Trac Test system by using Component CssTemplate for inserting CSS file (but of course you can simply change / override it in Firebug or Trac itself).
follow-up: 13 comment:10 by , 13 years ago
Replying to franz.mayer@…:
Replying to cboos:
Because we already have too many links cropping up everywhere. If we were to always duplicate the contextual navigation ones, this would only be getting worse, especially on pages with a small height where you'd see both the (same) top and bottom links.
Yes, this is probably the nicest way for users.
We could perhaps instead search for ways to make those links always reachable? (JIRA like?)
I don't know what you mean with "JIRA like" (tried Jira Sandbox but could not find any "always reachable links").
Look into an "issue", in particular when you're coming from a query, you'll see the issue title at the top left and some links at the top right (e.g. (^) 3 of 135 <br> (v) Return to search) and below that, even some action buttons; they'll all stick at the top of the page when you scroll down.
But I played a little around with fixed menus and here's some hack for fixing
mainnavandctxtnavon top of browser page (see http://limpid.nl/lab/css/fixed/header and stackoverflow entry for CSS details):
Yes, something like that. The JIRA way also involves a bit of Javascript to only make it stick when scrolling down (and to "unstick" it again when scrolling up). I'm not saying we should do exactly the same, but we could find something similar and fitting in Trac.
I already experimented a bit with the action buttons in particular (for the Wiki), but this could also be extended to (some) nav links (probably just the contextual ones, not the mainnav).
comment:11 by , 13 years ago
| Summary: | [PATCH] Prev, Query, Next links at buttom of ticket page → [PATCH] Prev, Query, Next links at bottom of ticket page |
|---|
comment:12 by , 13 years ago
Replying to cboos:
Look into an "issue", in particular when you're coming from a query, you'll see the issue title at the top left and some links at the top right (e.g.
(^) 3 of 135 <br> (v) Return to search) and below that, even some action buttons; they'll all stick at the top of the page when you scroll down.
Ahh … now I see … with Chrome, because with my very old Firefox 8 it is not working :-P
follow-up: 14 comment:13 by , 13 years ago
Replying to cboos:
Yes, something like that. The JIRA way also involves a bit of Javascript to only make it stick when scrolling down (and to "unstick" it again when scrolling up). I'm not saying we should do exactly the same, but we could find something similar and fitting in Trac.
It is the strategy I used for my 'Talk' plugin, where the interactive chats may extend to become quite long pages. I use a sidebar that flows with the activity. I think I have anonymous read access for the demo talk room, so you can have a look at it:
comment:14 by , 13 years ago
Replying to osimons:
It is the strategy I used for my 'Talk' plugin, where the interactive chats may extend to become quite long pages. I use a sidebar that flows with the activity. I think I have anonymous read access for the demo talk room, so you can have a look at it:
Well, honestly I do not like this solution so much, because there is always a delay of a few ticks. So you get the feeling of having a jumping box on your side. I would prefer having a fix menu / navigation bar (like a frame in old HTML) - but maybe this feels ancient in times of Web 2.0 …
comment:15 by , 13 years ago
I implemented the requested enhancement as a plugin: NavigationDisplayPlugin
When setting user preference to buttom_ctx_menu it performs the action as described in ticket description. When setting fixed_menu it performs action as described in comment:9. There might also be more options, like described in comment:13.
Note: this plugin is quite a hack - for better handling of option fixed_menu (which is my personal favourite) the structure of Trac-HTML needs to be reorganized
If you would like to have another option (osimons?!) please let me know or be welcome to add it to the plugin. Comments to that plugin are also welcome (kind of RFC), since I'm not a native Python programmer.
comment:18 by , 12 years ago
| Milestone: | next-stable-1.0.x → next-dev-1.1.x |
|---|
well, once again… next-dev
comment:19 by , 10 years ago
| Milestone: | next-dev-1.1.x → next-major-releases |
|---|
Retargetting tickets to narrow focus for milestone:1.2. Please move the ticket back to milestone:next-dev-1.1.x if you intend to resolve it by milestone:1.2.
comment:20 by , 9 years ago
| Status: | reopened → new |
|---|
I'd say this is mostly a matter of customizing your site template to add an additional copy of the context nav elsewhere. So unless a good case can be made to have this in Trac's default template this should probably be closed.