On Tue, Jun 2, 2009 at 2:42 AM, Sergey Semernin<sergey.semer...@gmail.com> wrote: > Hello, All. > > What kind of fm2 preview plugin is mean?
Well, if you refer to Release item, it's a very minor stuff and is very costly (large amount of code) to do, so I'd postpone it as much as possible, maybe someone will do it as SoC another year. But anyway here it goes: > I see it as 'preview' fm2 filelist mode with: > 1. rect zone for embedding graphics, > 2. area with filelist, > 3. area with toolbar to rotate, zoom and pan preview. > > So, we need a way to bind file's mimetype and preview module, > that embedding into zone (1). Also we need unified preview > module interface, such as: > 1. open file and show it, > 2. zoom in/out, > 3. pan. > > Have e17 a way to bind mimetype and view plugin (for ex. as in KDE > KParts::ReadOnlyPart)? That's in order to avoid duplicating functionality. > Second, to build unified preview module interface, is it possible to use > E17 'smart objects' paradigm and structures with functors (pointers to > module's functions) or I need something else? AFAIK we do not have the KDE equivalent, but maybe raster knows something else. As for the other parts, that's about it. I did think a lot about things to share and not to share and at the end maybe it's better to have simple standalone applications to do the task. One of the reasons is that we do not have much to share between movie and documents (pdf, ps) and images, they're really different use cases and trying to make the plugin fit them all will be bad. Another reason is that most of these stuff are likely to crash and if they're an e module (inside same process) e17 will crash as well, something that we really do not want, or make it sluggish for the same reason. That said, another process will fit better, but we could try to make these apps look alike and be really simple so they load fast and are easy to use and to maintain. You could start doing these apps by changing most tests like emotion and epdf/eps/edvi, write something really simple for images (maybe just view one image, not even navigate in the same folder). If to improve usage from E we need to remote control or feed it parameters, then fine, as we're writing with this purpose we could make them read/write to sdin/stdout and e17 could be told about some actions or tell some actions. ATM i don't have any good use cases, but maybe opening this app will make it reparent over the efwin that launched it, maybe closing the efwin closes the preview, etc... Anyone has good ideas? as I said it's a minor point and can be easily dropped for e17. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
