I'd Prefer It Not Crash To Begin With, But ...

Eclipse doesn't save preferences until it quits — gracefully. Now, if it should ever happen that Eclipse (heaven forbid!) crashes or has to be killed, recent preference changes are lost. Keep in mind that setting up syntax highlighting the way you want it can easily take a half-hour given Eclipse's perverse preferences dialog (but that's a story for another day …).

This isn't the only way Eclipse goes out of sync when it crashes. Lord knows Eclipse is damn lazy about refreshing filesystem data (though if auto refresh is on, it's raving-lunatic zealous about it instead). But for God's sake, people can spend a long time tweaking preferences, even when the dialog isn't an affront to all that is holy. Sync preference changes to disk immediately if not PDQ. If the program has to sit for a few seconds when you hit OK so it can save the preferences, oh well. This is Eclipse. Why care about being sluggish only now?

Workaround

Once you've made your way through the labyrinth that is the preferences dialog (don't be fooled by the search field … if only the dialog were merely poorly organized … but again, another day), go to File → Switch Workspace … and switch to the workspace you're already using. It'll exit and relaunch immediately. Yes, that can take a good half-minute, but at least it's not a half-hour.

Related bug reports

• Bug #149629 is this issue, except I disagree with the solution (the preferences should simply be saved when they're changed).

Details, Details

When Eclipse launches into a lengthy operation (being all too often), it shows the all-too-familiar progress window, with an “operation in progress” message, a progress bar, and a line of detail text below the bar. Theoretically, the detail text is simply of the form “[Overall Task]: [Item]” where [Overall Task] could be “copy” and [Item] could be a particular file.

Unfortunately, the detail text is often mighty skimpy with the details. Many operations just have the overall task part, and let you sit there wondering what it's doing for several minutes. (It doesn't help when the progress bar doesn't move.)

So it's a good thing there's a button saying “Details >>” on the lower right, with that lovely chevron inviting the user to expand the dialog and reveal … well, details of some kind about the operation. Hopefully a filename, maybe an individual progress bar for the subtask if we're lucky.

But no such luck — the details area merely lists all operations in progress, with the same damn progress bar and detail line. So if there's only one operation going on, all you get is exactly what you already had. “Details >>” indeed.

It's not that showing the progress of background operations along with the current one is a bad idea; it's quite useful. But the button's name implies two things that are false:

• The expanded dialog will include deeper information about what's already in the dialog.
• The dialog's scope will remain this operation. The dialog's subject is one operation, and unless a control says otherwise, no other operations should be involved.

The fix here, of course, is to change the name of the button. It should be called “Show All >>” or something similar. Simply put, what's being offered is more breadth of information, not depth. Now if they'll just explain exactly what “scrubbing” is …

Related bug reports

• See bug #75968 for more dumb Details button behavior.

Out of Sync

Here's an irritating little time-waster: CVS sync on large projects takes a LONG time. So ain't it just dandy when, five or ten minutes through (I exaggerate not), I get this gem:


So:

1. Something is out of sync. (Actually most likely it's just a spurious timestamp change.)
   
2. Eclipse knows that it's out of sync.
3. Eclipse launched into a lengthy operation assuming that everything it thinks about all the tens of thousands of files in the project will hold.
4. It believed itself utterly helpless on finding that a file was out of sync.

For God's sake ... Get it back into sync! It shouldn't be complaining unless metadata has changed that could affect the processing of other files. Not so in this case — these were all just dumb resources. And if being in sync is that important and cached information is that frequently stale (this error appears fairly often to me), do the user a damn favor and check it all first. Yes, it'll take a while — but not as long as half a CVS sync, followed by the refresh, followed by the whole sync over again.

(Yes, this problem occurs less often if I turn automatic refresh on. Bonus: Automatic refresh causes Eclipse to hold everything up for minutes at a time at unpredictable moments. Yay!)

Related bug reports

• Bug #104224 is the same problem (RESOLVED INVALID, natch, since this is known behavior. Stupid known behavior, but known behavior.


• Bug #135712 is a similar problem, though it was never followed through (maybe it went away?).

“Cancel” Means “Cancel”

Okay, here's a nice, cute little behavior to start off ... so I forgot to turn off Build Automatically before I imported a sizeable project, and so it's stuck building (which, since I haven't set things up right yet, is doomed to failure anyway.) So I turn off Build Automatically. Silly me, I'm hoping (despite past experience) that this will make it stop building. So I click on the little progress bar button to have a look at the background tasks, and sure enough there's a “Building Workspace” and a “Refreshing Workspace.” I cancel both of them. Nothing happens, except that they both now have “(Cancelled)” in their names. Finally, I hope things will sort themselves out if I quit and start Eclipse again. So I do, but after the Eclipse window disappears, I'm confronted with this:


Nice, huh? It's waiting on a few cancelled operations to stop ... cancelling. Dammit, I wasn't kidding when I said “cancel.” And definitely not when I said “quit.”

So then it sits around like that for a while, the “building” progress bar empty and the “refreshing” one bouncing back and forth. A few minutes (?!) later, it finally disappears. So I try to start up Eclipse again, and ... it says the workspace is still in use. Yep, Java's still running. Had to kill it from the command line. (And, for reasons unclear, network usage was pegged at 100% until I killed it.)

So here it is: “Cancel” means “cancel.” I don't care what you're doing, but it'd better not take more than a few seconds not to be doing it anymore. If it really can't be cancelled, there should be no friggin' Cancel button to begin with. Have some respect for my time, for crying out loud.

Related bug reports

• Bug #150624 is similar.