- 17 Mar, 2015 13 commits
-
-
Jake Hartnell authored
-
Jake Hartnell authored
Clean up and delete a few unneeded things.
-
Jake Hartnell authored
-
Jake Hartnell authored
-
Jake Hartnell authored
-
Jake Hartnell authored
-
Jake Hartnell authored
-
Jake Hartnell authored
-
Randall Leeds authored
-
Randall Leeds authored
-
Jake Hartnell authored
-
Jake Hartnell authored
-
Jake Hartnell authored
-
- 14 Mar, 2015 3 commits
-
-
Randall Leeds authored
-
Randall Leeds authored
Make the bridge service a factory instead
-
csillag authored
- Remove unused support for options - Simplify the handling of scope - Make it a simpleton, and register the class as the constructor function. Also updated all tests. Kudos to @tilgovi for the feedback and ideas.
-
- 13 Mar, 2015 2 commits
-
-
Randall Leeds authored
Fix sidebar's focusing on annotation cards
-
csillag authored
When the user moves the mouse over a highlight in the document, the corresponding annotation card (in the sidebar) is supposed to be highlighted, to indicate focus. Our mechanism for this was broken in 3 different ways: 1. AnnotationUI service's focusAnnotations() method was working with annotation IDs. However, annotations being created right now don't yet have ID, only tags. So we should be working with tags instead. (Like we are, in many other cases when cross-frame communication communication is done around annotations.) I fixed that, and also updated the corresponding tests. 2. In controllers.coffee, when we were trying to check if a given annotation has focus, we were using the tag value, while on the other hand, it was not the tag, but the id that was put into the map. Of course this didn't work. Since now we are consistently using the tag, no change was needed here. 3. We are putting $$tag:true pairs into the map, but when checking for membership, the `in` operator was used. That works for lists, but not for maps. For maps, we simply have to read out the value belonging to the given key, and see if it's true. After fixing these problems, the feature works again.
-
- 12 Mar, 2015 1 commit
-
-
Randall Leeds authored
Replace type() typechecks with isinstance()
-
- 11 Mar, 2015 5 commits
-
-
Randall Leeds authored
-
Randall Leeds authored
I will let it have its way.
-
Randall Leeds authored
That shaves ~50kB off the minified bundle. Close #2019
-
Randall Leeds authored
Fix #2013
-
Randall Leeds authored
Use the jQuery from `Annotator.$`.
-
- 07 Mar, 2015 1 commit
-
-
Randall Leeds authored
Remove dead things, move specific things, rename things. - Drop the unmaintained Vagrantfile - Drop the SSL cert - Drop MANIFEST.in for setuptools_git (Close #1329) - Move install docs into docs - Move config files into config
-
- 06 Mar, 2015 15 commits
-
-
Randall Leeds authored
Improve separation of h.api
-
Randall Leeds authored
Fix replies hover highlight
-
Nick Stenning authored
Clicking on the share icon didn't result in the share link being shown. For now, the simplest way to fix this is to ensure that we get the correct container element by using event.currentTarget (which will always be the <a> tag) rather than event.target (which might be the <i> tag).
-
Nick Stenning authored
Previously, the event from the initial click on the "share" event was swallowed by the click handler on the parent thread: https://github.com/hypothesis/h/blob/fef9f43/h/static/scripts/directives/thread.coffee#L198-L221 Removing this has meant that the share dialog never shows. Incidentally, this also fixes #1802, which was caused by the same code in the thread directive, which swallowed all click events from its children and hence prevented the closure of the share dialog.
-
Nick Stenning authored
The reply count being drawn in the thread directive causes display issues if we want it to be in its current position alongside the annotation controls. This change moves the responsibility for (optionally) drawing a reply count into the annotation directive. It results in simpler, clearer CSS and in particular makes it possible to trigger a click event on the reply count element.
-
Nick Stenning authored
It doesn't make any sense to uncollapse threads which have no replies, so bake this into the toggleCollapsed method of the ThreadController.
-
Nick Stenning authored
Refine extension differentiators
-
Randall Leeds authored
Thread collapse clarity (and code clarity improvements)
-
Nick Stenning authored
This moves almost all of the logic determining what bits of the thread to render when out from the template and into the controller where it belongs.
-
Nick Stenning authored
Make threads start collapsed. This is possible because it now doesn't affect the visibility of top-level cards.
-
Nick Stenning authored
The meaning of "collapsed" in the context of a thread was immensely confusing: - on a top-level annotation card it referred to whether replies were or were not shown - on a reply, it referred to whether or not the entire annotation was hidden This change removes all reference to the latter meaning. Annotations (and replies) are still hidden appropriately when searches are performed, but now collapsing and uncollapsing refers only to the visibility of the *replies* of the addressed thread.
-
Nick Stenning authored
With the viewer template managing the root container, this is no longer necessary.
-
Nick Stenning authored
-
Nick Stenning authored
This stops thread cards with no replies changing in height when clicked.
-
Nick Stenning authored
Also removes one unnecessary ng-hide directive.
-