Edgewall Software
Modify ↓

Opened 19 years ago

Last modified 9 years ago

#2695 new enhancement

[PATCH] Pretty icons for various file types.

Reported by: Curtis Buys <trac@…> Owned by:
Priority: normal Milestone: next-major-releases
Component: version control/browser Version: 0.9.3
Severity: normal Keywords: patch icons mime-types
Cc: m@…, choll@…, trac@…, itamarost@…, Thijs Triemstra Branch:
Release Notes:
API Changes:
Internal Changes:

Description

I'd like to propose using different icons for various file-types in the browser view.

The Silk icon set at ​http://www.famfamfam.com/lab/icons/silk/ is "licensed under a ​Creative Commons Attribution 2.5 License and contains good icons for a number of file-types, including:

Even if no one likes my idea for the different file types, the basic folder, file, and deny icons could be used.

I've started hacking this together in my own Trac install, but I'm not a python developer, so I'm not sure if it's worth anything to anyone else. I'll be posting a first-attempt patch in just a moment.

Attachments (6)

pretty_icons.diff​ (2.6 KB ) - added by Curtis Buys <trac@…> 19 years ago.
First attempt, patched against Trac trunk.
example.png​ (5.7 KB ) - added by Curtis Buys <trac@…> 19 years ago.
Example of how this looks.
pretty_icons_2nd_pass.diff​ (10.1 KB ) - added by Curtis Buys <trac@…> 19 years ago.
My second attempt at this; still far from perfect, I know… I'm looking for any suggestiong anyone may have :)
overlay-example.png​ (2.0 KB ) - added by Itamar Oren 15 years ago.
Screenshot of source browser with lock-overlay for svn:needs-lock file
lock.png​ (749 bytes ) - added by Itamar Oren 15 years ago.
The lock.png used in the example (from Silk icons)
overlays-poc.patch​ (4.0 KB ) - added by Itamar Oren 15 years ago.
Initial overlay-icons proof-of-concept patch

Download all attachments as: .zip

Change History (23)

by Curtis Buys <trac@…>, 19 years ago

Attachment: pretty_icons.diff​ added

First attempt, patched against Trac trunk.

comment:1 by Curtis Buys <trac@…>, 19 years ago

Anyway, as I was saying, my grasp of Python is somewhat limited. I learned while putting this much together that there's no switch/select case type of structure in Python, so I imitated an idiom I discovered along the way.

I started with 'Rakefile' because I can match the whole file name against a string. From here I could use some help matching against file extensions, perhaps with regular expressions. I'd also considered working with mime_types to determine which CSS class should be applied.

Ideally, IMO, the icon mapping would occur in some misc. configuration file that could be easily updated, but my knowledge of Python and Trac internals prevented me from getting that far. Anyone want to lend some help and/or pointers?

Thanks!

by Curtis Buys <trac@…>, 19 years ago

Attachment: example.png​ added

Example of how this looks.

comment:2 by Markus Tacker <m@…>, 19 years ago

Cc: m@… added

I think it would be nice-to-have. Though icons should be set according to the files mime-type.

comment:3 by Christian Hollaender, 19 years ago

Cc: choll@… added

I agree it would be nice to have. And yes it should be set according to mime-types.

by Curtis Buys <trac@…>, 19 years ago

Attachment: pretty_icons_2nd_pass.diff​ added

My second attempt at this; still far from perfect, I know… I'm looking for any suggestiong anyone may have :)

comment:4 by Curtis Buys <trac@…>, 19 years ago

Cc: trac@… added
Summary: Pretty icons for various file types. → [PATCH] Pretty icons for various file types.

in reply to:  2 comment:5 by Matthew Good, 18 years ago

Replying to Markus Tacker <m@tacker.org>:

I think it would be nice-to-have. Though icons should be set according to the files mime-type.

Yes, I think that if implemented, we should follow the ​Freedesktop Icon Naming Specification since this would allow for easier integration of icon sets following that standard (such as ​Tango).

comment:6 by Christian Boos, 18 years ago

Keywords: icons mime-types added
Milestone: → 0.12
Owner: changed from Jonas Borgström to Christian Boos
Severity: trivial → normal

Would be nice even for 0.12

comment:7 by Itamar Oren, 15 years ago

Cc: itamarost@… added

Indeed would be nice.

I wonder if this idea could be combined with another idea I had - enabling icon overlays in browser listing as function of (mime-type, item properties, permissions, more?).

Few use cases to better explain what I mean:

  • For files with svn:needs-lock: overlay the file icon with a lock icon (could be even cooler if the repository layer checks the lock status and chooses between a locked or unlocked!)
  • Together with #6474: "Virtual" folders and files (resulting from external definitions) overlaid with a "link" icon.
  • For items with "access denied" for active user: Overlay with "no-entry" icon.
  • You get the idea…

what do you think?

in reply to:  7 ; comment:8 by Remy Blank, 15 years ago

Replying to itamaro:

what do you think?

Excellent ideas. Except maybe for the "access denied" icon, as those entries are actually hidden completely on purpose.

Go for it!

in reply to:  8 ; comment:9 by Itamar Oren, 15 years ago

Replying to rblank:

Replying to itamaro:

what do you think?

Go for it!

Gladly. Any ideas on how to implement icon overlaying? Is it in the level of Genshi? jQuery? Or some Python magic in the web_ui?

in reply to:  9 comment:10 by Remy Blank, 15 years ago

Replying to itamaro:

Any ideas on how to implement icon overlaying? Is it in the level of Genshi? jQuery? Or some Python magic in the web_ui?

I would use .png overlays with transparency, and use CSS classes to add them to selected entries. Of course, you'll need some Python-fu in web_ui.py to retrieve the image and overlay info (mime type, svn:needs-lock, svn:externals).

comment:11 by Itamar Oren, 15 years ago

By the way, in order to make this work, every time a folder is rendered it will be needed to loop over all the items and get their metadata (mime-type etc.).

In folders with many items this may cause a significant performance penalty, unless this information is cached during repository syncs.

From what I've seen, at the moment this information is not cached (unless I misunderstood something). Are there any plans to extend versioncontrol caching to include this? If not, I guess a different ticket is needed for this… (or an alternative solution I missed)

comment:12 by Christian Boos, 15 years ago

You're quite right - however you might as well ignore that aspect of things for the first approach, and make the whole feature enabled via a config option. So for small repositories where it doesn't matter much, you have the feature without the need to change the cache, and for bigger repositories, you can turn the feature off while waiting for the cache enhancements ;-)

Currently, only changeset information is cached, no per node information. That needs to be done with extreme caution, think about VCS backends like Subversion which branch by copying… it's currently cheap, as we only record the copy directory operation as expressed in the changeset, but if we would from that blindly store all the corresponding tree in order to cache the properties, that would quickly kill your disk ;-) (well, at least once your repository is in the 10000s of files and you have dozens of branches and hundreds of tags). Some old brainstorming on the topic can be found in VcRefactoring#NewRepositoryCache, although I didn't address the issue of properties.

by Itamar Oren, 15 years ago

Attachment: overlay-example.png​ added

Screenshot of source browser with lock-overlay for svn:needs-lock file

by Itamar Oren, 15 years ago

Attachment: lock.png​ added

The lock.png used in the example (from Silk icons)

by Itamar Oren, 15 years ago

Attachment: overlays-poc.patch​ added

Initial overlay-icons proof-of-concept patch

comment:13 by Itamar Oren, 15 years ago

Posted an initial patch (overlays-poc.patch​) that overlays a lock icon (The lock.png used in the example (from Silk icons)) over files with svn:needs-lock property set.

Example screenshot: Screenshot of source browser with lock-overlay for svn:needs-lock file

I'm not too comfortable messing with the CSS and templates, so I'd appreciate your feedback on this take, as well as any improvement ideas / tips.

By the way, is this "overlaying feature" on-topic for this ticket? Or should I create another ticket for it?

comment:14 by Remy Blank, 15 years ago

I haven't tested the patch yet, but the visual aspect is very nice. I'm wondering about the performance impact, though. IIRC, get_properties() directly hits the repository, as that information isn't cached, so for many files, I suspect that there's a noticeable slowdown.

in reply to:  14 comment:15 by Thijs Triemstra, 14 years ago

Cc: Thijs Triemstra added

Replying to rblank:

I haven't tested the patch yet, but the visual aspect is very nice. I'm wondering about the performance impact, though. IIRC, get_properties() directly hits the repository, as that information isn't cached, so for many files, I suspect that there's a noticeable slowdown.

Perhaps that should be configurable and up to the user, perhaps we can introduce 3 or 4 more, like the svn:needs-lock property?

comment:16 by Ryan J Ollos, 9 years ago

Owner: Christian Boos removed

comment:17 by figaro, 9 years ago

Keywords: patch added

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment
E-mail address and name can be saved in the Preferences .
Attachments ↑ Description ↑
 
Note: See TracTickets for help on using tickets.