-
Notifications
You must be signed in to change notification settings - Fork 77
Eclipse IDE ‐ Developers Community Call
Upcoming and past meetings are listed in the Eclipse IDE Community
calendar
Everyone that participates or is interested in participating in the development of the Eclipse core itself is invited to join, newcomers are explicitly encouraged to join too. It is planned as an open meeting without a fixed agenda, where everyone can suggest to discuss general or specific topics, changes or issues or can ask questions. This call is dedicated to the development of the core of Eclipse itself, mainly the top-level projects Eclipse-Platform, Equinox, Eclipse Java development tools (JDT) and Eclipse Plug-in Development Environment (PDE). It is not intended to provide support for users or consumers of Eclipse, for that other channels exists. If specific issues or changes are discussed, the exchanged arguments should be summarized in the corresponding issues or Pull-Requests and if decisions are made they should be justified. Of course others not participating in the call should still have the same chance to influence a decision.
-
The following topics were discussed
- General discussion about 'Corporate Capture' of Eclipse and how it affects the innovation at Eclipse in general and about how to improve the founding situation of smaller, yet essential projects.
- IDE UI "is very chaotic. For example, the context menus are very disorganized. How could they get cleaned up in a meaningful way?"
- Caused by many different contributing projects
- Style guide: https://eclipse-platform.github.io/ui-best-practices https://github.com/eclipse-platform/ui-best-practices
- Reducing duplication and improving the organization requires cross-project coordination.
- Suggestion for more placeholders that can be re-used by different projects in order to reduce duplication in the UI.
- "The documentation is overwhelming for beginners and good resources are hard to find."
- "It's all there but especially the official resources/docs are hard to find"
- "Many unrelated things on the main page"
Suggestions to consider a clean-up of or to make the documentation leaner
Because of overwhelming doc and UI the suggestion was made to discuss if the the position of EPPs Packages should be strengthens with a product-owner for each package that makes sure the default content of these packages looks good and the documentation is cleaned up.
- Where to report issues if the exact project is unknown?
Currently https://github.com/eclipse-platform/.github/issues In the future hopefully in the 'eclipse-ide' GitHub organization
-
The following topics were discussed
- Discussion about the requirement of the Eclipse-IDE respectively the requiring Java-21
- It would be nice to inform the user better during the update-process, for example show a corresponding dialog in the IDE.
- Discussion about if/when Eclipse SDK/top-levle projects should require Java-21
- Set up rules for Eclipse SDK/top-level projects (PMC TODO)
- Suggestion to add code that uses
- Code that uses Java-22 Foreign Function and Memory Access API could be placed in dedicated fragment to be usable before Java-25 is used in general.
- Appeal to re-use existing images or shared images to not replicate e.g. a close icon in 20 bundles (which is currently the case).
It unnecessarily increases the size of an installation, the required memory at runtime and the time to load all images.
Problem: Icons are resources and not 'API'.
- Images in platform plugins are quite stable.
- Suggestion: Generate constants (e.g. by PDE) that represent contained resources and provide coordinates to access them. The class and its constants are API and therefore the resources implicitly become part of the API, which can be checked with existing tools. Issue created: https://github.com/eclipse-pde/eclipse.pde/discussions/1315
- It should be discussed and stated if the path of the referenced resources within the bundle may change and if the content of the resources may change, while preserving the purpose. E.g. may a close-icon be redesigned while still being a close-icon.
- Short discussion about API-check failures in CI builds due to 'Component was disposed' errors, but no immediate solution is known.
- Discussion about the requirement of the Eclipse-IDE respectively the requiring Java-21
-
The following topics were discussed
- How to simplify the contribution process or what are the current pain-points during contributions, for experienced and new committers?
-
Unexpected build failures
- Due to necessary service/micro version bumps, especially in the beginning of a development cycle
- A concept about a work-flow that automatically creates the necessary version bump commits, based on existing Tycho capabilities, has been discussed.
- Intermittent failure of API tooling Already mentioned last time, see https://github.com/eclipse-pde/eclipse.pde/issues/553 and https://github.com/eclipse-pde/eclipse.pde/issues/1310
- JGit Error in the end of a Tycho-build:
java.lang.NoClassDefFoundError: org/eclipse/jgit/internal/JGitText
- Actually harmless but confusing for those that don't know it
- Edit: This is already fixed and only has to be released: https://github.com/eclipse-tycho/tycho/issues/3489
- Flaky tests in platform.ui
- Due to necessary service/micro version bumps, especially in the beginning of a development cycle
-
Provide and document a clear way to set up a developer IDE for contributions to Eclipse There should be a "gold standard for how to setup as a new contributor". Of course different ways are possible but one only 'ideal' way should be recommended and described (describing all can be confusing).
- One suggestion was to replace the Eclipse Committer Package by a corresponding Oomph configuration based on the Eclipse-SDK?
-
There is no
Report a bug button
in the IDE that leads to a place where one can start to report a bug or gets instructions how to contribute.
-
- How to simplify the contribution process or what are the current pain-points during contributions, for experienced and new committers?
-
The following topics were discussed
- We now own the
https://github.com/eclipse-ide
Github organization- Content is work in progress
- Is intended to become in the future the main starting point for contributors of code, reporters of issues, developers
- Should become the target of the Contributing menu entry in the IDE in future
- Suggestion to add a guide to find the right repository to report an issue or to start contributing
- It is to be decided if the
eclipse-ide
organization should also provide a general purpose issue tracker for IDE related issues, that are then redirected (with the help of EF-infra team tooling, Otterdog based?) to the right target
- It is to be decided if the
- TBD: How to assemble/maintain a list of projects/repositories related to the Eclipse-IDE there
- All from SimRel? Or let projects opt-in and let them provide a short description
- Generate it automatically from the list of Eclipse projects?
- Explain that an Eclipse installation can also contain third-party Plug-ins (e.g. from Marketplace)
- Guide to extract the corresponding issue from a error-message/stack-trace e.g. from error-log
- Remind that error-log can be source of valuable information
- Suggestion to use Mylyn to help identifying the desired repository to report an issue/start contributing and to e.g. see issues.
- Provide a Codespace/Gitpod/web-container like environment for Eclipse development
- Suggestion to contact Gitpot, since people who used to be at Eclipse are involved
- Could be a bigger task
- We now own the
-
The following topics were discussed
-
How to handle the current state of the modernized theming?
Create an opinion poll, to gather feedback from the community (open till Tuesday 20th of August 23:59 UTC). Poll is non-binding, final decision is made by Committers. Send it to cross-platform. Options:
- Only keep the modernized light-theme as default
- Keep old light-theme as another/second
Light Classic/Legacy
separate theme (allows opt-out of the modernized theme) How long it's kept it is another question, but it will not be maintained by the providers of the new theme - Provide the new light-theme as a new
Modern Light
theme (opt-in) - Revert the new light-theme for the release and reapply it in the beginning of next development cycle (effectively option 1, but delayed)
Keeping the old theming could act as a save guard in case severely broken elements were not discovered before the release and gives more time to those that need to adapt to it. However that is only possible for the light-theme. Because the dark-theme as a lot of extensions it would be too much work to provide more than one dark-theme.
-
SWT Edge Browser https://github.com/eclipse-platform/eclipse.platform.swt/discussions/1406
- Raised the general question how to introduce new features that ar only available for one OS/platform and can therefore not be made a cross-platform API: Suggestion for a work-around to handle it: https://akurtakov.blogspot.com/2016/09/runtime-css-styling-for-swt.html
-
-
The following topics were discussed
- Input for work on supporting SVG image in SWT
- On Linux/Mac SVG support is nativly available for rendering SVG as a raster-image
- On Windows a third-party library has to be used to render an SVG
- Multiple libraries should be compared regarding rendering performance and capabilities
- Existing pipeline for static rendering of SVG to PNG in platform.releng using batik SVG
- Searching the Internet for 'Java render SVG' provides links to multiple rendering libries
- 'API' for SVG support has to be completed but for Linux much work has already been done under the hood
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=545800
- Advantages of SVG are not only sharper images and more flexible resolution, but also less disk-space use because an icon is only provided once instead of multiple for each resolution and SVG often has better fonts
- Possible alternative is using emojis
- Managed by the OS, high resolution, zero disk-space required
- but difficult to decorate and e.g. no way to show it in a disable state
- Heads up about the Security team suggestion of the EF-secutiry stuff
- Discussion about the revised mission statement of the Eclipse IDE Working Group
- Request for feedback on the Communit issues:
- Input for work on supporting SVG image in SWT
-
The following topics were discussed
- State of Linux/Wayland support in SWT
- At the moment only latest LTS of Ubunutu/Suse/REHL is fully supported, but Wayland will become important in the future
- Suggestion to clarify in the API documentation of known limitations on some platforms that cannot be resolved (e.g. due to design decision of that platform)
- Win32 API might change soon too that need adaption for SWT on Windows
- Discussion about Marketplace client issues in the new release integration
- Some background information
- A summary of the PMC's decision about rules when new java versions are permitted to be used as required execution environment of a bundle were given
- The details will be published in written form soon
- State of Linux/Wayland support in SWT