Fossil SCM
Tables in ticket view set the bgcolor
700d423d2a44853…
· opened 16 years, 5 months ago
- Type
- Feature_Request
- Priority
- Immediate
- Severity
- Cosmetic
- Resolution
- Open
- Subsystem
- —
- Created
- Oct. 17, 2009 5:28 p.m.
I use a modified header/footer/css on my site, but the table for display a ticket sets the bgcolor rather than relying on css. I'd submit a patch, but this ticket system doesn't have that, so here's what needs to change:
- In tktsetup_.c remove all bgcolor="#d0d0d0" text.
- In style_.c add CSS to style the td tags (although they look find without it).
Additionally, these strings in the .c files could easily just be text files that are injected into sqlite. Not sure what the purpose is of putting them in there.
anonymous added on 2009-10-17 17:31:14:
Oops, sorry that's in src/tktsetup.c not tktsetup_.c.
anonymous added on 2009-10-17 17:38:06:
Alright, I need to read the code more carefully. I found the configuration page where you can just remove them.
Fossil rocks! :-)
anonymous claiming to be Dmitry Chestnykh added on 2009-10-21 15:28:12:
Still, it would be nice to move this to CSS, in case skins/themes are coming.
Comments (2)
A note from the future: the ticket colors are still hard-coded into the ticket report, so are customizable but inherently not skinning-friendly. Now that users can select their own skin, rather than the site operator selecting one for them, this can lead to some color conflicts. As per the OP's suggestion, moving the ticket state colors into CSS, so that they participate in the skinning process, would be a good thing to do someday.
As per the OP's suggestion, moving the ticket state colors into CSS, so that they participate in the skinning process, would be a good thing to do someday.
I see some problem. It would be quite easy I think to create CSS-Classes if a Variable cssclass or similar is created in the SQL-Query. That part is easy. But what CSS-Classes would a creator of a report pick? As the users can switch their skin, these would've to be supported in all available skins. We could provide some for common cases, but it would be hard to use more customized stuff. The report-creator has to make sure their CSS-Classes are added to the skins.
So it is not impossible to implement I think, but as I see it the usefulness would be limited if there isn't a way to add the needed classes to all skins or add custom classes to the report window as well. Which probably would be the best way, add another input for creating CSS that is injected on the report page. But then again it is not part of the skinning.