GNOME Bugzilla – Bug 400847
Store editing metadata on a per-project level
Last modified: 2007-06-15 11:28:23 UTC
When I open an existing project, no widget is selected and neither is any toplevel widget is displayed in the workspace. This is unhelpful and rather average behaviour. It would be better if when editing an existing project, the glade3 frontend serialized the last editing state to a metadata file. Then, when the user opens the same project at a later time, the initial editing state is set to what was used in the previous session. Here are all the states we could possibly serialize: * The currently selected widget * The toplevel currently being displayed in the workspace * The open nodes in the Inspector * The current page in the Property Editor I got this idea from gedit. The application saves the line number where a document was last editing. When the document is later opened, the text editor jumps to that line number. We could save all the session data to '$XDG_DATA_HOME/gladeui/metadata.xml'. We would identify each project in this file by using it's canonical URI. Example XML fragment (derived from the gedit implementation): <project uri="file:///home/vgeddes/dialog.glade"> <entry key="selected-item" value="hbox1"/> </project> Note: $XDG_DATA_HOME = '$HOME/.local/share', according to the XDG Base Directory Specification (http://standards.freedesktop.org/basedir-spec/latest).
Sure, session management is something that we've wanted for a long time, marking this as duplicate of the original bug. *** This bug has been marked as a duplicate of 142176 ***
I know very well about #142176, but I purposefully opened a new bug. The problem described in #142176 and the problem described here are actually quite different, despite their similarity at face value. Here, I am talking about saving state or metadata on a per-project level only. The other bug describes the problem of saving global settings, preferences, and other miscellaneous session data (like the size and location of the main window). I would like to keep these bugs apart, because their problem domain and potential solutions are actually quite independent. From an organisation point of view, it would be easier for me and others to keep track of these bugs. p.s. I am renaming this bug for added clarity.
Nah, I prototyped and tested this feature, and I think it may be confusing for the user. Imagine opening a glade file you last edited a week ago, to find that some arbitrary widget is initially selected. I think initially selecting the first item in the inspector would be simpler and more understandable.