Hi Everyone, Seems like our time zone has put us a bit behind on this topic, but here goes... I am working with Pat Costello in Sun on the documentation for GNOME on Solaris. At the moment I am documenting the Control Center, and in particular the Sawfish window manager capplets. The documentation I am working on is currently in SolBook, a subset of DocBook 3.0. We are planning to make this documentation available to the GDP, in Docbook compliant SGML, in time for the code freeze in November. Even though the Sawfish documentation is a core part of the GNOME on Solaris User Guide that Sun is developing, I would like to stress that we are writing the Sawfish documentation to be as generic as possible. In other words, the Sawfish documentation is non-OS specific, and therefore should be suitable for a broader audience than just Sun customers. Sawfish, and indeed the whole Control Center, is a complex set of capplets. Documenting all of this functionality is a significant undertaking in terms of writing time, as we have already discovered. As well as capturing all of the working functionality, we have uncovered various issues that take time to investigate, log or resolve. For example, I attach a document listing some of the issues I have come across so far. We are investigating these issues as the work progresses. To give an idea of what we are doing, I can offer my work on Sawfish so far as a SolBook SGML file to anyone who is interested. You will have to change the DTD to display it properly, but that should not be a major issue. This is very much a work in progress, with a long way to go before completion. Nevertheless, you should be able to see the approach we are taking from the work we have done so far, and whether the GDP can use the finished product. It would be really great if we could save some duplication of effort. Regards -- Michael McElree Technical Writer Sun MicroSystemsTitle: Gnome Control Center - Unresolved Sawfish Window Manager Questi
Conclusion: This is a technical question for the GNOME developer.
Conclusion: This is a technical question for the GNOME developer.
Conclusion: This is a technical question for the GNOME developer.
Conclusion: This is a technical question for the GNOME developer.
Our recommendation is to remove the "Raise windows when they are unshaded" option from the Miscellaneous capplet. It belongs in the Focus Behavior capplet. This is a technical issue for the GNOME developer.
There is also an apparent conflict between the Raise windows while they're temporarily selected during cycling option and the Disable auto-raising while temporarily selecting windows option in the Window Cycling tab.
Conclusion: This is a technical design issue for the GNOME developer.
We need a definition for "Name, Class, Icon Name, Host, Command, Locale" for Match window properties dialog.
We also need a definition for "State", and "Sticky viewport," "Ignored", and "Group"
Conclusion: This is a technical question for the GNOME developer. The developer needs to provide an explanation of the functionality of matching windows.
Conclusion: This is a technical question for the GNOME developer.
Conclusion: This is a technical question for the GNOME developer.
Conclusion: This is a technical question for the GNOME developer.
On Peripherals > Mouse, Mouse motion threshold, the slider doesn't work, or else it is being overridden by the setting in the Miscellaneous capplet. Technical issue: only works in one place, the working part should be in the Peripherals section and not Miscellaneous section.
Conclusion: This spin box should be moved from the Miscellaneous capplet to the Mouse capplet. The overlap between the slider in the Mouse capplet and the spin box needs to be resolved, and either the spin box or slider removed. This is a technical question for the GNOME developer.
Conclusion: The option should be removed from the Miscellaneous capplet. This is a technical question for the GNOME developer.
Conclusion: This appears to be a text box containing FYI information only. As such, it provides no user interaction with the desktop, and therefore should not be part of the UI. This is a technical question for the GNOME developer.
1 Determines how the contents of a window move when window is resized
2 Attraction of a sub-window to some part of it's parent window.
Conclusion: This is a technical question for the GNOME developer.
Conclusion: This is a technical question for the GNOME developer.
Conclusion: Original developer needs to explain what the placement rules are.
Conclusion: Developer needs to rethink GUI design here - or are there good reasons for the current design?
Conclusion: Developer needs to provide more information.
Conclusion: Developer needs to provide more information.