#4293 NORM Never A: Can't filter by all document types

[Zarro Boogs per Child]

#4293: Can't filter by all document types
-------------------------------+--------------------------------------------
  Reporter:  bert              |       Owner:  Eben          
      Type:  defect            |      Status:  new           
  Priority:  normal            |   Milestone:  Never Assigned
 Component:  interface-design  |     Version:                
Resolution:                    |    Keywords:                
  Verified:  0                 |  
-------------------------------+--------------------------------------------

Comment(by Eben):

 Replying to [comment:9 bert]:
 > For etoys projects that is almost true because a project is pretty much
 the state of the activity that is in the journal. It's not entirely true
 because you can download projects that were not done on an xo, and there
 would be no way of distinguishing.

 Right, that I can see.  However, I'm not sure I see reason to distinguish
 the two in this case.  They really are the same "thing", even if they came
 from different places.  They both behave identically within the UI.

 > But what about other documents - like, I can export a single etoys
 object, which would get a different mime-type which is still recognized by
 Etoys. Would that get the etoys icon too? But there would be no way of
 knowing this is not an activity instance? And there would be no way of
 filtering for that particular type of data?

 So, we do indeed want to support these other objects.  It's likely that
 these objects will get an icon specified by the activity that it came
 from, though I suppose it could also assume the icon of another activity
 that supports that type.  This would probably be up to the activity that
 created it.  As such, it would have an icon according to the activity
 which ''owns'' it, in a sense, but that icon wouldn't have to be the
 activity icon itself, necessarily.  Etoys could have a small library of
 icons for its known object types.

 As far as filtering goes, the thought is to filter by ''owner'', I guess,
 and not by mime-type.  There can be .png images that belong to Paint, and
 others that belong to Record, etc.  They have the same mime-type, but
 different owners.  As such, even if Etoys has 3 different object types in
 addition to the activity object (project), those would all appear in the
 filter when selecting Etoys from the menu.  To get more fine grained than
 this, you could add additional keywords or metadata searches into the
 search field.  You could obviously tag each object when creating it so
 that they have an additional "type" defined that is independent of the
 mime-type itself, if you wanted.  Maybe you have an "actor" object, for
 instance, that is a graphical object with some scripts attached.  Who
 knows.

 In the end, though, I'm sure you'd agree that the filter menu would become
 wholly unmanageable if it listed every (owner, mime-type) pair on the
 entire system...it's already getting large just restricting it to the list
 of owners.

 >And there is no way to filter for anything except text, image, audio,
 video, and link (huh?) - not even a generic "data" type that would be all
 data objects except the known ones.

 I'm unsure if link will remain a primary type.  It seemed kind of useful
 up front, but it hasn't really been used much yet.  In any case, we have
 been considering a "data" type...we do in fact have an icon for it
 already, which is used in the clipboard for data of unknown type.  We
 didn't add a filter for this because we weren't sure it would really be
 meaningful.  If you and others feel that it is, in light of the
 description above for activity filters, then we can add this single
 additional option back in.

-- 
Ticket URL: <https://dev.laptop.org/ticket/4293#comment:11>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system