[XESAM] Minutes of meeting 2007-05-15

[jamie]

On Mon, 2007-05-21 at 21:20 +0200, Mikkel Kamstrup Erlandsen wrote:
> 2007/5/21, jamie <jamiemcc at blueyonder.co.uk>:
>         On Mon, 2007-05-21 at 14:56 -0400, Joe Shaw wrote:
>         > Hi,
>         >
>         > On 5/21/07, Evgeny Egorochkin <phreedom.stdin at gmail.com>
>         wrote:
>         > > Not sure what you mean by "knowing how to display", 
>         >
>         > Simply that code has to exist which pulls specific
>         information
>         > provided and displays it in an optimal way.  For instance,
>         displaying
>         > some sort of widget for a "person" rather than a URI. 
>         >
>         > It must also know how to filter information so that a user
>         isn't
>         > overwhelmed.  For a person, inundating the user with all
>         possible
>         > information about that person in little more than a
>         key-value format 
>         > isn't useful.  Otherwise we might as well just be displaying
>         the FOAF
>         > file itself and not bothering to parse it. :)
>         >
>         > > but when app encounters meta-data outside of the core or
>         known onto, it has 
>         > > to deal with it nevertheless.
>         >
>         > Beagle's policy has always been to drop this information,
>         actually.
>         > If we can't present it sanely to the user, it probably won't
>         be useful
>         > to them.  (There is also the conscious decision that Beagle
>         is just a
>         > search tool -- it largely provides information "at a glance"
>         to the
>         > user; if they want details, another application is better
>         suited than 
>         > we could ever be.)
>         >
>         > > The more structured the onto is, the more opportunities
>         the app
>         > > has to present/process the data properly.
>         >
>         > Sure, but doesn't the app have to know about this? 
>         
>         
>         not really. Tracker is moving away from hard coding stuff like
>         this so
>         that it can handle custom services with a tile based gui
>         without a
>         priori knowledge or any hardcoding.
>         
>         EG see our service def files (note the TileMetadata fields!) 
>         http://svn.gnome.org/viewcvs/tracker/trunk/data/services/default.service?view=markup
> 
> 
> You mean by imposing a UIView and UIVisible property on each field
> and/or category i take it..? 

on category only

> 
> I can't really grok what the UIView property means...

thats for our (future) gui - basically some types are best shown in an
icon view or as a list view (images work best when shown as an icon view
and without snippets, music files are better shown in a grid like
rhythmbox does, docs are best shown as they are with snippets etc). So
it simply states what type of view that category prefers

jamie