Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Flux/Meeting minutes/20141016
Attendees
Martin, Nieraj, Andy, Alex, John, Jay, Kris
Updates
- new version of Orion adapted to get the latest changes in, the missing piece in Orion is still the multiple text snippet insert for content-assist (John will take a look and try to get this into the main Orion code base)
- looked at the hover support in Orion, need to move over the old prototype to the new hover support from Orion (Alex will take a look)
- fixing issues with the build
- Jay will work on quick-fix support for Flux using the Orion hover support for it, the code isolation for quick-fix inside JDT/UI, for the headless JDT service is a first bit and already in progress, and once the hover support from Orion is adopted in Flux (via the work that Alex is doing), we will leverage that for quick-fix (Jay will work on this)
- deploy-icon added to Orion to jump to the cf-deployer-app directly from the Orion UI
- work started on code refactoring for extracting the flux-messaging-connecting code into a lib (doing things via RabbitMQ and/or Websockets)
- trying to find out how to trigger the linked-edit-mode (for rename in file, John will ask inside the Orion team)
- created some artwork (icon and logo), feedback sent back to designer
- simple project web page needs to be done in time for EclipseCon Europe, Martin will do a first draft
John reporting about Orion work:
- new hover support, early support for quick-fix
Discussion
How should the quick-fix support do the text changes?
- create deltas and the editor applies the deltas
- service itself changes the file and sends back the changed file
We came to the conclusion that the headless JDT service had to apply the changes to files and editor buffers on the server side. Flux will take care of syncing those changes back to the web editor, for example. That means we will end up with a two-step communication: #1 the headless JDT service sends back information about quick-fix proposals (on request), #2 the headless JDT service will apply a certain quick fix proposal on files and editor buffers (on request).