On Fri, 2011-04-29 at 07:24 -0400, Matthew Barnes wrote: > On Fri, 2011-04-29 at 06:59 +0200, Milan Crha wrote: > > 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. > > Cool. That was my initial thought too but didn't know how much extra > work that would be.
Hi, so I did. There are new EBookClientView/ECalClientView defined. They use exactly the same interface, with same signal names defined and their signatures, the only difference is function naming and the GDBus object used at the background. Consider it as the first step on the "merge common code of cal/book factory and cal/book view", which will make it easier to adapt to such change in the future. As I mentioned earlier, factories and views, all concrete implementations and gdbus stubs can be merged and mostly reused between calendar and addressbook factories. The only issue is compilation order (some file placement restructuralization will be needed, for example to be able to define EClientView and have it available in e-client.h, but also in e-cal-client.h/.c and e-book-client.h/.c for exact implementation). I noticed one difference between factories, recently. The calendar factory keeps running all backends for all the time the factory is run (since the backend is opened for the first time), even when no consumers exist. The addressbook factory frees the backend as soon as the last client is gone. Each has its advantages for sure. I'm mentioning it here only to be aware of such difference and to anyone going further with the merge idea to pick the better of them. I'm not sure which it is, though. I'm not going any further in this merging effort, because I do not think it breaks anyhow the EClient idea as is. The merging can be postponed to any time later, even for 3.4 or beyond, from my point of view. Bye, Milan _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers