Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 348662

Summary: Setting tooptip to null in tool behavior provider doesn't clear up tooltip if the associated figure has a previous tooltip
Product: [Modeling] Graphiti Reporter: Shenxue Zhou <shenxue.zhou>
Component: CoreAssignee: Project Inbox <graphiti-inbox>
Status: CLOSED FIXED QA Contact:
Severity: major    
Priority: P3 CC: michael.wenz
Version: 0.8.0Flags: michael.wenz: juno+
Target Milestone: 0.9.0   
Hardware: All   
OS: All   
Whiteboard: Juno M1 theme_bugs Indigo SR1
Attachments:
Description Flags
clear figure's tooltip when the tool behavior provider return null or empty tooltip
none
Patch containing the change checked-in to head none

Description Shenxue Zhou CLA 2011-06-07 18:38:07 EDT
I want to display tooltips on my node only when the label on my node exceeds the space allocated for it. I do this in my tool behavior provider by overriding public String getToolTip(GraphicsAlgorithm ga) method. If a certain node's label meets this condition, I do see a tooltip displayed for it. However, if I shorten the label so no tooltip is needed, I still see the old tooltip. 

Stepping into Graphiti's PictogramElementDelegate class, I found the problem. At line 607, it sets the tooltip for the corresponding figure if the tool behavior provider return non-null, non-empty string as tooltip. However, it doesn't clear up the tooltip if the tool behavior returns null or empty string for the tooltip.

I'll provide a patch for it. We're approaching our release deadline, could you apply my patch ASAP if you find it acceptable? Thanks!
Comment 1 Shenxue Zhou CLA 2011-06-07 18:43:11 EDT
Created attachment 197551 [details]
clear figure's tooltip when the tool behavior provider return null or empty tooltip
Comment 2 Michael Wenz CLA 2011-06-08 03:49:03 EDT
Definitely right, but I'm afraid we won't get this into 0.8.0. Today's the last day for changes (only fixing or severe bugs or issue with clearly no side-effects).
Although I would tend to see this as in the second category, since you provided a patch for this, it will be IP log relevant and IP log is definitely closed for 0.8.0 Indigo. So I see this as a candidate for Indigo SR1.
Thanks for the patch anyway!

Michael
Comment 3 Shenxue Zhou CLA 2011-06-08 11:21:56 EDT
Understandable. We'll wait for your Indigo SR1 release. Thanks!
Comment 4 Michael Wenz CLA 2011-06-27 08:42:02 EDT
Shenxue,

while having a closer look and trying to reproduce this I tried to come up with an automated test for this. During that I noticed that this should actually work, at least for EMF domain models.
The tooltip gets cleared during the diagram editor refresh triggered by DiagramChangeListener, which is registered as a resource set listener. After the domain model change the tooltip (and other relevant stuff) is cleared (see PictogramElementDelegate.indicateNeededUopdates - Line 922) and afterwards automatically asked for again (where you applied the fix).
No I wonder if this is a gap in non-EMF domain model handling on our side or maybe a notifictaion gap in your tool. What happens in your tool on domain model changes? Do they somehow trigger a diagram editor refresh?

Michael
Comment 5 Michael Wenz CLA 2011-06-29 10:54:01 EDT
I had another look into this and found that my test case only works because it uses a simple and straightforward case: the ECore test tool has no ghost shapes and/or different selection shapes.
As soon as I try this with the tutorial (by setting an empty name for an EClass it is possible to set no tooltip) it does not work any more: after cleaning the tooltip it won't vanish from the UI.
It showed that the cleaning of the tooltip in the case of a different selection shape than the tooltip shape does not work correctly. I assume that you have a similar scenario. I have changed the retrieval and setting process for the tooltips so that works reliably now.
My change is checked-in to head. Could you please test the change in your scenario before I downport it to Indigo SR1?

Michael
Comment 6 Michael Wenz CLA 2011-06-29 10:55:44 EDT
Created attachment 198836 [details]
Patch containing the change checked-in to head

Attached is the change I did to head for downporting to Indigo SR1. You may also use this for testing the change.

Michael
Comment 7 Shenxue Zhou CLA 2011-07-11 15:43:44 EDT
(In reply to comment #6)
> Created attachment 198836 [details]
> Patch containing the change checked-in to head
> 
> Attached is the change I did to head for downporting to Indigo SR1. You may
> also use this for testing the change.
> 
> Michael

I'd love to test this bug fix. But where could I get a hold of the ZIP file? Thanks!
Comment 8 Michael Wenz CLA 2011-07-12 04:40:13 EDT
Shenxue,

you can test this either using our head/dev build (see our download page for the ZIP location) or by applying the attached patch if you have the Graphiti sources synced locally.

Michael
Comment 9 Shenxue Zhou CLA 2011-07-12 19:14:47 EDT
(In reply to comment #8)
> Shenxue,
> 
> you can test this either using our head/dev build (see our download page for
> the ZIP location) or by applying the attached patch if you have the Graphiti
> sources synced locally.
> 
> Michael

I tested the fix by syncing Graphiti plugins to the latest. It worked great. Thanks!

When will be the next milestone build available? Currently we are using org.eclipse.graphiti.site_0.8.0.201106071252.zip.
Comment 10 Michael Wenz CLA 2011-07-14 07:45:10 EDT
Thanks for testing! I have downported and checked-in the bugfix to our 0.8.x branch. It will be part of Indigo SR1.

Michael
Comment 11 Michael Wenz CLA 2011-07-14 07:50:54 EDT
(In reply to comment #9)
Shenxue,
our next milestone builds are still way ahead: for the Indigo-based release 0.8.x it will be SR1 RC1, for our head version it will be Juno M1 (both on August 19).

I would suggest that we provide an integration build for you to use. Just let me know if you would prefer to get the 0.8- (Indigo-) based or the head version (targeting Juno) build or both?

Michael


> When will be the next milestone build available? Currently we are using
> org.eclipse.graphiti.site_0.8.0.201106071252.zip.
Comment 12 Shenxue Zhou CLA 2011-07-14 11:11:53 EDT
(In reply to comment #11)
> (In reply to comment #9)
> Shenxue,
> our next milestone builds are still way ahead: for the Indigo-based release
> 0.8.x it will be SR1 RC1, for our head version it will be Juno M1 (both on
> August 19).
> 
> I would suggest that we provide an integration build for you to use. Just let
> me know if you would prefer to get the 0.8- (Indigo-) based or the head version
> (targeting Juno) build or both?
> 
> Michael
> 
Could you provide an integration build based on 0.8.x for us? I think that's enough for us now. Thanks,

Shenxue
Comment 13 Michael Wenz CLA 2011-07-15 06:52:48 EDT
(In reply to comment #12)
I have done an integration build for Graphiti 0.8 (version for Indigo SR1) and made the results available at the following locations:
- Update site: http://download.eclipse.org/graphiti/updates/integration/0.8.x
- ZIP: http://download.eclipse.org/graphiti/archives/integration/0.8.x/org.eclipse.graphiti.site_0.8.0.201107141140.zip

Let me know in case of any issues,
Michael

> (In reply to comment #11)
> > (In reply to comment #9)
> > Shenxue,
> > our next milestone builds are still way ahead: for the Indigo-based release
> > 0.8.x it will be SR1 RC1, for our head version it will be Juno M1 (both on
> > August 19).
> > 
> > I would suggest that we provide an integration build for you to use. Just let
> > me know if you would prefer to get the 0.8- (Indigo-) based or the head version
> > (targeting Juno) build or both?
> > 
> > Michael
> > 
> Could you provide an integration build based on 0.8.x for us? I think that's
> enough for us now. Thanks,
> Shenxue
Comment 14 Michael Wenz CLA 2012-04-11 10:26:02 EDT
Bookkeeping: Set target release
Comment 15 Michael Wenz CLA 2012-06-28 10:36:42 EDT
Part of Graphiti 0.9.0 (Eclipse Juno)