[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [emft-dev] Contribution to EMF-Compare as a Master's Thesis
|
Hi,
fist of all I don't know if this list is the right place for
discussing my concepts. If not, please point me to the right place.
What do I want to do in my Master's Thesis?
Create a diff viewer for EMF models using EMF compare, which goes
beyond the current tree structure.
This actually means displaying the model with edges and nodes using
draw2d figures.
Since the EMF model itself does not contain any information about the
graphical representation,
ideally any editor which is created or will be created using GMF,
should be able to serve as the base.
Goals would be as follows:
1 make use of any GMF editor to draw shapes and modify them
(e.g. dotted lines, various colors) to show deleted, added and
modified nodes/connections in a convenient way.
2 enable the creator of the GMF editor to override those defaults
and define how deleted/added/edited nodes and connections should look
I think this might be too much work for my Thesis, because there is
more than this to do.
But I can definitely do parts of it.
After some weeks of getting familiar with EMF, GMF and GEF, my idea to achieve
this is as follows:
- Use the EditPartFactory, which has been registered for the editor,
to fetch the EditParts
- Wrap my own EditParts around the original EditParts (decorator pattern)
I can now change the original look of the shapes.
- For Goal 2 a new extension point can be introduced. I haven't thought so much
about this yet, because it should not be the big problem
The reason I chose not using the decorator approach of GMF
(DecoratorProvider) is, that it does
probably not fit the requirements. The documentation says, that it is
inteded to decorate the shapes by
drawing something like an overlay on top of the shape. But I want to
change the look of the shape
itself. I read somewhere on the net, that it is possible to fetch the
edit part from the decorator and
modify the figures directly. If this is right, it would probably be a
better approach than mine.
Thank you for your attention. :)
Please tell me what you think about my ideas. Please also tell me if
this is not practible, conflicts
the design of GMF etc., this is not what you need or you don't like it
for any other reason.
Any suggestions are welcome because I'm new to EMF, GEF and GMF. :)
Toby
PS.: I've found a way to come into IRC at work now. If it's easier to
discuss things directly rather than email, my name is "jfbtoby" there.
On Wed, Apr 16, 2008 at 1:36 PM, Tobias Jähnel <tjaehnel@xxxxxxxxx> wrote:
> Hi Cédric,
>
> thank you for your suggestions.
> In fact the first one is the most interesting for me, so I decided to
> go into this topic.
> I sent an e-mail to my professor to ask him if this is an option, but
> I haven't got a response yet. Though I don't think there will be any
> problems.
>
> Unfortunately I cannot come into IRC. All IM protocols, including IRC,
> seem to be blocked by the proxy of the company (only ICQ is working).
>
> Could you go a bit deeper into what you expect?
> When you write "... and integration in graphical modelers", do you
> think of any concrete graphical modelers available?
> I think there should be an easy way to integrate with any modeler.
>
> Toby
>
>
>
> On Thu, Apr 10, 2008 at 7:02 PM, Cédric Brun <cedric.brun@xxxxxxx> wrote:
> > Hi Tobias,
> >
> > Any kind of contribution is obviously welcome!
> >
> > It really depend on your own interests but here are the challenges I can think
> > of (both intellectualy and practically interesting) :
> >
> > * Differences representation and integration in graphical modelers : this one
> > is tricky in the sense that we did not figured out yet what is the best
> > representation of differences for the end user. That's part of the reason why
> > we define many API so that other plugins may refactor the way differences are
> > kept and displayed. The user quickly ends up with many differences and the
> > classical hierarchical way of representing models doesn't fit with the user
> > expectations, there's obviously room for improvements.
> >
> > Correlated to this subject is "how we can visualize differences in a graphical
> > modeler", it's not a technical concern as it doesn't seems like GMF is a
> > blocker for that, it's more, there again, about what we need to display,
> > where, and how, to help the user manage the model evolutions.
> >
> > The Ecore Tools guys want to integrate emf compare in the Ecore modeler, this
> > could be a nice testbed for ideas concerning the graphical representations.
> >
> >
> > * Huge models management : the current implementation of the
> > GenericMatchEngine is not able to handle huge models, (by huge models I mean
> > more than 1GB ones) because the principles and algorithms are just not rights
> > for such data. Another interesting subject could be to provides an
> > alternative match engines for such models.
> >
> > That's two subjects I can think of but of course it's up to you, just to let
> > you know on the "research" side we'll work in the following month with the
> > Aquila University (Italy) on a model representation of the differences
> > (models changeset/patch) providing the same features as the textual patch
> > format (with fuzzy searchs and stuffs like that) but all the other areas are
> > opened for experimentation :)
> >
> > In a nutshell, the first subject I described seems to fit quite nicely with
> > your "part 2", the second one is just another area in which we know we have
> > some progress to do but whatever you want to focus on we would gladly help
> > you !
> >
> > You can use this mailling-list or come on the #eclipse-modeling IRC chan for
> > live discussions, Laurent is "Kellindil" there and I'm "Tortoose".
> >
> > Cheers,
> >
> > Cédric
> >
> >
> > Le Thursday 10 April 2008 11:05:54 Tobias Jähnel, vous avez écrit :
> >
> >
> > > EMF Compare developers,
> > >
> > > I am Tobias Jaehnel, student of Computer Science in Nuremberg, Germany.
> > >
> > > I'm going to start my Master's Thesis and I'm interested in
> > > contributing to the EMF-Compare project.
> > >
> > > Background:
> > > The topic I have chosen for my thesis it based on a state-chart
> > > editor, which uses EMF and GEF. This editor has been developed in the
> > > company I'm working for, for very particular needs. My thesis should
> > > be divided into two parts.
> > >
> > > Part 1: Design and Implementation of an algorithm to find the
> > > differences between two state charts
> > > Part 2: Visualizing the differences in one or two ways, which are
> > > convenient for the user
> > >
> > > After some research I found EMF Compare, which fits our requirements
> > > and entirely covers Part 1.
> > > Since I do not want to reinvent the wheel but are still very
> > > interested in this topic, I'm looking for some other challenge now.
> > >
> > > Can you think of a component or topic I could develop for you?
> > > I actually want to keep Part 2, but I would appreciate it, if I could
> > > make a contribution to EMF Compare in addition.
> > >
> > > Thanks in advance.
> > >
> > > Regards,
> > > Toby
> > > _______________________________________________
> > > emft-dev mailing list
> > > emft-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/emft-dev
> >
> >
> > _______________________________________________
> > emft-dev mailing list
> > emft-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/emft-dev
> >
>
