Cocoa with Xcode 10

[Neil Hodgson]

Xcode 10 was released recently and there were some warnings when building Scintilla.

One warning that appears is “Enable Base Internationalization”. This refers to a particular way of doing localization but currently Scintilla doesn’t do any localization or even have the .xib or .storyboard files that are the focus of Base Internationalization. A .xib file could be added and the “Use Base Internationalization” check box ticked. There are some literal strings provided for accessibility (“Scintilla”, “Scintilla Margin”, “source code editor”) that could potentially be localized into other languages.

However, this option requires macOS 10.8 so that would mean dropping 10.7. I haven’t yet managed to make a minimal .xib file that enables the option to work.

https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/InternationalizingYourUserInterface/InternationalizingYourUserInterface.html

There were also some warnings from the new version of Clang (negative shifts and reads of uninitialized values) in lexers (C++, Fortran, Verilog). These were fixed in:
https://sourceforge.net/p/scintilla/code/ci/d9edff9c928db83a99ab54355abe7e783e85648d/
https://sourceforge.net/p/scintilla/code/ci/041e498f21d3509aa148e19d783e88167fe8b25b/

Neil

[Chinh Nguyen]

The biggest issue with compiling Scintilla with Xcode 10 is that if you run your application on macOS Mojave, the ScintillaView's content is partially obscured by the margin view due to what I think is a bug in Mojave. I last checked with Mojave developer beta 11 and the bug still exists and I filed yet another bug report with Apple.

[Neil Hodgson]

Chinh Nguyen:

> The biggest issue with compiling Scintilla with Xcode 10 is that if you run your application on macOS Mojave, the ScintillaView's content is partially obscured by the margin view due to what I think is a bug in Mojave.

Starting behaviour can be improved with some rearrangement in the example and in Scintilla. For the ScintillaTest example, move the content setting after the margin setup so that the initial reset of the view parameters uses the full margin including line numbers.

diff -r 041e498f21d3 cocoa/ScintillaTest/AppController.mm
--- a/cocoa/ScintillaTest/AppController.mm Tue Sep 18 13:00:08 2018 +1000
+++ b/cocoa/ScintillaTest/AppController.mm Wed Sep 26 18:21:01 2018 +1000
@@ -74,10 +74,10 @@
// Let's load some text for the editor, as initial content.
NSString *sql = [self exampleText];

+ [self setupEditor];
+
[mEditor setString: sql];

- [self setupEditor];
-
sciExtra = nil;
}

Inside ScintillaCocoa::SetScrollingSize, move setting the margin width to before the change to the views.

diff -r 041e498f21d3 cocoa/ScintillaCocoa.mm
--- a/cocoa/ScintillaCocoa.mm Tue Sep 18 13:00:08 2018 +1000
+++ b/cocoa/ScintillaCocoa.mm Wed Sep 26 18:21:01 2018 +1000
@@ -1874,6 +1875,7 @@
bool ScintillaCocoa::SetScrollingSize(void) {
bool changes = false;
SCIContentView *inner = ContentView();
+ [sciView setMarginWidth: vs.fixedColumnWidth];
if (!enteredSetScrollingSize) {
enteredSetScrollingSize = true;
NSScrollView *scrollView = ScrollContainer();
@@ -1905,7 +1907,6 @@
SetVerticalScrollPos();
enteredSetScrollingSize = false;
}
- [sciView setMarginWidth: vs.fixedColumnWidth];
return changes;
}

However, that just makes startup look better.

The main problem appears to be a change in the rectangles of the views involved with negative coordinates used where they weren’t before. I am still quite confused though.

Neil

[Neil Hodgson]

The attached patch seems to fix the worst parts of the positioning problem. It adds the margin width to the ‘VisibleOriginInMain’ then subtracts it when horizontally scrolling. The setting of the margin width is moved earlier to ensure it is consistent - it may be better to make the margin read the ViewStyle::fixedColumnWidth instead of caching the value. I am still confused about what is occurring.

There is a problem with the patch that cursoring off the right doesn’t scroll at the correct point - the margin width likely needs to be taken into account there as well.

People using Cocoa with Xcode 10 should try this to ensure I am moving in a reasonable direction. We’ll also need to check on other versions of OS X - I only have a development system on 10.14 and an old box running 10.11.

Neil

[Chinh Nguyen]

I installed the 10.14.1 beta and the problem still exists. While filling out yet another bug report, I decided to add a checkbox to the test application that I submit with my bug reports that would allow the user to hide/show the vertical ruler.

This was really helpful because I could see that the ruler obscuring the document seems to be intentional. In previous versions of macOS prior to Mojave, the document would be repositioned as the rulers are made visible/hidden but now in Mojave, the document stays put. In Mojave, rulers have the vibrancy effect so when they overlay the document, you can see the part of the document underneath the ruler blurred out.

I'm guessing it's up to us to reposition the contentView but I checked the 10.14 Appkit notes and they make no mention of this. I've been searching the relevant header files for 10_14 to look for new APIs but don't see anything.

I've been comparing how contentInsets behaves for NSScrollView and NSClipView in Mojave and High Sierra and seeing different results. I've been playing around with automaticallyAdjustsContentInsets and contentInsets and seem to be getting somewhere. I'll report back if I make any progress.

[Mike Lischke]

Hi Neil,

  The attached patch seems to fix the worst parts of the positioning problem.

I can confirm it works on my fresh 10.14 box.

It adds the margin width to the ‘VisibleOriginInMain’ then subtracts it when horizontally scrolling. The setting of the margin width is moved earlier to ensure it is consistent - it may be better to make the margin read the ViewStyle::fixedColumnWidth instead of caching the value. I am still confused about what is occurring.

  There is a problem with the patch that cursoring off the right doesn’t scroll at the correct point - the margin width likely needs to be taken into account there as well.

Unfortunately, there are more problems. When you move the cursor on the left hand side while the content is scrolled horizontally, it will behave as if there was no margin. Also, when you move the cursor with the keyboard from end of line to beginning of line, it will not scroll correctly (probably related).

I tried to fix that in SelectionPosition Editor::MovePositionSoVisible but failed. The call to cs.GetVisible() always returns true in my case, which I don't understand, since the line in question is longer than the visible line. Guess I have to leave that to you to fix.

<nitpick>There's a typo: should probably be MovePositionToVisible</nitpick>

Mike
-- 
www.soft-gems.net

[Mike Lischke]

  The attached patch seems to fix the worst parts of the positioning problem.

I can confirm it works on my fresh 10.14 box.

I spoke too soon. It works on 10.14 yes, but causes display problems on 10.13:

Mike

-- 
www.soft-gems.net

[Neil Hodgson]

Hi Mike,

> Unfortunately, there are more problems. When you move the cursor on the left hand side while the content is scrolled horizontally, it will behave as if there was no margin.

Unsure about this. SciTE seems to be confused when margins are added or removed and calls for these may need to have additional processing on Cocoa.

Some bad image tile caching appears in SciTE so blowing away the cache (ScintillaCocoa::DiscardOverdraw) may be needed.

> Also, when you move the cursor with the keyboard from end of line to beginning of line, it will not scroll correctly (probably related).

An updated patch (attached) changes ScintillaCocoa::GetClientRectangle to subtract the margin from the width and this makes right arrow work.

> <nitpick>There's a typo: should probably be MovePositionToVisible</nitpick>

In long form it would be "Move The Position So That It Is Visible” where “So” is a conjunction “with the result that".

> I spoke too soon. It works on 10.14 yes, but causes display problems on 10.13:

Yes, the changes will have to be guarded. It can’t just check for the running macOS version as the changed behaviour occurs only when built with Xcode 10. There may be some way of looking at the view positions to determine which behaviour is active.

Neil

[Chinh Nguyen]

I ran my test app that I use for submitting bug reports and observed that pre-Mojave and Mojave scroll views behaved differently when positioning their subviews. In pre-Mojave, making rulers visible repositions the clip view and the document view and the clip view's contentInset is unchanged. In Mojave, making rulers visible only changes the clip view's contentInset. So I figured I just needed to get the scroll view to behave like it did in pre-Mojave.

First I had to stop the scroll view's contentView (aka clipView) from automatically adjusting the content insets and set them to 0.

 scrollView.contentView.automaticallyAdjustsContentInsets = NO;
 scrollView.contentView.contentInsets = NSEdgeInsetsZero;

Then whenever I made the ruler view visible, I repositioned the contentView like the pre-Mojave scroll view does:

 NSRect frame = scrollView.contentView.frame;
 frame.origin.x = 1. + (scrollView.rulersVisible ? scrollView.verticalRulerView.requiredThickness : 0.);
 scrollView.contentView.frame = frame;

That seemed to work although the document view was still obscured by the ruler view when the app was first run. I had to manually toggle the ruler view's visibility to get the content view to position itself correctly.

Seeing some progress, I then applied this logic to my unpatched version of Scintilla in ScintillaView.mm. In the scroll view setup, I set the content inset for the contentView like above. I repositioned the contentView in -setMarginWidth:. It worked once I forced my scintillaView to call -setMarginWidth:.

- (void) setMarginWidth: (int) width
{
  if (marginView.ruleThickness != width)
  {
    marginView.marginWidth = width;
    [marginView setRuleThickness:[marginView requiredThickness]];

    NSRect frame = [[scrollView contentView] frame];
    frame.origin.x = [scrollView rulersVisible] ? width : 0.;
    [[scrollView contentView] setFrame:frame];
  }
}

I could type and press enter, move the caret around with the keyboard, click to move the caret, and everything scrolled properly.

However, I struggled with finding the correct place to reposition the scrollView's contentView in the code other than -setMarginWidth:. Doing it in the scrollView setup doesn't have any effect which is the same thing I was seeing in my test app.

Also, I haven't tried to figure out how to handle auto layout because none of this works if the scroll view uses auto layout. To be safe, the code probably should only run on 10.14 or newer.

[Neil Hodgson]

Chinh Nguyen:

> First I had to stop the scroll view's contentView (aka clipView) from automatically adjusting the content insets and set them to 0.

Thanks for the update.

> scrollView.contentView.automaticallyAdjustsContentInsets = NO;
> scrollView.contentView.contentInsets = NSEdgeInsetsZero;

NSEdgeInsetsZero is available in macOS 10.10+. Changing to NSEdgeInsetsMake(0,0,0,0) makes it OK back to 10.7.

> Then whenever I made the ruler view visible, I repositioned the contentView like the pre-Mojave scroll view does:
>
> NSRect frame = scrollView.contentView.frame;
> frame.origin.x = 1. + (scrollView.rulersVisible ? scrollView.verticalRulerView.requiredThickness : 0.);
> scrollView.contentView.frame = frame;

The 1 above appears to be wrong - with dark mode there is a single dark pixel on the left.

> - (void) setMarginWidth: (int) width
> {
> if (marginView.ruleThickness != width)
> {
> marginView.marginWidth = width;
> [marginView setRuleThickness:[marginView requiredThickness]];
>
> NSRect frame = [[scrollView contentView] frame];
> frame.origin.x = [scrollView rulersVisible] ? width : 0.;
> [[scrollView contentView] setFrame:frame];
> }
> }

That seems quite good.

> I could type and press enter, move the caret around with the keyboard, click to move the caret, and everything scrolled properly.

Cursoring to the right doesn’t scroll at the right place - its off by the fixedColumnWidth. The change to GetClientRectangle mentioned earlier, subtracting the fixedColumnWidth from the width, fixes this.

> However, I struggled with finding the correct place to reposition the scrollView's contentView in the code other than -setMarginWidth:. Doing it in the scrollView setup doesn't have any effect which is the same thing I was seeing in my test app.

Yes.

As well as the issue with being mispositioned at startup, there is also bad placement if there is a positioning refresh. For example, going to the control panel and switching between light and dark appearance will cause the content to hide behind the margin again.

Attached is a patch with a set of changes that makes progress for me.

Neil

[Chinh Nguyen]

On Sunday, October 7, 2018 at 10:26:43 PM UTC-5, Neil Hodgson wrote:

 

> Then whenever I made the ruler view visible, I repositioned the contentView like the pre-Mojave scroll view does:
>
>  NSRect frame = scrollView.contentView.frame;
>  frame.origin.x = 1. + (scrollView.rulersVisible ? scrollView.verticalRulerView.requiredThickness : 0.);
>  scrollView.contentView.frame = frame;

   The 1 above appears to be wrong - with dark mode there is a single dark pixel on the left.

Yeah sorry, that was in reference to my sample app. I was just going with contentView's x location which was 1 + ruler width. For Scintilla, I did not add 1.

FWIW, I opened up a technical service incident with Apple asking for guidance on how we're supposed to get the old behavior back. I'll report back once I hear something.

 

[Matthew Yau]

Hi Neil,

Thank you for the patch. The patch works when the window is not in tabbed window. However, once I clicked Show Tab Bar under View menu. The problem appear again.

Matthew

[Neil Hodgson]

Matthew Yau:

> Thank you for the patch. The patch works when the window is not in tabbed window. However, once I clicked Show Tab Bar under View menu. The problem appear again.

Yes, its only partial progress as we are starting to understand the problem and trying to fix each symptom.

Neil

[Chinh Nguyen]

Here's the response I got from Apple Developer Technical Support: 

NSScrollView is now automatically adjusting the contentInsets to allow the documentView to scroll under the ruler. So yes the problem is that origin of the clipView has moved to under the ruler.
This isn't exactly new to Mojave. If you used a full content window so your scrollView document could bleed into the titlebar, you run into the same kind of problem.
The solution is to use scrollRectToVisible when you click your button, or at any other time.
    [self.scrollView.documentView scrollRectToVisible: NSZeroRect];
This method takes contentInsets into consideration and will do what you want.

The "click your button" they're referring to is referring to the button I have in my test app that does a [scrollView.documentView scrollPoint:NSZeroPoint] when clicked. I was using it to show that the documentView would get positioned under the ruler when you did that so you can ignore that part of the response. I replied to DTS that NSTextView's documentView doesn't get scrolled under the ruler nor resized to accommodate the ruler so I just want some guidance as to how to get the old behavior back or at least duplicate what NSTextView seems to be doing. I should note that I looked at NSTextView and it did not change the contentInsets so I'm not sure I was on the right path when fiddling with it.

I've got more immediate things on my plate that I have to get back to but I'll let you know what I hear back and will try to find more time to work on this problem when I do hear back from DTS.

[Neil Hodgson]

Chinh Nguyen:

> I should note that I looked at NSTextView and it did not change the contentInsets so I'm not sure I was on the right path when fiddling with it.

OK. If changing contentInsets appears the wrong path then we could return to something like my earlier patches that fiddled values by fixedColumnWidth in multiple places.

Neil

[Chinh Nguyen]

So I reverted all of my code and started over. No more changing the contentInsets. I created an NSTextView in my test app and observed its behavior and figured that if the main thing that's changed in Mojave is that the clipView now adjusts the contentInsets to account for the ruler, NSTextView must be using the contentInsets too (it probably always has).

So in addition to your change to ScintillaCocoa::GetClientRectangle(), I modified ScintillaCocoa::GetVisibleOriginInMain() to account for the contentInsets:

Scintilla::Point ScintillaCocoa::GetVisibleOriginInMain() const
{
  NSScrollView *scrollView = ScrollContainer();
  NSRect contentRect = [[scrollView contentView] bounds];

  return Point(static_cast<XYPOSITION>(contentRect.origin.x+scrollView.contentView.contentInsets.left),
    static_cast<XYPOSITION>(contentRect.origin.y));
}

and also in ScintillaCocoa::SetHorizontalScrollPos():

    [clipView scrollToPoint: NSMakePoint(xOffset-clipView.contentInsets.left, contentRect.origin.y)];

This appears to work on both Xcode 10 and Xcode 9 built executables running on Mojave. I can type a long line and the content scrolls properly. Using the contentInsets is the right approach rather than checking if the rulers are visible and using their width because its backwards compatible.

The big issue though is the first time you horizontally scroll a document, several lines are visually shifted to the right. Once you click on any line, the text from the beginning of the document to that line is visually shifted back to its proper place. I know I'm missing a spot to hit but I'm not sure where.

[Neil Hodgson]

Chinh Nguyen:

> and also in ScintillaCocoa::SetHorizontalScrollPos():
>
> [clipView scrollToPoint: NSMakePoint(xOffset-clipView.contentInsets.left, contentRect.origin.y)];

Since scrollToPoint does both x and y, the scrollToPoint call in SetVerticalScrollPos should be the same:

[clipView scrollToPoint: NSMakePoint(contentRect.origin.x-clipView.contentInsets.left, topLine * vs.lineHeight)];

> The big issue though is the first time you horizontally scroll a document, several lines are visually shifted to the right. Once you click on any line, the text from the beginning of the document to that line is visually shifted back to its proper place. I know I'm missing a spot to hit but I'm not sure where.

There appears to be something like a double counting error here (or something not quite synchronized) inside scrollerAction (ScintillaCocoa::UpdateForScroll) where the previous margin width is seen in GetVisibleOriginInMain and that is assigned to xOffset although it should be offset by the new margin width.

Adding a log in UpdateForScroll is interesting:

void ScintillaCocoa::UpdateForScroll() {
Point ptOrigin = GetVisibleOriginInMain();
NSLog(@"UpdateForScroll %d -> %d margin=%d\n", xOffset, static_cast<int>(ptOrigin.x), vs.fixedColumnWidth);
xOffset = static_cast<int>(ptOrigin.x);

Neil

[Chinh Nguyen]

FWIW, here's what Apple Developer Relations recently sent me:

This issue behaves as intended based on the following:  For apps linked on macOS 10.14, the document of an NSScrollView can scroll under the associated horizontal and vertical NSRulerView or findBarView. This means that the NSClipView is sized and positioned under those accessories and that will be reflected in the clip view’s contentInsets.  If you’re writing a document view class that observes the containing clip view’s size to determine its own size, take these contentInsets into account when you’re determining the document size to avoid being larger than the inset document area.

I think we're on the right track. But while we're at it, shouldn't we be accounting for all of the contentInsets? Right now I'm only accounting for the vertical ruler but what if I wanted to have the document scroll under the titlebar? I also use my own custom find bar but I wonder what effect the native one would have too.

Neil Hodgson:

   Since scrollToPoint does both x and y, the scrollToPoint call in SetVerticalScrollPos should be the same: 
[clipView scrollToPoint: NSMakePoint(contentRect.origin.x-clipView.contentInsets.left, topLine * vs.lineHeight)]; 

Yes, I forgot to hit that. It now makes the initial display obviously off. I'll try to make time to look into it.

 

[Chinh Nguyen]

Here's an improvement:

void ScintillaCocoa::SetVerticalScrollPos()
{
  NSScrollView *scrollView = ScrollContainer();
  if (scrollView) {
    NSRect visibleRect = [[scrollView documentView] visibleRect];

    visibleRect.origin.y = topLine * vs.lineHeight;
    [[scrollView documentView] scrollRectToVisible:visibleRect];
  }
}


void ScintillaCocoa::SetHorizontalScrollPos()
{
  PRectangle textRect = GetTextRectangle();

  int maxXOffset = scrollWidth - static_cast<int>(textRect.Width());
  if (maxXOffset < 0)
    maxXOffset = 0;
  if (xOffset > maxXOffset)
    xOffset = maxXOffset;
  NSScrollView *scrollView = ScrollContainer();
  if (scrollView) {
    NSClipView * clipView = [scrollView contentView];
    NSRect visibleRect = [[scrollView documentView] visibleRect];
    visibleRect.origin.x = xOffset - clipView.contentInsets.left;
    [[scrollView documentView] scrollRectToVisible:visibleRect];
  }

  MoveFindIndicatorWithBounce(NO);
}

Note that I now use scrollRectToVisible:  instead of scrollToPoint:. This prevents SetVerticalScrollPos() from shifting the text over on startup. 

But I'm back to the issue where the first horizontal scroll shifts the text over until you click on the text. Then everything is fine after that.

[Neil Hodgson]

Chinh Nguyen:

> Note that I now use scrollRectToVisible: instead of scrollToPoint:. This prevents SetVerticalScrollPos() from shifting the text over on startup.

Its still shifted in SciTE but later margin changes are good. There is some issue over when it is safe to make margin changes - perhaps there is a need to wait for first paint and reset margins then.

Neil

[Chinh Nguyen]

I now have time to work on this a bit more. Here's where I'm currently at:

- I open a document in the editor and the editor appears with the cursor on the first line and everything appears in the correct place (the text is not shifted to the right).

- I can type and move the cursor around and everything appears OK as long as I don't type enough for the text to horizontally scroll.

- If I open a document and horizontally scroll with my mouse, the text in lines 2-73 shift to the right (I'm mentioning line numbers in case it has any significance to you). If I then click in the content area, the text shifts back to its correct location and everything is fine after that as long as I don't type enough for the text to horizontally scroll.

- If at any time I type enough text for the editor to horizontally scroll, only the current line is rendered correctly after scrolling the text to the beginning of the line. All other lines have a margin width of text chopped off.

So for me, there are currently 2 issues. The first is that the text is shifted after the first time you horizontally scroll with the mouse. Clicking on the content area after that causes the content to render again and everything looks OK. After this, horizontally scrolling with the mouse no longer causes any issues. The second issue is typing enough text to cause the text to horizontally scroll always causes a problem (I have line wrapping disabled). You can click on the content area to cause it to render again and everything appears OK unless you type enough text for it to horizontally scroll again.

[Neil Hodgson]

Chinh Nguyen:

> - If I open a document and horizontally scroll with my mouse, the text in lines 2-73 shift to the right (I'm mentioning line numbers in case it has any

If you have 7 (or 14) point high lines then 73*7=511 and drawing is often performed in power-of-2 squares. On my laptop with 10.14.1 its 256x256 points (512x512 physical pixels) but I think there’ve been other sizes.

> significance to you). If I then click in the content area, the text shifts back to its correct location and everything is fine after that as long as I don't type enough for the text to horizontally scroll.
> - If at any time I type enough text for the editor to horizontally scroll, only the current line is rendered correctly after scrolling the text to the beginning of the line. All other lines have a margin width of text chopped off.

I’m fairly certain that retaining bad images is because of the tile buffering for responsive scrolling. Its possible that some tiles are captured with an offset that is then changed. If this is the case then the cached tiles can be discarded with ScintillaCocoa::DiscardOverdraw.

Neil

[Chinh Nguyen]

Unfortunately, I'm not making any progress on this. I can't seem to make any effect on the cached tiles.

[Alfred van Hoek]

I think that the problem relates to not define an accessoryView to the RulerView: I quote: 

property CGFloat reservedThicknessForAccessoryView;

    // This indicates to the ruler how much room it should leave for the accessory view.  Default is 0.0.  If you expect that a view in your document view will put an accessory view in the ruler, you can set this to make room fror it from the start.  If an accessory view is ever set for the ruler, and space was not reserved for it or it is bigger than the space reserved, the ruler grows the reserved space to be big enough and retiles the scroll view.  If you know that several different accessory views will be used it is best to set this to the height of the tallest one for horizontal rulers or the width of the widest one for vertical rulers.  If the reserved thickness is larger than an actual accessory view set into the ruler, the accessory view is centered in the thickness.

I might be wrong, but the behavior change in macOS 10.14, that shows a bouncing effect of the contentView from left to right, contrary to macOS 10.13 or lower, is constricted to a small bounce offset, suggesting the RulerView has somehow a limited width.

[Neil Hodgson]

Alfred van Hoek:

> I think that the problem relates to not define an accessoryView to the RulerView: I quote:

Accessory views are optional and not every ruler view has one. Scintilla never defines an accessory view so the thickness of the accessory view is always 0. The accessory view area seems to be treated just the same as the rest of the ruler so its probably not worthwhile trying variants like a 0-width ruler with an accessory view showing the margins. Looking at other apps, the accessory view doesn’t scroll with the ruler.

> I might be wrong, but the behavior change in macOS 10.14, that shows a bouncing effect of the contentView from left to right, contrary to macOS 10.13 or lower, is constricted to a small bounce offset, suggesting the RulerView has somehow a limited width.

I’m not seeing that - the left-right bounce seems as large as before and doesn’t depend on the margins that are visible.

Neil

[Alfred van Hoek]

On Thursday, December 20, 2018 at 8:24:51 PM UTC-7, Neil Hodgson wrote:

Alfred van Hoek:

> I think that the problem relates to not define an accessoryView to the RulerView: I quote:

   Accessory views are optional and not every ruler view has one. Scintilla never defines an accessory view so the thickness of the accessory view is always 0. The accessory view area seems to be treated just the same as the rest of the ruler so its probably not worthwhile trying variants like a 0-width ruler with an accessory view showing the margins. Looking at other apps, the accessory view doesn’t scroll with the ruler.

Ok, did not know this. 

> I might be wrong, but the behavior change in macOS 10.14, that shows a bouncing effect of the contentView from left to right, contrary to macOS 10.13 or lower, is constricted to a small bounce offset, suggesting the RulerView has somehow a limited width.

   I’m not seeing that - the left-right bounce seems as large as before and doesn’t depend on the margins that are visible.

I think, I should have mentioned that when you set the content to wrap, in macOS 10.14, you can bounce left-right and right-left. This behavior is not occurring when run in macOS 10.13. Particularly, the right to left causes a limited bounce. Part of the content remains under the rulerView. It is this behavior that suggested my earlier response. And as suggested earlier by others, clicking in each and every line, following the launch and the left to right and right to left (when wrapping is set) bounce maneuvers, the content seems to adjust.

Alfred

[Chinh Nguyen]

Unfortunately I just couldn't figure out what was going on with the non-Cocoa-specific code after I got ScintillaView to respect the contentInsets. So I reverted my code and went back to trying to figure out how to get the pre-Mojave behavior back.

What I ended up doing was creating a subclass of NSScrollView (I named it SciScrollView) and overriding the tile method to position the contentView out from under the vertical ruler:

- (void)tile
{
    [super tile];

    NSRect frame = self.contentView.frame;
    frame.origin.x = self.verticalRulerView.requiredThickness;
    frame.size.width -= frame.origin.x;
    self.contentView.frame = frame;
}

I use that NSScrollView subclass in the ScintillaView initWithFrame: method (I also had to adjust the scrollView's contentView's (aka clipView) contentInsets):

- (id) initWithFrame: (NSRect) frame
{
  self = [super initWithFrame:frame];
  if (self)
  {
    mContent = [[[[[self class] contentViewClass] alloc] initWithFrame:NSZeroRect] autorelease];
    mContent.owner = self;

    // Initialize the scrollers but don't show them yet.
    // Pick an arbitrary size, just to make NSScroller selecting the proper scroller direction
    // (horizontal or vertical).
    NSRect scrollerRect = NSMakeRect(0, 0, 100, 10);
    scrollView = (NSScrollView *)[[[SciScrollView alloc] initWithFrame: scrollerRect] autorelease];
    scrollView.contentView.automaticallyAdjustsContentInsets = NO;
    scrollView.contentView.contentInsets = NSEdgeInsetsMake(0., 0., 0., 0.);
    [scrollView setDocumentView: mContent];

It's not an ideal solution but so far it seems to work. I'll probably clean it up later so that it only does the custom tiling when < Mojave. This is my backup plan until we figure out to how to get ScintillaView to properly respect the contentInsets.

[Neil Hodgson]

Hi Chinh,

> What I ended up doing was creating a subclass of NSScrollView (I named it SciScrollView) and overriding the tile method to position the contentView out from under the vertical ruler:

> …

> It's not an ideal solution but so far it seems to work. I'll probably clean it up later so that it only does the custom tiling when < Mojave.

That seems reasonable. Can you please post a diff/patch to make it easy to add.

> This is my backup plan until we figure out to how to get ScintillaView to properly respect the contentInsets.

That’s better than my backup plan which was to try to stay with the old version of Xcode / SDK or try to fake the marker used to determine that it was built with the old SDK.

Neil

[Chinh Nguyen]

> It's not an ideal solution but so far it seems to work. I'll probably clean it up later so that it only does the custom tiling when < Mojave. 

I meant to say > Mojave.

 

   That seems reasonable. Can you please post a diff/patch to make it easy to add.

OK. I patched against 3.7.6 because that's what I'm still using. I still have to add my own custom code to the Scintilla source that subclassing can't handle which is why I'm typically not current and usually describe my fixes rather than post patch files.

[Neil Hodgson]

Chinh Nguyen:

> OK. I patched against 3.7.6 because that's what I'm still using. I still have to add my own custom code to the Scintilla source that subclassing can't handle which is why I'm typically not current and usually describe my fixes rather than post patch files.

Apart from an ‘autorelease’ which fails to compile on head (as it has ARC turned on), that is good. Thank you. Haven’t tried it on pre-Mojave yet.

Since this appears to improve behaviour on Mojave, it been committed. Anyone seeing reversions should report them so we can find fixes.
https://sourceforge.net/p/scintilla/code/ci/b428bfb5a7303838f7ac28c941c99e73140cb786/

There is a bug tracker item for this issue:
https://sourceforge.net/p/scintilla/bugs/2022/

I actually spent a fair bit of time on this, watching stuff flow around in the debugger but not finding much leverage or understanding. The bug presents differently with minor changes in operation sequencing. Reentrance during resizing makes everything more complex and I’d like to avoid it but the code has to handle both external resizing such as the user/app modifying layout and also internal resizing as contents change and elements are turned on and off.

Neil

[Chinh Nguyen]

On Tuesday, September 18, 2018 at 10:14:26 PM UTC-5, Neil Hodgson wrote:

  Xcode 10 was released recently and there were some warnings when building Scintilla.

   One warning that appears is “Enable Base Internationalization”. This refers to a particular way of doing localization but currently Scintilla doesn’t do any localization or even have the .xib or .storyboard files that are the focus of Base Internationalization. A .xib file could be added and the “Use Base Internationalization” check box ticked. There are some literal strings provided for accessibility (“Scintilla”, “Scintilla Margin”, “source code editor”) that could potentially be localized into other languages.

This cleared up the warning for me:

https://stackoverflow.com/questions/52102914/how-to-disable-xcode-warning-enable-base-internationalization

I edited ScintillaFramework.xcodeproj/project.pbxproj and added Base to knownRegions:

                        knownRegions = (

                                English,

                                Japanese,

                                French,

                                German,

                                Base,

                        );

 

[Neil Hodgson]

Chinh Nguyen:

> I edited ScintillaFramework.xcodeproj/project.pbxproj and added Base to knownRegions:
>
> knownRegions = (
> English,
> Japanese,
> French,
> German,
> Base,
> );

Thanks. That works and was committed as
https://sourceforge.net/p/scintilla/code/ci/7a24b18327fa298746071a2a0ed0c22b3e66487e/

Neil