On Wed, 2009-05-20 at 15:15 +0200, Gustavo Sverzut Barbieri wrote: > On Tue, May 19, 2009 at 1:35 PM, Rafael Antognolli > <antogno...@profusion.mobi> wrote: > > On Mon, May 18, 2009 at 7:13 PM, Viktor Kojouharov > > <vkojouha...@gmail.com> wrote: > >> On Mon, 2009-05-18 at 18:30 -0300, Rafael Antognolli wrote: > >>> On Mon, May 18, 2009 at 7:46 AM, Gustavo Sverzut Barbieri > >>> <barbi...@profusion.mobi> wrote: > >>> > On Mon, May 18, 2009 at 6:31 AM, Ryan Raasch <ryan.raa...@gmail.com> > >>> > wrote: > >>> >> Hello, > >>> >> > >>> >> I am trying to write an EThumb_Plugin to load an xml file with an > >>> >> embbeded jpeg file. However, the plugins written for Ethumb need > >>> >> "ethumb_private.h". This is not very practical to develop plugins > >>> >> outside of the source tree. > >>> >> > >>> >> Is there any thoughts on this? I will help if needed. > >>> > > >>> > yeah, Ethumb struct could be moved to Ethumb_Plugin or even better: > >>> > the attributes we need could have setters in Ethumb.h or > >>> > Ethumb_Plugin.h, most are already in Ethumb.h, now just need couple to > >>> > access canvas and all, then move plugins to use it instead. > >>> > >>> I've just added some getters to Ethumb API. I think they are enough > >>> (at least to my plugins), but let me know if you need any other. > >> > >> > >> maybe this is the right thread to brings this up: > >> > >> could be a good idea to have a some sort of generic getter/setter that > >> sets properties for plugins to look at. Instead of having > >> ethumb_video_time_get|set, and the document page equivalent, it would be > >> better to have ethumb_property_get|set or something of that sort, so > >> that plugins can be able to obtain other properties that could be > >> useful, without adding more setters and getters. This would also make > >> the video_time and document_page functions obsolete. > > > > I agree. I only have made these video_time and document_page functions > > because it was simpler than having a generic property get/set > > function, and since I was not planning to write newer plugins soon, it > > wasn't really necessary. > > > > But maybe it's time to do it now. I'll take a look at it soon, just > > finishing the client/server stuff and some changes on ethumb lib > > itself. > > I disagree as this would defeat the purpose of plugins implementing a > set of features. For example, if you start to make it open, > applications would need to know deep into plugins, and that's not > good. By forcing a explicit api we can stop and think about stuff, how > to unify and be consistent. Otherwise applications will start to use > emotion plugin on frames and xine plugin on time and mplayer plugins > on tick based, defeating the purpose of the whole thing. So far we did > document/paging and video, if you need new kind of feature, just say, > let's think about it and design a good system, it might help existing > stuff as well. I disagree with this. Its entirely up to the plugin to decide what features it can support. Just because the current API covers two cases, doesn't mean that you're safe. I can think of a few other properties besides frame or document page for plugins, and I'm sure other people might think of others as well. There should be no reason to limit what plugins support by hard-coding what properties any potential plugins should have. And if they are properly documented and there's even slight coordination, I doubt that the scenario you showed would surface.
> > As for "generic" property, it would be as hard as the current > implementation, instead of giving a single parameter and changing the > value in structure, just give two and append to a list. But please > don't do it, it will harm more than help the project. you can also use variable arguments to add as many properties in one go as you need. > ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
