Re: Renderer updates

[Kevin Godby <godbyk yahoo com>]

'allo.

On Thu, 2004-05-13 at 21:45 -0700, Matt Jones wrote:
> First the nit-picky:

I love nit-pickers.  (I'm one, too.)

> Just looking at the screenshot (I haven't had a chance to patch yet) -
> is it possibly to restrain list items (like the files) so that they
> align against the inside edge of the top vertical line? The im convos
> seem to, but not the files.

Yes, I know.  I whipped up some likely bad code to scale the icons down
to a smaller size.  I think that's why they're not aligning at the top
(as they should per the html code).  I'm going to be looking into it.

> Bigger suggestions - 
> Perhaps every renderer should display in a list format - all
> standardized to a list similar to the "Your files" section. What I mean
> by this is - (an example might make more sense)

* snip snazzy ascii art *

I disagree.  I think that the 'right thing' to do would be for the
renderers to display the most relevant/appropriate information depending
on the match it received.  So some matches will display more information
than others.  

For example, the MailMessage renderer displays the read/unread/deleted
status of the message along with the subject long, the sender, and the
date received. 

The IM conversation renderer currently only displays the chat partner
and the date of the conversation.  (This is because that's the only data
the Gaim Log backend sends the renderer.)

The File renderer (which primarily receives its matches from the
DeweyIndexer backend nowadays) currently only displays the associated
icon, filename, and last-modified date.  In the future, I'd like the
File renderer to display more apropos information for each file on an
individual basis.  OOo files should display the title and author of the
document (garnered from the OOo metadata), for example.

* snip *

> I can make a gimp-ed mockup if this is completely confusing, but
> hopefully the final design would be more uniform across different data
> types. The advantages are it provides a visual element for each item
> (rather than each list) - a key part of the original goals / vision for
> dashboard IIRC - and its visually consistent between data types.

If I'm understanding you correctly, you think each match should stand on
its own -- i.e., don't group items by their match type.

I brought this up a while back, because I think that it's more useful to
have the most relevant matches at the top of the result list, regardless
of their type.  At the time, Nat said he preferred keeping all like
items together so it'd be easier to find them.  I'm still thinking about
this.  :)

> I can't write code for this for the next week or two (just finishing up
> my senior year in high school), but i have a nice empty summer that i'd
> love to use some time in to help out / play around with dashboard.

Cool.  More coders are always welcome!

Thanks for the suggestions and ideas, Matt!

--Kevin Godby  <godbyk yahoo com>