#131 Restore DrJava State (State Everlasting)
There are a lot of aspects of DrJava that the user can modify during a session, but which are not maintained across sessions. Many of these things can and should be preserved transparently through the config framework. I would like to begin tabulating a list of such states, so that they can be gradually implemented as config options. When posting an idea, it would be helpful to include some comments about potential problems in restoring the state which would need to be checked when doing so.
My initial list:
Interactions history -- the current buffer of recent actions could be spooled to a file, or written out as a big-ass String in the .drjava. This would allow someone to resume their testing after a crash, for example. Semantics might be difficult to define when multiple copies of DrJava are being run simultaneously, but the problem isn't unique to this feature.
The current locations of windows and split panes -- these could easily be restored based on the last known coordinates. There is currently a bug which causes the split panes to revert to their default positioning, which could be fixed when adding this feature. We should check whether the main window has somehow gotten off-screen and correct it.
Most recent compiler -- restore the previous selection in the Compiler Output tab. Might revert to the first one (as now) if the previous compiler is no longer available.
Open documents -- restore the last known set of open documents when DrJava was quit. This may be too ambitious, but it is often handy. There are lots of potential problems with moved and renamed files, but most can be avoided by just failing to load the document in question. We might be able to restore the last visible portion of the document as well.
Debugger state -- breakpoints and watches are lost when the interactions pane is reset. Just restoring the debug mode at all after a reset would be a step in the right direction.
Find/Replace -- contents of the search fields and the Match Case toggle could be saved and restored.
That's all I can think of for now. Please post more as you encounter them.
Logged In: YES
user_id=431096
Go To Line dialog -- should remember the last location searched for (separately for each document, if possible). When the dialog comes up, the field should be in focus and selected, so that the user can immediately type in new data and replace the old (similar to current behavior with repeated Find commands).
Logged In: YES
user_id=429731
This sounds like a great idea, though it seems like these could be implemented to different degrees. Here are my thoughts:
Interactions history -- This could definitely be useful for recovering from crashes, but it's perhaps a larger project than the others. I would also say that it should not restore the state by default, but instead have a menu item that lets you restore your last session (in the case of a crash). I definitely want a clean slate when I start up DrJava.
Window/SplitPane location/sizes -- Great idea. Should be on by default.
Most recent compiler -- This is also good, and should be on by default.
Open documents -- Useful, good for a second iteration of development, but arguably not on by default. (Again, I'd like a clean slate.) User can turn it on in the prefs, or perhaps choose a menu item to open all previously open documents.
Debugger state -- This is a whole can of worms in itself, but one that needs to be opened at some point. Perhaps it can be discussed on a feature request of its own.
Find/Replace -- Is this that useful between sessions? I suppose it couldn't hurt. (A side note: we have Match Case on by default because it's much faster-- we don't have to convert the whole document to lower case first.)
Go to line -- Again, is this useful between sessions? On the other hand, during a given session, I think it should behave like Find/Replace. If you choose Go to line a second time, the last number you typed in should be entered and highlighted, so that if you start typing, you'll replace it, but if you hit enter, you'll go back to it.
Logged In: YES
user_id=431096
Just to clarify, by "Interactions history", I meant the list of entries on the command line, not the state of the JVM. Essentially, I want the up arrow from the interactions command line to do something useful, even if I just launched DrJava. Since we already have a config option for the maximum number of history items to remember, we might as well remember up to that many through restarts as well as within a single session.
Logged In: YES
user_id=429731
Ah, yes-- I misunderstood. Yes, I think the Interactions history should be restored by default.
Logged In: YES
user_id=431096
Window and document list sizes are now saved and restored.
There is some problem with the tab panes - even though I
change the split position, it still goes back to the default
size at startup. I don't know why, since I can't find any
place where the position is explicitly changed.
Window positioning is a little tricky because of
platform-specific window managers - the Windows task bar,
Mac OS X menu bar, etc. Bounds checking to make sure we are
not off screen becomes complex because there is no universal
mechanism for finding the usable screen space.
Logged In: YES
user_id=666678
Originator: NO
Breakpoints are now stored in the project file.
Logged In: YES
user_id=1075744
Originator: NO
Re-classified as feature request.
Some of this is already done:
- window positions are saved
- breakpoints and watches are saved in the project
But we could definitely do more.