On Thu, 2010-09-09 at 11:50 +0100, Patrick Ohly wrote:
> On Wed, 2010-09-08 at 20:25 +0100, Alexander Bokovoy wrote:
> > On Wed, Sep 8, 2010 at 21:29, Auke Kok <[email protected]> wrote:
> > > Do we need bugs against handset components for not providing the proper
> > > "MimeType=..." fields in the respective handset app's .desktop files?
> > Yes, we do need that. See libcontentaction for details.
> 
> Ah, great! That was what I was looking for. Thanks for the pointer.

After thinking about this some more, I'm still wondering whether a truly
generic Tracker search + visualization + action implementation is
possible.

For a simple kind of visualization, yes, this probably works:
     1. show uri (not localized, very technical)
     2. pass uri to Action class to get list of available actions
     3. show ContentAction::Action's localized name and icon (both from
        the .desktop file)

But step 1 is clearly not sufficient. What would be needed instead is
some class specific formatter which extracts further information and
displays that. For example, a contact might be displayed with photo and
full name.

I was wondering whether there were "generic" RDF triplets that would
help (like "display name" or "thumbnail", set for anything which has
something remotely resembling such properties), but that doesn't seem to
be the case.

Is there perhaps a libcontentvisualizer or libcontentsummarizer (mapping
to some common properties, like thumbnail and text)? I doubt it because
this is so design specific, but as always, better ask than be sorry ;-)

Regarding step 3, there's a similar issue. Suppose there is a contact
with several email addresses and an action for email addresses described
as "send email". It would be nice to show this as:
        Aaron Alewife
          send email to work address ([email protected])
          send private email ([email protected])

Instead one can only concatenate:
    Aaron Alewife
      work address ([email protected]): send email
      private address ([email protected]): send email

The part before the colon would have to be generated by some domain
specific code.

Because the "send email" part is provided by MeeGo apps without
necessarily knowing in which context the text will be used, should we
establish some MeeGo guidelines?

For example:
      * reasonably short (40 characters)
      * no complete sentence
      * therefore capitalization as in the middle of a sentence ("send
        email" instead of "Send email")

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev

Reply via email to