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 firstname.lastname@example.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers