Re: Re: GMail plugin extension



Hi,

I'm sorry but I simply didn't have time for Kupfer in the last time.
The grouping functionality could be characterized as a hack, but
anyway it works by using the content "slot" of the contact leaf to
instead contain a group of contacts; that means that a grouped leaf
can't define any content itself. The easy way out would be to make the
information available in a different way, for example triggered by
using an action on the contact.

Ulrik

2010/9/16 Adi J. Sieker <adi sieker info>
>
> Hi,
>
> I sent this to the list a week ago. Is there still some feedback coming?
>
> Regards
>    Adi
>
> -------- Original Message --------
> Subject: Re: GMail plugin extension
> Date: Wed, 08 Sep 2010 21:07:34 +0200
> From: Adi J. Sieker <adi sieker info>
> To: kupfer-list gnome org
>
> Hi Ulrik,
>
> On 08.09.2010 13:17, Ulrik Sverdrup wrote:
> > 2010/9/7 Adi J. Sieker<adi sieker info>:
> >>
> >> I just pushed an update to the GMail plugin to
> >> git://github.com/adsworth/kupfer.git
> >> The plugin now downloads all data and the contact leaf now provides a
> >> content source,
> >> which contains most data from the contact. Currently that's all email
> >> addresses as an EmailContact,
> >> all phone numbers, postal addresses and IM account's as TextLeafs.
> >>
> >> All feedback welcome
> >>
> >
> > Hi Adi,
> >
> > In general, it's a good idea. However as it is now, this change
> > conflicts with contacts grouping (since grouping uses the contents
> > "slot" to show the contacts grouped together); this patch does away
> > with grouping all together of course (no longer using EmailContact).
> > So there is no direct conflict, but it needs to be explicitly
> > addressed somehow. It doesn't mean that this can't be solved, or that
> > this information could not be exposed in a different way.
> >
> I tried to get my head around what a GroupingLeaf does, but I didn't
> find any documentation on that. Google just shows commit messages.
> So if I could get an introduction to GroupingLeaves or you have
> suggestion as to how I can rework it.
>
> > If you don't mind, the code review reads like this:
>
> I did ask for it. :)
>
> > The commit log message must adhere to git standards
> > (the first line must not be longer than 60-70 letters ideally).
> Since I pushed the commit already. I recreated my github fork, cloned,
> commited and pushed again. So if someone added me as a remote and
> fetched it would probably be best to delete the remote and add it again.
>
> > The patch also has some whitespace
> > problem (git diff  should highlight these, if you have git configured
> > for color, else use git diff --check);
>
> Corrected the trailing whitespaces.
>
> > and get_items is better written
> > as a generator.
> And reworked get_items.
>
> Adi


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]