Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [graphiti-dev] ImageProviders

Hi,

Yes, I also think this deserves a bug of its own. I'll close bug 366452 with the comment I added yesterday regarding URIs, that should cover most of the use cases described, and open a new one regarding this problem.

Regards,
Félix


2012/12/11 Wenz, Michael <michael.wenz@xxxxxxx>

Hi,

 

if that’s the case I would vote for cleaning that up. To me it sounds like a bug, a DTP should only have access to the image provider it has registered itself (plus the platform image provider). If that means an incompatible change, we should do it; we’re in incubation to clean up such wrong stuff.

 

I’m not sure if that fits under this improvement bug, I would rather say we should open a new one and describe the API change there. What do you think?

 

Regards,

Michael

 

From: graphiti-dev-bounces@xxxxxxxxxxx [mailto:graphiti-dev-bounces@xxxxxxxxxxx] On Behalf Of Felix Velasco
Sent: Montag, 10. Dezember 2012 17:49


To: Discuss development topics on Graphiti
Subject: Re: [graphiti-dev] ImageProviders

 

Hi,

I also thought that the image provider being registered with the DTP meant it was only available for it. However, it only means that the ImageProvider is registered when the DTP is created. After that, once the ImageProvider is registered, it's available for all the graphiti diagrams, no further check needed. If the ids have been registered, as you say, with the plugin id as their prefix, there should be no problem, but there's no real guarantee regarding that.

Currently, the IImageService methods retrieve the images only with the imageId, knowing nothing of DTP scopes, so it just looks into every registered ImageProvider.

Regards,
Félix

 

2012/12/10 Wenz, Michael <michael.wenz@xxxxxxx>

Hi,

 

as far as I know, image providers need to be registered at the diagram type provider in the plugin.xml. In case a diagram type omits that, it won’t get the images from that image provide. Please correct me in case that is wrong…

 

The idea behind was to enable reuse between different diagram types, but I’m not sure if that is used or it is a really valuable feature. Where would the conflicts come from? At least if the recommendation to use the plugin id as prefix of the image ids is followed that should not happen. Maybe we should somehow enforce that or make it more explicit.

 

The PlatformImageProvider needs to be available in all diagram types, otherwise the default icons would not be displayed. Do you think all tools should define a dependency to it? It would be definitely cleaner but also incompatible. Do you have examples for the strange behavior you referred to?

 

Comments from others highly welcome, as that part of the coding has been created before I joined the project…

 

Regards,

Michael

 

 

From: graphiti-dev-bounces@xxxxxxxxxxx [mailto:graphiti-dev-bounces@xxxxxxxxxxx] On Behalf Of Felix Velasco
Sent: Montag, 10. Dezember 2012 12:58
To: Discuss development topics on Graphiti
Subject: [graphiti-dev] ImageProviders

 

  Hi all,

  I was reviewing bug 366452, and ran into a rather unexpected behavior regarding ImageProviders. Once an ImageProvider is created, its images are available for all the graphiti diagrams, there's no real link to its DiagramTypeProvider.

  Changing this behavior would imply adding a parameter to the ImageService methods, and potentially several changes in order to make the providerId available everywhere these methods are called, which may or not be feasible.

  Not changing it, on the other hand, can provoke conflicts when several graphiti diagrams are used in the same eclipse instance.

  Besides, there may be some strange behaviors for dtp's that don't explicitly define PlatformImageProvider, since it's currently always available, and used for some stock icons (i.e., delete).

  All in all, I'd like to hear from you on how to approach this, whether to change the code, change the documentation, or (hopefully) a smarter move I can't see right now.

  Regards,
Félix


_______________________________________________
graphiti-dev mailing list
graphiti-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/graphiti-dev

 


_______________________________________________
graphiti-dev mailing list
graphiti-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/graphiti-dev



Back to the top