For the selection, I was thinking something like the Hightligther than would hold the selection until the Editor is disposed (either because an annotation was created or the action was cancelled.). I tried quickly to use directly the Highlighter plugin and it seemed to "work" but I would need only the display part of it and remove all event handler bound to it. If I have more time I'll probably work on this a bit. I agree with you that trying to hold the browser selection might be impossible if we only use the browser selection.
For the adder behavior, I'll try to open a PR tomorrow or next week to discuss that. I have a couple of idea but they don't really work if multiples bubble or items can be shown at the same time. I wanted to have the Adder, Editor and Viewer always on top and centered but it caused problems since can all appear at the same time on the version I am using. And yes, there's some polishing to do here to make sure it displays properly depending on the window. I had also problems where the body had a fixed width that was smaller than the window (like any support.apple.com pages) which caused a wrong placement. As for the last point, I agree that plugins should not know each other, but I feel there's something missing to coordinate the global behavior of the library. I wondered why I didn't see his PR... it's 4 hours old :). I'll definitely check it out. I'm still wondering if using master was the right choice at the beginning, but since I knew we would mosty certainly want to customize the behavior (which we did), the new version seemed to be better than v1 (better code organization and so on). Marc-Antoine Lemieux 2014-09-25 16:26 GMT-04:00 Randall Leeds <[email protected]>: > On Thu, Sep 25, 2014 at 1:14 PM, Marc-Antoine Lemieux < > [email protected]> wrote: > >> Here's the behavior I am talking about for the overlapping bubbles ( >> https://dl.dropboxusercontent.com/u/11784435/Selection_021.png). To be >> clear, there's always only one Editor bubble shown. It's the interactions >> with the Viewer and the Adder that are problematic. I also made sure it was >> instantiated only once. >> > > Ah, okay. > > I thought it wasn't possible for these things to be shown at the same > time. It may be a regression of sorts on master, even. > > >> >> As for the disappearing selection, I don't know what I can show you... >> it's only that the selection is "lost" when entering the comment and we had >> user that came back to us saying it was confusing and they'd prefer to have >> the selection there while they enter a comment. >> > > I understand. I'm not sure if there's anything that can be done for this > one, as I don't know how well we can prevent the selection from being lost > while typing and focusing the editor, although we could restore it > afterward probably. > > >> >> About the jumpy experience, we also had feedback from our users saying >> that when they hover an annotation and they mouseout and mouseenter >> against, the Viewer is just jumping from one place to another instead of >> staying in place. We had a similar comment about the Adder that appears >> where the cursor is instead of on a relative position to the annotation. We >> currently have a fix that is not working <= IE9 but it provides us an >> experience similar as the one on https://medium.com/. (gist of our >> solution: https://gist.github.com/lemieux/9470dcf998bfe90d4a45) >> Basically, it display the Adder icon always on top center of the annotation. >> > > Yeah! I saw your gist and I'm fond of the idea. Let's open a PR and > discuss how we can test it and also ensure it's always visible (I think it > may need some bounds clamping to ensure its on screen) > > >> About the display manager, it was only an idea on how to manage that >> stuff. Currently, it seems to me that plugins are "fighting" against each >> other for mouse events, display, etc. and I'm not too certain on how one >> plugin should tell another to hide or to move. >> > > Since you're keeping up with master, you _definitely_ want to check out > Nick's latest PR. We're attempting to finally clean this up nicely. > https://github.com/openannotation/annotator/pull/444 > > The idea is that plugins should not know about one another. Instead, > either a composite plugin that includes both or simply the application > should handle the coordination. So we could add a very lightweight amount > of "display management" code to the Default UI that simply ensures that > only one bubble is visible at a time, for instance. > > I'm sure Nick would be glad for more feedback, though. I know I would be. > This refactoring started months ago but I never had time to finish it up. > >
_______________________________________________ annotator-dev mailing list [email protected] https://lists.okfn.org/mailman/listinfo/annotator-dev Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev
