Hey. Where does the extra information come from for the Macromates bundles? Also, any chance of adding a link to the GitHub project for all those?
I'd also really like to inclue some really basic html into the descriptions of my bundles. I'd especially like to get a few images into my more visual bundles.
So, how hard would it be to convert the more-info thing into a webview? And where do I actually add those descriptions? For GitHub bundles you could parse the README files for the bundles like GitHub does.
— thomas Aylott @ subtleGradient
On 23.07.2008, at 18:45, Thomas Aylott wrote:
Hey. Where does the extra information come from for the Macromates bundles?
Do you mean the descriptions of bundles hosted at the svn trunk? If so, I parse the info.plist of each bundle, tag <description>.
Also, any chance of adding a link to the GitHub project for all those?
This could be done I guess. Maybe also for the svn bundles. And this could be put into a more-info thing.
I'd also really like to inclue some really basic html into the descriptions of my bundles.
Do you mean for svn and github?
I'd especially like to get a few images into my more visual bundles.
So, how hard would it be to convert the more-info thing into a webview?
I'll try something.
And where do I actually add those descriptions? For GitHub bundles you could parse the README files for the bundles like GitHub does.
For svn bundles I don't see a chance to add a more detailed description. He only way would be that Allan decide to add soemthing like that into the bundle architecture.
For github, well, to parse the README file would be tricky caused by the issue that these are coming in different formats. But it could be, maybe, possible to get the README stuff from github's HTML page meaning e.g. the <div id="readme">...</div> part of http://github.com/subtleGradient/subtlegradient-tmbundle/tree/master
Then the HTML rendering will be done by github.
--Hans
BTW I uploaded a new GetBundles to the review. The entire error handling is strongly improved. I also added a help nib plus button, and a check box to make it possible to install a git bundle by downloading it as zipball. This is useful for users whose computer is behind a firewall which blocks the git port.
On Jul 23, 2008, at 1:00 PM, Hans-Jörg Bibiko wrote:
On 23.07.2008, at 18:45, Thomas Aylott wrote: I parse the info.plist of each bundle, tag <description>.
Also, any chance of adding a link to the GitHub project for all those?
This could be done I guess. Maybe also for the svn bundles. And this could be put into a more-info thing.
Maybe we could add the link to the description in the info.plist. And for Github you could just tack on the homepage value for the repo.
I'd also really like to inclue some really basic html into the descriptions of my bundles.
Do you mean for svn and github?
Seems Allan already officially added support for html in the description over a year ago:
Author: duff Date: Sun Mar 4 20:11:31 2007 +0000
Add the following keys to the bundle’s info.plist: contactName: The full name of the contact for this bundle. contactEmailRot13: A ROT13 encoded email address for the bundle contact (weobfuscate it to avoid spammers from picking up the files, seeing how bundles will often be available via anonymous svn over http). description: A short description for this bundle. Do link to more info about the language (or whatever) the bundle is about. I decided on using HTML for this (but leave out the initial paragraph tag) since it seemed like overkill to run a single line of text through Markdown.pl, just to convert [foo](link) into <a href="link">foo</a>
Many of the current descriptions could use some improvements,I just wanted to get the ball rolling :)
For GitHub bundles you could parse the README files for the bundles like GitHub does.
For svn bundles I don't see a chance to add a more detailed description. [The] only way would be that Allan decide to add soemthing like that into the bundle architecture.
You could just parse a README file in the root of the bundle (if it exists) like for GitHub bundles.
For github, well, to parse the README file would be tricky caused by the issue that these are coming in different formats.
There are only a couple of options on GitHub: plain text, textile, markdown, etc... You could just simply support the first three with the existing textile and markdown parsers in the textmate support folder. Nobody seems to really use any but those anyway.
But it could be, maybe, possible to get the README stuff from github's HTML page meaning e.g. the <div id="readme">...</div> part of http://github.com/subtleGradient/subtlegradient-tmbundle/tree/ master
Then the HTML rendering will be done by github.
Well, whichever has the best performance. It might be faster to do that than to load the README file yourself and then parse it yourself.
--Hans
BTW I uploaded a new GetBundles to the review. The entire error handling is strongly improved. I also added a help nib plus button, and a check box to make it possible to install a git bundle by downloading it as zipball. This is useful for users whose computer is behind a firewall which blocks the git port.
Yep! I saw it. There are a few minor issues I was going to nit-pick about but figured I'd wait until you were done. I don't think nib changes merge very well, so should I post another zip if I change anything?
Thanks!
— thomas Aylott @ subtleGradient
On 23.07.2008, at 19:27, Thomas Aylott wrote:
Maybe we could add the link to the description in the info.plist. And for Github you could just tack on the homepage value for the repo. Seems Allan already officially added support for html in the description over a year ago:
Author: duff Date: Sun Mar 4 20:11:31 2007 +0000
Add the following keys to the bundle’s info.plist: contactName: The full name of the contact for this bundle. contactEmailRot13: A ROT13 encoded email address for the bundle contact (weobfuscate it to avoid spammers from picking up the files, seeing how bundles will often be available via anonymous svn over http). description: A short description for this bundle. Do link to more info about the language (or whatever) the bundle is about. I decided on using HTML for this (but leave out the initial paragraph tag) since it seemed like overkill to run a single line of text through Markdown.pl, just to convert [foo](link) into <a href="link">foo</a>
Many of the current descriptions could use some improvements,I just wanted to get the ball rolling :)
Well, if this is consistently done one could parse a href for getting more infos but I also saw bundle descriptions mentioned something like: [fictive] bla foo, the language deals with Python (www.python.org), ....
How to distinguish between such a link at the link to an HTML description?
Or did this mean either a plain text for describing the bundle or a link to a external document, but not both? If so then it'd possible I guess.
You could just parse a README file in the root of the bundle (if it exists) like for GitHub bundles.
For github, well, to parse the README file would be tricky caused by the issue that these are coming in different formats.
There are only a couple of options on GitHub: plain text, textile, markdown, etc... You could just simply support the first three with the existing textile and markdown parsers in the textmate support folder. Nobody seems to really use any but those anyway.
But it could be, maybe, possible to get the README stuff from github's HTML page meaning e.g. the <div id="readme">...</div> part of http://github.com/subtleGradient/subtlegradient-tmbundle/tree/ master
Then the HTML rendering will be done by github.
Well, whichever has the best performance. It might be faster to do that than to load the README file yourself and then parse it yourself.
I'll try to set up a basic thing.
BTW I uploaded a new GetBundles to the review. The entire error handling is strongly improved. I also added a help nib plus button, and a check box to make it possible to install a git bundle by downloading it as zipball. This is useful for users whose computer is behind a firewall which blocks the git port.
Yep! I saw it. There are a few minor issues I was going to nit-pick about but figured I'd wait until you were done. I don't think nib changes merge very well, so should I post another zip if I change anything?
If you have something post it to me.
On the other hand I have to fix some "tiny" issues, e.g. how to cancel a runnig installation. Up to now I disallow it, because an installation process is a fragile thing. Even if you quit TextMate the installation runs further and finally it opens TM again, but this I have to fix. Or an other issue I'm using Ruby's Timeout::timeout but this is a bit tricky. E.g. I cannot interrupt such a running timeout. And some other stuff.
--Hans
On Jul 23, 2008, at 2:00 PM, Hans-Jörg Bibiko wrote:
On 23.07.2008, at 19:27, Thomas Aylott wrote:
Maybe we could add the link to the description in the info.plist. And for Github you could just tack on the homepage value for the repo. Seems Allan already officially added support for html in the description over a year ago:
Author: duff Date: Sun Mar 4 20:11:31 2007 +0000
description: A short description for this bundle. Do link to more info about the language (or whatever) the bundle is about. I decided on using HTML for this (but leave out the initial paragraph tag) since it seemed like overkill to run a single line of text through Markdown.pl, just to convert [foo](link) into <a href="link">foo</a>
Many of the current descriptions could use some improvements, I just wanted to get the ball rolling :)
Well, if this is consistently done one could parse a href for getting more infos but I also saw bundle descriptions mentioned something like: [fictive] bla foo, the language deals with Python (www.python.org), ....
How to distinguish between such a link at the link to an HTML description?
Or did this mean either a plain text for describing the bundle or a link to a external document, but not both? If so then it'd possible I guess.
The actual commit included: <key>description</key> <string>Support for <a href="http://developer.mozilla.org/en/docs/About_JavaScript ">JavaScript</a>.</string> for the javascript bundle.
I'd say, this field is officially supposed to be pure text or html. If it's not an html link, then just use it asis without any extra parsing. If they want it to be a real link they can change their description.
— thomas Aylott @ subtleGradient
Hi,
please check out the latest GetBundles.tmbundle from the Review repository. I tried to implemented a 'More details' button or simply press SPACE.
Please note this is the FIRST trial ;)
For git stuff it shows all info about the repository and if available the README file rendered as HTML. For svn it shows 'svn info ...' stuff.
I wasn't able to implement a NSWebView in the NIB (I guess it only works for plugins) but I found a way to display formatted text, provide links, and partly images etc. by converting an HTML file into a rtfd document which will be displayed in the NIB.
Comments?
--Hans
On Jul 24, 2008, at 9:41 AM, Hans-Joerg Bibiko wrote:
Hi, please check out the latest GetBundles.tmbundle from the Review repository. I tried to implemented a 'More details' button or simply press SPACE.
Please note this is the FIRST trial ;)
For git stuff it shows all info about the repository and if available the README file rendered as HTML. For svn it shows 'svn info ...' stuff.
I wasn't able to implement a NSWebView in the NIB (I guess it only works for plugins) but I found a way to display formatted text, provide links, and partly images etc. by converting an HTML file into a rtfd document which will be displayed in the NIB.
Comments?
--Hans
Very cool. Ditch the OK button though. Make it a normal non-textured window with the textview stretched to the very bottom. I tried it out with a HUD view instead and it looked pretty good, kindof like quickview. I'd really prefer to be able to access the main window while the more info thing is still open though. And then either close the more-info window when you select a different bundle, or replace the contents of the more-info window with the extra info the the new selection. Whichever would technically work.
This is getting much awesomer by the second!
—Thomas Aylott / subtleGradient
On 24 Jul 2008, at 18:22, Thomas Aylott wrote:
Ditch the OK button though. Make it a normal non-textured window with the textview stretched to the very bottom.
OK
I tried it out with a HUD view instead and it looked pretty good, kindof like quickview.
Would this be compatible to Tiger?
I'd really prefer to be able to access the main window while the more info thing is still open though.
Actually I want to display that info within the main window. But I have to think about whether it's possible to distinguish between a single click at a list item to display the bundle's default description and a modus to display in the same window the extended info.
One chance is to use the double-click event. Now it's bound to Install Bundles. Maybe we can change this?
It's tricky to use a async DIALOG window and I'm glad that I found a way to some stuff. The more functionality we want the more I tend to put this into a plugin.
And then either close the more-info window when you select a different bundle, or replace the contents of the more-info window with the extra info the the new selection. Whichever would technically work.
;) It was my first trial
--Hans
Hi,
the info window now is an async window which will be replaced by a new one. The OK button disappeared. A Problem is that Tiger hasn't set the NSInfo icon thus one has to create a separate icon for it.
Up to now I wasn't able to catch a single click in the bundle list. I want to be able to click at an item (bundle) and get this selection back in the Ruby script. But I guess one is only able to use a double- click event for this. I can set a performButtonClick event to a data cell but I do not know how to get the selection?
Anyway, I'll try it further ;P
Cheers,
--Hans
On 24 Jul 2008, at 20:37, Hans-Jörg Bibiko wrote:
Up to now I wasn't able to catch a single click in the bundle list. I want to be able to click at an item (bundle) and get this selection back in the Ruby script. But I guess one is only able to use a double- click event for this. I can set a performButtonClick event to a data cell but I do not know how to get the selection?
I think with the ‘observe’ addition to tm_dialog, we can have it return when the selection changes (sort of a single click).
I didn’t understand if you guys are talking about having a short and long (more info) description for each bundle? I think this is a bad idea, there should just be one description (getting just one good description is hard enough :) ). If you want a shorter one to show inline in the UI we can make a convention like everything below a <hr> or similar will not be shown inline.
And yes, the value of the description key is supposed to be HTML, but is implicitly wrapped in <p> -- so technically this would be legal:
{ description = 'first paragraph</p> <p>next paragraph'; }
With that in mind, the convention about inline text could be first paragraph.
On 4 Aug 2008, at 15:21, Allan Odgaard wrote:
On 24 Jul 2008, at 20:37, Hans-Jörg Bibiko wrote:
Up to now I wasn't able to catch a single click in the bundle list. I want to be able to click at an item (bundle) and get this selection back in the Ruby script. But I guess one is only able to use a double- click event for this. I can set a performButtonClick event to a data cell but I do not know how to get the selection?
I think with the ‘observe’ addition to tm_dialog, we can have it return when the selection changes (sort of a single click).
Yeap ;)
I didn’t understand if you guys are talking about having a short and long (more info) description for each bundle? I think this is a bad idea, there should just be one description (getting just one good description is hard enough :) ).
I totally agree ;)
If you want a shorter one to show inline in the UI we can make a convention like everything below a <hr> or similar will not be shown inline.
And yes, the value of the description key is supposed to be HTML, but is implicitly wrapped in <p> -- so technically this would be legal:
{ description = 'first paragraph</p> <p>next paragraph'; }With that in mind, the convention about inline text could be first paragraph.
This sounds feasible. I can be modified rather easily if such a convention is written down elsewhere. By myself I would argue for "we can make a convention like everything below a <hr.*?> will not be shown inline"
--Hans
-
Allan Odgaard -
Hans-Joerg Bibiko -
Hans-Jörg Bibiko
-
Thomas Aylott