Yes, that makes a lot of sense. It sounds for sure like the greatest value added is going to come -- at least in the shorter term -- from the facilitation of turning sketches into crisp diagrams in generic usage -- as your proposal is very clear on. And I think you're right about going that route because it does seem more broadly useful. After all gestures are at the heart of the user experience of .. um.. a few reasonably successful new products out there right now. ;)
Also, in a funny way I wonder if an obsessive working from model approach can result in a design that gets frozen too early -- I've felt this a bit from my experience with AMF. The issue is that as soon as you get a good model put together, even though you can "easily" generate code for the model changes and even do some M2M for backward compatibility you end up needing to build up all kinds of API and infrastructure that relies on it as well. So it's never a matter of saying "let's just tweak this one interface..or add a new one" -- instead you're really looking to a major segment change to pile a bunch of changes into.
Hopefully the discussion has still been useful -- I wasn't really thinking there was much chance of a change, but more throwing it out there to get a dialog going as I think the ultimate implications for modeling are quite interesting.
cheers,
Miles
On Apr 24, 2010, at 3:33 PM, Ugo Sangiorgi wrote: Hi MilesThank you for your input, I think your questions are very pertinent. Trying to answer a subset of them: the plan is to evolve Sketch to be not only modeling-focused (as it was thought and coded initially, prior to the proposal) to be a more independent tool, an API to receive data (such points, time they were drawn, and so on) and respond accordingly with a command (create editpart..) or just a formatted result. The goal is to get this kind of flexibility.
But primarily the goal of making it an Eclipse project is exactly to interact with other projects and receive contributions from projects where it would be needed. I think to foster this discussion and direct its evolution from an early point of development, when there isnt much complexity in it, might increase the chances of Sketch to succeed.
Anyway I think its a bit late to change the top-level project. But your considerations still apply.
Thanks again,
Ugo On Sat, Apr 24, 2010 at 2:51 PM, Miles Parker <milesparker@xxxxxxxxx> wrote:
I don't know that it's necessary to split out sub-projects, my sense is that it would be best just to pick out a home that is going to feel comfortable for the longer run. There are projects outside of Modeling that depend on EMF of course -- and hopefully there will be more and more of those -- though I'm not sure about GMF. And on the other hand, a number of Eclipse Modeling projects have significant components that don't have any dependencies on the modeling stack. So there are going to be orthogonalities.
So I think the question is what feels right to you and to the modeling team? My tendency is to want to see some kinds of natural groupings emerge whenever possible as Technologies is really a very flat catch-all. Modeling is doing a nice job I think of herding cats or at least allowing them to self-organize w/o force fitting. So I think the questions to ask are along the lines of..
Is Sketch likely to be used for tasks other than modeling in the broadest sense of that word? (Can we ever think of Sketch artifacts as being modeless?) Is Sketch primarily a tool for doing shape ad gesture recognition, or is it more than that?
Would sketch always have some kind of backing internal meta-model or might there be an API back end as well? What are potential relationships with modeling tools from the immediate to fanciful?
Does it matter whether dependencies are on GMF or just GEF? To what extent is Sketch a *meta*-model consumer vs. a potential *meta*-model provider?
One of my motivations for above questions comes from my thinking that the point of GMP is that GMF != Modeling + Graphics, and that we want room for many other lighter-weight or complimentary approaches. On the other hand, I've found that Zest / GEF plus EMF makes a very nice light-weight substitute for GMF, but I wouldn't suggest that Zest should be part of modeling. That is because the backing models for Zest are and can be arbitrary, API based, etc... But it seems to me that the backing models for Sketch would always involve some kind of formal model, (or in the fanciful case an informal model mediated by a formal model :)).
I'd be interested what other PMC folks think as this is really just as much a question about how modeling sees itself as where Sketch does.
-Miles
On Apr 24, 2010, at 9:16 AM, Ugo Sangiorgi wrote: Hi Miles, before start to write the proposal I discussed with Chris and Mariot about where Sketch would fit in, and Technology seemed to be a more flexible choice since (as Mariot pointed) we have plans to provide gesture capabilities for GEF.
But I dont know really what would be better: if to extract a sub-project from modeling.sketch to provide only gesture to GEF (and draw2d maybe) or to create a modeling.sketch derived/forked from technology for modeling on GMP. I dont know what makes more sense.
what do you think?
cheers, Ugo ___________________________________________________________ Ugo Braga Sangiorgi - usangiorgi@xxxxxxxxxxxxxx
+ http://linkedin.com/in/ugosangiorgi===================================
On Fri, Apr 23, 2010 at 5:14 AM, Mariot Chauvin <mariot.chauvin@xxxxxxx> wrote:
Hi Miles,
I am not sure it makes sense to have Sketch under the GMP. It would be
usable without a modeling dependency directly on top of GEF. Of course
combining Sketch with a graphical modeling toolkit/runtime will allow to
build awesome graphical modeling tools.
Cheers
Mariot
Miles Parker a écrit :
>
> Congratulations Anthony. I think this is a really positive and forward
> looking change. My guess is that the way that the subprojects (i.e.
> existing GMF) are restructured to encourage different tooling and
> runtime approaches will be really helpful.
>
> I wonder if anyone has discussed the possibility of having Sketch
> included under the umbrella instead of at ETP? It probably didn't
> make sense before under modeling, but as part of GMP it seems a pretty
> natural fit even though it is arguably more end-user enablement
> focussed. Would that be worth suggesting to them? The proposal review
> is on the 28th.
> On Apr 22, 2010, at 4:39 PM, Anthony Hunter wrote:
>
>> Hi Team,
>>
>> Our GMF Restructure has been approved by the EMO, so we are
>> proceeding with the creation of the Graphical Modeling Project.
>>
>> I blogged about our goals for the restructure again in
>> http://ahuntereclipse.blogspot.com/2010/04/graphical-modeling-at-eclipse.html
>>
>> We are now starting the actual restructure. The ongoing work will be
>> tracked in https://bugs.eclipse.org/bugs/show_bug.cgi?id=310208 if
>> you wish to follow along.
>>
>> Cheers...
>> Anthony
>> --
>> Anthony Hunter mailto:anthonyh@xxxxxxxxxx
>> Software Development Manager
>> IBM Rational Software: Aurora / Modeling Tools
>> Phone: 613-270-4613
>>
>> _______________________________________________
>> modeling-pmc mailing list
>> modeling-pmc@xxxxxxxxxxx <mailto:modeling-pmc@xxxxxxxxxxx>
>> https://dev.eclipse.org/mailman/listinfo/modeling-pmc
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> modeling-pmc mailing list
> modeling-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/modeling-pmc
>
_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev
_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
|
