WIP - gutter link previewer
-
Continuing the discussion from Is link highlighting now broken in topic lists?:
Actually, this reminds me of something I've been wanting to make but haven't gotten around to trying:
@Monarch, you've done some ui stuff here, right? Have you been looking for another project?
I guess the answer is yes sort off?
the code in the following gist implement this idea. yet it is missing one critical functionality.
it currently only work once for links that are loaded in the page.-
I need to find where to "plug" a call to
setupLinkEvents()
;
on new post load, in an efficient manner ( hence the WIP tag) -
I need to wrap the code in a namespace to make the global scope cleaner.
-
I am using jQuery popup plugin, didn't want to reinvent the wheel, and didn't want to use discourse modal box.in a different code that I used it there was a bug with the close button.
for simplicity I used a centered overlay. as the tooltip mode of the jQuery popup plugin didn't work well out of the box, and it is not to flexible.
-
-
Looks great! (Though I haven't got it to work on my machine yet; my javascript level is very low)
One other place I think it could be really useful would be in the topic list–(especially if it could mark displayed posts as read after an appropriate timeout—though I suppose some would find that annoying, depending how it works out with gray circles or whatever)–no more loading entire topics just to view one post!
-
You could make
setupLinkEvents()
take a post ID as a parameter and useEmber.View.reopen
event to get any rendered posts, I guess. For every post you already processed you could add a class / data attribute to mark it already processed to avoid looking for links multiple time.This only makes editing a problem, though you could put last modification time into the data attribute and compare that, and look for links again only if it changed. No idea how efficient it would be, but it's an option.
-
I think there's a new
decoratePost
function that you can use to get triggered on every post render.
-
Looks great! (Though I haven't got it to work on my machine yet; my javascript level is very low)
for testing all you need to do is paste the code in console. when you have a post with a link. and then just hover with a mouse for a second.
One other place I think it could be really useful would be in the topic list–(especially if it could mark displayed posts as read after an appropriate timeout
Adapting the solution to work for other internal links should be fairly easy.
basically we only need to expand the element selector. and find where to put the hook to callsetupLinkEvents
depend on the view that we are working on.may be in the future I will implement something like that. for know I am just going make the basic idea working.
You could make setupLinkEvents() take a post ID as a parameter and use Ember.View.reopen event to get any rendered posts, I guess. For every post you already processed you could add a class / data attribute to mark it already processed to avoid looking for links multiple time.
setupLinkEvents
uses a selector, to attach the "tooltip" event (mouseenter, mouseout). you can call setupLinkEvents() many times and it is safe.line 37 from the gist
active_links = $(".track-link").not(".hasTooltipHND");
I think there's a new decoratePost function that you can use to get triggered on every post render.
Ideally I need to hook to an event when a topic finish rendering a batch of posts. I have to see what decoratePost do maybe I can use it when a signle post is updated.
-
I only mentioned it because I thought you load the remote post immediately instead of on mouseover. I skimmed it while still undercaffeinated and with a headache, so I missed out on that bit being inside the event handler. Whoops.
I still think you might want to do it, or make it configurable at least. Outside the cases where we abuse the links to other topics (which does happen but hey, this is TDWTF, dickweedery expected) it might be better to do that since it reduces the wait time on hover. Then again, you are fetching raw, that should be fast... Requires benchmarking methinks.
Ideally I need to hook to an event when a topic finish rendering a batch of posts.
IIRC, that's what
View.reopen
does. Well, it will do it again for any single updated post as well, so new posts will get processed as well. The downside is it renders the whole batch again so it is a bit more looping than required. Maybe thisdecoratePost
is a better option in this case. Maybe unbind the event bound inView.reopen
once it's done and binddecoratePost
after that?DISCLAIMER: Some of the things stated above are from my shaky memory. Take with a grain of salt. Shake before use.