Re: New addressbook backend.
- From: Joe Gasiorek <gasiorek yakko cs wmich edu>
- To: Nat Friedman <nat novell com>
- Cc: dashboard-hackers gnome org
- Subject: Re: New addressbook backend.
- Date: Mon, 02 Feb 2004 23:04:26 -0500
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
> 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
> 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.
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
] [Thread Prev