Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Ver: Modo: Orden:
KHTML para Gnome | 23 comentarios (23 temáticos, editoriales, 0 ocultos)
¿y por qué no? (none / 0) (#3)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Thu Sep 9th, 2004 at 11:26:59 AM CET
(Información Usuario) http://speedball.servemp3.com

Primero, hay que comentar que las modificaciones en el gconf no requieren reiniciar la aplicación, precisamente se diseñó para que las aplicaciones se enterasen en caliente de los cambios de la configuración.

Segundo, es posible (o lo que yo haría) que lo que tengas oculto en el gconf es la opción de activar o no la posibilidad de cambiar de motor de renderizado. De esta forma, el usuario novato y pardillo no ve opciones raras que no comprende, y los h4k3r5 del infierno, tras pelearnos con el gconf-editor, tener todos esos botones y submenús tan chulos y potentes. De hecho algo así tienes en el Nautilus con la opción "Eliminar archivo" del menú contextual: por defecto no aparece a menos que la actives en el gconf, con lo que puedes "Enviar a la papelera" o directamente "Eliminar el archivo".

De hecho creo que eso es lo que deberían haber hecho con el Galeon en lugar de crear el Epiphany: hacer que las opciones, botones y menús sean "escamoteables": se puedan ocultar o enseñar según las opciones del gconf. De esta manera, en una configuración en particular seguir el HID a pie de la letra, y con otras desmadrarse tanto como el usuario quiera. Incluso se podría hacer que no tuviese nada: ningún menú, ningún botón, ningún menú contextual... sería práctico en según que entornos ;)

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar
[ Padre ]


Me parece bien (none / 0) (#5)
por jorginius ("jorginius" en Google Mail) a las Thu Sep 9th, 2004 at 01:52:53 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Primero, hay que comentar que las modificaciones en el gconf no requieren reiniciar la aplicación,

Pues es verdad. Perdón :-)

Segundo, es posible (o lo que yo haría) que lo que tengas oculto en el gconf es la opción de activar o no la posibilidad de cambiar de motor de renderizado. De esta forma, el usuario novato y pardillo no ve opciones raras que no comprende, y los h4k3r5 del infierno, tras pelearnos con el gconf-editor, tener todos esos botones y submenús tan chulos y potentes.

Entiendo y yo lo haría también así pero eso me suena bastante parecido tener un botón en Epiphany que ponga a "Opciones avanzadas", salvando que no es un botón lo que pulsarías para ver esas opciones en el navegador sino que cambiarías una entrada en el registro.

Tener menús de "opciones avanzadas", aunque sean submenús ocultos por defecto, está expresamente prohibido en el Gnome HIG (y no "HID" como escribí antes: pensaba en diseño de interfaces para humanos. Perdón otra vez).

Otros problemas más prosaicos son que la aplicación tiene un código apalancado en memoria en diálogos a lo "huevos de pascua" (que no usa la mayoría de los usuarios por desconocimiento) y que, si bien añadir entradas en un menú dinámicamente es fácil, para añadir los botones ocultos y otros wigets de configuración avanzada (los activados por la opción de GConf) habría que reservar de antemano un espacio en los diálogos, con lo cual el diseño de los mismos para que se vean bien con y sin opciones avanzadas se complica.

Aunque sea salirse por la tangente y aunque ya lo he dicho muchas veces, a mí personalmente que en Gnome estés obligado a hacer cosas de estas por no poder colocar las opciones avanzadas en el mismo interfaz de la aplicación (aunque separadas por si el usuario no quiere complicarse) me parece mal.

Primero porque por mucho que documentes las entradas en el GConf siempre será más claro que te expliquen qué hace esa opción sobre el mismo diálogo: con notas, ejemplos, posibilidad de ver al vuelo que hace y de volver atras, con enlaces al manual, etc. Aparte de que las tienes más a mano.

Y segundo porque un usuario de a pie puede no interesarle las opciones avanzadas... hoy, pero quizás sí mañana: ocultar las opciones avanzadas demasiado provoca en el síndrome "anda leche, si hubiera sabido que con esa opción se podía hacer también así me hubiera ahorrado el trabajo bestial de aquella semana". No sé si me explico. Ponerlas separadas pero a la vista por si a alguno le pica la curiosidad. El GConf intimida más al usuario de a pie curioso que una pestaña autista que rece "Opciones avanzadas", pienso yo.

De todas formas, hacerlo como tú dices y ya que Gnome no da otra alternativa, me parece bien. A ver con lo que nos salen luego... :-)

[ Padre ]


Puntualizando, que es gerundio (none / 0) (#6)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Thu Sep 9th, 2004 at 06:14:33 PM CET
(Información Usuario) http://speedball.servemp3.com

Aunque sigo en el curro, ahora me he desplazado a una máquina con GNOME 2.6 ;)

En Epiphany puedes personalizar la barra de herramientas. La opción es totalmente visible en Editar -> Barra de herramientas. Perfectamente pueden hacer que al hacer en el gconf que /apps/epiphany/general/enable_change_render=1 aparezca en el editor de barras de herramientas de Epiphany la herramienta "render selector". ¿Eso viola el HIG?

En el Nautilus tienes que si activas /apps/nautilus/preferencies/enable_delete, te añade una opción más en el menú contextual (Eliminar). Si Nautilus hace eso y cumple el HIG, perfectamente Epiphany puede activar la opción "Usar siempre KHTML en este sitio" o algo similar, y no violar el HIG ¿ok?.

La verdad es que ocultar demasiadas cosas en el gconf me parece mal, o directamente muy mal. Lo que también se debería hacer es un gconf-editor más simple, estable, sencillo y bonito (y que cumpla el HIG) que pudiese ser llamado directamente desde cualquier programa y sólo mostrase las opciones de dicho programa. En el plan de las "opciones avanzadas" que comentabas. Creo que debería estar en el gconf aquellas opciones que se cambian la primera vez y ya no se vuelven a tocar jamás.

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar
[ Padre ]


Interpretando las Gnome HIG (none / 0) (#8)
por jorginius ("jorginius" en Google Mail) a las Thu Sep 9th, 2004 at 09:27:50 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

En Epiphany puedes personalizar la barra de herramientas. La opción es totalmente visible en Editar -> Barra de herramientas.

Las barras de herramientas sí. De hecho dice que todas las acciones que se incluyan en los menús deben poderse añadir a la barra de herramientas (lo normal). Que se pueda cambiar la orientación o ocultarla, que se pueda usar vista de texto y/o iconos, etc.

Perfectamente pueden hacer que al hacer en el gconf que /apps/epiphany/general/enable_change_render=1 aparezca en el editor de barras de herramientas de Epiphany la herramienta "render selector". ¿Eso viola el HIG?

Yo pienso que sí. Gnome HIG dice que en los menús sólo deben aparecer las acciones que son necesarias para que el usuario cumpla la tarea de la aplicación, sin marear con los detalles. Un menú para cambiar el motor del navegador cae fuera de lo que es estrictamente la tarea de navegar, creo yo. Igual que un menú con opciones que no sean las imprescindibles.

En el plano práctico claro que puedes hacerlo, pero cuando actives Epiphany ya no cumple HIG y en teoría el Gnome HIG está pensado tanto para usuarios noveles como para expertos (según sus propias palabras). Si para contentar a los expertos tienes que meter una puerta trasera para cambiar la interfaz por otra que viola HIG es que algo no marcha en esa interfaz.

A lo mejor depende del punto de vista, pero yo veo más coherente con las líneas maestras de usabilidad dejar la elección del motor sólo como una entrada de GConf... Aunque veo mucho más coherente conmigo mismo lo que tú dices :-).

En el Nautilus tienes que si activas /apps/nautilus/preferencies/enable_delete, te añade una opción más en el menú contextual (Eliminar).

Quizás eso tiene más sentido porque eliminar archivos sí es una tarea propia de un gestor de archivos, mientras que seleccionar un motor de representación no lo es de un navegador, que lo que hace es navegar. Sería de esperar que lo del motor fuera transparente.

Al respecto de lo que hace Nautilus, hay otro punto en el que se hace hincapié en las HIG y es sobre los menús contextuales, que deben limitarse en lo posible y siempre dar una método de acceso alternativo. Supongo que al añadir la opción al menú contextual de Nautilus también aparecerá en algún otro menú, ¿o no?. De todas formas creo que esto ni ellos mismos lo cumplen... Sé que soy un brasas pero en el diálogo para abrir archivos de Gnome, donde la opción de ver archivos ocultos está en un menú contextual, no hay nada alternativo para fijar la opción, contraviniendo las HIG.

[ Padre ]


La solución (none / 0) (#9)
por musg0 a las Thu Sep 9th, 2004 at 10:33:43 PM CET
(Información Usuario) http://helvete.escomposlinux.org

En el menú "Preferencias de escritorio" se crea una nueva sección "presentación HTML" o como quieran llamarlo y se pone un diálogo para seleccionar el motor de render HTML que quieras, con un ejemplo de cómo renderiza uno u otro.

Si los temas, las fuentes o los menús se cambian desde ahí no sé porqué no se va a poder seleccionar el motor HTML.

[ Padre ]


Ahí estaría bien puesta pero... (none / 0) (#10)
por jorginius ("jorginius" en Google Mail) a las Thu Sep 9th, 2004 at 11:40:55 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

... Volvemos a lo mismo: para que fuera útil, para cambiar el motor al vuelo según qué página estás viendo, lo interesante es que la opción la tuvieras cerquita, en el mismo navegador, pero las HIG no permiten eso. Siempre, como digo, en mi opinión: que esto no pasa de ser una entelequia y si alguien me argumenta que puede ir ahí me callo.

En fin, que si no puedes colocar la opción en Epiphany, las alternativas que te quedan, como irse al GConf para hacerlo o cambiarlo en las preferencias de escritorio, no son buenas para lo que lo queremos usar.

[ Padre ]


 
Yo a lo mio (none / 0) (#11)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Fri Sep 10th, 2004 at 12:37:19 AM CET
(Información Usuario) http://speedball.servemp3.com

"Gnome HIG dice que en los menús sólo deben aparecer las acciones que son necesarias para que el usuario cumpla la tarea de la aplicación, sin marear con los detalles. Un menú para cambiar el motor del navegador cae fuera de lo que es estrictamente la tarea de navegar"


Ok en cuanto a lo que dice el HIG, en un principio, pero no lo que tu dices de que seleccionar el motor del navegador no es estrictamente navegar. Es estrictamente navegar en cuanto que unas páginas no pueden ser visualizadas por Gecko y por KHTML si, y viceversa.

Si tienes algún método fiable para que de forma automática el navegador pueda escoger el mejor motor para una página en particular, pues si, no necesitas la opción.

Pero en cuanto te puedes encontrar con que una página no se ve, se ve mal, o directamente no va, el probar un método alternativo de renderizado forma parte de la navegación. Que quizás no sea cuestión de que aparezcan las palabras "renderizado Gecko" y "renderizado KHTML" porque eso esta por emcima de las necesidades del usuario, ok, busquese otro nombre menos técnico si se quiere, pero la opción debe estar ahí.

De hecho me acabo de acordar de otro ejemplo exáctamente idéntico que si se hace en GNOME. Tan idéntico que es exáctamente lo mismo: si abres una página web con Nautilus te permite seleccionar el motor de renderizado. Recuerdo que tiempo atras podía seleccionarse entre gtkhtml y Gecko. Ahora no lo tengo tan claro, pero en mi equipo permite: ver como página web, ver como página web (Galeon), ver como texto. La última muestra el código html, y las otras dos muestran claras diferencias por lo menos en el tipo de letra y su tamaño. Si Nautilus cumple el HIG, entonces es totalmente posible hacer lo que he propuesto sin saltarse el puñetero HIG.

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar
[ Padre ]


Depende de cómo lo veas (none / 0) (#14)
por jorginius ("jorginius" en Google Mail) a las Fri Sep 10th, 2004 at 11:08:08 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

seleccionar el motor del navegador [...] Es estrictamente navegar en cuanto que unas páginas no pueden ser visualizadas por Gecko y por KHTML si, y viceversa.

Si tú lo dices. Lo puedes ver cómo cuando cambias la letra de una página web porque la que pensó el diseñador es muy pequeña o la prefieres sin serif. Eso sí lo permite Epiphany.

Yo lo veo más de esta manera, que es parecido a como está/estaba implementado en KDE:

Dejamos de lado la modificación directa de GConf y suponemos que se puede cambiar el motor desde alguna interfaz de usuario. Elegir el motor consiste en cambiar la asociación que hay entre el tipo MIME "text/html" y el componente actual que se encarga de los archivos con ese MIME, que sería Gecko, para que ahora apunte a otro componente, que sería el port de KHTML.

Entonces, según HIG, esto sólo debería poder hacerse desde donde se modifican las asociaciones MIME, que no es Epiphany.

De hecho me acabo de acordar de otro ejemplo exáctamente idéntico que si se hace en GNOME. Tan idéntico que es exáctamente lo mismo: si abres una página web con Nautilus te permite seleccionar el motor de renderizado.

Pero actualmente creo que esto no es así (en Gnome 2.6.0, al menos). Igual que tienes plugin para ver PNG, tienes un único plugin externo para ver archivos html dentro de Nautilus que usa gtkhtml2, y que además se empaqueta aparte. Quizás haya más por ahí fuera. Estoy buscando en "Gnome por defecto".

Supongo que podrías de la misma manera tener un plugin para ver archivos html con KHTML, pero sería eso: un plugin.

De todas formas, ya te digo que todo esto es interpretable. Yo leo las Gnome HIG y no me parece que se pueda hacer tal como tú lo dices, pero yo no hago Epiphany :-). Ni siquiera programo para Gnome desde hace años.

[ Padre ]


Creo que te pasas tres pueblos (none / 0) (#15)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Fri Sep 10th, 2004 at 06:37:02 PM CET
(Información Usuario) http://speedball.servemp3.com

Me parece que ya es demasiado decir que al cambiar el motor de renderizado en una página estas cambiando la asociación del tipo MIME. De hecho desde Nautilus 2.4.2 (estoy en casa, donde tengo GNOME 2.4, pero en el curro tengo una máquina con GNOME 2.6) puedes visualizar páginas web con diferentes "motores" y abrir documentos con diferentes programas sin modificar los tipos MIME.

Por ejemplo, si pulso con el botón derecho del ratón sobre un documento de Word me aparecen las siguientes opciones:
  • Abrir
  • Abrir en una ventana nueva
  • Abrir con
  • Cortar el archivo
  • Copiar el archivo
  • Crear un enlace
  • Renombrar
  • Mover a la papelera
  • Eliminar
  • Añadir al paquete
  • Propiedades


"Abrir" evidentemente me abre el OpenOffice.org con dicho documento. Abre el OpenOffice.org porque es la aplicación por defecto para abrir documentos de Word. "Abrir con" en cambio me abre un submenú en el que me muestra la opción de abrir el documento con OpenOffice.org o con Abiword (que es una aplicación también asociada al tipo "doc", aunque no la de "por defecto"). Si lo abro con AbiWord en ningún momento modifico la configuración MIME para hacer que sea el Abiword el programa predeterminado para estos documentos.

Pues esto es lo mismo. Evidentemente que previamente debe estar el motor KHTML asociado a los documentos html, y si esta asociado "por defecto" entonces Epiphany debería usar KHTML por defecto. Pero si hay dos asociados (dos, tres, cien...) debería dejarte la opción de, en cualquier momento, cambiar a otro diferente.

Nautilus 2.4 lo hace, tanto con la asociación de los documentos como con los visores, en particular con los de html precisamente. Nautilus 2.6 se que hace lo primero porque lo uso constantemente, lo segundo no lo se a ciencia cierta porque no acostumbro a visualizar ficheros html desde él y no lo recuerdo, pero diría que también lo hace.

Es posible que Nautilus no cumpla el HIG al 100%, pero lo que si es evidente es que es la cara de GNOME, la parte más visible de todo el entorno ya que es el encargado de dibujar el escritorio en pantalla. Si el HIG es sagrado en GNOME, Nautilus debe cumplirlo, y si no lo cumple, no es tan sagrado. Por lo tanto Epiphany puede añadir una opción para cambiar el motor de renderizado en cualquier momento sin incumplir el HIG, o inclumpliendolo tanto o menos que Nautilus.

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar
[ Padre ]


La cara de Gnome (none / 0) (#16)
por algarcia a las Fri Sep 10th, 2004 at 07:02:11 PM CET
(Información Usuario)

Es posible que Nautilus no cumpla el HIG al 100%, pero lo que si es evidente es que es la cara de GNOME, la parte más visible de todo el entorno ya que es el encargado de dibujar el escritorio en pantalla.

Para mi, en mi caso personal e intrasferible cuando usaba Gnome, el Nautilus no lo era, porque lo usaba más bien poco. No porque usase más otra cosa, sino porque más que nada no suelo tener muchos ficheros guardados y bueno, no sé que no es lo que más uso el admin. de ficheros. Para mi la cara de Gnome sería el panel, que eso siempre lo veía por narices claro. O incluso el Epiphany, porque el navegador debe ser la aplicación que más uso siempre.

Por cierto, hablando del Epiphany, un ¿bug? que vi en el Epiphany muy extraño: al ir a escribir en la barra de direcciones, se bloqueaba y no se veía nada, aunque estuviese escribiendo una dirección. Así unos segundos hasta que se veía, y entonces salía todo lo que hubiese escrito ahí. Una cosa rara y bastante incómoda. Me fijé que sólo pasaba cuando tenía el historial con bastantes páginas, si no no me pasaba. En Mozilla AppSuite nunca había experimentado ese comportamiento y en Mozilla Firefox no me pasa, así que debe ser algo endémico del Epiphany. ¿Le pasa a alguien más? ¿Alguien sabe cuál es el motivo de ese comportamiento?

--
No me pregunto lo que yo puedo hacer por el S.L., si no lo que todos vosotros podéis hacer por mí. :-P
[ Padre ]


Me pasa con Evolution (none / 0) (#21)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Sun Sep 12th, 2004 at 10:03:16 PM CET
(Información Usuario) http://speedball.servemp3.com

En el curro tengo el Evolution con el Connector, ya que la empresa (una multinacional) utiliza el puto Exchange. Es muy normal que me suceda lo que comentas al poner un nombre en el campo de direcciones y el Evolution lo intente buscar por todo el Active Directory (que es inmenso, ya que es mundial).

Supongo que deben usar los dos el mismo código, y si se trata de listas muuuy largas pues le cuesta. Entiendo que la lista del AD de la empresa, con miles de empleados, sea lo suficientemente grande como para saturar cualquier cosa, pero ¿tu historial de páginas visitadas?? ¿acaso eres una "araña" del google?

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar
[ Padre ]


 
El símil con Abiword y OpenOffice.org no es bueno (none / 0) (#17)
por jorginius ("jorginius" en Google Mail) a las Fri Sep 10th, 2004 at 09:30:55 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Por ejemplo, si pulso con el botón derecho del ratón sobre un documento de Word [...] "Abrir" evidentemente me abre el OpenOffice.org con dicho documento. Abre el OpenOffice.org porque es la aplicación por defecto para abrir documentos de Word. "Abrir con" en cambio me abre un submenú en el que me muestra la opción de abrir el documento con OpenOffice.org o con Abiword [...]

Si lo abro con AbiWord en ningún momento modifico la configuración MIME para hacer que sea el Abiword el programa predeterminado para estos documentos.


Ya, pero no es el mismo caso "Abrir con..." el Abiword o con el OpenOffice.org porque ésas son dos aplicaciones independientes. De lo que estamos hablando aquí no es de "Abrir con..." Epiphany y "Abrir con..." otro navegador diferente o un "Epiphany-khtml", o quizás yo lo entendí mal: creía que se trata de elegir el motor en caliente y desde el propio Epiphany, a ser posible.

Si lo quieres hacer así, con un menú en Nautilus y con dos navegadores o quizás con dos procesos del mismo navegador independientes ("$ epiphany" y "$ epiphany --khtml"), por supuesto que se podría. Es otra posibilidad de entre las que recuento ahora:

  1. GConf
  2. Menús de preferencias globales
  3. Menús de "Abrir con..." en el Nautilus


Pero, si no te entendí mal, ninguna es buena porque todas te obligan a dar un rodeo mientras usas Epiphany (cambiar de ventana) para indicar que usarás el motor alternativo a partir de ahora.

Suponiendo que tratas de hacer lo que yo he supuesto, el asunto está así al final:

  • Si de elegir el motor se ocupa Epiphany entonces no habra interfaz de usuario porque, en todo caso, la opción es una opción avanzada y tiene que ir al GConf. Estirando el ejemplo del Abiword y del OO.org, en el Abiword tampoco hay una opción que sea "Abrir con OpenOffice.org" por si el Doc que abriste no se muestra correctamente.
  • Si Gnome se ocupa, Epiphany usaría siempre el motor que Gnome indique por defecto, que estará etiquetado por el MIME que maneja o por lo que sea. Epiphany no puede tocar eso desde su UI porque para él es una opción avanzada con pinta de ser más bien de preferencias generales. Para cambiarla tienes que ir a otra ventana/menú/whatever, cambiar el motor por defecto asociado a esa etiqueta (que lo normal es que sea el MIME, que es lo que identifica los componentes en KDE) y ya lo tienes para la nueva pestaña que abras en Epiphany


Esas son las dos alternativas que he sacado en limpio, y ninguna me parece buena para, repito, el uso que creo que proponias.

Si el HIG es sagrado en GNOME, Nautilus debe cumplirlo, y si no lo cumple, no es tan sagrado.

O es un bug de Nautilus que será reparado en próximas versiones.

[ Padre ]


 
Ah, ¿a lo mejor te referías a qué...? (none / 0) (#18)
por jorginius ("jorginius" en Google Mail) a las Fri Sep 10th, 2004 at 10:31:13 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

¿Por qué si Nautilus tiene menús de "Abrir con..." no lo puede tener también Epiphany?. Bueno, creo que es obvio: porque Nautilus maneja archivos, una de las operaciones que se pueden hacer con los archivos es abrirlos y como dos aplicaciones pueden abrir archivos con el mismo MIME (Los MS doc con el Abiword y el OO.org, por ejemplo) es lógico que de la opción.

En KDE, elegir motor estaba resuelto de forma global (Vas a las preferencias globales de los tipos MIME y cambiabas el componente que mostraba HTML por defecto), lo que ocurre es que Konqueror es manejador de mimes, navegador de archivos y navegador web, todo junto, con lo que tenías todas las opciones implicadas en el mismo sitio, o a dos clicks de distancia como mucho.

[ Padre ]


 

KHTML para Gnome | 23 comentarios (23 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:
Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda