On 2/7/2006, at 17:30, Daniel Käsmayr wrote:
do you think you could change the filter list in the bundle editor so there is a chance for bundle developers to provide a short description of each bundle? Either via ToolTip or an extra column in that listing?
The Filter List as we know it will likely go -- but I do plan to add some editable bundle meta info as this will be necessary for more automated bundle installs (picking from a list.)
And speaking of cool stuff for bundle developers: is there any chance of having bundle developers create custom file icons? ;)
Unfortunately not -- the problem is that document icons have to be declared in TextMate.app/Contents/Info.plist and they need to be placed in TextMate.app/Contents/Resources -- so the only way to support this, would be if TM ensured that they were copied to the application package and the info property list was updated.
But since TM can’t be sure it can actually write to TextMate.app, and the administrative work related to ensuring that it’s always in sync is simply too complex for this to be feasible :( it would however be a very nice change (so I won’t totally rule out that maybe some day I actually do go through the hassle of making it work.)
it would be nice to see from this listing
- bundle version / date of last "release" i.e. svn revision date
I might provide “per bundle” RSS feeds, and show these in the bundle editor, which should also make it possible to subscribe to third party bundles (and at the same time users should be able to publish their stuff.) Though I haven’t really settled on an automated bundle updating system that I like yet.
- if there are local modifications
- where the bundle is installed (/Library, Pristine etc.)
Yes, these have long been on my own wish list :) with the delta stuff things are a little more muddied. A “Revert to Defaults” would also make many support sessions shorter :)
[...] Is there a way to access the not-plist-stuff from bundles from within the bundle editor?
No -- one of the ideas is to turn the bundle editor into a special type of project (for the 2.0 GUI), which would make it closer to a regular project, and thus make available all the usual tools of TM (such as e.g. svn for bundle developers, diff against the default for normal users, etc.) and it would give access to the Support folder -- but there are also some losses by not writing a dedicated editor. I am however pretty keen on turning it into a special type of project mostly for pragmatic reasons.
On 2/7/2006, at 20:03, Oliver Taylor wrote:
[...] To me, the most important items are (in order):
- Some kind of bundle version number
- Where to find out more about the bundle (new versions,
documentation, screencasts, etc.) 3. Author(s) credit & date. 4. Short Description. 5. If there are local modifications.
Except for #5 the convention is to create a Help command which shows documentation with this info using the HTML output window.
Many bundles currently do have this, of course, many of the help files are also outdated ;) probably to counter outdated documentation it would be best to provide per-item documentation and offer a way to show this in an aggregated form (a la how most code documentation systems work), so that the documentation doesn’t refer to bundle items by name or mention key bindings (some of what changes the most.)