zeniko wrote:Hardly... and you even do less (mainly not handling multiple dropped files and not treating image links as links).
It was intentional. I disliked the idea of overriding the default file drop handler (or any of the built-in handlers, for that matter). That seemed to be something that is out of the scope of what was desirable--my goal with QuickDrag was to limit the scope of its impact as much as possible (so doing something like replacing nsDragAndDrop::checkCanDrop that's used all over the place would be out of the question for my goals, and similarly so would overriding file drop handling). SD&G didn't handle multi file drops anyway, what file drop it did handle was just duping the built-in behavior (which could be problematic because if the built-in behavior was ever updated in a future FF version, SD&G would be overriding the new version's behavior), so there was no benefit in SD&G's promiscuous scope.
I had only briefly glanced at your code, so I didn't notice that yours does support multi file drops. Sorry about that. So that is one place where my implementation falls short on features. But I've personally used SD&G only for the browsing tasks of navigation/searching/saving, so I didn't find it missing.
zeniko wrote:BTW: What's the reasoning behind preferring link text to the proper hyperlink? I mostly drag proper hyperlinks - and I always want the URL.
I explained that in the FAQ, and it's the same reason I don't treat image links as links. Middle-click-to-open has always existed, and I've always used that for opening stuff in a new tab. At the same time, I've often wanted to save an image that was linked, and I've often wanted to search for some text that was linked. With SD&G, if I wanted to search for text that happened to be linked, it was annoyingly difficult because I had to select the text (w/o accidentally clicking on it in the process) along with some text outside of the link (so that the drag won't register as a link, which wasn't always possible, and would sometimes involve manually fixing up the search afterwards if the outside text changed the meaning of the query)--it was basically my biggest complaint about SD&G. Because the middle-click-to-open behavior already existed (and most trackpad drivers support tap zones or other means to emulate a middle button; I do a lot on a laptop w/o a physical middle button and I still use middle-click-to-open) and because middle-click-to-open is even easier and faster than drag-to-open, it seemed a waste to have yet another mouse action mapped to open a link when it could instead be mapped to search or to save an image.