| Re: [gef-dev] Interest in GEF-Web? |
Alex,
I was thinking about this back and forth communication with the server. Until introduction of HTML5 the task of storing intermediate snapshots of the graphical model on client would not be possible. However, I was reading about HTML5's client side storage and there might be something in using this for WEB-GEF. I am certainly not an expert in current web technologies (although I used to be in simpler times :)), but can this client storage be used to save states of the model and then persist them once GEF model is saved?
Thanks,
AlexOn Mar 2, 2012 5:05 AM, "Alexander Nyssen" <alexander.nyssen@xxxxxxxxx> wrote:Hallo Vineet,quite nice. However, I fear that - as Miles said - performance problems will inevitably turn out as some sort of show stopper, as it has already been the case for the RAP-based GEF ports (at least as far as I have observed it). And I also fear that these problems are caused by GEF's architecture and cannot be simply overcome "through more engineering", unless one either bypasses the basic interaction principles of the framework or adjusts the framework's architecture itself.I give you an example of what I mean. If you take a look at how GEF handles moving/resizing operations, you will notice that for every mouse movement (i.e. pixel-wise) the selected tool generates a request object that send to the responsible edit part and answered by a command, which is in turn evaluated by the tool and used to indicate feedback to the user. If you stick to this mechanism and simply exchange the rendering framework (Draw2d) with web technologies you will run into a lot of traffic for each single interaction (that is what I observed with the RAP ports, I assume you have to it equally?). To really overcome these problems, I think one either has to bypass these interaction patterns (and e.g. only issue a request for the final mouse position) or move parts of the controller logic to the client as well (so you could indicate feedback in between), which is not so straightforward with the current GEF architecture.Having said so let me point out that I appreciate the work you are doing and that I would welcome any ideas of how we could improve the current GEF architecture so that it becomes applicable in the web as well as the rich client world. I have recently thought of a "suggestion box" wiki page for GEF4, where we could collect all those kind of annoyances that we have with the current GEF and also collect suggestions for future improvements. Looks like a good cause to get this started.... Would be nice if we could collect the condensed input from you as well as the RAP team w.r.t. this.CheersAlexanderAm 01.03.2012 um 17:53 schrieb Miles Parker:_______________________________________________Hi Vineet,This is really cool -- especially the underlying work that is motivating this. It works quite well except for the issue that has been key all along in providing GEF capabilites for web and RAP -- performance / scalability. And actually, the latter isn't as important as the former. But I think that without real-time feedback and interactivity, the usage of the tools will be limited. Do you think that that is something that can be overcome through more engineering, or is that mostly a limitation of the underlying stack?cheers,MilesOn Mar 1, 2012, at 7:42 AM, Vineet Sinha wrote:Angelo,Thanks for the pointer. I will look into this. My understanding from the RAP team was that the GEF feature set had many limitations. But it will be great to join forces. I will see how if I can get in touch with the team.In the meantime, we have gotten a few requests for such web capabilities from teams that have built GEF based editors. They are mostly not wanting to move their entire tooling, but just want to reuse their GEF editor and build a custom/simpler UI for a web page. My primary focus is in helping such teams.Regards,On Thu, Mar 1, 2012 at 3:13 AM, Angelo zerr <angelo.zerr@xxxxxxxxx> wrote:Hi Vineet,
I don't know if you are interesting with GEF/RAP demo, but we use GEF with RAP in our RCP/RAP Application http://xdocreport-rap.opensagres.cloudbees.net/xdocreport?startup=fr.opensagres.xdocreport.eclipse.ui.application
(Go to the menu Administration->Graphics Skills and it opens a GEF Editor to manage skills with graphics means). It works well except the graphic palette which is a little slowly when you add Skill in the diagram.
Regards AngeloLe 1 mars 2012 05:12, Vineet Sinha <vineet@xxxxxxxxxxxxx> a écrit :Sounds great. I will try the RAP forum.If there is anyone else interested here, please let me know.Regards,On Wed, Feb 29, 2012 at 11:01 PM, Alex Kravets <kravets.dev@xxxxxxxxx> wrote:
Vineet,
You can try RAP (forum http://www.eclipse.org/forums/index.php?t=thread&frm_id=34) or RAP mailing list (https://dev.eclipse.org/mailman/listinfo/rap-dev). There was some work being done in this area I believe, but the requirement is not to use any technologies like Flash or Silverlight.
Alex
On Feb 29, 2012 10:50 PM, "Vineet Sinha" <vineet@xxxxxxxxxxxxx> wrote:
Alex,We are currently using WebSockets for the connection and Canvas for the drawing. For older browsers we degrade using Flash - but we have not tested that part as extensively.Would you be able to connect me to teams that also want to get this happening? We will hopefully be able to pool resources and make this happen much faster.Regards,Vineet--President & CTO, Architexa - www.architexa.com
Understand & Document Code In SecondsOn Wed, Feb 29, 2012 at 10:40 PM, Alex Kravets <kravets.dev@xxxxxxxxx> wrote:This is very exciting news! I was at RAP meeting at last EclipseCon and a lot people (including me) were interested in using RAP for GEF/GMF applications. What is behind these prototypes (sorry I am on mobile - can't check source) , is it CSS/HTML/JQuery, Flash or HTML 5?
Alex
On Feb 29, 2012 10:26 PM, "Vineet Sinha" <vineet@xxxxxxxxxxxxx> wrote:Hey Guys,Some of you might know of the work that we have done in bringing different prototypes of GEF working in a web browser. Since then we have settled on an architecture and have a working implementation. We are curious to see how much interested there is from the community for it.We have built the project and have deployed it on 3 GEF apps built by us. Our intention has always been of contributing the gef-web framework to the GEF project. However, before that happens we intend to do some performance improvements, and are hoping that we can work on a couple of projects - to make sure that we have deployed the code in multiple situations.My hope is that we will have this in place for GEF4.You can see the engine in action here: http://www.codemaps.org/e/Eclipse_GEF (select a diagram, and press 'explore').Looking forward to your thoughts.Regards,
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev
--Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer
Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
http://www.itemis.de
alexander.nyssen@xxxxxxxxx
itemis AG
Am Brambusch 15-24
44536 Lünen
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus
Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev