Re: Issues with NSTextView Attachments

[Gordon Apple]

Thanks, Kyle.  I¹ll look into that.  It¹s not clear exactly how this gets
used, especially within an attrituted string, but, hopefully, I¹ll figure it
out.

Reference docs are good to have, but they are often (and usually) deficient
in telling you how to use it.  Frameworks are somewhat akin to giving you
all the pieces of an automobile but letting you figure out how to actually
construct an automobile.

I wish someone really knowledgable would write a book on text editing, maybe
in the Prag Programming series.  Maybe it¹s too narrow a subject for broad
dissemination, but I think a lot of people would be interested, especially
now that much of it is migrating to iOS.  I could write a chapter on text
containers.  I¹ve had a text container for years now that does what the new
iOS stuff does, and more, on MacOS.  But there is so much I don¹t know.


On 8/22/13 8:24 PM, "Kyle Sluder"  wrote:

> On Thu, Aug 22, 2013, at 04:40 PM, Gordon Apple wrote:
>> > I guess the operative word here is ³custom².  So how does NSTextView
>> > handle
>> > attachments which are not custom, because it does?  Why not RTFD?  I
>> > thought
>> > RTF didn¹t handle attachments.
> 
> It uses RTFD, but it might be the case that RTFD might only support file
> wrappers.
> 
> Have you implemented -[
> textView:writablePasteboardTypesForCell:atIndex:] and
> -[ textView:writeCell:atIndex:toPasteboard:type:]?
> 
> --Kyle Sluder


___

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: Issues with NSTextView Attachments

[Kyle Sluder]

On Thu, Aug 22, 2013, at 04:40 PM, Gordon Apple wrote:
> I guess the operative word here is ³custom².  So how does NSTextView
> handle
> attachments which are not custom, because it does?  Why not RTFD?  I
> thought
> RTF didn¹t handle attachments.

It uses RTFD, but it might be the case that RTFD might only support file
wrappers.

Have you implemented -[
textView:writablePasteboardTypesForCell:atIndex:] and
-[ textView:writeCell:atIndex:toPasteboard:type:]?

--Kyle Sluder

___

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: Issues with NSTextView Attachments

[Gordon Apple]

I guess the operative word here is ³custom².  So how does NSTextView handle
attachments which are not custom, because it does?  Why not RTFD?  I thought
RTF didn¹t handle attachments.

So, it looks like I need to archive the attributed string segment as a
custom pboard type, in addition to the normal RTF, and prioritize that.  In
my (internal) storage, I generally just archive the attributed string.


On 8/22/13 2:02 PM, "glenn andreas"  wrote:

> When NSTextView puts rich content on a pasteboard (for copy/paste or
> drag/drop), it converts the text to RTF.  RTF has no concept of custom text
> attachment cells, so they get dropped.
> 
> You'll need to add your own custom data type that preserves that content (such
> using an archive)
> 

___

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: Issues with NSTextView Attachments

[glenn andreas]

When NSTextView puts rich content on a pasteboard (for copy/paste or 
drag/drop), it converts the text to RTF.  RTF has no concept of custom text 
attachment cells, so they get dropped.

You'll need to add your own custom data type that preserves that content (such 
using an archive)


On Aug 22, 2013, at 1:48 PM, Gordon Apple  wrote:

> I¹ve successfully managed to override Paste and PerformDrag to embed images
> which are resizable and with specified fractional (fraction of
> height)baseline offsets.  They also archive and unarchive properly.  I¹m
> using a custom TextAttachmentextCell which archives the size and the
> fractional baseline offset, and returns the appropriate values to draw
> properly.  Undo/redo even works.  However, it¹s still not right.  I cannot
> copy/pasts or drag/drop a text segment containing the attachment without
> losing the attachment.  NSTextView¹s handling of images, without my
> enhancements, does this correctly.  So what am I missing?
> 
> I don¹t really understand the various ³fix² methods.  When I did my own text
> editor (pre-OSX), which was uses in some Mayo Clinic multimedia CDs, I
> handled all this automatically when pasting, etc.  I did put in a
> fixAttachmentAttributeInRange call after insertion.  That didn¹t help.
> 
> 
> On 8/10/13 12:31 PM, "Gordon Apple"  wrote:
> 
>> Using NSTextView¹s native ability to embed image attachments, we have
>> successfully implemented resizing of the image by using a resizable frame 
>> with
>> a drag handle, and using setSize on the NSImage.  Works great.  Only one
>> problem, re-archiving the NSAttributableString loses the image size change.
>> Any way to fix this?  Internally, in a CoreData auxiliary file folder, we
>> archive NSAttributableString.  Would we be better off storing it as RTFD?
>> 
>> I also see allusions to subclasses of NSTextAttachment, but I see no way to
>> tell NSTextView, or its associates, to use such a subclass.
>> NSTextAttachmentCell is a protocol.  But who adopts this protocol?  For an
>> image, is this really a NSImageCell adopting this protocol?  Or is it the
>> NSTextAttachment?  Confusion here.  Documentation on attachments is sparse.
>> 
>> We would also like to have the ability to set the baseline when an image is
>> inserted, and change it when the image is resized.  Certain NSPDFImageReps
>> contain baseline info in private dictionaries, which we would like to use,
>> when available. In view of the above, should we abandon NSTextView¹s
>> paste/drag-in capabilities for images and override all the relevant methods 
>> to
>> do our own attachment inserts using a custom NSAttachment class?
>> 
>> Related question about NSImage.  I¹ve never understood setSize in NSImage.
>> Does this just affect the cached image, or does it have any impact on the
>> underlying imageRep, such as resizing and remapping a bitmap?
>> 
>> One more:  I¹ve never found a straightforward way to make a textView 
>> re-layout
>> all or a portion of the text.  The best way I¹ve found is to call
>> textContainerChangedGeometry.  Works, but seems rather obtuse.
>> 
>> Inquiring minds need to know.
> 
> 
> ___
> 
> 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/gandreas%40me.com
> 
> This email sent to gandr...@me.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: Issues with NSTextView Attachments

[Gordon Apple]

I¹ve successfully managed to override Paste and PerformDrag to embed images
which are resizable and with specified fractional (fraction of
height)baseline offsets.  They also archive and unarchive properly.  I¹m
using a custom TextAttachmentextCell which archives the size and the
fractional baseline offset, and returns the appropriate values to draw
properly.  Undo/redo even works.  However, it¹s still not right.  I cannot
copy/pasts or drag/drop a text segment containing the attachment without
losing the attachment.  NSTextView¹s handling of images, without my
enhancements, does this correctly.  So what am I missing?

I don¹t really understand the various ³fix² methods.  When I did my own text
editor (pre-OSX), which was uses in some Mayo Clinic multimedia CDs, I
handled all this automatically when pasting, etc.  I did put in a
fixAttachmentAttributeInRange call after insertion.  That didn¹t help.


On 8/10/13 12:31 PM, "Gordon Apple"  wrote:

> Using NSTextView¹s native ability to embed image attachments, we have
> successfully implemented resizing of the image by using a resizable frame with
> a drag handle, and using setSize on the NSImage.  Works great.  Only one
> problem, re-archiving the NSAttributableString loses the image size change.
> Any way to fix this?  Internally, in a CoreData auxiliary file folder, we
> archive NSAttributableString.  Would we be better off storing it as RTFD?
> 
> I also see allusions to subclasses of NSTextAttachment, but I see no way to
> tell NSTextView, or its associates, to use such a subclass.
> NSTextAttachmentCell is a protocol.  But who adopts this protocol?  For an
> image, is this really a NSImageCell adopting this protocol?  Or is it the
> NSTextAttachment?  Confusion here.  Documentation on attachments is sparse.
> 
> We would also like to have the ability to set the baseline when an image is
> inserted, and change it when the image is resized.  Certain NSPDFImageReps
> contain baseline info in private dictionaries, which we would like to use,
> when available. In view of the above, should we abandon NSTextView¹s
> paste/drag-in capabilities for images and override all the relevant methods to
> do our own attachment inserts using a custom NSAttachment class?
> 
> Related question about NSImage.  I¹ve never understood setSize in NSImage.
> Does this just affect the cached image, or does it have any impact on the
> underlying imageRep, such as resizing and remapping a bitmap?
> 
> One more:  I¹ve never found a straightforward way to make a textView re-layout
> all or a portion of the text.  The best way I¹ve found is to call
> textContainerChangedGeometry.  Works, but seems rather obtuse.
> 
> Inquiring minds need to know.


___

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: Issues with NSTextView Attachments

[Kyle Sluder]

On Sat, Aug 10, 2013, at 10:31 AM, Gordon Apple wrote:
> Using NSTextView¹s native ability to embed image attachments, we have
> successfully implemented resizing of the image by using a resizable frame
> with a drag handle, and using setSize on the NSImage.  Works great.  Only
> one problem, re-archiving the NSAttributableString loses the image size
> change.  Any way to fix this?  Internally, in a CoreData auxiliary file
> folder, we archive NSAttributableString.  Would we be better off storing
> it
> as RTFD?

You could store it as a custom attribute on the attachment character.

> 
> I also see allusions to subclasses of NSTextAttachment, but I see no way
> to
> tell NSTextView, or its associates, to use such a subclass.

You will need to create the attachment object yourself and assign it as
the value of the NSTextAttachmentAttributeName for the attachment
character.

You could do this in an implementation of -[
didChangeText:] so that user drag-and-drop of images still results in
your custom attachment class being created.

> NSTextAttachmentCell is a protocol.  But who adopts this protocol?  For
> an
> image, is this really a NSImageCell adopting this protocol?  Or is it the
> NSTextAttachment?  Confusion here.  Documentation on attachments is
> sparse.

The current architecture dates back to when NSCell was a useful class to
instantiate directly. I believe NSCell still implements
, but it might actually be NSImageCell. But yes,
that's the gist of the design.

> 
> We would also like to have the ability to set the baseline when an image
> is
> inserted, and change it when the image is resized.  Certain
> NSPDFImageReps
> contain baseline info in private dictionaries, which we would like to
> use,
> when available. In view of the above, should we abandon NSTextView¹s
> paste/drag-in capabilities for images and override all the relevant
> methods
> to do our own attachment inserts using a custom NSAttachment class?

Maybe. See above for one idea of how to continue using NSTextView's drag
and drop support.

> 
> Related question about NSImage.  I¹ve never understood setSize in
> NSImage.
> Does this just affect the cached image, or does it have any impact on the
> underlying imageRep, such as resizing and remapping a bitmap?

NSImage.size is a semantic property. It tells the caller how big the
image is in device-independent points. It is no longer related to
caching. See the App Kit release notes for 10.6, section titled "NSImage
Behavior: Simplifying caching and related interfaces": 


> 
> One more:  I¹ve never found a straightforward way to make a textView
> re-layout all or a portion of the text.  The best way I¹ve found is to
> call
> textContainerChangedGeometry.  Works, but seems rather obtuse.

NSLayoutManager has many invalidation methods.

--Kyle Sluder

___

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

Issues with NSTextView Attachments

[Gordon Apple]

Using NSTextView¹s native ability to embed image attachments, we have
successfully implemented resizing of the image by using a resizable frame
with a drag handle, and using setSize on the NSImage.  Works great.  Only
one problem, re-archiving the NSAttributableString loses the image size
change.  Any way to fix this?  Internally, in a CoreData auxiliary file
folder, we archive NSAttributableString.  Would we be better off storing it
as RTFD?

I also see allusions to subclasses of NSTextAttachment, but I see no way to
tell NSTextView, or its associates, to use such a subclass.
NSTextAttachmentCell is a protocol.  But who adopts this protocol?  For an
image, is this really a NSImageCell adopting this protocol?  Or is it the
NSTextAttachment?  Confusion here.  Documentation on attachments is sparse.

We would also like to have the ability to set the baseline when an image is
inserted, and change it when the image is resized.  Certain NSPDFImageReps
contain baseline info in private dictionaries, which we would like to use,
when available. In view of the above, should we abandon NSTextView¹s
paste/drag-in capabilities for images and override all the relevant methods
to do our own attachment inserts using a custom NSAttachment class?

Related question about NSImage.  I¹ve never understood setSize in NSImage.
Does this just affect the cached image, or does it have any impact on the
underlying imageRep, such as resizing and remapping a bitmap?

One more:  I¹ve never found a straightforward way to make a textView
re-layout all or a portion of the text.  The best way I¹ve found is to call
textContainerChangedGeometry.  Works, but seems rather obtuse.

Inquiring minds need to know.

___

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