-
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
-
The following topics were discussed
- Current state of UI-refresh and how to proceed (https://github.com/eclipse-platform/eclipse.platform.ui/issues/2114)
- Should the theme be tailored for IDEs (with an Editor as 'main actor') or should it be designed for general RCP applications focused
- Suggestion to keep the old theme for now in a separated file in the git-tree (but not deliver it) as a public archive so that those interested can easily fetch it and maintain it if desired.
- State of AI support in Eclipse
- Prerequisites are getting in shape
- Edge Integration
- Code-Mining (for 'ghost text')
- Extraction of the IDE context to feed it back to a LLM
- Prerequisites are getting in shape
- Call for actions to flag more issues as 'Good first issue'
- Report about resolution of identified contribution obstacles (discussed in #18th-july-2024):
- Workflow for automatic version bumps is being rolled out
- Tycho 4.0.9 does not display a JGit error in the end anymore
- How to keep the number of attendees to this call up? Without prior notification this attendee count significantly declines)
- Link the dev-call in the Contributing section of the TLP repos and spread the word in issues/PRs.
- Keep the notification mails (those that are not interested will eventually filter them).
- Have potential topics pre-selected and listed in the reminder mail
- Open discussion remains possible and input is more than welcome
- Current state of UI-refresh and how to proceed (https://github.com/eclipse-platform/eclipse.platform.ui/issues/2114)
-
The following topics were discussed
- Report about the progress in SVG support for SWT.
- Question if there are existing users of the
linux.ppc64le
port of SWT and Eclipse/Equinox- If it is not used and nobody is interested in the maintenance, we consider dropping it to reduce future maintenance effort.
- Raised the question if it's possible to systematically fade-out support for older OS versions, mainly in SWT
- Idea was to add OSGi requirements and capabilities, but it's hardly feasible to correctly determine the capabilities at runtime correctly.
- Some APIs are added only with specific updates
- E.g. Under Linux different distributions deliver different versions of libraries or even patch them.
- Idea was to add OSGi requirements and capabilities, but it's hardly feasible to correctly determine the capabilities at runtime correctly.
- Heads up that PHP on
eclipse.dev
project websites will not be supported anymore by the EF after December- Relevance of current content should be checked first and irrelevant or outdated content should be removed before anything is migrated
- Instead of migrating the page the relevant content could also either be moved into the GitHub repository, e.g. into the README or could be added to the PMI entry of the project
- The project's dev website could then simply point to the PMI entry or the Github page.
- Example for PDE:
- No call in two weeks because of EclipseCon/OCX 2024
- Meeting will be removed from calendar, but no reminder/announcement will be send (drops the number of participants any ways).
-
The following topics were discussed
- Possibilities to depend on or include a library for SVG rendering in SWT.
- Usage of the latest JDK-23 early access build in I-Build tests for Linux-java23, which currently have failures due to a bug in JDT 23.0.1.
-
The following topics were discussed
- Progress report in built-in support in SWT for rendering SVG-images
- No API changes will be necessary, users can just pass SVG-files like now other formats can be passed
- Current plan is to use the JSVG
- Performance is probably sufficient, but caching results is probably desired -> Good occasion to clean-up duplicated images
- License is compatible: MIT License
- Integration of JSVG as a dependency
- Suggestion to make SVG-rendering support optional in the beginning and to pull in JSVG as runtime dependency using a fragment.
- Alternatives are adding a runtime dependency for JSVG to SWT or to embedded the jar or 'shade' it's content into SWT.
- Some discussion about tool support to ensure embedded resource exist at a specified path.
- Progress report in built-in support in SWT for rendering SVG-images
-
The following topics were discussed
- Continue on: https://github.com/eclipse-pde/eclipse.pde/discussions/1315
- PR with demonstration: https://github.com/eclipse-equinox/equinox/pull/714
- Heads up and discussion about: https://github.com/eclipse-platform/eclipse.platform.ui/discussions/2588
- Discussion about icon theming (students of Vector are about to started to work on it)
- Discussions about https://github.com/eclipse-platform/eclipse.platform.swt/pull/1632
- No moving tabs are nice, but the exact 'dirty' symbol might be a (personal) preference.
- Discussion about making Smoke test results more visible.
- The could be displayed next to the full I-build test results, but it requires more care, which hopefully come with more attention.
- Continue on: https://github.com/eclipse-pde/eclipse.pde/discussions/1315