Improve UX when user's try and edit non-editable resources

[pq]

What steps will reproduce the problem?

1. Open samples/swarm
2. Open an editor on SliderMenu.dart
3. Edit and attempt to save

What is the expected output? What do you see instead?

The file is damaged but not saveable. You'd expect it either to be truly readonly (and so not damageable) or actually writable.

NOTE: SliderMenu.dart is in the ui_lib which is in a sibling folder to swarm and so is not in this case residing in the workspace.

Besides the obvious that locked files just aren't, a few quick thoughts:

* the lock icon is not dramatic enough; it's easily overlooked

• the lock icon does not communicate enough --- e.g., it would be nice to know that this is an "external" file or an SDK lib file and so for that reason readonly

[pq]

OK, with a little poking around I figured out why the files are quasi-editable. The issue is that ExternalCompilationUnitEditorInput has been wired to always be modifiable:

com.google.dart.tools.ui.internal.text.editor.ExternalCompilationUnitEditorInput {

  public boolean isModifiable() {
    // TODO (danrubel) Investigate implementing or removing this method in future CL
    return true;
  }
}

The good news is Dan was nice enough to leave some fingerprints so I know who to blame... :)

The CL that introduced this change is

http://codereview.chromium.org//8631010

More from Dan soon (I hope ;))

  

---

Set owner to @pq.
Added Accepted label.

[keertip]

Just a note on read only/editable issue. We do want the bundled libraries to be read only, but what about imported user libraries? My guess is that they should be editable. Both bundled and user defined libraries are opened as ExternalCompilationUnit.

[pq]

I'm not actually sure... Do we want files outside the workspace to be editable? I haven't thought it through but my gut was we did not since I was assuming this would break assumptions made by analysis. But maybe I'm wrong!

[bwilkerson]

It would break at least one assumption. Because they are not represented by an IResource there would not be any resource change notification to cause them to be re-analyzed. (Of course we already have that problem if the user edits them outside of Editor, but that's a separate issue.)

[keertip]

I would want the ability to tweak the libraries as I am working on the application to suit my needs - maybe the solution is that they should be opened in the editor to do so.

And for files not in the workspace we should make it truly readonly so that users do not get into a quasi state.

[pq]

The burning issue (external files eronneously appearing as quasi writable) is addressed by: http://codereview.chromium.org/10536079/.

Remaining is the larger question of UX.

Reassigning to Luke for input.

---

Set owner to @lukechurch.
Removed Type-Defect label.
Added Type-Enhancement, Usability, Triaged labels.
Changed the title to: "Improve UX when user's try and edit non-editable resources".

[danrubel]

CL looks good as it solves the underlying problem that read-only files should not be editable. Unfortunately, it disables code completion in read-only files, but perhaps we can find another way to get code completion working there.

[danrubel]

Added Fixed label.