dimecres, de maig 05, 2010

Perquè la decoració de les finestres sí s'hauria de fer al client

Aquesta setmana, en Mark ens ha deixat veure al seu bloc quines són les idees que li rondaven pel cap per aprofitar la part de la dreta de la finestra. Sembla que en general és una idea que ha agradat bastant i no ha passat allò tant típic de quan la gent veu una cosa nova, tothom se li tira a sobre del que ho proposa amb un: "però que fas! Com ens pots canviar això que ho hem estat fent així tota la vida encara que sigui la forma més estúpida de fer-ho!".

Entre totes les coses que explica al seu apunt, hi ha una que si que ha aixecat una mica de polèmica, tot i que no és imprescindible per tal d'implementar la seva idea. I aquesta és la proposta de realitzar la decoració de les finestres a la pròpia aplicació i no al gestor de finestres.

Just després d'aparèixer l'apunt d'en Mark, va aparèixer un altre apunt explicant els motius de per què no s'hauria de fer la decoració de les finestres a l'aplicació. Doncs la meva opinió es totalment contraria. Jo crec que la decoració de les finestres sí que s'hauria de fer a la banda del client, de l'aplicació, i no al gestor de finestres.

S'expliquen moltes coses en aquest apunt. Que no hi haurà consistència entre l'aspecte d'aplicacions llavors o que no es podrà canviar de tema fàcilment, que les aplicacions decorades al client donen problemes i que no podran tenir ombres (amb kwin), etc.

Tot això no crec que sigui cert o solucionable fàcilment. Primer de tot, que la decoració de la finestra es faci al client no implica que cada aplicació faci la seva i que no es pugui tenir un tema, fàcilment intercanviable, per l'aspecte d'aquesta que mantingui la consistència entre totes. O es que ara l'aspecte de les aplicacions GTK+ són inconsistents entre elles? No, oi? Totes fan servir el mateix tema. I sí, tot es dibuixa a l'aplicació.

La meva proposta seria la següent: que GTK+ passi a dibuixar la decoració de la finestra també. GTK+ ja estableix comunicació amb el gestor de finestres. Mitjançant aquesta API pots indicar ja si vols iniciar l'aplicació maximitzada o la vols moure a una determinada posició, per exemple. Llavors l'únic que caldria es implementar la part de dibuixat, que que seria? Doncs exactament com fa Metacity o Mutter, o com fa GTK+ amb els seus temes, llegir el tema de decoració de finestres seleccionat al sistema i dibuixar. Vale, però, això implicaria fer modificacions a les aplicacions? La meva resposta: No. Per defecte, si no se li especifica res, GTK+ dibuixa el tema de la finestra tal com ho faria Metacity o Mutter. De fet, a GTK+ ja li pots dir si vols la finestra sense vores, llavors la dibuixaria sense vores.

Fins aquí, on es la inconsistència? On són les dificultats de canvi de tema? On són les grans reimplementacions a les aplicacions? Per defecte tot llegeix del mateix tema, igual que sempre, mantenint la consistència entre l'aspecte de les aplicacions. Però amb grans avantatges. El primer és que tota la finestra es pot dibuixar d'un sol cop. I el segon és que les aplicacions ho tindrien molt més fàcil per accedir a aquests espai molts cops perdut. Això es podria fer estenent l'API GTK+ per a que proporcioni aquesta funcionalitat.

Els altres problemes que es veuen ja semblen més propis d'una implementació deficient de kwin... Si Chrome dona problemes, potser es més aviat per que deu ser bastant peculiar en el seu funcionament, no per que la decoració es faci a l'aplicació. I si kwin no sap dibuixar ombres a les finestres que es decoren al client, que s'ho faci mirar...

D'altra banda, aquesta idea de passar a fer la decoració de les finestres a l'aplicació no és invenció d'en Mark. Ja fa un temps que l'havia vist en un document de referencia sobre el disseny del GNOME Shell. Cito d'aquest document:

This frame was historically not drawn by the application and as a result appeared to be
different from the rest of the window, both in visual appearance and behavior. There are a
few reasons why we may wish to reconsider this approach.

  • Windows may request that they not be provided decorations
  • Allow decorations to be drawn by the application in order to achieve a consistent look across the application
  • Minimize use of decorations so that they don't distract from the focal area
  • Allow the rendering system to draw the entire window at once

És un document molt interessant, que quan l'estava buscant per escriure aquest apunt, he vist que ha crescut considerablement des de el cop que me'l vaig llegir. Altres coses molt interessants que diu i amb les que estic plenament d'acord són que no hi hauria d'haver diferencia clara de color entre la barra de títol de l'aplicació i el cos de l'aplicació. Això donaria més l'aspecte de la finestra de l'aplicació com a bloc i no com a dos parts com és ara. I un altra és que donat que no hi ha diferencia entre la barra de títol i l'aplicació, l'acció de moure la finestra s'hauria de poder fer des de qualsevol punt lliure de l'aplicació. Per mi, molt més intuïtiu que el sistema actual.I així unes quantes coses més. Si teniu temps, no dubteu en llegir-lo.

Edito: Se m'havia oblidat d'enllaçar el document.

1 comentari:

  1. Hi,

    I noticed you were a fan of GCstar (http://elblogdelredox.blogspot.com/2007/07/catalogant.html). I thought I'd email you about a article I've recently put together about cataloging software I'd like to call: The Ultimate Guide to Cataloging Software.

    http://www.onlinecollegeguru.com/blog/ultimate-guides/ultimate-guide-to-cataloging-software/

    I've gone through a lot of cataloging software (42 to be exact) and picked 4 apps that I believe are the best in the following categories: Best Mac, Best Windows & Linux, Best Web based, and Best Delicious Library for Windows Software.

    When you get a chance, can you take a look at the guide? If you like it, could you give it a little plug on http://elblogdelredox.blogspot.com/?  I think you're readers might find it informative and useful, at least I hope so, or I've just wasted a day on it;(

    Thank You,

    Richard

    ResponElimina