Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

PartServiceImpl.activate(..) leads to scrolling within scrolledComposites even if triggered through a mouse click

Abierto
  • ¿Algo no está bien?
#3,744 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
java
Área
desktop

Línea de trabajo

Start by tracing the reported focus chain from PartServiceImpl.activate(..) through PropertySheet.setFocus(), FormToolkit$VisibilityHandler.focusGained(FocusEvent), and FormUtil.ensureVisible(Control) to ScrolledComposite.setOrigin(int, int). The issue does not name files or tests, so locate those entry points and check how focus events are handled. Done means a click in the property page does not trigger disruptive scrolling, while visibility scrolling still works when needed.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement

Let's make sure issue is not already fixed in latest builds first.

Suggestion

We implemented a customized property page using the eclipse IPropertySheetPage approach. Within this property page is a scrolled composite containing usual form widgets (laben, text etc.). Those are created with the org.eclipse.ui.forms.widgets.FormToolkit which leads to that fact, that they got attached the VisibilityHandler which is triggered by "setFocus()" from any of these widgets. That method also calls "FormUtil.ensureVisible((Control) w)" which leads to scrolling by the scrolledComposite to ensure the focused item is within the visible area. But if the setFocus is triggered by a mouse click, the attempt to scroll makes no sense, then the control must be already visible, otherwise it cant be clicked. So the setFocus method should somehow provide the information, what event caused the setFocus(). That would make it possible to react to such behavior.

Our concrete Problem is, that the first click within our property page leads to:

PartServiceImpl.activate(..)->
PartRenderingEngine.focusGui(MUIElement) ->
PropertySheet(PageBookView).setFocus() ->
TabbedPropertyComposite(Composite).setFocus() ->
ScrolledComposite(Composite).setFocus() ->
.. multiple composite levels later: ->
Twistie(Control).setFocus() ->
FormToolkit$VisibilityHandler.focusGained(FocusEvent) ->
FormUtil.ensureVisible(Control) ->
ScrolledComposite.setOrigin(int, int)

So the first click into that property page leads to scrolling which leads to an empty click, which does not hit its target.

One way or the other, there should be a way to react to such situations by using the scrolling only in situations where it is necessary and does not disturb the user experience.

Community

  • I understand suggesting an enhancement doesn't mandate anyone to implement it. Other contributors may consider this suggestion, or not, at their own convenience. The most efficient way to get it fixed is that I implement it myself and contribute it back as a good quality patch to the project.
Lenguaje dominante
Java
Estrellas
124
Forks
269
Merge medio
2 d 6 h
PR fusionados (30 d)
69

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de eclipse-platform/eclipse.platform.ui

Todos los issues de eclipse-platform/eclipse.platform.ui

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.