2009/5/20 Viktor Kojouharov <vkojouha...@gmail.com>: > 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.
As you can imagine I disagree with that. First, the idea with plugins was to transparently handle media, not to specifically talk to one. Applications talk to thumbnailer and say "get me a visual representation of this file", and you specify some properties you'd like. Actually these properties should be guessed, but it's too difficult to guess right so we're giving hints. For example, if it was easy to avoid black screens and producer's logo/introduction from videos without wasting too much cpu time, we'd not even specify video properties. Same for documents, if we can find a good heuristics to avoid cover/empty/index pages, we could avoid these properties at all. Remember we're doing a thumbnailer, not a general purpose image resizing framework, the main goal is to make it easy to generate visual representation of files, not to replace gimp/imagemagick. And as I said, these properties are hints, of course plugins might not implement it. But when plugins implement, they have a rule of what to implement. Example, we know video have couple of properties with well known meaning. Generally we should not even specify such properties, but if we do (to overcome technical problems), we might present user with an interface to set such programs, even visually as Playstation3 do for video, you know the parameters you need to set. If we start to let it too loose we'll have to force apps to query installer plugins, then their properties and then try to map these to ui. Xine and others tried to do such a generic property-ui mapper and it sucks hard. > There should be no reason to limit what > plugins support by hard-coding what properties any potential plugins > should have. I really believe it's not a limitation, it's just forcing us to think, design and implement in central place. It will avoid fragmentation and help system overall. We tried to design it to fit cases we imagined, but if you really think of extra parameters, write them in a wiki and let us know, let's discuss and they'll go into the public api. This helps everybody. > And if they are properly documented and there's even slight > coordination, I doubt that the scenario you showed would surface. This is the same as saying "plugins will write to a memory address that is docummented" (same process usage, regular ethumb api), or "plugins will register a dbus interface on their own to handle specific properties" (client-server api). Think about these, they're really ugly solutions, aren't they? But that's exactly what you're asking for, but dressed in the form of a api method. >> 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. that's syntax sugar, it's easy. I'm more concerned with the system usefulness of such thing. -- 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
