ElChristou wrote:selden wrote:...Documentation just needs to be readable.
Yep, you're probably right and your problem with Runar fancy and elegant work is really annoying. Nevertheless the problem of documentation "just" readable is that in general no one read it. Now, as we want Celestia more user friendly with new GUI, content, etc, this doc was perfect from this point of view. Clear, again elegant and really clever. Why clever? because there is quite a lot of content in it and despite this point the doc seems "light" (easy to read/easy to understand/easy to assimilate). IMHO it was a really good doc for a soft as complex as Celestia...
But, BTW, what's the idea here? online doc? Imbued in the next GUI? Or simply just like this (in a folder next to the app)?
If option one or two, perhaps your problem is not relevant? If option three, then yes I guess too much people are still using IE and so something should be done...
Yes, a very big thanks to Runar for designing the HTML template, I am very thankful that he did that. I am not very good at HTML, CSS and let alone JS. I think also as Christophe that it looks really good and is easy to navigate.
For this version I just adapted a few points (added a menu point and revamped the "Contributions").
The idea here (at least from my side) is to use it as an interim solution (to be included already in 1.6.1?) and have it called up, when you select "Help" within the help menu in Celestia. Calling up the standard webbrowser of the user and presenting the file most probably.
And it should also be a guide and cornerstone to a "real" help file in the unified GUI. But for that I would then very much prefer to use XML files as input files. Those are a lot easier to maintain.
I also have an idea about an issue that was just encountered with the README and its quotations of textures not being up to date and correct. Well, if you don't read every post in the forum and/or the dev list, it's easy to overlook something.
Why not make something like a database in Sourceforge, where everyone that is updating/putting textures, models, scripts ... in the official package is requested to enter a dataset before the content is put in the trunk?
Okay it would be a lot of work to do that for everything that is already in there, but it could be worth it. We would have a clear documentation and it would be easy to export it into a help file or where ever. And we could also see, how old a texture is and what was used to create it.
For textures I was thinking about a dataset like this:
Object; resolution (maximum); creator; source (with date); type 1 (normal, bump, emissive, ...); type 2 (LOK, fictional/interpreting); manipulation (colorizing with reference, ...); date of creation; special data (cooperation, rework, etc...)
Best regards,
Guckytos