Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Contribution annotation does not disappear #32

Closed
dpp-gerrit opened this issue Jul 15, 2012 · 8 comments
Closed

Contribution annotation does not disappear #32

dpp-gerrit opened this issue Jul 15, 2012 · 8 comments
Labels
Area: Eclipse Issue affecting Saros for Eclipse (Saros/E) Aspect: User Experience Issue that describes a problem with the usability/user experience of Saros State: Fixed Issue has been resolved Type: Bug Issue that describes an unintended behavior of Saros

Comments

@dpp-gerrit
Copy link

What happened:

  • Session with Julia, Franz, Stephan
  • Julia opens a file (MUCManager.java from Saros sourcecode), selects and copies whole content and pastes it multipe times
  • On Franz' side: Whole content is colored in Julia's color (blue)
  • On Franz' side: Own changes don't have any color at all.
  • Stephan joins, and makes a few changes
  • On Franz' side: First, Stephan's changes are green, but after a few keystrokes they don't lose their color, instead they get blue, as if Julia's copy-paste actions have made blue the "Default Color".

See attached screenshot for Franz' view (was taken 12:45, thus the corresponding changes happend a few minutes before).

Reported by: fzieris

Original Ticket: dpp/bugs/757
@dpp-gerrit
Copy link
Author

dpp-gerrit commented Jul 15, 2012 •
edited
Loading

Screenshot of Franz' view (taken 12:45)

contribution_annotation

Original comment by: fzieris

@dpp-gerrit
Copy link
Author

dpp-gerrit commented Jul 15, 2012 •
edited
Loading

Franz' logfiles

franz_2012-07-13.zip

Original comment by: fzieris

@dpp-gerrit
Copy link
Author

dpp-gerrit commented Jul 15, 2012 •
edited
Loading

Julia's logfiles

julia_2012-07-13.zip

Original comment by: fzieris

@dpp-gerrit
Copy link
Author

dpp-gerrit commented Jul 15, 2012 •
edited
Loading

Stephan's logfiles

stephan_2012-07-13.zip

Original comment by: fzieris

@dpp-gerrit
Copy link
Author

Your own changes are not colored on your side, so this is fine.

It seems that the annotation are not correctly splitted.

E.G:

A insert 10 characters per C&P, these 10 characters are annotated by a single annotation.

B start overwritting some characters from A. If B insert enough characters, every annotation that is older then the last 20 inserted annotions from B, these annotations will be removed and so showing the annotation from A again.

Original comment by: kargor

@dpp-gerrit
Copy link
Author

As stated on the mailing-list, Steffen and I will be working on this issue.

Original comment by: ercankk

@dpp-gerrit dpp-gerrit added Aspect: User Experience Issue that describes a problem with the usability/user experience of Saros sourceforge labels Mar 27, 2018
@dpp-gerrit dpp-gerrit self-assigned this Mar 27, 2018
@dpp-gerrit dpp-gerrit removed their assignment Mar 27, 2018
srossbach added a commit that referenced this issue Jul 28, 2019
@srossbach
[FIX][E] #32 Splitting annotations do not honor the history
0a76658 
This patch fixes the last outstanding issues regarding #32.

Annotations that were split are now correctly inserted to the history
and so correctly removed.

This patch introduces a new method to the annotation helper as well as
it reduces LOC in the ContributionAnnotationManager.
@srossbach srossbach mentioned this issue Jul 28, 2019
Merged
srossbach added a commit that referenced this issue Jul 29, 2019
@srossbach
[FIX][E] #32 Splitting annotations do not honor the history
f89f081 
This patch fixes the last outstanding issues regarding #32.

Annotations that were split are now correctly inserted to the history
and so correctly removed.

This patch introduces a new method to the annotation helper as well as
it reduces LOC in the ContributionAnnotationManager.
srossbach added a commit that referenced this issue Aug 2, 2019
@srossbach
[FIX][E] #32 Splitting annotations do not honor the history
9d4eae0 
This patch fixes the last outstanding issues regarding #32.

Annotations that were split are now correctly inserted to the history
and so correctly removed.

This patch introduces a new method to the annotation helper as well as
it reduces LOC in the ContributionAnnotationManager.
srossbach added a commit that referenced this issue Aug 5, 2019
@srossbach
[FIX][E] #32 Balloon after saving partial sharing selection is too big
c39f2c7 
This fixes issue #32. Changed the default anchor as my current testing
did not produce the result shown in the picture of the issue entry, e.g
the notification was shown outside of the WizardPage.
@srossbach srossbach mentioned this issue Aug 5, 2019
Merged
srossbach added a commit that referenced this issue Aug 5, 2019
@srossbach
[FIX][E] #32 Balloon after saving partial sharing selection is too big
59aac89 
This fixes issue #32. Changed the default anchor as my current testing
did not produce the result shown in the picture of the issue entry, e.g
the notification was shown outside of the WizardPage.
srossbach added a commit that referenced this issue Aug 6, 2019
@srossbach
[FIX][E] #32 Balloon after saving partial sharing selection is too big
1a86c48 
This fixes issue #32. Changed the default anchor as my current testing
did not produce the result shown in the picture of the issue entry, e.g
the notification was shown outside of the WizardPage.
@srossbach
Copy link
Contributor

srossbach commented Aug 27, 2019 •
edited
Loading

I was able to reproduce this always.

First defect, the annotation is always inserted twice by the EditorManager.
The EditorManager assumes that there is no anntotation at the given point which can be wrong.

Easy to reproduce

Mark some characters (eg. 10). Copy and paste them into the same document.
Go somewhere in the middle between the copied text. Start to insert characters.

Result: Eclipse will auto expand the annotation however the ContributionAnnotationManager will not update the history nor insert the annotation because there is already a given annotation at the current position.

@srossbach srossbach reopened this Aug 27, 2019
@srossbach
Copy link
Contributor

image

@tobous tobous added Area: Eclipse Issue affecting Saros for Eclipse (Saros/E) State: Open Confirmed issue not currently being worked on Type: Bug Issue that describes an unintended behavior of Saros labels Jan 16, 2020
m273d15 added a commit that referenced this issue Mar 9, 2020
@m273d15
[INTERNAL][E] Use always contribution annotation with length 1
71c3120 
Fix: #32
Instead of splitting big annotation if we insert new annotation,
this handling only uses annotations of size 1 and stores multiple
annotations as one entry in the history.
Therefore, the split handling is removed and the issue with
auto-expanding annotations is fixed.
m273d15 added a commit that referenced this issue Mar 17, 2020
@m273d15
[INTERNAL][E] Avoid annotation split handling
8ca59bf 
Instead of splitting big annotation if we insert new annotation,
this handling only uses annotations of size 1 and stores multiple
annotations as one entry in the history.
Therefore, the split handling is removed and the issue with
auto-expanding annotations is fixed.
Fix: #32

Furthermore, the history handling for split view is fixed.
The old handling assumed that the entries that are removed
from the history and have to be removed from the models use
the same model as specified in the parameter of insertAnnotation.
The new handling uses the model assigned to the annotation to
remove the annotation.
m273d15 added a commit that referenced this issue Mar 17, 2020
@m273d15
[INTERNAL][E] Avoid annotation split handling
a8c7b2d 
Instead of splitting big annotation if we insert new annotation,
this handling only uses annotations of size 1 and stores multiple
annotations as one entry in the history.
Therefore, the split handling is removed and the issue with
auto-expanding annotations is fixed.
Fix: #32

Furthermore, the history handling for split view is fixed.
The old handling assumed that the entries that are removed
from the history and have to be removed from the models use
the same model as specified in the parameter of insertAnnotation.
The new handling uses the model assigned to the annotation to
remove the annotation.
m273d15 added a commit that referenced this issue Mar 24, 2020
@m273d15
[INTERNAL][E] Avoid annotation split handling
bf006d1 
Instead of splitting big annotation if we insert new annotation,
this handling only uses annotations of size 1 and stores multiple
annotations as one entry in the history.
Therefore, the split handling is removed and the issue with
auto-expanding annotations is fixed.
Fix: #32

Furthermore, the history handling for split view is fixed.
The old handling assumed that the entries that are removed
from the history and have to be removed from the models use
the same model as specified in the parameter of insertAnnotation.
The new handling uses the model assigned to the annotation to
remove the annotation.
@tobous tobous added State: Fixed Issue has been resolved and removed State: Open Confirmed issue not currently being worked on labels Apr 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Area: Eclipse Issue affecting Saros for Eclipse (Saros/E) Aspect: User Experience Issue that describes a problem with the usability/user experience of Saros State: Fixed Issue has been resolved Type: Bug Issue that describes an unintended behavior of Saros
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@fzieris @dpp-gerrit @tobous @srossbach