Re: New addressbook backend.

[Joe Gasiorek <gasiorek yakko cs wmich edu>]

On Mon, 2004-02-02 at 21:56 -0500, Nat Friedman wrote:
> On Sun, 2004-02-01 at 04:07, Jim McDonald wrote:
> > [...]
> > 
> > > When this is working, I'm ready to do a release.  Post 0.1, I want to
> > > spend some serious time cleaning up the architecture.  Some of the new
> > > resultset stuff is confusing and makes writing backends harder, and the
> > > fact that match rendering is now uniform no matter the match type is
> > > somewhat suboptimal for the user; different types of data shouldn't
> > > look the same.
> > 
> > In what areas do you think that the resultsets API is confusing?  I'd
> > hoped that it made backends easier, not harder, to write.
> 
> I think you're on the right path; I didn't mean to come across as wholly
> negative.  Here are my comments:
> 
>         * The rename from BackendResult to Result is good.  I'd go
>         further and call a Result a Match; as far as I can tell from
>         your code, this was the intent, and it seems to map everywhere I
>         see the Results being used.  So Result -> Match, ResultSet ->
>         MatchSet, etc.
>         
>         * Matches should have types, so that you can map a type to a
>         renderer:
>         
>         	Match m = new Match ("BugzillaBug");
>         
>         A renderer can then register itself for BugzillaBug matches:
>         
>         	RegisterRenderer ("BugzillaBug", RendererClass);
>         
>         We can someday have a generic set of renderers that are split
>         out from the backends, but this way backends for new types can
>         still ship a single file which contains the renderer, and
>         registers it in the StartUp method.
>         
>         If you don't specify a type for the Match, you go to the generic
>         renderer that you have now in gui.cs.
>         
>         For now renderers will just return the HTML of the rendered
>         match, and can hookup to provide the images themselves; in the
>         future they can return widgets, when we get to that point.
>         
>         Putting the match type in the match itself instead of using the
>         backend category makes backend authoring more flexible, since
>         you can return multiple types of matches in one backend.
>         
>         We should have a file doc/matchtypes.txt with all the match
>         types people create renderers for, just like with the cluetypes.
>         
>         * Match fading.  I'm glad you are thinking about this.  We need
>         to get the match grouping and relevance filtering working better
>         before we can tune the fading, though.
>         
>         Having match types will make grouping easier since we can
>         cluster all of the matches of a given type in one area.
>         
>         Getting relevance-based filtering working is a matter of
>         tuning.  Right now almost all backends return the same level of
>         relevance for a given match, and there is no relevance
>         attenuation happening when we cluechain.  Both of these need to
>         get fixed, and that will be a gradual process.
>         
>         Grouping is fundamentally harder than it looks, and I am sure
>         will require a rethink of the engine at least once.   Here's
>         why: It is possible that your frontend active object will have a
>         structure of its own which should be reflected in the order of
>         the matches in the dashboard.
>         
>         For example, if you are viewing a calendar with three
>         appointments in it, you may spawn two matches related to
>         appointment #1, two related to appointment #2, and one related
>         to appointment #3.  
>         
>         It would be really good to know in the dashboard which matches
>         came from which appointments, even in the presence of
>         cluechaining.
>         
>         In order for this to happen, though, we need to maintain
>         information about the structure of the frontend object all the
>         way through to the backend.  This is not possible with our
>         current setup; I think it is okay to treat this as a mid-term
>         problem though.
>         
>         * Coding style.  Do you think you could make your code look like
>         the rest of the dashboard code?  Your stuff is absolutely great,
>         but the formatting doesn't match.
>         
> All that remains for a release to go out is that we get the Evolution
> EDS backend working.  I'm ready to release as soon as that happens.
> 
> The next *big* project post-release is to get focus handling working
> properly, so that we can all begin to use dashboard on a day-to-day
> basis.  If anyone is interested in tackling this, I can writeup how I
> think it should work.
> 
> Best,
> Nat

Just a thought about focus handling, and maybe i'm getting ahead of
myself here, but have we decided if we are going to go with the libwnck
approach or the frontend-centric approach?  IMHO as good as the use of
libwnck would be (it would limit the code needed in the frontends) I
think it might be more trouble than its worth.  But I am not speaking
from experience...so this is why I'm asking.

> 
> 
> _______________________________________________
> Dashboard-hackers mailing list
> Dashboard-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/dashboard-hackers