Since I initially gave a "+1" to the proposal of yanking out the
plug-ins, I think I need to give my 2cts on the current proposal:
- I think I've been convinced by the thread that taking out the current
"Experimental" plug ins is not a good idea as it'll hinder potential
contributors to tinker with code, so I'm taking back my "+1" on that. I
was wrong.
- I don't think we have enough time to implement Andi's (most excellent)
proposal: it's great but too late and Preview's focus is on delivering a
great end user experience. I'd rather spend time on perf, fit and
finish, better interop to name a few.
- We still need to prevent unsuspecting users to launch the plug-ins
without proper warning so I'm supporting for Preview the idea of a
binary toggle that would pop up a warning message when toggled on (UI TBD)
Cheers,
- Philippe
Phillip J. Eby wrote:
At 11:44 AM 2/14/2007 -0800, Ted Leung wrote:
On Feb 14, 2007, at 9:03 AM, Phillip J. Eby wrote:
At 05:15 PM 2/13/2007 -0800, Ted Leung wrote:
On Feb 13, 2007, at 4:57 PM, Phillip J. Eby wrote:
At 04:33 PM 2/13/2007 -0800, Ted Leung wrote:
So while README's are good,
they aren't nearly enough.
Yes, I'm just saying that this doesn't seem to me to interfere or
compete with Andi's proposal. Andi has uses for the functionality
and the willingness+ability to develop it -- which is not really
the case for what you're proposing, IIUC.
At least having README's and buildable plugins goes a good way
towards having examples that others can tinker with. Improved
ability to tinker (e.g. the menu proposal) is also helpful.
Arguably, good tinkering support is at least as important as
reference documentation and tutorials, which we already have
several of.
Obviously, all documentation can always be improved, but in terms
of rounding out what we have, Andi's proposal does help to fill out
one of the weaker spots.
Andi solicited feedback on his proposal and I gave it. If you guys
want to ignore it, that's your perogative.
Ted, in this thread:
http://lists.osafoundation.org/pipermail/design/2007-February/
006301.html
you +1'd a proposal that differs very little from Andi's as far as
I can tell in practical terms. It would be helpful if you would
clarify why your opinion appears to be so different now. Note that
both proposals call for plugins to be initially inactive, and to
have a UI facility for accessing them. Andi's proposal allows us
to offer more features in the plugin selection UI (i.e., the
Cheeseshop one) at comparable cost.
The proposal I thought I was +1 ing involved a single menu item (a
binary toggle) to enable or disable all the demo plugins at once.
There is no plugin activation UI, no browser for discovering new
plugins, etc, which is what would be needed for the plugin selection UI.
Ah... now I see. There's some context from the conversation between
Andi and I that I now see wasn't clear in the proposal posted, or at
least an assumption I had from our conversation that wasn't reflected
there.
Specifically, I assumed that we would not need to make anything
available in preview except the ability to pop up the platform web
browser, pointed at the Cheeseshop page for Chandler plugins, similar
to this page for Trac plugins:
http://cheeseshop.python.org/pypi?:action=browse&c=516
To me, popping up a web browser seems less challenging than an
"enable/disable plugins" feature to implement, hence my confusion.
I'm confused by your remarks at this point because I don't
understand what developer documentation has to do with the subject
at hand (i.e., what to do about plugins in the Preview release).
The subject at hand (in my mind) is do we include the demo plugins.
The reason why is to encourage developers to try writing their own
plugins. Given that as the ultimate goal, if we are going to spend
time doing more UI than the binary toggle,
Right -- and I'm seeing it as *less* UI, with most of the items Andi
proposed being 1.0 items rather than being blocking features for
Preview. If some of them (appropriately prioritized) happen to make
it to Preview, then great. But the only one I see as essential would
be the one that gets you to a page with plugins.
So, something like a "Plugins" menu with an "Install..." item, that
just pops up a dialog saying that future versions will have something
fancier, and for right now we're going to launch your web browser to a
page that lists OSAF-developed and user-contributed plugins, and
please see their individual web pages for instructions.
Anyway, that's what I'm visualizing from Andi's proposal in the
Preview timeframe.
then I would rather see us
spend the time on more docs. But I would be plenty happy with just
a binary toggle for Preview, and I've given up hope that we will get
any more dev docs by Preview. We just have too many other things
(like performance) to work on.
Does that help?
Yes, thank you.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
