Discussion:
[Skim-app-develop] Skim on Mavericks
Christiaan Hofman
2013-11-08 10:26:05 UTC
Permalink
Does anyone here have Mavericks? There seem to be some problems with the note tool mode on 10.9. But it is impossible for me to debug that.

Christiaan
Adam R. Maxwell
2013-11-08 13:53:13 UTC
Permalink
Yeah, I have it. I could look at it this weekend, I think.
Post by Christiaan Hofman
Does anyone here have Mavericks? There seem to be some problems with the note tool mode on 10.9. But it is impossible for me to debug that.
Christiaan
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
skim-app-develop mailing list
https://lists.sourceforge.net/lists/listinfo/skim-app-develop
Christiaan Hofman
2013-11-08 14:00:46 UTC
Permalink
Post by Adam R. Maxwell
Yeah, I have it. I could look at it this weekend, I think.
Post by Christiaan Hofman
Does anyone here have Mavericks? There seem to be some problems with the note tool mode on 10.9. But it is impossible for me to debug that.
Christiaan
Thanks. The problem seems to be a hang. As both adding notes and resizing/moving notes works, the only two things I can think of are:
1. Maybe PDFView has problems with zero-size notes, which is the initial size in note tool mode.
2. Perhaps it hangs on the- nextEventMatchingMask:... call in doSelectAnnotationWithEvent:.

Christiaan
Adam R. Maxwell
2013-11-09 04:19:11 UTC
Permalink
Post by Christiaan Hofman
1. Maybe PDFView has problems with zero-size notes, which is the initial size in note tool mode.
This seems to be the problem. If I set a minimum size like so:

- (void)addAnnotationWithType:(SKNoteType)annotationType contents:(NSString *)text page:(PDFPage *)page bounds:(NSRect)bounds {
PDFAnnotation *newAnnotation = nil;
PDFSelection *sel = [self currentSelection];
if (NSIsEmptyRect(bounds)) {
bounds.size.height = MAX(bounds.size.height, 5);
bounds.size.width = MAX(bounds.size.width, 5);
}

the problem goes away. Note that a minimum size of 1 will still cause a hang, and initial resizing is a bit weird; if you drag it diagonally or horizontally, the circle only stretches vertically. After releasing the mouse and dragging again, diagonal resize works. Might be something with the mouse location; I didn't look too hard.

Adam
Christiaan Hofman
2013-11-09 10:08:24 UTC
Permalink
Post by Adam R. Maxwell
Post by Christiaan Hofman
1. Maybe PDFView has problems with zero-size notes, which is the initial size in note tool mode.
- (void)addAnnotationWithType:(SKNoteType)annotationType contents:(NSString *)text page:(PDFPage *)page bounds:(NSRect)bounds {
PDFAnnotation *newAnnotation = nil;
PDFSelection *sel = [self currentSelection];
if (NSIsEmptyRect(bounds)) {
bounds.size.height = MAX(bounds.size.height, 5);
bounds.size.width = MAX(bounds.size.width, 5);
}
the problem goes away. Note that a minimum size of 1 will still cause a hang, and initial resizing is a bit weird; if you drag it diagonally or horizontally, the circle only stretches vertically. After releasing the mouse and dragging again, diagonal resize works. Might be something with the mouse location; I didn't look too hard.
Adam
The latter problem is because the resizing takes a zero size as a sign that this is just added by the tool mode and therefore adapts the drag handle to the drag direction rather than having it fixed (in dragAnnotationWithEvent:). So much more should be changed if the initial size is changed.

I wonder what really gets the problem: drawing the small note, or perhaps the redisplay. What happens if you change in PDFView(SKExtensions) setNeedsDisplayForAnnotation:onPage:, or perhaps setNeedsDisplayInRect:ofPage: to handle small notes differently?

Christiaan
Christiaan Hofman
2013-11-09 11:56:58 UTC
Permalink
Post by Christiaan Hofman
Post by Adam R. Maxwell
Post by Christiaan Hofman
1. Maybe PDFView has problems with zero-size notes, which is the initial size in note tool mode.
- (void)addAnnotationWithType:(SKNoteType)annotationType contents:(NSString *)text page:(PDFPage *)page bounds:(NSRect)bounds {
PDFAnnotation *newAnnotation = nil;
PDFSelection *sel = [self currentSelection];
if (NSIsEmptyRect(bounds)) {
bounds.size.height = MAX(bounds.size.height, 5);
bounds.size.width = MAX(bounds.size.width, 5);
}
the problem goes away. Note that a minimum size of 1 will still cause a hang, and initial resizing is a bit weird; if you drag it diagonally or horizontally, the circle only stretches vertically. After releasing the mouse and dragging again, diagonal resize works. Might be something with the mouse location; I didn't look too hard.
Adam
The latter problem is because the resizing takes a zero size as a sign that this is just added by the tool mode and therefore adapts the drag handle to the drag direction rather than having it fixed (in dragAnnotationWithEvent:). So much more should be changed if the initial size is changed.
I wonder what really gets the problem: drawing the small note, or perhaps the redisplay. What happens if you change in PDFView(SKExtensions) setNeedsDisplayForAnnotation:onPage:, or perhaps setNeedsDisplayInRect:ofPage: to handle small notes differently?
Christiaan
And be careful, setNeedsDisplayForAnnotation:onPage: has an override in SKPDFView.

Christiaan
Adam R. Maxwell
2013-11-09 22:05:09 UTC
Permalink
Post by Christiaan Hofman
The latter problem is because the resizing takes a zero size as a sign that this is just added by the tool mode and therefore adapts the drag handle to the drag direction rather than having it fixed (in dragAnnotationWithEvent:). So much more should be changed if the initial size is changed.
I wonder what really gets the problem: drawing the small note, or perhaps the redisplay. What happens if you change in PDFView(SKExtensions) setNeedsDisplayForAnnotation:onPage:, or perhaps setNeedsDisplayInRect:ofPage: to handle small notes differently?
I think it's a drawing issue. From the sample, it looks to me like they've got a math issue in spline interpolation, if you look at where it's hanging. I'm not sure what to try in the display methods to work around that.

Also, the tests for "Debug" in the build shell scripts no longer work in Xcode 5, which explains why it was taking so damn long to build each time. BUILD_STYLE is no longer set, and CONFIGURATION seems to be the appropriate variable. This makes debugging much less painful, though Xcode 4 & 5…ugh.

Sample of hanging thread below; tried as attachment, but apparently we have a 40kb message limit. Welcome to 1996.

Sampling process 96703 for 3 seconds with 1 millisecond of run time between samples
Sampling completed, processing symbols...
Analysis of sampling Skim (pid 96703) every 1 millisecond
Process: Skim [96703]
Path: /Volumes/Local/Users/amaxwell/BuildProducts/Debug/Skim.app/Contents/MacOS/Skim
Load Address: 0x100000000
Identifier: net.sourceforge.skim-app.skim
Version: 1.4.6 (80)
Code Type: X86-64
Parent Process: debugserver [96702]

Date/Time: 2013-11-09 13:55:20.578 -0800
OS Version: Mac OS X 10.9 (13A603)
Report Version: 7

Call graph:
1859 Thread_3605499 DispatchQueue_1: com.apple.main-thread (serial)
+ 1859 start (in Skim) + 52 [0x1000020c4]
+ 1859 main (in Skim) + 34 [0x100013f52] main.m:15
+ 1859 NSApplicationMain (in AppKit) + 940 [0x7fff87180803]
+ 1859 -[NSApplication run] (in AppKit) + 646 [0x7fff87195a29]
+ 1859 -[SKApplication sendEvent:] (in Skim) + 469 [0x100086d15] SKApplication.m:70
+ 1859 -[NSApplication sendEvent:] (in AppKit) + 2021 [0x7fff87345744]
+ 1859 -[SKMainWindow sendEvent:] (in Skim) + 571 [0x1000b339b] SKMainWindow.m:58
+ 1859 -[NSWindow sendEvent:] (in AppKit) + 11296 [0x7fff873a6d08]
+ 1859 forwardMethod (in AppKit) + 122 [0x7fff873a2d9a]
+ 1859 forwardMethod (in AppKit) + 122 [0x7fff873a2d9a]
+ 1859 forwardMethod (in AppKit) + 122 [0x7fff873a2d9a]
+ 1859 forwardMethod (in AppKit) + 122 [0x7fff873a2d9a]
+ 1859 -[SKPDFView mouseDown:] (in Skim) + 2898 [0x1000417d2] SKPDFView.m:1163
+ 1859 -[SKPDFView doDragAnnotationWithEvent:] (in Skim) + 1082 [0x100056a6a] SKPDFView.m:3002
+ 1859 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] (in AppKit) + 122 [0x7fff871a18db]
+ 1859 _DPSNextEvent (in AppKit) + 1434 [0x7fff871a228e]
+ 1859 _BlockUntilNextEventMatchingListInModeWithFilter (in HIToolbox) + 65 [0x7fff826e7abc]
+ 1859 ReceiveNextEventCommon (in HIToolbox) + 173 [0x7fff826e7b85]
+ 1859 RunCurrentEventLoopInMode (in HIToolbox) + 226 [0x7fff826e7f0d]
+ 1859 CFRunLoopRunSpecific (in CoreFoundation) + 309 [0x7fff8b82e275]
+ 1859 __CFRunLoopRun (in CoreFoundation) + 776 [0x7fff8b82e7b8]
+ 1859 __CFRunLoopDoObservers (in CoreFoundation) + 391 [0x7fff8b83d017]
+ 1859 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ (in CoreFoundation) + 23 [0x7fff8b83d0a7]
+ 1859 __83-[NSWindow _postWindowNeedsDisplayOrLayoutOrUpdateConstraintsUnlessPostingDisabled]_block_invoke1331 (in AppKit) + 46 [0x7fff87912cd1]
+ 1859 _handleWindowNeedsDisplayOrLayoutOrUpdateConstraints (in AppKit) + 884 [0x7fff8733e89e]
+ 1859 -[NSView displayIfNeeded] (in AppKit) + 1680 [0x7fff872d963a]
+ 1859 -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] (in AppKit) + 2828 [0x7fff872fa209]
+ 1859 -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] (in AppKit) + 314 [0x7fff872fd201]
+ 1859 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] (in AppKit) + 6151 [0x7fff872fef0e]
+ 1859 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] (in AppKit) + 6151 [0x7fff872fef0e]
+ 1859 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] (in AppKit) + 6151 [0x7fff872fef0e]
+ 1859 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] (in AppKit) + 6151 [0x7fff872fef0e]
+ 1859 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] (in AppKit) + 6151 [0x7fff872fef0e]
+ 1859 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] (in AppKit) + 6151 [0x7fff872fef0e]
+ 1859 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] (in AppKit) + 3199 [0x7fff872fe386]
+ 1859 -[NSView _drawRect:clip:] (in AppKit) + 422 [0x7fff8730069b]
+ 1859 -[NSView(NSLayerKitGlue) _drawRectAsLayerTree:] (in AppKit) + 591 [0x7fff873019a2]
+ 1859 CA::Transaction::commit() (in QuartzCore) + 388 [0x7fff81a78016]
+ 1859 CA::Context::commit_transaction(CA::Transaction*) (in QuartzCore) + 236 [0x7fff81a7837c]
+ 1859 CA::Layer::layout_and_display_if_needed(CA::Transaction*) (in QuartzCore) + 35 [0x7fff81a788f1]
+ 1859 CA::Layer::display_if_needed(CA::Transaction*) (in QuartzCore) + 590 [0x7fff81a791a2]
+ 1859 -[_NSTiledLayer display] (in AppKit) + 404 [0x7fff873528e8]
+ 1859 -[_NSTiledLayerContents update:] (in AppKit) + 5545 [0x7fff87354175]
+ 1859 -[NSTileLayer display] (in AppKit) + 119 [0x7fff87357ccf]
+ 1859 CA::Layer::display_() (in QuartzCore) + 1539 [0x7fff81a79a6b]
+ 1859 x_blame_allocations (in QuartzCore) + 84 [0x7fff81a79f5c]
+ 1859 ___ZN2CA5Layer8display_Ev_block_invoke (in QuartzCore) + 59 [0x7fff81a79fa0]
+ 1859 CABackingStoreUpdate_ (in QuartzCore) + 2220 [0x7fff81a7a852]
+ 1859 -[NSTileLayer drawInContext:] (in AppKit) + 169 [0x7fff87b2c565]
+ 1859 -[CALayer drawInContext:] (in QuartzCore) + 115 [0x7fff81a7bcc9]
+ 1859 -[_NSTiledLayerContents drawLayer:inContext:] (in AppKit) + 172 [0x7fff87357dbc]
+ 1859 -[_NSTiledLayer drawTile:inContext:] (in AppKit) + 654 [0x7fff873580b8]
+ 1859 -[CALayer drawInContext:] (in QuartzCore) + 115 [0x7fff81a7bcc9]
+ 1859 -[_NSBackingLayerContents drawLayer:inContext:] (in AppKit) + 149 [0x7fff8735857c]
+ 1859 -[NSView(NSLayerKitGlue) drawLayer:inContext:] (in AppKit) + 108 [0x7fff87302848]
+ 1859 -[NSView(NSLayerKitGlue) _drawViewBackingLayer:inContext:drawingHandler:] (in AppKit) + 2297 [0x7fff87303153]
+ 1859 __46-[NSView(NSLayerKitGlue) drawLayer:inContext:]_block_invoke (in AppKit) + 186 [0x7fff8730336d]
+ 1859 -[NSView(NSInternal) _recursive:displayRectIgnoringOpacity:inGraphicsContext:CGContext:topView:shouldChangeFontReferenceColor:] (in AppKit) + 1843 [0x7fff87303bb0]
+ 1859 -[NSView(NSInternal) _recursive:displayRectIgnoringOpacity:inGraphicsContext:CGContext:topView:shouldChangeFontReferenceColor:] (in AppKit) + 1075 [0x7fff873038b0]
+ 1859 -[PDFDisplayView drawRect:] (in PDFKit) + 1779 [0x7fff87f74c64]
+ 1859 -[PDFDisplayView drawPDFHighLevel:] (in PDFKit) + 138 [0x7fff87f74e15]
+ 1859 -[SKPDFView drawPage:] (in Skim) + 313 [0x10003ac19] SKPDFView.m:385
+ 1859 -[PDFView drawPage:] (in PDFKit) + 196 [0x7fff87f8e642]
+ 1859 -[SKPDFPage drawWithBox:] (in Skim) + 418 [0x1001934f2] SKPDFPage.m:93
+ 1859 -[PDFPage(PDFPagePrivate) drawWithBox:inContext:] (in PDFKit) + 2553 [0x7fff87f43f0d]
+ 1859 -[PDFPage(PDFPagePrivate) drawAnnotationsWithBox:] (in PDFKit) + 392 [0x7fff87f434bb]
+ 1859 -[PDFAnnotationCircle drawWithBox:inContext:] (in PDFKit) + 1126 [0x7fff87f59a96]
+ 1859 CGContextDrawPath (in CoreGraphics) + 192 [0x7fff8577f361]
+ 1859 ripc_DrawPath (in libRIP.A.dylib) + 343 [0x7fff8896f9ab]
+ 1859 RIPRenderPath (in libRIP.A.dylib) + 137 [0x7fff88958c26]
+ 1859 CGPathApply (in CoreGraphics) + 46 [0x7fff85720724]
+ 1859 CG::Path::Ellipse::apply(void*, void (*)(void*, CGPathElementType, CGPoint const*)) const (in CoreGraphics) + 72 [0x7fff857ca172]
+ 1859 CG::Path::Sequence::apply(void*, void (*)(void*, CGPathElementType, CGPoint const*)) const (in CoreGraphics) + 41 [0x7fff85721995]
+ 1859 CG::Path::Subpath::apply(void*, void (*)(void*, CGPathElementType, CGPoint const*)) const (in CoreGraphics) + 42 [0x7fff857219d4]
+ 1859 CG::Chunk::apply(void*, void (*)(void*, CGPathElementType, CGPoint const*)) const (in CoreGraphics) + 53 [0x7fff85721a1d]
+ 1859 (anonymous namespace)::adaptor::callback(void*, CGPathElementType, CGPoint const*) (in CoreGraphics) + 171 [0x7fff85721aff]
+ 1859 path_iterator_add_curve_to_point (in CoreGraphics) + 81 [0x7fff8576f311]
+ 1859 CG::stroker::add_curve_to_point(CGPoint const*) (in CoreGraphics) + 151 [0x7fff85792893]
+ 1859 CG::stroker::add_cubic_segment(CG::Cubic const&) (in CoreGraphics) + 1103 [0x7fff85792e1d]
+ 1859 CG::stroker::path_stroke_round_cube(CG::Cubic const&) (in CoreGraphics) + 556 [0x7fff857936ae]
+ 1859 CG::stroker::path_stroke_round_cube_offset(CG::Cubic const&, int, int) (in CoreGraphics) + 1039 [0x7fff85793b2f]
+ 1859 CG::Cubic::is_near(CG::Point const&, double, double) const (in CoreGraphics) + 873,839,... [0x7fff857944f7,0x7fff857944d5,...]
Christiaan Hofman
2013-11-09 22:26:34 UTC
Permalink
Post by Adam R. Maxwell
Post by Christiaan Hofman
The latter problem is because the resizing takes a zero size as a sign that this is just added by the tool mode and therefore adapts the drag handle to the drag direction rather than having it fixed (in dragAnnotationWithEvent:). So much more should be changed if the initial size is changed.
I wonder what really gets the problem: drawing the small note, or perhaps the redisplay. What happens if you change in PDFView(SKExtensions) setNeedsDisplayForAnnotation:onPage:, or perhaps setNeedsDisplayInRect:ofPage: to handle small notes differently?
I think it's a drawing issue. From the sample, it looks to me like they've got a math issue in spline interpolation, if you look at where it's hanging. I'm not sure what to try in the display methods to work around that.
I was thinking of checking the aRect in [PDFView(SKExtensions) setNeedsDisplayForRect:ofPage:], and make it larger when it's too small. But when it's the drawing of the note that would not make any difference.

But I have an idea for an alternative, adding the note in dragAnnotationWithEvent: instead at the first mouseDragged.
Post by Adam R. Maxwell
Also, the tests for "Debug" in the build shell scripts no longer work in Xcode 5, which explains why it was taking so damn long to build each time. BUILD_STYLE is no longer set, and CONFIGURATION seems to be the appropriate variable. This makes debugging much less painful, though Xcode 4 & 5…ugh.
Does the test [ "${BUILD_STYLE}" = "Debug" -o "${CONFIGURATION}" = "Debug" ] work for this?

Christiaan
Adam R. Maxwell
2013-11-09 22:43:28 UTC
Permalink
Post by Christiaan Hofman
But I have an idea for an alternative, adding the note in dragAnnotationWithEvent: instead at the first mouseDragged.
Let me know what you want me to try; I'm not familiar enough with the code anymore to do much without flailing around :).
Post by Christiaan Hofman
Post by Adam R. Maxwell
Also, the tests for "Debug" in the build shell scripts no longer work in Xcode 5, which explains why it was taking so damn long to build each time. BUILD_STYLE is no longer set, and CONFIGURATION seems to be the appropriate variable. This makes debugging much less painful, though Xcode 4 & 5…ugh.
Does the test [ "${BUILD_STYLE}" = "Debug" -o "${CONFIGURATION}" = "Debug" ] work for this?
Yeah, that seems to do it.

There are also some codesign issues to deal with for Mavericks.

http://furbo.org/2013/10/17/code-signing-and-mavericks/

Here's what I use in TeX Live Utility for frameworks:

LOCATION="${BUILT_PRODUCTS_DIR}"/"${FRAMEWORKS_FOLDER_PATH}"
IDENTITY="TeX Live Utility Signing Certificate"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/Sparkle.framework/Versions/A"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/FileView.framework/Versions/A"

and for auxiliary executables:

LOCATION="${BUILT_PRODUCTS_DIR}"/"${EXECUTABLE_FOLDER_PATH}"
IDENTITY="TeX Live Utility Signing Certificate"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/python_version.py"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/uninstall_local_agent.sh"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/parse_tlpdb.py"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/agent_installer.py"

My Foundation helper tool is signed separately and has an embedded Info.plist. Not sure if you'd need to do that for helper tools.

Finally, if you're managing localized strings files manually, I've got a Python program that updates them. Looks like it chokes on some of Skim's, so I'll look at that; let me know if you're interested or grab it from the mactlmgr repo.

Adam
Christiaan Hofman
2013-11-09 23:10:30 UTC
Permalink
Post by Adam R. Maxwell
Post by Christiaan Hofman
But I have an idea for an alternative, adding the note in dragAnnotationWithEvent: instead at the first mouseDragged.
Let me know what you want me to try; I'm not familiar enough with the code anymore to do much without flailing around :).
I changed the code in the HEAD. So please update and try it out. It should fix the problem is it's the drawing problem.
Post by Adam R. Maxwell
Post by Christiaan Hofman
Post by Adam R. Maxwell
Also, the tests for "Debug" in the build shell scripts no longer work in Xcode 5, which explains why it was taking so damn long to build each time. BUILD_STYLE is no longer set, and CONFIGURATION seems to be the appropriate variable. This makes debugging much less painful, though Xcode 4 & 5…ugh.
Does the test [ "${BUILD_STYLE}" = "Debug" -o "${CONFIGURATION}" = "Debug" ] work for this?
Yeah, that seems to do it.
There are also some codesign issues to deal with for Mavericks.
http://furbo.org/2013/10/17/code-signing-and-mavericks/
LOCATION="${BUILT_PRODUCTS_DIR}"/"${FRAMEWORKS_FOLDER_PATH}"
IDENTITY="TeX Live Utility Signing Certificate"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/Sparkle.framework/Versions/A"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/FileView.framework/Versions/A"
LOCATION="${BUILT_PRODUCTS_DIR}"/"${EXECUTABLE_FOLDER_PATH}"
IDENTITY="TeX Live Utility Signing Certificate"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/python_version.py"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/uninstall_local_agent.sh"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/parse_tlpdb.py"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/agent_installer.py"
My Foundation helper tool is signed separately and has an embedded Info.plist. Not sure if you'd need to do that for helper tools.
Finally, if you're managing localized strings files manually, I've got a Python program that updates them. Looks like it chokes on some of Skim's, so I'll look at that; let me know if you're interested or grab it from the mactlmgr repo.
Adam
Thanks, I'll have to look into that.

Christiaan
Christiaan Hofman
2013-11-09 23:19:22 UTC
Permalink
Post by Adam R. Maxwell
Post by Christiaan Hofman
But I have an idea for an alternative, adding the note in dragAnnotationWithEvent: instead at the first mouseDragged.
Let me know what you want me to try; I'm not familiar enough with the code anymore to do much without flailing around :).
Post by Christiaan Hofman
Post by Adam R. Maxwell
Also, the tests for "Debug" in the build shell scripts no longer work in Xcode 5, which explains why it was taking so damn long to build each time. BUILD_STYLE is no longer set, and CONFIGURATION seems to be the appropriate variable. This makes debugging much less painful, though Xcode 4 & 5…ugh.
Does the test [ "${BUILD_STYLE}" = "Debug" -o "${CONFIGURATION}" = "Debug" ] work for this?
Yeah, that seems to do it.
There are also some codesign issues to deal with for Mavericks.
http://furbo.org/2013/10/17/code-signing-and-mavericks/
LOCATION="${BUILT_PRODUCTS_DIR}"/"${FRAMEWORKS_FOLDER_PATH}"
IDENTITY="TeX Live Utility Signing Certificate"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/Sparkle.framework/Versions/A"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/FileView.framework/Versions/A"
LOCATION="${BUILT_PRODUCTS_DIR}"/"${EXECUTABLE_FOLDER_PATH}"
IDENTITY="TeX Live Utility Signing Certificate"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/python_version.py"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/uninstall_local_agent.sh"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/parse_tlpdb.py"
codesign --verbose --force --sign "$IDENTITY" "$LOCATION/agent_installer.py"
My Foundation helper tool is signed separately and has an embedded Info.plist. Not sure if you'd need to do that for helper tools.
Finally, if you're managing localized strings files manually, I've got a Python program that updates them. Looks like it chokes on some of Skim's, so I'll look at that; let me know if you're interested or grab it from the mactlmgr repo.
Adam
BTW, do the plugins (importer, auicklook) and the displayline script also need to be signed this way?

Christiaan
Adam R. Maxwell
2013-11-09 23:28:53 UTC
Permalink
Looks like you've fixed the circle annotation bug! Tip of trunk works for me on 10.9, now. I checked text/box/underline also, just for the heck of it.
Post by Christiaan Hofman
Post by Adam R. Maxwell
Finally, if you're managing localized strings files manually, I've got a Python program that updates them. Looks like it chokes on some of Skim's, so I'll look at that; let me know if you're interested or grab it from the mactlmgr repo.
I've kind of fixed some of the problems…it assumed UTF-8 encoding. Looks like the cs.lproj/Localizable.strings isn't included in the Xcode project?
Post by Christiaan Hofman
BTW, do the plugins (importer, auicklook) and the displayline script also need to be signed this way?
The plugins should be signed, I believe. For scripts, I'm honestly not sure. I signed mine, but haven't gone looking for the documentation on it (if it even exists).

adam
Christiaan Hofman
2013-11-09 23:38:57 UTC
Permalink
Post by Adam R. Maxwell
Looks like you've fixed the circle annotation bug! Tip of trunk works for me on 10.9, now. I checked text/box/underline also, just for the heck of it.
Great!
Post by Adam R. Maxwell
Post by Christiaan Hofman
Post by Adam R. Maxwell
Finally, if you're managing localized strings files manually, I've got a Python program that updates them. Looks like it chokes on some of Skim's, so I'll look at that; let me know if you're interested or grab it from the mactlmgr repo.
What exactly does this script update? There is a built in script phase that updates (english) .strings files from .xib files.
Post by Adam R. Maxwell
I've kind of fixed some of the problems…it assumed UTF-8 encoding. Looks like the cs.lproj/Localizable.strings isn't included in the Xcode project?
All strings files are in UTF-16, that is what the documentation recommends (at least here), and also what ibtool gives.
Post by Adam R. Maxwell
Post by Christiaan Hofman
BTW, do the plugins (importer, auicklook) and the displayline script also need to be signed this way?
The plugins should be signed, I believe. For scripts, I'm honestly not sure. I signed mine, but haven't gone looking for the documentation on it (if it even exists).
adam
Adam R. Maxwell
2013-11-09 23:55:30 UTC
Permalink
Post by Christiaan Hofman
What exactly does this script update? There is a built in script phase that updates (english) .strings files from .xib files.
It reads the english Localizable.strings file and looks for missing (and extra) keys in translated Localizable.strings files. Missing keys are appended to the end of the translated files, and it gives warnings about extras.
Post by Christiaan Hofman
Post by Adam R. Maxwell
I've kind of fixed some of the problems…it assumed UTF-8 encoding. Looks like the cs.lproj/Localizable.strings isn't included in the Xcode project?
All strings files are in UTF-16, that is what the documentation recommends (at least here), and also what ibtool gives.
Huh. I switched to utf-8 because of this

http://lists.apple.com/archives/xcode-users/2011/Sep/msg00189.html

and also because utf-8 plays better with localizers and is diffable in subversion. I had problems with translators screwing up the UTF-16 BE/LE, and it was a mess. I have to run iconv on genstrings output, though, which is a nuisance.

adam
Christiaan Hofman
2013-11-09 23:53:00 UTC
Permalink
Post by Adam R. Maxwell
Looks like you've fixed the circle annotation bug! Tip of trunk works for me on 10.9, now. I checked text/box/underline also, just for the heck of it.
Post by Christiaan Hofman
Post by Adam R. Maxwell
Finally, if you're managing localized strings files manually, I've got a Python program that updates them. Looks like it chokes on some of Skim's, so I'll look at that; let me know if you're interested or grab it from the mactlmgr repo.
I've kind of fixed some of the problems…it assumed UTF-8 encoding. Looks like the cs.lproj/Localizable.strings isn't included in the Xcode project?
The cs.lproj is not maintained, so none of it is included in the Xcode project. The files are still there in the repository though.
Post by Adam R. Maxwell
Post by Christiaan Hofman
BTW, do the plugins (importer, auicklook) and the displayline script also need to be signed this way?
The plugins should be signed, I believe. For scripts, I'm honestly not sure. I signed mine, but haven't gone looking for the documentation on it (if it even exists).
adam
Actually, it does not let me sign these plugins, codesign says the contents is unsuitable.

Christiaan
Adam R. Maxwell
2013-11-09 23:57:32 UTC
Permalink
Post by Christiaan Hofman
Actually, it does not let me sign these plugins, codesign says the contents is unsuitable.
I sign Spotlight/QL plugins by setting a certificate in the project inspector, and it doesn't complain. Whether it actually does anything, I don't know…signing is kind of a mess as far as I'm concerned.
Christiaan Hofman
2013-11-10 00:17:22 UTC
Permalink
Post by Adam R. Maxwell
Post by Christiaan Hofman
Actually, it does not let me sign these plugins, codesign says the contents is unsuitable.
I sign Spotlight/QL plugins by setting a certificate in the project inspector, and it doesn't complain. Whether it actually does anything, I don't know…signing is kind of a mess as far as I'm concerned.
OK, I did it from the Skim project. From their own projects it works.

Christiaan
Christiaan Hofman
2013-11-10 00:30:34 UTC
Permalink
Post by Adam R. Maxwell
Post by Christiaan Hofman
Actually, it does not let me sign these plugins, codesign says the contents is unsuitable.
I sign Spotlight/QL plugins by setting a certificate in the project inspector, and it doesn't complain. Whether it actually does anything, I don't know…signing is kind of a mess as far as I'm concerned.
I wonder if this signing stuff is related to Gatekeeper complaining on 10.9 about the updated Skim.

And do you know if the expiration date for the certificate is crucial? I saw that mine is to expire at the end of the year. Is it possible to extend a certificate, i.e. using the same keys?

Christiaan
Adam R. Maxwell
2013-11-10 00:35:31 UTC
Permalink
Post by Christiaan Hofman
I wonder if this signing stuff is related to Gatekeeper complaining on 10.9 about the updated Skim.
Could well be. I didn't have any problems in that regard with TLU, but released a new version soon after 10.9 came out.
Post by Christiaan Hofman
And do you know if the expiration date for the certificate is crucial? I saw that mine is to expire at the end of the year. Is it possible to extend a certificate, i.e. using the same keys?
AFAIK, you have to create a new cert. I think you used to be able to keep signing with the expired one; pretty sure I accidentally did that with BibDesk for a while.

Adam

Loading...