Getting polyscope parent window size/dimensions for callback
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 20/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Área
- desktop-dev
Línea de trabajo
Start by comparing the C++ source's parent-window sizing and docking updates with the Python callback path using the imgui bindings. Determine whether the reported window and content-region values expose the needed parent context, then define the scope for sizing access, callback renaming, and control of the Structure, Picker, and Polyscope elements.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I'm creating custom UI elements since the default callback seems to only support a single additional window and also has a hardcoded name of "Command UI". In the C++ source, I noticed the windows are being docked by continually updating the current window heights of the parent window and adjusting the positions accordingly.
I'm trying to do this in the Python implementation with the imgui bindings, but the functions GetWindowHeight() and GetWindowWidth() seem to return completely static values when I call them within my callback, and do not change if I move/resize the parent window or the actual callback GUI element. It's unclear what it's doing. I'm seeing the same trouble with GetWindowContentRegionMax() and GetContentRegionMax().
Not sure if this is a ImGui specific question but it seems related to PolyScope. For that matter, it would be nice if the main polyscope instance could return the window sizing params for this purpose if the above bindings don't actually have the parent window context. Otherwise, I'm not sure how to get GUI elements to dock to different sides of the window, etc. It would also be nice if we could rename the default callback GUI, as well as enable/disable the Structure, Picker, and Polyscope GUI elements from Python like that can be done in C++. Additionally, further customization of those default elements would be highly appreciated since without it, users who want to customize the UI will have to turn off the boilerplate and re-write it which defeats the purpose in my opinion.
- Lenguaje dominante
- C++
- Estrellas
- 53
- Forks
- 25
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de nmwsharp/polyscope-py
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
nmwsharp/polyscope-py#56 ·
-
Imgui Bundle Abierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
nmwsharp/polyscope-py#44 · 1 comentario ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
nmwsharp/polyscope-py#41 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 25/100
nmwsharp/polyscope-py#39 ·
-
enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
nmwsharp/polyscope-py#36 · 1 reacción ·
Todos los issues de nmwsharp/polyscope-py
Issues similares
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 92/100
autowarefoundation/autoware_universe#13413 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
-
automated-analysis bug memory-safety
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
-
Sensor initialization takes very long when `--initial-sim-time` is set to current UNIX timestamp Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
gazebosim/gz-sensors#662 · 1 comentario ·