Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 238975 - unsaved (*) symbol on shared editors is confusing.
Summary: unsaved (*) symbol on shared editors is confusing.
Status: RESOLVED DUPLICATE of bug 239048
Alias: None
Product: ECF
Classification: RT
Component: ecf.cola (show other bugs)
Version: 2.0.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: ecf.core-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-30 09:02 EDT by Max Berger CLA
Modified: 2009-05-12 18:55 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Max Berger CLA 2008-06-30 09:02:27 EDT
The unsaved notion (the * symbol) is confusing on shared editors. On the viewers side, it is completely disfunctional. 

This bug is marked as critical, because: When I try to close the editor it asks me "Save?" I click yes, and NOTHING HAPPENS. This mis-functionality could therefore lead to data loss!

On the other hand, when I click on save, the * disappears, but again, nothing happens!

Suggestion: Either implement remote saving (preferred), or disable the "changed" notion.
Comment 1 Remy Suen CLA 2008-06-30 10:00:28 EDT
Disabling the "dirty" concept would be quite difficult if not impossible since it is up to each individual editor to return a boolean value when isDirty() is called. I'm not sure if I'm down with the concept of "remote saving" since just because you want to save doesn't mean the other person wants to save.
Comment 2 Max Berger CLA 2008-06-30 10:20:17 EDT
Here's another alternative: Let the editor keep its "dirty" flag. When saving, offer to save the file locally. If this is canceled or not done, the editor stays dirty.
Comment 3 Scott Lewis CLA 2008-06-30 10:46:10 EDT
>On the viewers side, it is completely disfunctional. 

This is not correct...save is functional, it just does not save to the workspace (rather, outside of the workspace).  Point at the title bar to see the path.

I also agree with Remy...we can't just disable the dirty flag, and I don't think its acceptable to save remotely.  We can/could give more information about where the file is being saved to...or perhaps give some other save options (to workspace, etc).

I'm going to move this bug from critical to normal severity. 
Comment 4 Mustafa K. Isik CLA 2008-06-30 11:06:34 EDT
I agree with Remy and Scott.

IMHO it should be enough to let the user know where the file is going to be saved locally. I am not even sure, whether or not the realization of any more functionality of this kind is a good idea - since as Scott points out, you can actually determine the location of the file in the filesystem as described in his previous comment.

Any more elaborate mechanisms seem to be a waste of effort, since general project sharing should be the next goal to pursue for DocShare. Project Sharing would essentially resolve this issue.
Comment 5 Scott Lewis CLA 2008-06-30 15:46:13 EDT
(In reply to comment #4)
> 
> Any more elaborate mechanisms seem to be a waste of effort, since general
> project sharing should be the next goal to pursue for DocShare. Project Sharing
> would essentially resolve this issue.
> 


Yes.  I've created an enhancement request for this capability at bug #239048.



Comment 6 Scott Lewis CLA 2009-05-12 18:55:14 EDT
Given the comments below, I'm going to resolve this bug as a duplicate of bug #239048.


*** This bug has been marked as a duplicate of bug 239048 ***