Skip navigation.

Galeon, A History

Galeon
Galeon

The Galeon folk have released a brief history document, laying out what's gone before and what's coming soon.

Re: Galeon, A History

You don't really refute anything I said. ;-)

You support my desire to see better documented preferences. This is not only better documentation for the end user, but for the developer. In the large projects I have been involved in, business rules, exceptions, preferences were all well documented in a database or spreadsheet. Every developer should do this or the growth in the the number of preferences leaves the developers desk and becomes an end-user problem. That is not acceptable. GConf can and should be documented (one of the failures of the Windows registry), but it should not be the source of said documentation. That source should be used to document GConf (a very excellent system, btw), document a preference GUI and help the developer keep track of all preferences and how they are used.

That leads to project management. It seems a lot of projects could use more organized management, even metacity. If you are unable to manage adding [insert configuration option or feature] to metacity, perhaps you could benefit from better documentation. I don't mean to insult you or your skills, just making the case. Proper management of a project involves proper management of features. A large number of features doesn't have to lead to an unmaintainable project.

As the poster below mentions, Pan has a mess of options. That is nice, _but_ the problem is that they are not as well organized as they could be and not documented as they should be. Any end user should be able to look at a prefernece dialog, mouse over an option or give it focus and immediately know what it is for if it isn't intuitive. Perhaps GNOME needs a kickass preference dialog that has a 3 panel view. Far left might be the categories, middle would be the pref widgets and far right could be a nice panel using gtkhtml to quickly display pref by pref help or tips in a very obvious manner. Yes, this could be a pain in the ass, but if you are really trying to attract the users who don't care or aren't educated in computers to start digging into preference dialogs, it might be necessary. The user could simply hover over a checkbox, slider, whatever and the panel on the right would show a pretty, user-friendly description that makes [un]intuitive options more clear. That would make the abundance of preferences everyone screams about a non-issue. It would put proper documentation in the hands of the developers where it should be. That doesn't mean that a team couldn't help.

It seems that the users are continually suffering from poor project management. The cost you talk about is the responsibility of better managing a project. It's that damn simple.

Later,

Erick