[Chandler-dev] Yet another proposal for Chandler plugins

[Philippe Bossut]

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