Subclasificación eficiente de los controles de cacao estándar

Question

A pesar de que existe un documento de Directrices de interfaz humana (HIG), muchas aplicaciones de escritorio de Mac de alta calidad utilizan controles personalizados. Mi pregunta es: ¿cuál es el mejor enfoque para comenzar a crear subclases de controles para el desarrollo de Cocoa? Me sorprende la poca (buena) información que hay sobre este tema. ¿Qué camino es el mejor a seguir para que no termines con un buen control pero medio roto?

Answer 1

He aquí una lista:

• Asegúrese de que el control funciona correctamente al doble de resolución. Use Quartz Debug para probar esto. Deberá probar la cordura del dibujo (en todos los estados: normal, seleccionado, presionado, deshabilitado y otros) y la cordura de la operación (que la prueba de golpe coincide con las cosas que aparecen en la pantalla/otro dispositivo de destino).
• Para obtener crédito adicional, asegúrese de que su control funcione correctamente con una resolución 1.5 (o alguna otra, similarmente no integral).
• Pruebe cómo funciona el control estándar cuando se hace clic. Probablemente lo hagas de todos modos. Haz lo que hace el control estándar.
• Pruebe cómo funciona el control estándar cuando se hace clic medio (el mouse hacia abajo dentro, el mouse hacia afuera).
• Pruebe cómo funciona el control estándar cuando hace clic en el lado oscuro (el mouse hacia abajo afuera, el mouse hacia adentro).
• Pruebe cómo funciona el control estándar cuando se arrastra dentro.
• Pruebe por encima de cuatro con los otros botones del mouse (derecha y central).
• Pruebe lo que hace el control estándar cuando se desplaza con una rueda de desplazamiento. También pruebe shift + scroll y, en un mouse que los tenga (por ejemplo, la mayoría de los ratones Logitech), desplácese hacia los botones izquierdo/derecho.
• Pruebe lo que hace el control estándar cuando desplaza dos dedos en cada eje y en ambos ejes.
• Pruebe lo que hace el control estándar cuando pellizca y cuando desenlaza.
• Pruebe lo que hace el control estándar cuando desliza con tres y cuatro dedos en cada eje.
• Pruebe cómo funciona el control estándar con "Acceso completo al teclado" activado. ¿Puedes tabularlo? ¿Puedes presionarlo con la barra espaciadora? ¿Puedes ingresarlo con la tecla de retorno? ¿Puedes salir de ella?
• Pruebe cómo responde el control estándar a las consultas de accesibilidad. Use el inspector de accesibilidad. Consulte el Accessibility Programming Guidelines for Cocoa para obtener información sobre cómo responder a consultas de accesibilidad y mensajes bajo su control.
• Pruebe su aplicación, incluidos, entre otros, sus controles personalizados en VoiceOver. Cámbiate los ojos y trata de usar la aplicación solo con VoiceOver.
• Si corresponde, imprima su vista de prueba. Puede imprimir para Vista previa si no quiere matar un árbol para su proceso de desarrollo.
• Impresión de prueba en otros tamaños de papel. Si estás en los Estados Unidos, prueba A4; de lo contrario, pruebe la carta de los Estados Unidos. Pruebe otros tamaños de papel (como Legal y A3) si se siente meticuloso.
• Si está implementando una rueda de desplazamiento (poor you), pruebe que su desplazamiento responde correctamente a la preferencia "Saltar a la (siguiente página | punto donde se hizo clic)" en el panel Apariencia en Preferencias del Sistema. "Correctamente" significa que debe hacer lo que el usuario seleccionó.
• Asegúrate de que implementa correctamente las cuatro configuraciones de la posición de la flecha de desplazamiento: One at each end (Mac style), both at the lower/left end (NeXT style), both at the upper/right end, and both at each end (power user style). Como siempre, necesitas dibujar correctamente y pulsar/probar/reaccionar correctamente.(Se sugiere by @radiofreelunch/by David Dunham)
• Además, si está implementando una rueda de desplazamiento, asegúrese de que responde correctamente a la preferencia "Desplazamiento suave".
• Probar que responde correctamente a las diferentes preferencias de velocidad de desplazamiento.
• Si está implementando un campo de entrada de texto de algún tipo, o cualquier vista que responda a algún tipo de tecla de acceso rápido especial (como Enter para enviar un mensaje en una línea de entrada), pruebe de derecha a izquierda (hebreo/árabe) entrada de texto y métodos de entrada alternativos. El Visor de caracteres es un buen comienzo.
• Además, prueba que no rompes ctrl-q. Por ejemplo, ctrl-q, pestaña siempre debe ingresar un carácter de tabulación. Lo mismo generalmente se aplica a la opción + (clave), como la opción de retorno en una línea de entrada.
• Compruebe que responde correctamente a las diferentes preferencias de repetición de teclas.
• Si implementa cualquier atajo de teclado personalizado (⌘ + cero o más modificadores diferentes + una o más teclas de caracteres) por medios que no sean el manejo de atajos de menú estándar de Cocoa, pruebe su comportamiento de acceso directo personalizado bajo Dvorak. No hay una manera más rápida de agriar nuestras percepciones de su aplicación que responder a ⌘ 'al dejar de fumar.
• Muestre su aplicación a los usuarios que nunca la han usado ni visto ninguna maqueta antes. Descalificar a los programadores. Si no reconocen su control como un (lo que se supone que debe ser), rediseñelo. Si alguna vez dice "el scroller está aquí" o "necesita hacer clic en eso", falla instantáneamente.
• Pruebe que su control responde (o no responde, si la respuesta sería peligrosa) cuando su aplicación está en segundo plano. (Suggested by @chucker.)
• Compruebe que su control responde, pero no adelanta la aplicación, cuando su aplicación está en segundo plano y el usuario hace clic en ella con la tecla down. (Suggested by @chucker.)
• Pruebe cambiando el tamaño de su vista. Entre otras cosas, esto asegurará que configure la máscara de autoresize correctamente. También está buscando elementos de dibujo distorsionados, huecos, etc. (Parte de este suggested by @Bagelturf.)
• Si su control es, de hecho, un control, envíelo sizeToFit y asegúrese de que haga lo correcto. (Suggested by @Bagelturf.)
• Si trabaja con las coordenadas del mouse, no asuma que serán números enteros. Asegúrese de manejar números fraccionarios, ceros (positivo y negativo) y números negativos correctamente. (Parte de este suggested by @Bagelturf.)
• También podría considerar dividir su control en un control y una celda. En este último caso, también realice todas estas pruebas en su célula incrustada en una NSMatrix y en una NSTableColumn.
• Si su control tiene un menú, pruebe lo que sucede cuando el control está en uno o más bordes de la pantalla. El menú debería moverse para no caer fuera del espacio de la pantalla.
• Si su control tiene un menú, pruebe que el usuario puede ingresarlo con la tecla de flecha hacia abajo cuando usa "Acceso total al teclado". Si también es un campo de texto (como un cuadro combinado), pruebe que esto solo ocurre cuando el usuario presiona la flecha hacia abajo al final del texto; de lo contrario, el comportamiento normal del campo de texto debería imperar: presionar hacia abajo en una línea que no sea la última línea debe mover el cursor hacia abajo en una línea, y presionar hacia abajo en la última línea debe moverse hacia el final de la línea.
• Si su control tiene un menú, compruebe que permanece abierto cuando se hace clic y que no se cierra inmediatamente cuando se mantiene abierto. There is a function you can use to do this correctly y it is available in 64-bit.
• Si su control tiene un menú, compruebe que es navegable (las cuatro teclas de dirección + Inicio, Fin, Re Pág, Página Abajo), utilizable (barra espaciadora/acción de retorno) y cancelable (esc) con el teclado.

Answer 2

Es difícil agregar nada a la lista de Pedro, pero si está haciendo una barra de desplazamiento, asegúrese de que maneja todas las ubicaciones desviadas de las flechas de desplazamiento (como DoubleBoth).