Hello,
I would really like to be able to browse the documentation for e.g. jQuery within the Amber IDS, i.e. in the same way I can look at any Class's methods in Pharo. Obviously, I could create an Class called jQueryDoc and simply build the documentation into the class by duplicating all the methods in jQuery. However, I was hoping there may be a better way of doing this.
What does everyone else do? Do you just have the documentation for e.g. Processing, open in a browser window? Cheers Andy
|
This would indeed be great,
Speaking of Processing,... you all should have a look at the Processing IDE. The debugger is awesome. Ideal for beginners. The debugger points the developer direktly to the appropriate page of the dokumentation. I just wrote a wrapper aorund the whole processingJS API and added the dokumentation as comments (SubClasses of the API are yet missing,... but will follow next days). Have a look here: https://github.com/HeSe/amber-processingJs This makes live much easier. Sebastian Am 30.10.2012 11:46, schrieb Andy Burnett: > Hello, > > I would really like to be able to browse the documentation for e.g. > jQuery within the Amber IDS, i.e. in the same way I can look at any > Class's methods in Pharo. > > Obviously, I could create an Class called jQueryDoc and simply build > the documentation into the class by duplicating all the methods in > jQuery. However, I was hoping there may be a better way of doing this. > > What does everyone else do? Do you just have the documentation for > e.g. Processing, open in a browser window? > > Cheers > Andy |
That looks great!
Perhaps we should each make a point of adopting a javascript library, and start to roll it into Amber. Obviously, our choices would be based upon what was important to each of us individually, but it would be nice to avoid duplication.
My thought is that the Amber port should contain all the methods that a library offers - unless there is some obvious reason why that wouldn't work.
On Tue, Oct 30, 2012 at 2:53 PM, Sebastian Heidbrink <[hidden email]> wrote: This would indeed be great, |
In reply to this post by Andy Burnett
I'm not so sure of this.
why coupling Amber with *any* external library? We already have a proxy to access them all, not everyone is well documented and anyone can google the docs they need. What we do need badly is to have an IDE that kick every other butt out there And we can make it Have you guys saw the helios branch? my two cents sebastian On Tuesday, October 30, 2012 4:46:05 PM UTC-2, Andy Burnett wrote: Hello, |
I think you get to the heart of the issue. Should the documentation for any library just be another tab in the browser - this would presumably always give us the most up to date version of the docs. Or, should it be a seamless part of the IDE.
My thoughts are driven by the 'cognitive load' I am experiencing in using jQuery, and then - in my mind - multiplying it for every other library I might want to use. It isn't a huge issue. But, if you think of your experience of, e.g. using montecello to install Zinc, you can pull in a package that you don't know at all, and immediately see all the classes, methods, and comments. For me, this is really helpful when I am trying to use new code. I would love to have the same experience when I am using processing, Raphael, Sencha, or anything else that we find interesting to explore.
However, there might be much better ways of dealing with this. Which is why I am curious how the rest of you guys handle the problem. Cheers Andy
On Tue, Oct 30, 2012 at 4:29 PM, Sebastian Sastre <[hidden email]> wrote: I'm not so sure of this. |
In reply to this post by sebastianconcept
Well, I coupled it exact because of
that reason. I did not want to have a look into the dokumentation
all the time and checkout what the API might provide.
And it provides a great decoupling of what and where to expect the Amber debugger and where to use e.g. firebug. Methods and their params are fixed an therefore one is be able to share examples and codeing based on such an interface without having 3 versins of a method like: draw: x: y: w: h: , drawX: y: width: height, draw: p:2 p3: p4:,..... Helios looks awesome. Any roadmaps and release dates available yet? Sebastian Am 30.10.2012 13:29, schrieb Sebastian Sastre: I'm not so sure of this. |
the only available thing we know for sure is the need for help to get it done :D
want to change the world? here is a way to be part of the revolution >:) On Tuesday, October 30, 2012 6:42:48 PM UTC-2, HCSebastian wrote:
|
In reply to this post by Andy Burnett
I get your point and I'm not saying it's a bad idea in the abstract.
What I say is that we are having cognitive friction because: 1. our IDE isn't as good as it should be (helios will change that) 2. we don't have a smalltalk debugger (that kicks everyone else's butt and the new compiler should make it feasible) 3. so we don't have yet the hyper-productive development cycle smalltalkers are used to experience Let's trust design and focus on having a solid foundation first Once we get that done all will fit into place by itself By that time you're head will explode of good things to do with it the other way around? Wont work not at all sebastian On Tuesday, October 30, 2012 6:39:26 PM UTC-2, Andy Burnett wrote: I think you get to the heart of the issue. Should the documentation for any library just be another tab in the browser - this would presumably always give us the most up to date version of the docs. Or, should it be a seamless part of the IDE. |
I love the idea of my head exploding with exciting possibilities :-) Ok, let's park this for now, and I will focus on helping the Helios branch.
Cheers Andy
|
In reply to this post by sebastianconcept
Sebastian, I think you are now making Amber worse than it is.
Sure, tooling isn't as good as what we are used to, but it is way better than the stuff one might has to use once you are used to any kind of Smalltalk IDE browser. Where is the list, or statement that you guys are looking for help? How can the Amber users contribute? Amber templates, HMI, Flow, Ludus, Twitterwall, ProcessingJS,... they are all some kind of contribution.... But how do you guys plan to extend the kernel? I was just looking at Point and missed "dist:", ... how can we provide such, if not as an extension? Does Nicholas have the time to answer all pull requests? There's an issue list, but as a Amber beginner I don't want to mess up something I'm not 100% familiar with. I think it might be useful to have a list of small tasks which are strictly realted to Amber that might help bringing the core team forward. I can share general things that come across my amber implementions. Things like missing methods or classes in the core. My colleagues won't want to read several APIs of js libraries/classes e.g. Math, JSON,... just to find out what might be out there. They want to be able to play around with low effords and therefore I think a more clear interface to JS might make sense. Will Kernel stay a single js file? I could imagine, that Amber might soon become quite large and one should have a chance to strip the needed js sources down to a minimum for deployment. How do you want to bring all implementations together? Do contributer just write examples and fork the whole amber repository? Do you prefer the usage of Git submodules, and how shall we use them? Will Amber become Node dependend, or are other servers planned? ...? ... ? Amber is great already but it is a black box. No offense, Sebastian |
In reply to this post by Andy Burnett
Hi!
The question on an Amber Magritte was asked for quite some time and I just thought about an alternative in form of an hybrid solution. Shouldn't it be possible to have Magritte, or MagritteMagic with the JSON Addon on e.g. pharo server side and something like this on the amber client side? https://github.com/daffl/jquery.dform found via http://daffl.github.com/2011/01/06/jquery-dform.html a test site: http://jsfiddle.net/Zt4Rz/ Sebastian |
Free forum by Nabble | Edit this page |