This improves the chance that someone googling for a certain accessibility
attribute or other accessibility constant in order to find inspiration how to
implement it will find our code in OakTextView. It also makes the code more
understandable for reading by someone else, and generally follows the way
others write accessibility code (including Apple in their code samples). It
does make the code more verbose, but I think that does not outweight the above
advantages.
Inspired by: googling and "githubbing" for NSAccessibilityLinkTextAttribute:
http://lists.apple.com/archives/accessibility-dev/2014/Aug/msg00016.html
These methods were deprecated in 10.7. Use `convertRectToScreen:` and `convertRectFromScreen:` instead. This is required for proper high resolution support.
These methods were deprecated in 10.7 and log warnings in the console when called. The documentation says to use `convertPointToBacking:` and `convertPointFromBacking:`, respectively, instead; however, these methods should not really be used in this case. We just want to store the top left position (point) of the OakChoiceMenu's frame in the OakDocumentView's coordinate systems so we can update its frame to the new position when OakDocumentView's bounds change. We do not need exact pixel alignment. The original choice to use the above deprecated methods was probably based on the use of `convertBaseToScreen:` and `convertScreenToBase:`, but these were also deprecated in 10.7. They can be replaced with the equivalent `convertRectToScreen:` and `convertRectFromScreen:`, respectively.
So instead, for this case, `convertRect:toView:` and `convertRect:fromView:` suffices and actually yields better tracking. (We could have used the corresponding "point" methods, as well, but we needed to convert the point to a NSRect to use `convertScreenFromRect:`, etc.)
With the original code, when the view bounds change, the position of the OakChoiceMenu would extend well below/above the placement of the caret.
The latter has been deprecated since 10.6 but hasn’t given any deprecation warnings (and it’s not like I’m eager to touch the NSTextInput protocol implementation, as I just barely understand how this stuff is supposed to work).
This fixes an issue with complex input managers.
Using Chinese pinyin input and entering ‘ci’ followed by ‘1’ to insert first glyph would insert the glyph (‘刺’) and then set the pending marked range (0-2), which would have caret end up in the middle of a multi-byte sequence.
This makes Zoom support avoid doing all 2 conversions between UTF-8 to UTF-16,
and replaces call to rect_for_range with call to rect_at_index, which is
more efficient.
Note that this is a typical micro-optimization not resulting from any
actual performance measurement, but just from a desire to have a lean
code not doing redundant work.
When setSelectionString is called during editing of text (like inserting
or deleting a character), it catches layout in a semi-consistent state
where horizontal position of individual characters cannot be determined.
Therefore during such events, we cannot pass the correct screen position
to the call to UAZoomChangeFocus.
So let's do the UAZoomChangeFocus call after this iteration of run loop.
This ensures everything in layout that had to update has updated when
calling UAZoomChangeFocus, thus enabling us to provide correct horizontal
screen position.
This reduced the file size with more than 90%.
Since the PDF files are mapped into TextMate’s address space, it results in a reduction of memory usage.
This change was prompted by the appearance of the `tabSizePopUp` button in the status bar. After dismissing the menu, the title would be disabled.
To ensure we do not have similar issues elsewhere, let's prefer the use of `NULL` to `nop:` when assigning the action for menu items unless we are sure that the menu item should always be disabled (e.g., the item is used as a label).
I mainly dislike the trailing zeroes because CGFloat used to be a float but 1.0 is a double (1.0f would be a float). So better to under-specify and let the compiler figure out the proper type.
This is only when caret is at a word, when not on a word, we do not respond to the cancelOperation: method. This way, pressing escape in a window where another responder implements cancel:/cancelOperation: (e.g. commit window) the key will be handled by the other responder (and presumably close the window).
For example the bundle item “Execute Line / Selection” will (without a selection) show as “Execute Line” in the menu, and now also if the command causes the error sheet to appear or the user press ⌃C / ⌘. to prematurely kill it.
The standard doesn’t care which side the keyword is placed on, but placing it on the right makes it easier to read types.
E.g. reading “int const* const” from right to left we get “const pointer to const integer”.
We want to disable “make selection visible” when the user is drag-selecting, though the previous check was too broad and would disable it if user opened a document via double click (e.g. a find in folder result).
Previously it would just make sure the selection was visible, so if the symbol was already visible, no scrolling/centering would take place.
For most actions we want to minimize scrolling since it makes it easier to keep track of the location in the document, but for the “Go to …” actions, we’re doing an absolute positioning rather than a relative jump, so it makes sense to always center.
For bookmarks, it’s only when choosing a specific bookmark from the Navigation menu that we center selection, not when using the next/previous bookmark actions.
For example when caret is at the beginning of the document, using “move left” would be a no-op and would cause “refresh” to be skipped, which meant if the caret was outside the visible area, no scroll would happen (to make it visible).
We now rely on the table view to obtain the entries and setup the data cell, which should make the code easier to use for other table views with a different data source implementation.
