On Thu, 2011-04-28 at 15:04 -0400, Matthew Barnes wrote:
> On Thu, 2011-04-28 at 19:53 +0200, Milan Crha wrote:
> > Only the last thing for the enum values, I would personally prefer
> > something with a prefix E_CLIENT_SOURCE_TYPE_... only to not have it
> > confusion-able with E_CLIENT_TYPE constant.
>
> Do you mean E_TYPE_CLIENT (for getting EClientClass's GType)?
Heh, right, I meant E_TYPE_CLIENT. I should read-before-write more
often, I'm sorry.
> Regardless, I'm fine with the longer prefix if you'd prefer that.
Preferred on my side, yup.
> > By the way, the proposed merge of server side parts, it may also involve
> > merging client side bits (for E*View) and thus finally drop all the old
> > cruft. It's a benefit, I hope, even with broken backward compatibility.
> > (I would prefer to break backward compatibility personally, rather than
> > inventing special names for structs not intersect with old names.)
>
> I haven't been following the E*View changes very closely. What's
> considered cruft?
There was just a little problem with ECalView, which had 'client'
property, which is referring to ECal, instead of ECalClient, and I was
forced to "invent" different name for it. But after a bit of sleeping
and small thinking I might be wrong on this point too, as it should be
easy to define EBookClientView/ECalClientView and keep old
EBook/CalView-s as they are, at least their public API.
I see I did really too quick thinking on these.
Bye,
Milan
_______________________________________________
evolution-hackers mailing list
[email protected]
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
