| |||||||||||||
|
| |||||||||||||
Documented?Documented?Posted Nov 10, 2009 12:52 UTC (Tue) by djao (subscriber, #4263)In reply to: Clutter by Frej Parent article: GNOME 3.0 in September 2010 In my experience, gconf-editor settings are absolutely atrociously documented, and in fact the special curse in the original posting was addressed specifically towards such an instance of poor documentation.
(Log in to post comments)
Documented? Posted Nov 10, 2009 16:25 UTC (Tue) by drag (subscriber, #31333) [Link]
In my experience you are wrong.
In a modern Gnome environment run gconf-editor.
Select 'Apps' --> Nautilus
Click on one of the subfolders. Click on a key value. Notice how there is a
--------------------------
There are few things more hateful and lazy then a developer filling up
Gconf-editor works for me because it provides a logical tree layout of
Documented? Posted Nov 10, 2009 18:06 UTC (Tue) by djao (subscriber, #4263) [Link] Yes, very good.In the original comment, ncm was complaining about exactly such a long description, that you have so eloquently described. The description in question is, and I quote: "Basename of the default theme used by gtk+." You claim "I can't find anything that does not have a decent enough description that I can use to figure out what the keypair does." I challenge you to explain how in the world can anyone tell from this description that the two valid settings for this value are "default" and "Emacs"? The description of this particular gconf option was not always so awful. In previous versions of gnome, the help text specifically mentioned by name that the two possible settings of the option were "default" and "Emacs". Someone actually thought it was a good idea to remove that help text. They say GNOME is open source, and that if you see a problem you should provide a patch, but what possible response is there to this nonsense, when the necessary patch consists merely of reverting to the previous version?
Documented? Posted Nov 10, 2009 19:55 UTC (Tue) by drag (subscriber, #31333) [Link]
Well seeing how it is certainly possible that you can have many different
key themes it would be impossible for the GTK folks to tell you what the valid entries are. Seeing how that key entry is actually for what it states the description is actually very accurate and not misleading or to short or wrong in any fashion.
The actual problem is not that it does not list valid theme names, which
If Gnome actually had good documentation on what a "Key Theme" is and what
So therefore this same exact problem is going to plague LXDE, XFCE,
Also the problem will plague KDE since I don't can't find any information
Documented? Posted Nov 10, 2009 20:42 UTC (Tue) by djao (subscriber, #4263) [Link] Everything you say is correct, but absolutely none of it is justification for making the documentation any worse than it already was before.What bothers me is not actually the poor documentation. If the documentation was poor and improving, or poor and static, then I could at least understand where things are coming from. But in reality the documentation is poor and getting worse with each revision. That is what I don't understand.
Documented? Posted Nov 11, 2009 15:18 UTC (Wed) by drag (subscriber, #31333) [Link] Well if you think about it it just made the description "more correct".Emacs may or may not be a valid entry depending on whether or not that theme is installed. Also there are other themes names possible. You can have a 'vi' theme, for example. So saying that possible entries are 'Emacs' or 'Default' is actually factually incorrect and misleading. The real problem in the original post, which is a very long running source of anger on lwn torwards gnome, is just the lack of documentation and support for "gtk key themes"; and very specifically Emacs-style keybindings. And yes the lack of documentation is very bad. Documentation is what makes software usable. Shitty software with good documentation is superior to excellent software with shitty documentation. This is a chronic problem with Linux software.
Documented? Posted Nov 11, 2009 17:03 UTC (Wed) by nix (subscriber, #2304) [Link]
We have a homebrewed version-control system at work. It has excellent documentation but does not support branches or directories and takes >30s to check out a single file.
I prefer git, not-very-nice documentation though it may have.
Documented? Posted Nov 11, 2009 17:08 UTC (Wed) by nye (guest, #51576) [Link]
Hmm. I consider git to be one of the better documented open source programs, since documentation is extensive and includes numerous examples, often including discussion of what options are for (one of the things I hate is documentation with entries like "--enable-frobnobulator - sets whether or not you want the frobnobulator enabled". Well thanks *so much* for that helpful tip).
Documented? Posted Nov 11, 2009 19:51 UTC (Wed) by djao (subscriber, #4263) [Link] I dispute the characterization that omitting the names of the default and Emacs key themes makes the documentation "more correct". As shipped by the upstream source, the values "default" and "Emacs" are the only possible functional values. You can modify your own private installation to add more key themes, but then again, we're talking about open source software here -- any behavior can be customized. That is no excuse whatsoever to omit mentioning the two originally valid values.Moreover, even if the possibility of local modification is a serious concern, there are far better ways to handle this in the documentation. For example, add a line such as "Depending on local system modifications, other key themes may also be present." I feel, however, that you are still missing my main point. I am not angry at poor documentation in and of itself. What upsets me is the actively hostile attitude of the upstream developers towards improving the documentation. This attitude makes it impossible for the community to contribute positively, short of forking the software. It drains away one of the most important advantages of open source in the first place.
Documented? Posted Nov 11, 2009 20:37 UTC (Wed) by tuna (guest, #44480) [Link]
You are accusing the gnome developers of being actively hostile to documentation patches. Do you have any sources or examples to back this up?
Documented? Posted Nov 11, 2009 21:47 UTC (Wed) by djao (subscriber, #4263) [Link] Of course, although this thread is getting quite long already. The example is the same example that started this whole thread. The change to reduce the description of the gtk-key-theme option was certainly either introduced or approved by a GNOME developer, and this action is hostile and actively detrimental to improving the documentation.Even if the change is technically "correct" as per the grandparent post (which I do not agree that it is), there are many natural ways to improve correctness without reducing specificity. It takes an actively destructive mindset to apply the fix that was actually applied.
Documented? Posted Nov 12, 2009 2:25 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
I think it is better to assume goodwill and send a documentation patch than complain about perceived hostility.
Documented? Posted Nov 12, 2009 4:04 UTC (Thu) by djao (subscriber, #4263) [Link]
I already raised this issue rhetorically earlier in the thread. What possible patch can anyone send? The necessary code is already in their svn/git repository. Just revert to a previous version.
Documented? Posted Nov 12, 2009 15:09 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
A patch can very well revert a setting and the important part is to initiate a discussion in the GNOME development forums. The key is to assume good will.
Documented? Posted Nov 12, 2009 16:15 UTC (Thu) by djao (subscriber, #4263) [Link] It seems a discussion has already been initiated, at least: https://bugzilla.gnome.org/show_bug.cgi?id=558198As I assumed, there was no movement on the issue. However, if you insist, I will go there and raise the issue more forcefully, in a little while, after I get my work done.
Documented? Posted Nov 11, 2009 10:17 UTC (Wed) by russell (subscriber, #10458) [Link]
why not put gconf-editor in the user's face then. Instead it's a developer tool because they don't want to eat their own dog food.
Documented? Posted Nov 11, 2009 15:11 UTC (Wed) by drag (subscriber, #31333) [Link]
It's just a tool for enabling/disabling features that are rarely used.
It's not a development tool. It's really a administrative tool. You can use
Documented? Posted Nov 13, 2009 4:39 UTC (Fri) by russell (subscriber, #10458) [Link]
I was not very clear what I was meaning.
I don't have a problem with gconf-editor, it's just a tool, rather, it bugs me ( and others ) that the options visible to users are decided by a very narrow view of what people do. If not, the proliferation of options would be huge. That doesn't stop people from wanting to customise, have options, and do things there own way.
One change I would welcome to the way GNOME does things would be to put a visibility flag next to each of the gconf options ( where possible ) to make that customisation available through preferences.
Then we could all satisfy our own use cases without pushing anything on each other.
Documented? Posted Nov 12, 2009 15:04 UTC (Thu) by nix (subscriber, #2304) [Link]
What GNOME provides, all too often, is 'figure out what I consider to be
the best default and provide no visual indication that this is in any way configurable, thus driving away all users who disagree with me'.
|
|
||||||||||||