[Design] [Proposal] Removing plugins and what else for Preview?

[Ted Leung]

+1 to the new proposal.  I think that hiding plugins in the end-user  
release is a mistake.

On Feb 9, 2007, at 12:39 PM, Katie Capps Parlante wrote:

> We've been discussing how to handle plugins on the chandler-dev  
> list, and I think we've hit on some topics that really belong on  
> design, so moving the conversation.
>
> For background on the conversation that followed Heikki's initial  
> message, check out the dev-list thread:
> http://lists.osafoundation.org/pipermail/chandler-dev/2007-February/ 
> 007608.html
>
> Ok, new proposal...
>
> + Do not remove plugins from end-user release
>    - have them be "disabled" by default, not loaded
>    - leave the projects/ and samples/ directories in the distribution
>    - have a menu item that "turns on" or "enables" plugins
>
> (Presumably in the future we'll have a better ui to do this plugin  
> by plugin, perhaps from a preferences panel, but just do something  
> very basic for Preview)
>
> + Create a "test" plugin and move test code to this plugin
>    - e.g. "generate items"
>
> + Remove the "Test" menu altogether, and create a "Tools" menu  
> which is available in all releases.
>    - "test" plugin can insert some menu items into "Tools"
>    - "check repository" and similar tools can remain available in  
> "Tools" by default, even in end-user release
>
> + Rename "Experimental" to the shorter "Demo"
>    - plugins like "amazon" and "flickr" can insert menus here while  
> they are still of "demo" quality
>
> Arguments in favor of the proposal:
> - the current plugins do not dramatically impact the download size,  
> so we're not losing much here
> - end-user awareness of plugins is a GoodThing(tm)
> - some potential developers will grab the end-user release --  
> lightweight plugin development should be doable with the end-user  
> release (long term goal); basically we don't want to *hide* the  
> idea of plugins from people (developers or users), we want to do  
> the opposite
> - the main advantage of not including the plugins was to not make a  
> commitment to a high quality level in the "demo" plugins -- we  
> satisfy this goal if they are disabled by default
>
> Cheers,
> Katie
>
> Heikki Toivonen wrote:
>> Katie mentioned that we plan to remove plugins from Preview. This
>> prompted me to get a clarification of what exactly do we want to  
>> remove
>> in Preview.
>> I'd like to trim the end-user release to NOT include:
>> projects/ directory (i.e. plugins)
>> tools/ directory (i.e. functional and performance tests)
>> *tests* directories (i.e. unit tests)
>> samples/ directory
>> all files not needed to run Chandler or Python itself under release/
>> directory (i.e. remove any scripts and utility executables still left
>> there - I have proposed to make a separate zip download for people  
>> who
>> want these)
>> Experimental menu
>> Test menu (we'd probably want to move some more of these items to the
>> remaining menus)
>> I'd leave developer release as is.
>> Note that this would mean that localizers would need to get the
>> developer build unless we made a localizer's zip that could be  
>> unpacked
>> over the end-user release.
>> Pros:
>> * Smaller downloads
>> * Smaller disk footprint
>> * Slightly smaller memory footprint
>> * Slightly better performance
>> * A little cleaner UI
>> Cons:
>> * Dealing with the confusion of different files in end-user and
>> developer releases
>> * Need to make some downloadable packages for tools
>> --------------------------------------------------------------------- 
>> ---
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> Open Source Applications Foundation "chandler-dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design