Wiki


#1

anyone think a jucewiki would be a good idea? would be better than stickies for getting folk started and keeping the rest of us up to date.

whatever happened to plans for the “official” juce forum?

?


#2

I’d participate for sure. Posting snippets and stuff.


#3

that sound like a good idea


#4

yeah for sure ! i’m with you :wink:


#5

Yea, a good wiki would be very nice.


#6

sounds good to me


#7

I’ll set one up here, if people see the need for it.

It’ll take me a couple of days though as I’ve never set one up before.


#8

I’ve setup a few if you want to know anything. In my opinion, MediaWiki is one of the best php ones.


#9

Here you go: http://www.annoware.com/wiki


#10

there are any guidelines in the writing of the wiki ?
trying it out… creating the main topics… then adding some content as example… mmmh there isn’t a [code] tag…


#11

use for inline code blocks or indent with two spaces for code blocks.


#12

So, is there a plan with regards to the structure and type of content or something. Or are we taking the GNU style organic approach? :smiley:


#13

hmm… why don’t we just stick with the wikipedia policies? http://en.wikipedia.org/wiki/Wikipedia:List_of_policies


#14

actually the plan could be:

  1. in the main page we will have the main topics and subtopics (which imho could be the internal juce tree structure)
  2. in every subtopic we will have information on class
    usage and specific tips that involve two or more classes
  3. every leaf should give internal links for every other class it specify (in order to make the navigation faster)

something like

(Main)
*User Interface
*Controls

(Controls)
*how to make non linear slider
*using the ProgressBar class

(how to make non linear slider)
blah blah [Slider] … [Component] blah blah

or something like this… we can even go further in the tree of topics if we need.

Some ideas ?


#15

Fair enough, but I dont think there will be much info on classes as such. It’s already in the docs and there is no point in duplicating that.
The most useful info is usually problems that have been solved. That is, how-tos and quick tutorials.

I would add FAQs to that, but I think JUCE is to much of a moving target still. The only question I’ve seen asked more than once or twice is the old aliased font rendering thing.

EDIT>
I added an example of the type of articles I myself would like to see. Check under graphics.


#16

[quote]actually the plan could be:

  1. in the main page we will have the main topics and subtopics (which imho could be the internal juce tree structure)
  2. in every subtopic we will have information on class
    usage and specific tips that involve two or more classes
  3. every leaf should give internal links for every other class it specify (in order to make the navigation faster)

something like

(Main)
*User Interface
*Controls

(Controls)
*how to make non linear slider
*using the ProgressBar class

(how to make non linear slider)
blah blah [Slider] … [Component] blah blah

or something like this… we can even go further in the tree of topics if we need.

Some ideas ?[/quote]

Sounds good but maybe we could that on a separate page and leave the main page relatively small? How about the main page have links to a “What is Juce” type page, an api help page which would be as you described, a page for juce projects, and a link to the rms site?


#17

nice one. so i’ll leave off the classes and start this faq - quick help !
anyway could be easier to read if we structure a bit more the articles… when we have 50 articles in the Graphics topics… when i’ll find a specific usage of the Image class i need ?


#18

There should probably be some discussion on using the JUCE event model, as at least a few people have been confused by the various broadcasters, and the base message class.


#19

The wiki for UT editing has code trees, user code, ideas, ton of things that would be a good way to copy the style of for a Juce wiki.


#20