Need icons for clippings in clipboard

[Zack]

I copied some text from Write using Ctrl-C. The clipboard object's icon is the same as Read's, not Write's. Seen in 502.

[tomeu]

The icon does not indicate the activity of origin, but the kind of data represented. Eben, should text snippets be represented by Read, Write or another icon?

[Eben]

We want to keep the distinction between objects and clippings, which can be "whole objects" in the technical sense, but won't actually represent an actual activity instance as saved in the Journal or elsewhere.

Thus, when an entire activity object (Read, Write, Draw, Browse, whatever) gets copied at once - via drag and drop or the copy button inside the Journal - the icon for the associated activity should appear. When a selection of text image, combination thereof, or other data is made, a clipping icon should appear. The clipping icon will be more generic, and not directly associated with any activity. We may simply distinguish between text, image, and other or something. I'll try to get together a set of icons for this purpose.

If anyone has some specific recommendations for the standard set of clippings based on MIME types, please attach some info on this ticket.

[coderanger]

Adding reporter to CC list

[coderanger]

Adding reporter to CC list

[Eben]

I've attached a first pass at the clippings. There are 6 "primitive types" for which icons are specified:

• image
• video
• audio
• text
• url
• data

Data is, of course, the most generic and may be used for any type of clipping whose type is otherwise not covered by the primitives. The SVGs have the proper entities, so they should be ready to go. We may change a few of these in the future (in particular, we're unhappy with using a non-universal music note for the audio file...), but this should get the system working.

We'd also like to recommend an addition (unless this already exists, I'm not sure) to the clipboard API which allows activities to provide custom icons for clippings as they are created. This goes hand in hand with our treatment of objects within the interface and within the Journal. Many activities will have "sub-activity" objects which are still formally defined and should have an associated icon separate from the icon for the activity itself. We want to embrace this idea and adding support for providing icons for custom types is a step in the right direction.

Let me say a few things to clarify the idea of clippings vs. objects vs. activities:

Clippings: are transient objects by nature. They represent a piece of data that is independent of any particular activity id (it does not take the id of that it was copied from) and has no version. Clippings, of course, may be "upgraded" into activities by selecting the "Keep in Journal" action. All data created via standard copy mechanisms should be represented as clippings unless specifically told not to by the activity. Examples are an image from a web page in Browse or some text from a story created in Write.

Objects: are permanent and self-contained. They can have associated metadata and can also live inside the Journal. They will have a creator, but don't have an associated activity id or a history. These will generally appear in the clipboard when a "whole object" is copied from within an activity. Examples might be a "loop object" or an "instrument" in TamTam.

Activity objects: are permanent and self-contained objects that have an activity id which tracks changes with versions in the Journal. They may have associated metadata. Most importantly, they have a specific association with an activity (the application) that they open in and share an icon with. Activity objects will appear in the clipboard when a whole Journal entry is copied to the clipboard.

[tomeu]

Replying to Eben:

I've attached a first pass at the clippings. There are 6 "primitive types" for which icons are specified: - image - video - audio - text - url - data Data is, of course, the most generic and may be used for any type of clipping whose type is otherwise not covered by the primitives. The SVGs have the proper entities, so they should be ready to go. We may change a few of these in the future (in particular, we're unhappy with using a non-universal music note for the audio file...), but this should get the system working.

Done

We'd also like to recommend an addition (unless this already exists, I'm not sure) to the clipboard API which allows activities to provide custom icons for clippings as they are created. This goes hand in hand with our treatment of objects within the interface and within the Journal. Many activities will have "sub-activity" objects which are still formally defined and should have an associated icon separate from the icon for the activity itself. We want to embrace this idea and adding support for providing icons for custom types is a step in the right direction.

This is #2458