[EMAIL PROTECTED] wrote: > Moving this discussion to the mailing list, for others to participate: > > "Alexander Trauzzi" <[EMAIL PROTECTED]> writes: >> Qooxdoo has a lot of neat features that dojo doesn't. Qooxdoo looks a lot >> more programmer-friendly, even in spite of dojo's their "package >> management". The biggest I can think of is asynchronous JSON calls and the >> features surrounding it all. Dojo just didn't seem to care when I brought >> that to their attention. >> >> There are some widgets and features however that put dojo a few steps ahead >> of you guys. Text editor, widget appearances. Your windows are better, but >> how do I use them?! Documentation and tutorials are a must. >> >> If there are any developers willing to sit online on some weekends and put >> up with my painful questions, I'll help write documents... >> >> It would really be a good idea not to just put this to some time in the >> future and assign it a meaningless priority. The more users qooxdoo can >> attract, the more momentum you'll gather. Right now I want to make some UIs >> using qooxdoo but I simply have no documents and examples to easily learn >> off of. >> >> Good luck! > > I responded: > >> Alexander, >> >> Your help in generating better documentation would most certainly be >> appreciated! I think you'll find that if you ask questions on the mailing >> list rather than "sit online on some weekends" as you suggest, you'll get >> better input from more people. There are different people with expertise in >> various areas of the code. If there are particular areas that require a >> discussion rather than email, moving the discussion to IRC is certainly an >> option. >> >> The 0.5.2 version that you're using (or at least that you reference in this >> bug report) is not being actively developed any longer; it's the "previous >> generation". Bug fixes are still being done for it, but very little new >> development. Pretty much all of the new development is going into the >> 'namespaces' branch, which is in fact about to become 'trunk' in svn. In >> 'namespaces', there is "better" documentation and a much better method of >> finding/viewing the documentation. From a user perspective, though, there's >> still a *very* lot that can be done to document overall usage vs. usage of a >> particular function or class. Having someone like you dedicated to writing >> user documentation would be wonderful! >> >> Please, start asking your questions. I will answer what I can, although my >> knowledge areas in qooxdoo are still somewhat limited. I'm quite sure that >> others will help answer your questions as well. Ask away! >> >> Derrell > > "Alexander Trauzzi" <[EMAIL PROTECTED]> followed up with: > >> Thank you for the quick and warm response! >> >> It looks like I am using 0.5.3, so that was a mistake on my part for the >> drop down selection. What are some detailed differences about the >> namespaces trunk-to-be? How does one find and view the documentation, or is >> this still in the works? I am new to learning the lay of the land with >> participating in projects and so perhaps there is information technical >> enough for me to absorb already? I'm just not finding it. >> >> I have an overall decent grasp of javascript, certainly not quite to the >> level of the developers of JS libraries, but enough to know that it isn't >> truly a full-blown OO language etc. >> While developing documentation, I may sometimes need to be reminded that "In >> Javascript, this is like that", although I seldom have that problem as it >> is. If you guys are forgiving of this, I'd love to evolve my learning >> process a little to make it readable, postable and palatable. Information >> on where to post my lessons once compiled would also be appreciated. >> >> I have subscribed to the mailing list, so I'll get down to things as time >> permits! > > I just went searching on the web site for a page to refer you to, that > explains the overall changes in 'namespaces'. Unfortunately, there doesn't > appear to be one. All of the discussion of the differences have been on the > mailing list. Given that the 'namespaces' branch is about to become 'trunk', > I expect that Andreas Ecker will be posting a "what's changed" document very > soon. (Andreas, if you weren't already planning on it, something should go on > the web site as well as to the mailing list about this.) > > A couple of significant differences that you'll see in 'namespaces' are: > > - The class names are all namespace-safe. Instead of QxImage, for example, > you'll find qx.ui.basic.Image. Aside from the namespace benefits that this > provides, it also makes it very easy to find the source file for any class, > since the source hierarchy, with very few exceptions, is layed out in the > same way as the namespace hierarchy. > > - API documentation is much improved over the 0.5.x versions. A new > automated API documentation generation tool allows developers to provide > documentation within the code, which is extracted and presented in a useful > manner to users of qooxdoo. > > - A bunch of new development has been done in this new version: > > - The new Table widget is a great enhanced over the standard ListView. > Table is a "virtual" widget which allows large datasets to be available > for display while rendering only those that are actually visible. This > provides a huge benefit in rendering speed. > > - Remote Procedure Calls using JSON are working well, and both a Java and a > PHP JSON-RPC server (back-end) are provided. > > - Many small improvements and probably some other new widgets that I'm not > thinking of right now. > > You can check out the 'namespaces' branch with > > svn co https://svn.subversion.net/svnroot/qooxdoo/branches/namespaces > namespaces > > I believe that within the next week or so, this branch will be moving into > 'trunk' to replace the 0.5.x version that currently in 'trunk'. > > To generate the API documentation for 'namespaces', look at > > http://qooxdoo.org/documentation/developer/api_documentation > > See, also, the other pages in the 'developer' section. Although they mostly > apply to the 0.5.x version, with some class name changes, the principles still > apply. > > Cheers, > > Derrell > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >
Derrell, Thanks for the helpful post, but I think your response echoes the OP's point that more needs to be done towards documentation. Not only is the namespace documentation light to non-existent, but the documentation you site on how to generate the documentation is out of date. I tried following the steps listed at 'http://qooxdoo.org/documentation/developer/api_documentation' and the structure of the subversion tree has changed. The better way to do things from what I can tell is to enter the 'frontend' directory in the source and perform a 'make docs' (frontend vs. backend isn't even discussed in the referenced link, nor is the make file). Unfortunately, after I figured that out from parsing the makefile, running 'make docs' still didn't help because the docs point us to 'source/demo/apiviewer/index.html' which does not exist. I found what I think the viewer should be at '/frontend/api/build/index.html' but opening that produces a popup window with loads of errors and no documentation that I can actually view. After all that effort, my interest in getting the docs working for the namespaces API is all but gone and sadly I've given up and gone back to cranking dojo widgets. <rant-warning/> <rant> The lack of API (the examples are great) docs is one of only two things keeping me from using Qooxdoo straight away. Sure, it's a volunteer effort and I understand that but the lack of docs is an huge barrier to entry for those interested in helping out. If Qooxdoo is the best toolkit available and nobody but the devs can figure out how to use it, Qooxdoo will join a long list of projects that were great but never reached their uptake potential. I truly think Qooxdoo is the best paradigm for rich ajax development out there right now, but sadly I can't recommend using it to my customers due to things like the documentation issues and this dead zone between the 'no new development' 0.5.x branch and the 'no releases or docs yet' namespaces branch. </rant> -erik ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
