we have to talk about structure first. I am against category structure, because category is not always clear. I am also against library structure, because that is just an arbitrary structure for me, worse than categories. for name clashes make a disambiguation page or directly jump to the object that is more in use and link to the other one with the same name. I am TOTALLY against the word class or selector in any structure layout!!! totally confusing for 99% of the users. have a look at http://maxobjects.com. that is basically it. but pdobjects will have a wiki underlying. marius.
IOhannes m zmoelnig wrote: > Hans Steiner wrote: >> Here's my first stab at representing classes, selectors, and >> libraries in the wiki: >> >> http://pdpedia.at.or.at/test/index.php >> >> Feedback please! > > i don't understand the differentiation between the toplevel "Class" and > "Library": e.g. > Library/zexy vs. Class/zexy/drip > why not do: > > /zexy/drip (for the class-description) > /zexy (for a general library descriptions, including all subitems in the > folder (objects in the library)) > > furthermore, the "selectors" secion doubles information from > puredata.info for no apparent reason. > > i thought the idea behind the wiki was to create a community maintained > database rather than re-create the entire online documentation. > for this we can well use the old puredata.info portal. > >> (keep in mind, this pdpedia is on a very old slow server. It'll be >> moving to a dual 2GHz G5 shortly). > > yeah, i wanted to ask that: the site seems to be as slow as the > puredata.info plone-site; so we could have used that instead without > having to setup a new server.... :-) > > > fmga.sdr > IOhannes > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
