Quoting Pavel Roskin <[EMAIL PROTECTED]>: > > First, simple suggestions:
> > (2) can we display URL of MC homepage, *and* URL of MC FAQ, > > in many places, like: > > * email footer in this list > > * first help page (at least as text) > > I downloaded MC for Win from some freeware site, and was not aware > > it is part of GNOME and has homepage. > > MC is not part of GNOME. GNOME hosts our mailing lists and CVS > repository. OK. MC's homepage mentions GNOME and URL is on GNOME. Rest are technical niceties. ;-) Don't you think it will be usefull for newcomers here, if email footer has a link to MC homepage and FAQ? And archives? Or for newbies, if first help page has MC URL, too? Don't you think it will be usefull for newbie users? > > (3) At MC homepage, can we place link to FAQs into more prominent place? > I agree, the homepage needs more work. Just simple reorder: put para3 first (what MC is), screenshots, FAQ and HOW-TOs first (for newbies). Then, technical stuff for gurus. Use [H2] FAQ [/H2] to make FAQ more visible. Not much of work, IMHO. > > (4) FAQ is huge plain text file. At least table of contens should be > > clickable. I propose to convert text to POD (perl docs) format, and then > > to HTML. I can do it. And add more HOW-TOs... ;-) > > FAQ doesn't represent the questions that are often asked now. The problem > with excessive documentation is that we put too much strain on people > changing the code - they have to update too much documentation. OK. I propose to create new FAQ and keep also link to old one. > The documentation should be more consolidated and less overlapping. FAQ > in HTML would be good - most developers know HTML. More exotic formats > will lead to obsolete documentation. We used to have the manual sources > in SGML, and some developers were updating the manual, not the source. > Finally the SGML file was removed because resynchronizing it with the > changes manual would be too much work. I just volunteered to be doc maintainer. Did you notice? ;-) If developers are swamped, somebody else might help with docs. That's me. My idea is, I can write first draft of docs, and then gurus can fix misunderstandings. Obviously, gurus cannot ask stupid questions. We need beginners for that... ;-) > > (5) I am playing with colors. Looking into archives, it is FAQ. (and it > > helped me - thank you guys.) I may add some questions/answers as I learn > > something. Currently I am trying to set a "white theme" - with white > > background, for ssh terminal. Having every color option at new line > > would help a lot... 8-( > > I agree. It's is TODO already. > > > (6) About forgetting F-keys: > > > > This bug bite me, too, before I realized what is going on. Bad news, > > this bug will bite a novice when just experimenting with MC - and might > > scare her away from MC forever. > > Also in TODO. How do you plan to handle that? This bug desperately needs to go into FAQs or HOW-TOs. Again: I can do that.... Maybe you can decide, which fixes are "critical", and rest can wait until next release. > > > Maybe keys/colors should be in another .ini file, saved only by request? > > We have one single "Auto save setup" option. Splitting it means remaking > the dialog and changing the documentation. What about if I'll do docs, you'll do dialog? ;-) Yeah, now I recall. Exactly as in NC... ;-) I disabled Autosave and it works better (for what I want) now. Thank you, Peter _______________________________________________ Mc mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc
