|It has been suggested that this article or section be merged with Gadget kitchen. (Discuss)|
Pretty much this is pure open source: people being given the chance to completely rework the user interface, and by tying into the server-side API, construct all kinds of awesome new tools.
Extension:Gadgets provides a way to present individual code chunks as options selectable in Special:Preferences, and has a very primitive management interface at Special:Gadgets which, unfortunately, is based on making local sysops edit MediaWiki: message pages without much direct assistance. There is documentation here so it's manageable, but we could do so much better.
There's a few things that would make a huge difference, without significantly changing how it works, mostly covered in Extension:Gadgets/Roadmap notes already:
- Give Special:Gadgets management page a basic GUI!
- create a new gadget with a click
- provide UI for selecting options (RL compatibility, dependencies, rights restrictions)
- edit the localized names in inline fields instead of linking off to the standalone MediaWiki: message pages
- enable screen shots or logos to be associated with gadgets, and pretty "add gadget", "remove gadget" type buttons.
- Consider a svn path to gadget mapping that makes it easy to do local testing and to import a copy from svn to the wiki page ( maybe beyond baby step )
- It should be fairly trivial to produce a list of relevant pages and drop them into Special:Export automatically. Primary thing to consider is the definition line, which could be split out to its own little page or something.
- This actually got in a while back it looks like -- but you still have to copy-paste the line manually. It does at least show it to you, but that should be automatable too.
- Code editor
- Editing JS and CSS in the wiki editor is awkward: the editor doesn't autoindent, the tab key jumps to another field, and there's no syntax highlighting until you save (if syntax highlight plugin is enabled).
- Embedding something like SkyWriter's code editor could be beneficial, and should be mostly a drop-in.
- Detection of syntax errors while you edit is SO HELPFUL ITS NOT FUNNY
- Integrate Gadgets with user scripts
- make it easy to edit your own *personal* gadgets through the same interface
- one-click publishing from the personal gadget space to the public gadget space
- Integrate Gadgets with site scripts
- lock in 'default gadgets' rather than having to work in a separate area for 'global site js'
- Straightforward way to stash a library of JS scripts, CSS chunks, and images on-wiki? (so they don't have to be loaded from offsite hosting that might not scale or stick around)
- Another task for a well thought out svn bridge, but also accessible via the web with forms and a set paths for "asset buckets" per gadget.
- Default gadgets activated for new user accounts ("training wheels")
Safety and stability
This may be harder!
- menu, toolbar, embedded file rendering hooks, data api access, etc
- stability: defined interfaces should be independent of skin details etc, will continue to work in future
- safety: subset of defined interfaces won't expose direct access to HTML & JS context, so can hook up to restricted execution environments...
- Create safe execution contexts that can let code use the stable interfaces, but not anything else
- Caja-like restricted execution through code rewriting?
- off-site iframes with communication over window.postMessage?
- this is kind of tricky.. but would be useful if we have an opt-in permissions system ie when you click "add gadget" it presents you with a little list of capabilities it needs, with the most permissive being the script runs directly on the wiki ( some things like XHR binary uploads of modified images or videos would be very tricky or slow to do over postMessage )
Live editing and debugging
Being able to at least refresh a script and poke at it while you're working could be quite handy. Really general debugging aids might be tough but fun.