Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Talk:E4/Web-based IDE"
(Ideas.) |
m (minor reformatting) |
||
| Line 3: | Line 3: | ||
Imagine for a minute a direct port of the full existing version of eclipse to the web. | Imagine for a minute a direct port of the full existing version of eclipse to the web. | ||
| − | + | #The file system could be remote or local or both, obviously some better tools for building incrementally would be required to keep performance acceptable. | |
| − | + | #Tools, configurations, perspectives, projects could all be stored in the web. | |
| − | + | #A standard set of organizational plugins could be instantly distributed to the entire team, and the IDE could be configured identically for SCM, database access, etc, easing development efforts related to setting up and configuring the IDE. | |
| − | + | #Recovering crashes to an earlier working point automatically and seamlessly would be required, corrupt .metadata must not destroy the users experience. | |
| − | + | #Navigation and behavior of the IDE should not be changed if possible. In accordance with the principle of least surprise nothing unexpected should be done to the IDE usability experience. | |
| − | + | #This may mean the "browserness" may be severely diminished or removed entirely. The navigation and concept of moving from page to page makes little sense in an IDE. The browser in this case is basically merely a possible view in the "chrome" of the IDE. | |
| − | + | #Start up times and performance must not be prohibitive. The experience must not block and halt. Additionally dispatching the compile and other activities to a back end could make for a much more fluid and responsive experience. | |
| − | + | #Perhaps a webstart applet based version of eclipse with a reworked model for event handling implemented as a webkit plugin could me made to work. | |
Latest revision as of 13:26, 4 April 2014
In my view as a programmer of 20 years, you have to work with what exists. What could be done and what should be done, what advantages could the web bring.
Imagine for a minute a direct port of the full existing version of eclipse to the web.
- The file system could be remote or local or both, obviously some better tools for building incrementally would be required to keep performance acceptable.
- Tools, configurations, perspectives, projects could all be stored in the web.
- A standard set of organizational plugins could be instantly distributed to the entire team, and the IDE could be configured identically for SCM, database access, etc, easing development efforts related to setting up and configuring the IDE.
- Recovering crashes to an earlier working point automatically and seamlessly would be required, corrupt .metadata must not destroy the users experience.
- Navigation and behavior of the IDE should not be changed if possible. In accordance with the principle of least surprise nothing unexpected should be done to the IDE usability experience.
- This may mean the "browserness" may be severely diminished or removed entirely. The navigation and concept of moving from page to page makes little sense in an IDE. The browser in this case is basically merely a possible view in the "chrome" of the IDE.
- Start up times and performance must not be prohibitive. The experience must not block and halt. Additionally dispatching the compile and other activities to a back end could make for a much more fluid and responsive experience.
- Perhaps a webstart applet based version of eclipse with a reworked model for event handling implemented as a webkit plugin could me made to work.