[XESAM] Minutes of meeting 2007-05-15

jamie jamiemcc at blueyonder.co.uk
Mon May 21 12:29:04 PDT 2007


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







More information about the xdg mailing list