On Tue, 2004-06-22 at 14:54, Tilman Sauerbeck wrote: > Carsten Haitzler <[EMAIL PROTECTED]> [2004-06-22 20:28]: > > > I'm talking about ecore_evas_callback_foo_set() :) > > > > aaah yes. i see what you mean. the reason i did this is it matched evas's > > setting of callbacks on objects better - i guess this is open for debate :) > > Okay, reasons for using ecore_event instead: > > o Used widely in ecore-based libs/apps, everyone who's familiar with > Ecore is also familiar with ecore_event > o API consistence with other ecore-based libs > > reasons against it: > > o API similar to evas' > o callbacks only occur for the object (ecore evas) you registered them > on > > IMHO, the last point is really weak. If we don't use ecore_event because > event handlers are always global and not tied to a specific object, we > admit that the system sucks :] > > IMHO two, most users (developers) don't care whether the API is similar > to Evas, because they'll prolly never use Evas' callback system > directly, because that's what they use ecore_evas for. > > Please, folks, comment :)
I have to agree that you should probably stick to a consistent API within one package (i.e. ecore). I've generally found libraries that are internally consistent easiest to use. The whole idea behind creating a convenience wrapper is to enable a user to learn one API that suits their needs. Employing multiple callback interfaces adds more complexity than a develop who wants to take care of as much as possible with ecore really needs. They are, after all, not using an abstraction API for the fun of it. They're using it to reduce the learning curve and thereby shorten their development cycle. Keeping that in mind, it only makes sense to hide the actual evas callback syntax and employ something that is consistent to the rest of ecore. That's just my $0.02. This is based on my looking at the ecore library myself, in the position of a relative newcomer to the E APIs, but a reasonably seasoned developer otherwise. -- Jon Olson ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
