+1: I answered on the chandler-dev without realizing that Katie already
did such a great synthetic proposal.
Cheers,
- Philippe
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
