On Thu, 2011-04-28 at 11:59 -0400, Matthew Barnes wrote: > On Thu, 2011-04-28 at 16:34 +0200, Milan Crha wrote: > > You obviously face of a circular dependency, so it's not doable in a > > clean way. Also because EClient is in libedataserver, EBookClient in > > addressbook/libebook and similarly ECalClient in calendar/libecal. Both > > descendants link to libedataserver... Having another > > register_client/unregister_client function will make things only less > > clear for readers (like if one tries to follow signal handlers by > > reading the code. > > Way to douse me with a bucket of cold water there. :) > > You're right about the library dependencies. That does kinda put a > bullet in unifying the "new" function. I agree a type registration > system is overkill for a mere two GTypes. > > Still, is there any value in having such an enum defined in e-client.h? > > I cited one benefit in consolidating my "get_default_source" functions, > but that alone is not really compelling. Are there other use cases?
Yes, when I was changing server side data-views for book and cal, then if turned out that the D-Bus API is exactly the same except of the DBUS_PROXY_NAME and book/cal strings in a file. Thus having type param for both factories too, though for book unused, may clean the code very nicely, forcing us to exactly one implementation of base EGDBusFactory, EGDBusView, EDataFactory, EDataView and subclass these to EGDBusBookFactory, EGDBusCalFactory, ... and changing only really minimum on them. Basically the effort which started Travis Reitter in his eds branches. _______________________________________________ evolution-hackers mailing list email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers