Re: [graphiti-dev] Improvement request: execute a feature in an asynchro

["Wenz, Michael" <michael.wenz@xxxxxxx>]

Hi Antoine,

many thanks, I added that Bugzilla to the queue for the next development cycle. It would affect APIs and since we are already after API freeze for the current cycle cannot add that now. We will get back to this in summer for the Eclipse Mars development.

Best regards and thanks,
Michael


-----Original Message-----
From: graphiti-dev-bounces@xxxxxxxxxxx [mailto:graphiti-dev-bounces@xxxxxxxxxxx] On Behalf Of Antoine Lorence
Sent: Montag, 12. Mai 2014 08:54
To: graphiti-dev@xxxxxxxxxxx
Subject: Re: [graphiti-dev] Improvement request: execute a feature in an asynchronous job

Hi Michael and thank you for your answer,

My intention here was to ask Graphiti developers for an enhancement. But 
rather than just asking, I wanted to share the workaround I wrote for 
the issue I described and share it with you as a base for a maybe future 
improvement in Graphiti SDK. I am pretty sure the code I provided can't 
be used as it since is is not optimized and could be implemented in a 
much better way using properly the SDK.

That being said, I totally understand issue with licence set to this 
file (it is part of our project). I will check if I can have the right 
change it for this file or provide the same code without licence in an 
enhancement ticket on bugzilla. If not, I will consider the possibility 
to improve Graphiti SDK on my free time with a new code.

Best regards,

Antoine Lorence

Le 08/05/2014 16:41, Wenz, Michael a écrit :
> Hi Antoine,
>
> thanks for bringing this up and sharing that code, that can surely be useful for other clients of Graphiti.
>
> Not sure what your intentions with that coding are, if you would like other users of the Graphiti framework use this coding in their own tool implementations, I would suggest to post this to our forum (http://www.eclipse.org/forums/index.php?t=thread&frm_id=187). The focus of this mailing list is internal discussion on Graphiti framework, mostly not targeting users, while the forum targets users of the framework.
>
> If you intention is to contribute this coding to the Graphiti framework itself, I'm afraid that the license will not allow us to use it. In case you would like to contribute that coding it must be under the Eclipse EPL license (http://www.eclipse.org/legal/epl-v10.html), otherwise the Eclipse legal process does not allow us to include that coding. The easiest thing in that case would be to open an enhancement bugzilla for Graphiti and add the coding (with EPL or without any license in the header) and state that you have the right and are willing to contribute that coding under EPL to Graphiti.
>
> Anyhow, thanks for bringing this up and the time you spent on this. It's good to see people care about how to bring our project forward.
>
> Best regards,
> Michael Wenz
>
> -----Original Message-----
> From: graphiti-dev-bounces@xxxxxxxxxxx [mailto:graphiti-dev-bounces@xxxxxxxxxxx] On Behalf Of Antoine Lorence
> Sent: Mittwoch, 7. Mai 2014 15:45
> To: graphiti-dev@xxxxxxxxxxx
> Subject: [graphiti-dev] Improvement request: execute a feature in an asynchronous job
>
> Hi,
>
> At some point our projects have Graphiti custom features which can take
> some time to finish (depending on the diagram size). In the basic
> CustomFeature context, execution of such features freezes Eclipse GUI.
> We wanted to:
>    1. Run it asynchronously
>    2. Be able to provide progress information to user
>
> To achieve that, we tried to execute the feature in a Job instance. But
> to be able to perform updates on models, we had to define and execute a
> RecordingCommand in the Job. Indeed, the CustomFeature only schedule it
> and ends before this Job has really finished.
>
> Please find the abstract class we wrote to get rid of these issues on
> http://pastebin.com/XBjmy2sP
>
> Information about this feature:
>    - it defines a new execute(ICustomContext, IProgressMonitor) abstract
> method
>    - it set other execute() methods to final, to prevent users from
> overriding it
>    - hasDoneChange() always returns false, since the feature itself does
> nothing but launching the Job. This ensures only 1 command will be added
> on the CommandStack after the full execution
>    - getDiagramBehavior().getDiagramContainer().updateDirtyState(); is
> executed just after the inner command, to update diagram state only when
> it has been executed
>
> The example code I provides is probably redundant  (run a command in a
> job in a command) but this is maybe the best I can do from a user point
> of view. I don't have enough skills to hack Graphiti source by myself,
> so I give you the code. Maybe it will be useful for users to be able to
> define some CustomFeature to be asynchronous and to use a
> IProgressMonitor. At least, having this by default in Graphiti SDL could
> be helpful for us ;)
>
> Best regards,
>
> Antoine Lorence
>

-- 
INSA de Rennes - Département EII
IETR - Groupe Image

Bureau 214 - Bat. 10
20, Avenue des Buttes de Coësmes
CS 70839
35708 Rennes Cedex 7

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