Community
Participate
Working Groups
In the navigator, with some project containing a directories nested a few levels deep, navigate down to some file, and click to open the editor on it. Once in the editor, press the browser back button to return to the navigator. This returns you to a collapsed navigator, it would be much more convenient if the navigator remained in the same expanded state we left it in.
Not sure what it would take to make this work, but I have to say the current behavior is frustrating. I hit it constantly.
I'll be doing something similar with selection caching in bug 339450, so I'm marking M7. I assume we'll use some kind of session cookie.
This and bug 339450 both involve caching of UI state so that page transitions/history return you to a more usable state. I'm wondering what we should use to store this info. It seems like a good idea to use a common API (preferences?) and then we could retarget the back end storage as needed. - we use cookies elsewhere, as does dojo, for things like splitter location, etc. This can be a pain for testing and remote reproduction of bugs. - I was thinking of simply using preferences and taking advantage of the session caching that we do. This way we retain the info per user. Do we need an expiration on this kind of state? (Would you expect your navigator at any given location to always open with your last expanded or selection state?) Any other ideas?
Fixed in HEAD. I used user preferences to store the UI state. The preference node is defined as "Navigator/rootlocationid/uiState" where rootlocationid is basically the root location with special characters stripped out. This way we can store the UI state at any level in the navigator. Gosia - the first segment of the pref path is defined by the client. So if you want caching of UI state in the Git UI, you need to specify the property "cachePrefix" in the options that you give to your explorer renderer. For example, the navigator does: this.renderer = new eclipse.FileRenderer({checkbox: true, cachePrefix: "Navigator" }, this);
User settings are a store per site backed by localStorage. I think perhaps sessionStorage would be a better choice here - e.g. state per tab (per site)
(In reply to comment #5) > User settings are a store per site backed by localStorage. I think perhaps > sessionStorage would be a better choice here - e.g. state per tab (per site) This makes sense to me. I switched to sessionStorage for nav UI state. It's all in one place so easy enough to change. We may find over time that there are some ui state settings that are important enough to preserve in the user space, but I don't think expansions and selections fall in that category.
