[Chandler-dev] Yet another proposal for Chandler plugins
pbossut at osafoundation.org
Thu Feb 15 10:43:12 PST 2007
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
- 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)
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:
>>> 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
> 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:
> 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
More information about the chandler-dev