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. 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. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ 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
