Gustavo Sverzut Barbieri wrote: > 2009/5/20 Jose Gonzalez <jose_...@juno.com>: > >> Gustavo wrote: >> >> >>> 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. >>> >>> >>> >> Well I like their idea and think they should give it a shot >> and see what they can come up with. You're being overly picky >> here in the name of some abstarct notion of 'quality control' >> and what it's really amounting to is restriction and limitation. >> The notion of having these plugins somehow being able to >> use each other isn't all that big an impact here since most of >> these would be one-time shots, not 30-times-per-sec deals.. and >> you and raster actually wanted such a filters-pipeline in evas, >> so it's odd you're against a similar capability here. >> But even if these plugins don't evolve into such a system, >> what they're proposing as a generic 'property/value' api for >> controlling pluging states is very useful for having generic/ >> loadable plugins.. rather than being restricted to some fixed >> set of them with built-in special-purpose state api functions >> for just this or that known or built-in plugin. >> >> There's a lot that can be done.. but not if arbitrary restrictins >> are kept in the name of some fixed functionality that you happen >> to want right now or some ideal notion that you can pick the >> best centralized design that will cover all that's interesting. >> >> I'd say let Viktor and Rafael use their imagination and skills >> and let them try and experiment and do their thing here. :) >> > > As I said we have a purpose for doing such Ethumb and we need to > remember about it. We're not restricting one's capabilities in doing > whatever he wants, evas is always there, everyone is free to write > whatever stuff wanted, but in order to keep things manageable we need > to balance features and restrictions and I think this is a good trade > off. > >
Evas is evas, this is its own lib for generating "thumbs". Some of that can have built-in cases that are important, but there's no a priori need to limit things to that. As to balancing features vs. restrictions.. Sure, that's always a given. But just why are your restrictions here soooo necessary that all is lost with a more flexible plugin system? You even mentioned something about it 'harming the project', tell me exactly HOW that would 'harm' anything? > I'm still waiting to see concrete ideas of more ideas that can benefit > most and not single special case. Really, there is always a balance of > feature/configurability and ease of use. Evas is one example of such > balance that I believe is good: it does not allow you to do > everything, but the things that it allows you to do it does fast and > it's very easy. If one want to do vector or direct pixel manipulation > it's not the way to go, but if you want to do simple raster effects > it's very powerful and easy. Gtk's TreeView/TreeStore is what I'd > Nonsense. It's just as possible to do vector stuff as raster stuff with evas, api wise. It's just a pain to support all the various engines people have been adding (in particular the 16bpp ones which you pushed for and now have no interest in supporting), and also to work with its primitive internal engine func api which was designed a long time ago for a quick and limited set of abilities. This latter wouldn't be such a big deal to change if again there were fewer engines. There's no loss and large gains in having evas support vgfx directly, as well as further filter and other gfx notions. It's not a problem at all. There is a bit of other stuff at the canvas level that needs redoing if one wants to support complex gfx operations on arbitrary objects, and some of the problems there are due to the way smart-objects were implemented at the canvas level. But again, there's nothing that can't be done, and done quite efficiently - far more so than most current gfx libs do. > say is a bad balance, it allows you to do whatever you want, but it's > very tricky to get right and the simplest table needs lots of work. I > want to avoid having a thumbnail that can generate everything in every > way but it's unmaintainable and awkward to use. > > And as I said, if you really want to experiment, try a global, mmap, > file or export a dbus object to do that. It's as problematic, ugly but > unleashes the power you want. If it proves to be good, we can absorb > the idea in the main api. But I'm against fragmenting the > application-thumbnailer relationship at this point. What we need are > requirements, think about then and act. What we do not need is lots of > special parameters growing out of nowhere and causing more headaches. > Just imagine we add a generic name-value association, to do dbus we > need to add way to serialize it, then to do configuration we need to > add labels, descriptions, range and possible example usage, and at the > end we have a complete me > I'll leave it up to you and the others to come up with a good design here... Can you do it? :) ____________________________________________________________ Start Email Marketing - fast, affordable, and measurable. Click here. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTEFeNwYieh0dm5yIlIoVU1P14sCnGtRLBvyk9ShjNxqc6ZIsMvwEA/ ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
