Hide Forgot
Description of problem: The GUI window does not indicate the configuration file name of the configuration displayed. A user could erroneously edit/save a configuration file because there is no display of the current configuration file name. In addition, the "Save As" function does not indicate the name of the file--instead it defaults to /etc/cluster/cluster.conf. Version-Release number of selected component (if applicable): system-config-cluster-0.9.5-1.0 How reproducible: See "Description of problem". Actual results: See "Description of problem". Expected results: See "Description of problem".
will fix
UI now has text field at top of cfg tab that shows file currently being edited, or a states that this is a new, unsaved file Fixed in 0.9.17-1.0
partially fixed. It now displays the file currently being edited (like /tmp/my_foobar_cluster.conf) however when I go to 'save as' it still defaults to "/etc/cluster/cluster.conf", that needs to change as well.
This bug (I believe) was originally about the UI's lack of a way to tell you what file you were editing. A text field was added to the top of the UI for this purpose. Now, I *think* you are asking that if a file is open, and 'Save As' is chosen from the drop down menu, then the file selector box be pre-populated with the location of the file currently being edited. Is this correct? I defaulted to always placing /etc/cluster/cluster.conf there, as this tool *is* about editing that very file.....and expects the file to be saved there for use by the cluster. That said, I have absolutely no problem having the file selector dialog be preset to the path and location of the currently edited file - wherever that may be. Is this what you want?
The intent of the original bug description is based on a use case where a user would configure a file to be used later--not the active configuration file--then it would be easy for the user to erroneously save to the active file (etc/cluster/cluster.conf). Therefore, it is necessary to display the file name. That is addressed with the fix. Regarding the "Save As" concern, if a user edits a non-active file and wants to save again using "Save As" it seems like the file name that is populated should be the same name as the file that is currently being edited--as a starting point. I'm not certain if that is a GUI standard, but it seems like expected behavior compared to other text editing applications.
Okee Dokee. Finished in 0.9.44
fix verified in -44.