Deprecate/remove `is-color-display?`
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
- Refactorización
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Área
- desktop
Línea de trabajo
Inspecciona las implementaciones de is-color-display? en los backends gtk3, cocoa y win32, junto con las referencias de la API GUI pública. Decide el alcance de la deprecación o eliminación y, a continuación, verifica que los tres backends y la API expuesta reflejen esa decisión de forma coherente.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
The function is-color-display? is useless, in its current form, and I propose that it be deprecated and/or removed.
- It has separate implementations in all 3 backends (gtk3, cocoa, win32) and all of them simply hardcode a constant:
(define (is-color-display?) #t) - Modern GUI toolkits don't seem to have a corresponding function for it to easily wrap (perhaps because nearly every display in use today has color), so there's no obvious and simple path to fixing it -- nor does there seem to be any great demand for this functionality
- Unlike most other per-monitor attributes which have racket/gui accessors, this one doesn't take a
#:monitorargument (so you can't answer questions like: "Am I drawing on a monochrome monitor right now?") - There's no corresponding event that I can find, so when monitors or settings change, your program won't know (unless you poll, which brings its own set of problems)
- No Racket program that I've found uses this function, and nobody has ever mentioned that it doesn't do what it claims to do
Even if all the issues here were fixed, it's not clear what its intended use is. Perhaps a program could use this as a hint to distinguish visuals by shape rather than simply color, but given the prevalence of colorblindness, they should always do that, anyway.
The one place where I can imagine such a feature being useful is for printing, as black-and-white printers are still fairly common, but that obviously goes through printer-dc% and dc<%>, not the default monitor, and those interfaces have no such feature, so it can't be used for that.
- Lenguaje dominante
- Racket
- Estrellas
- 68
- Forks
- 83
- Merge medio
- 12 d 5 h
- PR fusionados (30 d)
- 3
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
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 racket/gui
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
Colorer messes up when given a lexer that supplies nonzero backupsPosiblemente ocupada @otherjoel la tomó hace 1 día. Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
Todos los issues de racket/gui
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
KnifeLemon/Filee#363 ·
Los mantenedores suelen responder en 1 día
-
bug good first issue help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 63/100
marcovisona/arca#5 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
qbittorrent/qBittorrent#25117 · 1 comentario ·
Los mantenedores suelen responder en 2 días
-
[Feature request]: Configurable date/time format for currentTimeInBreaks (add date and weekday)Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
longbridge/gpui-kit#3620 ·
Los mantenedores suelen responder en 1 día