[Sugar-devel] [DESIGN] for Journal Plugins feature
Aleksey Lim
alsroot at member.fsf.org
Fri Nov 27 11:15:52 EST 2009
On Fri, Nov 27, 2009 at 04:57:40PM +0100, Bert Freudenberg wrote:
> On 27.11.2009, at 07:13, Aleksey Lim wrote:
> >
> > Hi all,
> >
> > Want to know what people think about Journal Plugins feature[1]
> > and particularly that design team think about UI changes[2] involved
> > in this feature.
> >
> > [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#
> > [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes
>
> I like the idea.
>
> Reminds me of how in OS X, the Finder can be extended to support more file formats by a plugin stored in an application bundle. The Finder knows how to show previews for several document types (audio, video, multi-page document). It recognizes a limited set of formats (like jpg, mov, pdf), and the app's plugin simply needs to convert its own format into one of these formats.
yup, I had the same in mind, API will let Journal plugin to use query
(tags(which include MIME types tags) and search string) to restrict
final set of objects
> That's a lot simpler than having to write an actual viewer plugin (which also would have to be maintained for every new version of the viewer). E.g., Etoys stores a thumbnail in its project file which are simply zipped, so the preview plugin just extracts the thumbnail picture from the project. Tt does not have to care about the actual UI used to display the thumbnail.
there is another benefit for separate plugins -
plugins could be out of sugar release cycle(;P to core maintainers)
--
Aleksey
More information about the Sugar-devel
mailing list