Re: Questions on using a NSTextView as a source viewer.
On Oct 11, 2014, at 9:23 AM, Keary Suska wrote: > On Oct 11, 2014, at 3:53 AM, Daryle Walker wrote: > >> On Oct 10, 2014, at 1:58 AM, Ken Thomases wrote: >> >>> I tested this and it worked for me. In summary, all three steps: >>> >>> * Set the text view's max. width >>> * Set the text view to be horizontally resizable >>> * Set textView.textContainer.widthTracksTextView = NO >> >> I had that before my last post; didn’t fix it, made it worse (text width is >> the initial width of the window, even if I Zoom it out, or manually make it >> wider, or narrower(!)). > > I think Ken mis-stated what he meant--the max width isn't terribly relevant. > You need to set the actual container size (width minimally) to an unlikely > large number. Apple's TextViewSizing example project demonstrates this. They > use the value 1.0e7, which comments say is the largest possible value before > experiencing text drawing issues. You will have to set this value in code, as > it can't be set via IB. No, I said what I meant. I tested the configuration I laid out and it worked. I'm not sure why it wasn't working for Daryle. Explicitly setting the text container size seems like a reasonable step, of course; it just wasn't necessary in my experiments. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Questions on using a NSTextView as a source viewer.
On Oct 11, 2014, at 1:31 PM, Daryle Walker wrote:
> There was a minor detour where I just had “textContainer.containerSize” set.
> You need BOTH “containerSize” and “widthTracksTextView” set (to {10M, 10M}
> and NO, respectively). Both of these can be set in the user-defined run-time
> attributes section of IB. I heard about this a few months ago as a power-user
> hint. I first tried it to set the text-view’s font to the system fixed-width
> font, but I couldn’t do it. NSFont is not a type supported by the runtime
> attribute section, but NSSize and BOOL are.
I stand corrected. I think this was new as of Xcode 5, since I haven't used
that feature since Xcode 4, but I am glad the added it.
> Oh, I want read-only actions supported. Those don’t break the illusion that
> the source-view and browser windows are connected.
Sorry, I misunderstood. I thought you didn't want those either.
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Questions on using a NSTextView as a source viewer.
On Oct 11, 2014, at 10:23 AM, Keary Suska wrote:
> On Oct 11, 2014, at 3:53 AM, Daryle Walker wrote:
>
>> On Oct 10, 2014, at 1:58 AM, Ken Thomases wrote:
>>
>>> On Oct 10, 2014, at 12:02 AM, Daryle Walker wrote:
>>>
On Oct 7, 2014, at 8:03 PM, Ken Thomases wrote:
> On Oct 7, 2014, at 5:29 PM, Daryle Walker wrote:
>
>> 1. Although the text in the window expands vertically as needed, it
>> never does horizontally. Wrapping always happens when lines are too
>> long, but it adjusts as the width of the window is changed. How do I get
>> “infinite” space horizontally? I tried various tweaks in Interface
>> Builder and looked at various Apple guides, but I can’t turn off the
>> horizontal wrapping.
>
> On the Size inspector of IB, enable Resizable Horizontally. Then, in
> code, do this (assuming self.textView is the outlet property):
>
> self.textView.textContainer.widthTracksTextView = NO;
>
> I couldn't find anyplace in IB that exposes the text container attributes.
I added “textContainer.widthTracksTextView” to the run-time attributes
section in Interface Builder as a Boolean, and it changes the behavior in
the other direction; the text wraps at the window’s original width, even
if I make the window wider. Changing it to YES (i.e. turning on the
checkbox) brings back the previous behavior. (I first changed the
horizontal point limit to 10K, just like the vertical limit.)
>>>
>>> Did you also set Resizable Horizontally (the first step, above)? And, yes,
>>> good catch: I forget to mention changing the max. width.
>>
>> Yes.
>>
>>> I tested this and it worked for me. In summary, all three steps:
>>>
>>> * Set the text view's max. width
>>> * Set the text view to be horizontally resizable
>>> * Set textView.textContainer.widthTracksTextView = NO
>>
>> I had that before my last post; didn’t fix it, made it worse (text width is
>> the initial width of the window, even if I Zoom it out, or manually make it
>> wider, or narrower(!)).
>
>
> I think Ken mis-stated what he meant--the max width isn't terribly relevant.
> You need to set the actual container size (width minimally) to an unlikely
> large number. Apple's TextViewSizing example project demonstrates this. They
> use the value 1.0e7, which comments say is the largest possible value before
> experiencing text drawing issues. You will have to set this value in code, as
> it can't be set via IB.
This fixed it. Thanks.
There was a minor detour where I just had “textContainer.containerSize” set.
You need BOTH “containerSize” and “widthTracksTextView” set (to {10M, 10M} and
NO, respectively). Both of these can be set in the user-defined run-time
attributes section of IB. I heard about this a few months ago as a power-user
hint. I first tried it to set the text-view’s font to the system fixed-width
font, but I couldn’t do it. NSFont is not a type supported by the runtime
attribute section, but NSSize and BOOL are.
>> On Oct 7, 2014, at 5:33 PM, Daryle Walker wrote:
>
>> 3. The text in the view-source window is editable, although I turned
>> that off. (It’s still selectable.) I can cut/copy/paste. Isn’t turning
>> off editing supposed to stop this?
>
> Are you using bindings? Do any of them have Conditionally Sets Editable
> enabled in the binding options?
Yes, one for the text view's contents, and another on the window's title
(using the format substitution version). There is a binding for the text
view being editable, but I’m not using it. (The text contents property in
my window controller class is read-write.)
>>>
>>> My point was to check the options on those bindings for the Conditionally
>>> Sets Editable option. If any of them have that option enabled, that would
>>> explain why your text is editable when you set the text view to
>>> non-editable. The binding option is overriding the attribute you set.
>>> Turn it off.
>>
>> I thought you meant the “Editable” attribute under “Availability.” I haven’t
>> activated that Binding at all. But now I see you meant the C.S.E. option
>> under the Binding I did make. That option is checked.
>>
>> Turning it off blocks Cut and Paste, but still allows Copy, Select All, and
>> Find.
>
> You will need to also turn off "selectable" (setSelectable: in code) which
> should disable the rest, and possibly change "find" value to "none"
> (setUsesFindBar: and/or setUsesFindPanel:).
Oh, I want read-only actions supported. Those don’t break the illusion that the
source-view and browser windows are connected.
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins
Re: Questions on using a NSTextView as a source viewer.
On Oct 11, 2014, at 3:53 AM, Daryle Walker wrote: > On Oct 10, 2014, at 1:58 AM, Ken Thomases wrote: > >> On Oct 10, 2014, at 12:02 AM, Daryle Walker wrote: >> >>> On Oct 7, 2014, at 8:03 PM, Ken Thomases wrote: >>> On Oct 7, 2014, at 5:29 PM, Daryle Walker wrote: > 1. Although the text in the window expands vertically as needed, it never > does horizontally. Wrapping always happens when lines are too long, but > it adjusts as the width of the window is changed. How do I get “infinite” > space horizontally? I tried various tweaks in Interface Builder and > looked at various Apple guides, but I can’t turn off the horizontal > wrapping. On the Size inspector of IB, enable Resizable Horizontally. Then, in code, do this (assuming self.textView is the outlet property): self.textView.textContainer.widthTracksTextView = NO; I couldn't find anyplace in IB that exposes the text container attributes. >>> >>> I added “textContainer.widthTracksTextView” to the run-time attributes >>> section in Interface Builder as a Boolean, and it changes the behavior in >>> the other direction; the text wraps at the window’s original width, even if >>> I make the window wider. Changing it to YES (i.e. turning on the checkbox) >>> brings back the previous behavior. (I first changed the horizontal point >>> limit to 10K, just like the vertical limit.) >> >> Did you also set Resizable Horizontally (the first step, above)? And, yes, >> good catch: I forget to mention changing the max. width. > > Yes. > >> I tested this and it worked for me. In summary, all three steps: >> >> * Set the text view's max. width >> * Set the text view to be horizontally resizable >> * Set textView.textContainer.widthTracksTextView = NO > > I had that before my last post; didn’t fix it, made it worse (text width is > the initial width of the window, even if I Zoom it out, or manually make it > wider, or narrower(!)). I think Ken mis-stated what he meant--the max width isn't terribly relevant. You need to set the actual container size (width minimally) to an unlikely large number. Apple's TextViewSizing example project demonstrates this. They use the value 1.0e7, which comments say is the largest possible value before experiencing text drawing issues. You will have to set this value in code, as it can't be set via IB. > On Oct 7, 2014, at 5:33 PM, Daryle Walker wrote: > 3. The text in the view-source window is editable, although I turned that > off. (It’s still selectable.) I can cut/copy/paste. Isn’t turning off > editing supposed to stop this? Are you using bindings? Do any of them have Conditionally Sets Editable enabled in the binding options? >>> >>> Yes, one for the text view's contents, and another on the window's title >>> (using the format substitution version). There is a binding for the text >>> view being editable, but I’m not using it. (The text contents property in >>> my window controller class is read-write.) >> >> My point was to check the options on those bindings for the Conditionally >> Sets Editable option. If any of them have that option enabled, that would >> explain why your text is editable when you set the text view to >> non-editable. The binding option is overriding the attribute you set. Turn >> it off. > > I thought you meant the “Editable” attribute under “Availability.” I haven’t > activated that Binding at all. But now I see you meant the C.S.E. option > under the Binding I did make. That option is checked. > > Turning it off blocks Cut and Paste, but still allows Copy, Select All, and > Find. You will need to also turn off "selectable" (setSelectable: in code) which should disable the rest, and possibly change "find" value to "none" (setUsesFindBar: and/or setUsesFindPanel:). HTH, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Questions on using a NSTextView as a source viewer.
On Oct 10, 2014, at 1:58 AM, Ken Thomases wrote: > On Oct 10, 2014, at 12:02 AM, Daryle Walker wrote: > >> On Oct 7, 2014, at 8:03 PM, Ken Thomases wrote: >> >>> On Oct 7, 2014, at 5:29 PM, Daryle Walker wrote: >>> 1. Although the text in the window expands vertically as needed, it never does horizontally. Wrapping always happens when lines are too long, but it adjusts as the width of the window is changed. How do I get “infinite” space horizontally? I tried various tweaks in Interface Builder and looked at various Apple guides, but I can’t turn off the horizontal wrapping. >>> >>> On the Size inspector of IB, enable Resizable Horizontally. Then, in code, >>> do this (assuming self.textView is the outlet property): >>> >>> self.textView.textContainer.widthTracksTextView = NO; >>> >>> I couldn't find anyplace in IB that exposes the text container attributes. >> >> I added “textContainer.widthTracksTextView” to the run-time attributes >> section in Interface Builder as a Boolean, and it changes the behavior in >> the other direction; the text wraps at the window’s original width, even if >> I make the window wider. Changing it to YES (i.e. turning on the checkbox) >> brings back the previous behavior. (I first changed the horizontal point >> limit to 10K, just like the vertical limit.) > > Did you also set Resizable Horizontally (the first step, above)? And, yes, > good catch: I forget to mention changing the max. width. Yes. > I tested this and it worked for me. In summary, all three steps: > > * Set the text view's max. width > * Set the text view to be horizontally resizable > * Set textView.textContainer.widthTracksTextView = NO I had that before my last post; didn’t fix it, made it worse (text width is the initial width of the window, even if I Zoom it out, or manually make it wider, or narrower(!)). Same thing happens when I put the “self.textView.textContainer.widthTracksTextView = NO;” in code instead of the runtime attributes section of Interface Builder. Guess: The maximum width and height are 10M. The minimum values are the initial sizes of the window: 480x270. The text (source of “http://www.apple.com”) blows both of those values when you allow “infinite” width or height. The system expands the virtual height when it blows the initial height, but the same doesn’t happen when the virtual width exceeds the initial width; it wraps and never allows readjustment. I have to find the switch that wraps text (i.e. insert line breaks) on the initial read and turn that off. >> On Oct 7, 2014, at 5:33 PM, Daryle Walker wrote: >>> 3. The text in the view-source window is editable, although I turned that off. (It’s still selectable.) I can cut/copy/paste. Isn’t turning off editing supposed to stop this? >>> >>> Are you using bindings? Do any of them have Conditionally Sets Editable >>> enabled in the binding options? >> >> Yes, one for the text view's contents, and another on the window's title >> (using the format substitution version). There is a binding for the text >> view being editable, but I’m not using it. (The text contents property in my >> window controller class is read-write.) > > My point was to check the options on those bindings for the Conditionally > Sets Editable option. If any of them have that option enabled, that would > explain why your text is editable when you set the text view to non-editable. > The binding option is overriding the attribute you set. Turn it off. I thought you meant the “Editable” attribute under “Availability.” I haven’t activated that Binding at all. But now I see you meant the C.S.E. option under the Binding I did make. That option is checked. Turning it off blocks Cut and Paste, but still allows Copy, Select All, and Find. — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Questions on using a NSTextView as a source viewer.
On Oct 10, 2014, at 12:02 AM, Daryle Walker wrote: > On Oct 7, 2014, at 8:03 PM, Ken Thomases wrote: > >> On Oct 7, 2014, at 5:29 PM, Daryle Walker wrote: >> >>> 1. Although the text in the window expands vertically as needed, it never >>> does horizontally. Wrapping always happens when lines are too long, but it >>> adjusts as the width of the window is changed. How do I get “infinite” >>> space horizontally? I tried various tweaks in Interface Builder and looked >>> at various Apple guides, but I can’t turn off the horizontal wrapping. >> >> On the Size inspector of IB, enable Resizable Horizontally. Then, in code, >> do this (assuming self.textView is the outlet property): >> >> self.textView.textContainer.widthTracksTextView = NO; >> >> I couldn't find anyplace in IB that exposes the text container attributes. > > I added “textContainer.widthTracksTextView” to the run-time attributes > section in Interface Builder as a Boolean, and it changes the behavior in the > other direction; the text wraps at the window’s original width, even if I > make the window wider. Changing it to YES (i.e. turning on the checkbox) > brings back the previous behavior. (I first changed the horizontal point > limit to 10K, just like the vertical limit.) Did you also set Resizable Horizontally (the first step, above)? And, yes, good catch: I forget to mention changing the max. width. I tested this and it worked for me. In summary, all three steps: * Set the text view's max. width * Set the text view to be horizontally resizable * Set textView.textContainer.widthTracksTextView = NO > On Oct 7, 2014, at 5:33 PM, Daryle Walker wrote: >> >>> 3. The text in the view-source window is editable, although I turned that >>> off. (It’s still selectable.) I can cut/copy/paste. Isn’t turning off >>> editing supposed to stop this? >> >> Are you using bindings? Do any of them have Conditionally Sets Editable >> enabled in the binding options? > > Yes, one for the text view's contents, and another on the window's title > (using the format substitution version). There is a binding for the text view > being editable, but I’m not using it. (The text contents property in my > window controller class is read-write.) My point was to check the options on those bindings for the Conditionally Sets Editable option. If any of them have that option enabled, that would explain why your text is editable when you set the text view to non-editable. The binding option is overriding the attribute you set. Turn it off. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Questions on using a NSTextView as a source viewer.
On Oct 7, 2014, at 8:03 PM, Ken Thomases wrote: > On Oct 7, 2014, at 5:29 PM, Daryle Walker wrote: > >> 1. Although the text in the window expands vertically as needed, it never >> does horizontally. Wrapping always happens when lines are too long, but it >> adjusts as the width of the window is changed. How do I get “infinite” space >> horizontally? I tried various tweaks in Interface Builder and looked at >> various Apple guides, but I can’t turn off the horizontal wrapping. > > On the Size inspector of IB, enable Resizable Horizontally. Then, in code, > do this (assuming self.textView is the outlet property): > >self.textView.textContainer.widthTracksTextView = NO; > > I couldn't find anyplace in IB that exposes the text container attributes. I added “textContainer.widthTracksTextView” to the run-time attributes section in Interface Builder as a Boolean, and it changes the behavior in the other direction; the text wraps at the window’s original width, even if I make the window wider. Changing it to YES (i.e. turning on the checkbox) brings back the previous behavior. (I first changed the horizontal point limit to 10K, just like the vertical limit.) > On Oct 7, 2014, at 5:33 PM, Daryle Walker wrote: > >> 3. The text in the view-source window is editable, although I turned that >> off. (It’s still selectable.) I can cut/copy/paste. Isn’t turning off >> editing supposed to stop this? > > Are you using bindings? Do any of them have Conditionally Sets Editable > enabled in the binding options? Yes, one for the text view's contents, and another on the window's title (using the format substitution version). There is a binding for the text view being editable, but I’m not using it. (The text contents property in my window controller class is read-write.) — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Questions on using a NSTextView as a source viewer.
On Oct 7, 2014, at 5:29 PM, Daryle Walker wrote: > 1. Although the text in the window expands vertically as needed, it never > does horizontally. Wrapping always happens when lines are too long, but it > adjusts as the width of the window is changed. How do I get “infinite” space > horizontally? I tried various tweaks in Interface Builder and looked at > various Apple guides, but I can’t turn off the horizontal wrapping. On the Size inspector of IB, enable Resizable Horizontally. Then, in code, do this (assuming self.textView is the outlet property): self.textView.textContainer.widthTracksTextView = NO; I couldn't find anyplace in IB that exposes the text container attributes. On Oct 7, 2014, at 5:33 PM, Daryle Walker wrote: > 3. The text in the view-source window is editable, although I turned that > off. (It’s still selectable.) I can cut/copy/paste. Isn’t turning off editing > supposed to stop this? Are you using bindings? Do any of them have Conditionally Sets Editable enabled in the binding options? Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Questions on using a NSTextView as a source viewer.
On Oct 7, 2014, at 6:29 PM, Daryle Walker wrote: > I implemented a new window XIB and controller class for my web-browsing > project. It’s for “View Source.” It’s active if the current page’s > WebDataSource object indicates it supports a text representation. The window > just contains a NSTextView-wrapped-in-a-NSScrollView object provided by the > Interface Builder portion of Xcode. The controller has properties for the > source-text, source-URL, and title. These are used during user-interface > Resume; the view-source window never references the originating web-browser > window after creation. The original web-browser window could have its > current-page changed or be closed independently of a view-source window; the > web-browser window also doesn’t track its view-source windows, so you could > (pointlessly) create as many view-source windows for a particular page as you > like. > > 1. Although the text in the window expands vertically as needed, it never > does horizontally. Wrapping always happens when lines are too long, but it > adjusts as the width of the window is changed. How do I get “infinite” space > horizontally? I tried various tweaks in Interface Builder and looked at > various Apple guides, but I can’t turn off the horizontal wrapping. > > 2. I wonder if I should scrap this way of viewing source and use an attached > sheet. This obviously gives up source-viewing as independent. I also have to > add a property to the web-browser window to indicate if source-viewing is > active (so I can Restore that). [I knew I forgot an Important question.] 3. The text in the view-source window is editable, although I turned that off. (It’s still selectable.) I can cut/copy/paste. Isn’t turning off editing supposed to stop this? — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Questions on using a NSTextView as a source viewer.
I implemented a new window XIB and controller class for my web-browsing project. It’s for “View Source.” It’s active if the current page’s WebDataSource object indicates it supports a text representation. The window just contains a NSTextView-wrapped-in-a-NSScrollView object provided by the Interface Builder portion of Xcode. The controller has properties for the source-text, source-URL, and title. These are used during user-interface Resume; the view-source window never references the originating web-browser window after creation. The original web-browser window could have its current-page changed or be closed independently of a view-source window; the web-browser window also doesn’t track its view-source windows, so you could (pointlessly) create as many view-source windows for a particular page as you like. 1. Although the text in the window expands vertically as needed, it never does horizontally. Wrapping always happens when lines are too long, but it adjusts as the width of the window is changed. How do I get “infinite” space horizontally? I tried various tweaks in Interface Builder and looked at various Apple guides, but I can’t turn off the horizontal wrapping. 2. I wonder if I should scrap this way of viewing source and use an attached sheet. This obviously gives up source-viewing as independent. I also have to add a property to the web-browser window to indicate if source-viewing is active (so I can Restore that). — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
