Feature discussion: synchronizing layer visibility across views
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
Línea de trabajo
Start by reading issue #2448 and compare its view-level synchronization proposal with the technology-based approach described here. Investigate requirements for technology-shared layer visibility, visibility groups, and undo behavior. Done means the requirements and preferred architecture are documented well enough to guide a later implementation.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
From the discussion in #2448 (a view-level "synchronized layers" button, like "Synchronized views" but for layer visibility).
There, @klayoutmatthias proposed taking this to a feature discussion first, with these starting points:
- synchronizing on technology objects instead of views: a technology keeps a layer properties map with a dynamic bidirectional update path between technology and view, so all layouts sharing one technology stay synchronized; less intrusive than view-level sync and avoids some of its logic issues
- possible synergy with visibility groups, which are currently emulated with tabs: a technology-global visibility state with presets could address several requests at once
- undo: layer visibility in the main undo stack is contentious; candidates are dropping it from undo or giving it a separate stack
The view-level approach from #2448 is one data point, the technology-based scheme the other candidate. Opening this to collect requirements and settle the architecture before any (re)implementation.
- Lenguaje dominante
- C++
- Estrellas
- 1.2k
- Forks
- 305
- Merge medio
- 3 d 2 h
- PR fusionados (30 d)
- 11
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
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 KLayout/klayout
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
KLayout/klayout#2554 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
KLayout/klayout#2412 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
DRC functions not working properly with clip in placePosiblemente ocupada @klayoutmatthias la tomó hoy. Abiertobug
KLayout/klayout#2553 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 50/100
Los mantenedores suelen responder en 1 día
-
Deep DRC can miss violations when a cell has many shapesQuizá libre de nuevo Un pull request para esta issue se cerró sin fusionarse. Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
KLayout/klayout#2546 · 5 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de KLayout/klayout
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día
-
Integer underflow and buffer overrun in detail::count_rows on disconnected distance matricesAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 3 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
LaneDibello/Kotor-Patch-Manager#375 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
Los mantenedores suelen responder en 1 día