Mark files as read/watched/listened/viewed and changing color by there status #187
Comments
|
Seems related to the issue #153 |
|
Providing the ability to store metadata bound to a given inode As addon functionailty, we've tried creating this for the xfce Thunar file manager: So, regardless how the metadata status indicator is displayed for a given item, it begs placement within an additional display column. Would that column display (conditionally) a select icon... or a conditional bgcolor (legend for which the user would be expected to setup, along with various status "tags")... or a text string representing the user's freeform (arbitrarily assigned) "tag" labeltext? Display of the metadata flag column should probably be optional. Performing a lookup against 2000+ child nodes in a given directory, to check for metadata flag value, would add considerable overhead. Personally, I find that neither "color coded" markings nor "tagword" markings will suffice. In my use, the notes are not necessarily intended to be private (per-user). Ultimately, I envision multiple users ~~ local accounts, or even all users of a given distro ~~ incrementally building a datastore. A user right-clicking a given file would have an opportunity to create a local note, or to visit a forum thread dedicated to (and created on-the-fly if a matching thread does not already exist) to that exact file, existing in that exact path across every installation of a given distro. Yes, I read man pages... and typically find their content to be sorely lacking. Spending half my waking hours researching examples of correct syntax use for a given beast... sooner or later I'll run out of hours, or patience. I suspect this is a huge deterrent to anyone attempting to "look under the hood" of their desktop operating system. |
|
One of the challenges here is how to identify a file. If you're going to attach a database entry to a file, how do you find it? By its path? What if spacefm moves it? Does the data move? What if another process moves, renames, or copies the file and spacefm doesn't know? Is it the same file or a different one? How can you tell? What if the file has a few or a lot of bytes modified? Is it a different file? What if another file is given the same name or copied to the same path, replacing another file that had annotations? What happens to the data if a file is deleted? Even if the data were stored in the file itself it presents challenges when duplicating and modifying, not to mention how or where do you store it. This can be simplified somewhat by just using a relative or absolute path to identify the file and tag it, but that has its limitations and becomes awkward when you want to reorganize, duplicate, backup, etc. But I agree it would be nice to make notes and annotations, mark as 'watched' etc. But storing more critical, less volatile data involves all of the above management issues. If a file is moved or renamed (by spacefm or outside of it), you might not mind losing your 'watched' tag and color. But you might mind losing all your notes, links, etc. How do other file managers handle this? Is there a common file placed in a directory with info about contained files? What format is used and is there any spec or convention? |
|
In the "custom action" script written for use with thunar, an annotated "object" is an inode (user is able to right-click and annotate any folder object, any file, any symlink). The bash script is straightforward, easily-readable, 40 lines of code ~~ it's pasted into the forum post I linked to, above. YES, in this simplistic approach, if an annotated file is moved (or renamed), the inode{--}note association is lost. I wasn't suggesting/requesting spaceFM should take care of managing the external "notes database"... probably because I had resigned myself to the status quo of employing the thunar action & later "finding" note content via those myriad txt files via recoll (file indexer). As an interim step, I might investigate creation of a spaceFM plugin to provide "one step up from" copy-path-to-clipboard functionality. Personally, I don't particularly care to track/monitor/worry whether a file associated with a given annotation is subsequently changed / renamed / moved / deleted. I would want the content of the datastore to endure, unaffected by file deletions, etc. For any users not sharing that mindset, I'd argue that a periodic (manual) sync-n-purge-stray notes operation should suffice. Although many of my notes contain URIs, the yad dialog only handles ascii chars. I'm fine with copy/pasting to make my way back to whatever reference page I've cited. I really don't expect to rely on a file manager app to support indexing / freeform search for the notes. Recoll index 'em just fine ~~ with the added benefit of recognizing embedded URIs and converting 'em into clickable links. Even if the file manager app were storing the notes to, say, a sqlite database... I believe their content will still be indexable. (For each search result, I think Recoll will display xx lines prior to and xx lines following, with the search term(s) within the sqlite stream highlighted.) Above, I spouted "inode". Admittedly, I'm unsure I have a firm grasp of what constitutes an inode? I did not intend to recommend/suggest some fandangled mechanism which employs notifyd (or whatever). Restating my immediate hope/goal for added functionality: |
|
further down the rabbit hole I go... When using caja (nautilus fork), the file manager component of "MATE desktop", right-clicking a file Yuk! the metadata annotations are handled via gvfs I read that spaceFM utilizes an inbuilt vfs (http://ignorantguru.github.com/spacefm/spacefm-manual-en.html) also read ( http://blogs.gnome.org/alexl/category/nautilus ) that sqlite is not a suitable vehicle No, I surely do NOT want file annotations stored to a shared datastore related reading: http://nuclear-imaging.info/site_content/2011/12/28/when-gvfsd-metadata-starts-using-100-processor/ http://ubuntuforums.org/showthread.php?t=1406468 http://askubuntu.com/questions/90853/file-notes-tab-gone-in-nautilus-3-2-1 http://askubuntu.com/questions/14669/are-file-notes-exclusive-to-nautilus-is-there-a-terminal-cli http://anxiousnut.wordpress.com/2010/09/22/getnotes-a-script-to-retrieve-metadata-notes/ http://answerpot.com/showthread.php?3237367-Gvfs+metadata+handling+on+removed+%2F+new+files https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/459439 http://blogs.gnome.org/alexl/2012/01/26/resources-in-glib/ |
|
I do have some ideas for how this could be done reasonably and in keeping with the open format of spacefm's other extensible features. As the above problems show, it's not something to be done carelessly, and spacefm certainly wouldn't use gvfs. Not sure when I will get to look at this more or implement some of it, but I agree it has potential. |
|
After quite a LOT of feature-searching, across various linux distros and various DEs... I've realized that the sorely-absent functionality doesn't fit the scope of a "Mark files as..." file manager app feature request. As a followup, to further explain my wish/hope/request, I'll open a discussion thread in the spaceFM forum at sourceforge. |
|
A simpler variation. A color and/or icon for system folders. These are basically just a root listing SpaceFM already signifies symlinks with a special icon. Users need similar clues on which folders are "system" and which are "for us." They aren't Linux gearheads and think of "/etc" as some kind of grab-bag available to them, not a system folder. I can't lock permissions. Over the phone I must tell people "open the file /etc/X11/xorg.conf and tweak this value..." Even in person, I need to save myself time playing sudo games and whatnot. Users will gladly follow "color" directions and can follow them without becoming geeks. Thanks... |
Hi,
i would like to see a feature which allows users to give their files a status, given the status of a file you either get a checkmark or a colored filenamed displayed. Green as "read/watched/..", yellow/orange as "in progress", red as "untouched".
Thank you
The text was updated successfully, but these errors were encountered: