Hi,
I’m surprised that this hasn’t popped up earlier in the forum, but here’s my question : I have a bunch of hooks to files that have been trashed (and the trash has been emptied).
These hooks still appear in the list, for example if I do a search of my hookmark database. Here is what I see:
Admittedly my use case was weird (i generate a bunch of hooks to test some automation on my mac, and I trashed all garbage hooks at once …) so I’m not sur if it’s just a matter of the database not catching up on my housekeeping?
They would need to be deleted one by one. Hookmark does not delete automatically delete bookmarks to items in the trash because (a) you remove the file from trash; (2) delete the file on one Mac yet one to keep the hook on another Mac. This is relevant because sync may be enabled.
Future:
We do intend to
support multi-select in the future to facilitate bulk operation on bookmarks (deletion, etc). The bookmarks will be available in a separate Hookmarks window.
have an option to hide bookmarks that are in the trash.
Not sure if it’s the same thing OP was asking about, but I’ve noticed something related to this. Sometimes, I’ll find that a bookmarked file has been moved (renamed). I’ll delete the old bookmark (usually using CTRL + Backspace), but sometimes it still appears in my list when I open Hookmark. In these cases, I’ll even use the mouse to look for right click > Advanced > Delete in Hookmark and find that this option is not available in the context menu (presumably because the bookmark is already deleted?).
Is there a way to cause the database to rebuild or something? It reduces my confidence that I’m looking at valid data when I open Hookmark.
I believe they continue to show up in Recent, but I’ll have to double check next time I see it. Would that be expected behavior for them to show up there?
that is currently undefined, meaning the behavior is not specified in custdoc or internal detailed functional specification, and can go either way depending on internal implementation. I can say that it is internally expected, but we don’t want to commit either way at the moment. CogSci Apps can commit (as far as committing goes) to saying “Recent items” does not/will not contain everything in your database. It’s for recent stuff only.
In Hookmark 6, RECENT items section has been moved from the Context window to the new Bookmarks window, along with PINNED and ALL bookmarks.
Candidly, and without any intention of causing offense, that approach is not a very elegant solution for a common problem where one may delete a hooked file. In my view, exporting and importing is a solution when one wants backup data. For an elegant piece of software whose goal is to reduce friction for accessing system resources, this does not seem to be a viable solution, especially when one considers that deleting files is a normal function that one performs when using a computer.
Ideally Hookmark would not display links to deleted files. It is, however, difficult to distinguish between a file having been deleted and it simply being unreachable. Hookmark is designed to be robust with respect to files stored in the cloud (like Dropbox and iCloud), version control systems (e.g., SVN and Git), network drives and disk images. Deleting bookmarks to files that can’t *currently* be reached is risky because the target might simply be temporarily unreachable (e.g., the disk image not yet mounted). Incidentally an analogous problem exists for objects in databases such as OmniFocus , DEVONthink or email. In many cases, Hookmark has no way of knowing what’s deleted.
Providing an option to hide links whose targets are currently unreachable might be the way to go. Something to think about here.
Thanks for the comments. I think that is a reasonable solution - hiding targets that are currently unreachable.
When it comes to DEVONthink or OmniFocus - there is the concept of trash and completed items, respectively. I understand that hooked items would still be accessible via x-callback-url when in these states. Hookmark could theoretically attempt to find the state of the link through the respective apps’ API - however, I get that this could require some overhead in processing.
Finally DEVONthink’s trash can be emptied and OmniFocus completed tasks can eventually be deleted (or archived). Either way, the DEVONthink resource of OmniFocus task is no longer available. Anyway, something for you to consider.
The inability to cull db app links is incredibly frustrating. There has to be a way to ‘ping’ a known dictionary item the with an x-callback. My five core apps are db apps that produce ~80% of my links.
Not to get too technical, but each app (such as DEVONthink) completes four stubs - Get Name, Get Address, New Item, Open Item.
No reason there couldn’t be a stub for “Item Exists” that returns a boolean. Error handling would be important. For instance, if it is a network resource and the network resource is not available, then that could be an error code that could be handled.
However, for items like local files or OmniFocus tasks, the script implementation could be able to handle the various states implemented by the specific application such as MacOS or OmniFocus or a DB.
What about the examples I gave? The DMG might not be mounted; a remote drive might not be mounted. The SVN or Git repository might not be present at the moment. The cloud shared folder might not be present. All of those are potentially simply transient states. I.e., the unreachable linked file might appear later. It is a feature of Hookmark that links are robust vis-à-vis these conditions.
I think one reasonable solution is to report to the user items that are no longer available, whether due to network resource not available or deletion of underlying hooked item. You could have a menu item for “Manage Unavailable Hooks”.
You could then allow a user to manually or batch delete the items. In this situation, software should still backup the deleted hook metadata and allow the user the ability to restore the hook, at least up to a configurable number of days
One additional comment - a possible logical place to display this functionality would be in the Bookmarks window as a separate item on the left side, below “Pinned, All Bookmarks, Recent, Tags”
Every link to a single source being unreachable would be a strong indicator for second pass trouble shooting on unavailable items. @LucB , would it be possible for Hookmark to use a portion of an existing url to determine if a specific non-local source was present?
I’m a bit outside of my wheelhouse here so please bear with me.
One more plug for implementing some type of functionality.
I have lots of hooks from OmniFocus to DEVONthink. Once the OmniFocus task is completed, I can’t see any reason for the hook to exist anymore, since the task has been marked as complete. Having the hook remain in Hookmark database just clutters the results when searching the bookmarks window and makes the results less trustworthy.
From my “noobie” perspective (and I am taking some liberty here), the deletion question (though a technical issue) ultimately seems to trace back to philosophy driving Hookmark’s development.
From my perspective, Hookmark seems designed for “static” projects - such as an academic research project. Though the linked resources may be updated or added to over time, the overall project is relatively long-term.
My use case is rapid and dynamic. Utilizing the “getting things done” methodology means projects and tasks are continuing being launched, completed, and dropped. The implication of this is that certain hooks are no longer needed.
Again, (outside the emphasized issue regarding a network resource not being available) an implementation for deletion would need to have a stub that queries the underlying app/engine (such as OmniFocus) which could return a status whether the item is active, deleted, or unknown.
For OmniFocus, deleted would refer to specifc OmniFocus status codes or the resource just not there (e.g. permanently deleted)
For DEVONthink, delete would refer to it being in trash or just not there (e.g. permanently deleted)
I understand the technical concerns regarding a network resource not being available, and I sure this is true for some users, but I definitely don’t think it applies to all users.
Suggestion would be to give the user the decision on whether they want hooks to be deleted automatically. Or maybe give them the option to delete links automatically for only certain types of hooks (e.g. OmniFocus). However, my guess (and of course I don’t know your userbase) is that many of your users don’t have network based resources and would like to keep their Hookmark database clean.
One’s hookmark database can so easily be cluttered. This reduces trust when searching for bookmarks (whether using the alfred workflow or bookmarks window) since any of the hooks may no longer be valid.
