Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
KHTML para Gnome

jorginius's Diary
Por jorginius
departamento al otro lado del espejo , Sección Diarios
Puesto a las Wed Sep 8th, 2004 at 10:14:21 PM CET
Christian Persch, uno de los principales desarrolladores de Epiphany, el navegador oficial de Gnome y preferido por algarcia, ha incluido en estas últimas semanas el código del componente de renderizado de páginas HTML KHTML en el CVS del proyecto Gnome bajo el nombre de gnome-webkit.

Hasta ahora el motor oficial de renderizado de Gnome (gtkhtml2 aparte) ha sido única y exclusivamente Gecko, del proyecto Mozilla. KHTML, que comparten navegadores como Konqueror, Safari o Tavia (página parcialmente en japonés), es nativo de KDE y sorprende que la gente detrás de Epiphany busque ahora "una segunda opinión" en la "competencia".

 


Una de las más controvertidas pretensiones de Ali Akcaagac y de su proyecto GoneMe, del que ya hablamos en el diario de davinci: Goneme, era precisamente reemplazar Gecko por KHTML como motor del navegador oficial. ¿Tendrá esto algo que ver?, ¿KHTML ha llegado a Gnome para quedarse y reemplazar a Gecko?. La mayoría de la parroquianos ya se declaró en su momento en contra de la idea de Ali (por ejemplo lo podemos ver en Barrapunto: Proyecto GoneME, fork de GNOME): ¿al final tendrán que comulgar con ruedas de molino? :-)

Al margen de todo esto, se trata sin duda de una muy buena noticia para los desarrolladores de KHTML y un avance sorprendente en la cooperación entre los dos escritorios libres más importantes. La dominación mundial está a un paso y se llama KHTML for Win32. ¿MS IExplorer acabará también usando KHTML?. Yo ya me lo creo todo :-)

< Cambio de licencia en X-chat para windows (15 comments) | Quedada FreeBSD en Vitoria-Gasteiz (0 comments) >
Enlaces Relacionados
· escomposlinux.org
· Epiphany
· Gnome
· algarcia
· KHTML
· CVS del proyecto Gnome
· gnome-webkit
· gtkhtml2
· Gecko
· Mozilla
· Konqueror
· Safari
· Tavia
· KDE
· GoneMe
· diario de davinci: Goneme
· Proyecto GoneME, fork de GNOME
· KHTML for Win32
· More on jorginius's Diary
· Also by jorginius

Encuesta
Epiphany usando KHTML
· Arggghfs, anatema. Penitenciagite, penitenciagite... 8%
· Gecko es muy superior, es una mala idea 16%
· Ya era hora: Gecko consume demasiados recursos 25%
· El mundo al revés: KDE *debe* usar Gecko 22%
· Normal, siendo la rubia developer de KDE 27%

Votos: 36
Resultados | Otras Encuestas

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
KHTML para Gnome | 23 comentarios (23 temáticos, editoriales, 0 ocultos)
Aclaraciones (5.00 / 1) (#7)
por xan (xan en gnome punto org) a las Thu Sep 9th, 2004 at 09:07:13 PM CET
(Información Usuario)

Más que nada para evitar suicidios prematuros:
- Por ahora sólo hemos portado KJS, de KHTML tenemos poco hecho. Para ellos hemos utilizado código de otro port empezado hace tiempo por Ian McKellar.
- Christian y yo (y cualquiera que quiera ayudarnos) pretendemos trabajar en esto en los ratos libres. Como ni él ni a mi nos pagan por esto se podría pensar que ténicamente TODO lo hacemos en los ratos libres. Cierto. Sólo quiero decir que no es un proyecto excesivamente prioritario (¿por ahora?).
- En principio seguiremos la rama desarrollada por Apple, no la de KDE. No por nada en especial (mal pensados) pero nos parece que Apple está haciendo cosas muy interesantes, como usar libxml2 y libxlst dentro de KHTML.
- No sabía que uno de los delirios de Ali era hacer esto, ni tampoco me interesa. No hay ninguna relación entre esta iniciativa y GoneMe. De hecho esta iniciativa ni siquiera es "oficial" en modo alguno, sólo usamos el espacio cvs del proyecto GNOME.
- En la (¿improbable?) eventualidad de que esto llegue a algún sitio la idea es permitir que Epiphany use WebCore opcionalmente. Mozilla seguirá siendo, para bien o para mal, el backend por defecto en el futuro inmediato y a medio plazo.
--
Sirviendo al Comité Revolucionario Permanente de los Hombres Topo desde 2002.


No era KHTML (none / 0) (#22)
por raster a las Sun Sep 12th, 2004 at 10:22:29 PM CET
(Información Usuario)

Según recuerdo, la idea para GoneMe era usar GtkHTML, el renderizador original de gnome para las páginas de ayuda y demás.

[ Padre ]


Era KHTML (none / 0) (#23)
por jorginius ("jorginius" en Google Mail) a las Mon Sep 13th, 2004 at 06:43:50 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Puedes encontrar varias referencias en Google, pero la más directa es la propia declaración de intenciones del proyecto en GoneME. Cito:

Investigate using the KHTML engine in GNOME. A good idea is good regardless regardless of its source.

Esto es al margen del navegador Atlantis, basado en gtkhtml, que mencionó algarcia.

[ Padre ]


 
Una idea estupenda (none / 0) (#1)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Thu Sep 9th, 2004 at 09:59:46 AM CET
(Información Usuario) http://speedball.servemp3.com

Aunque ahora estoy en el curro, y por tanto usando iExplorer, uso habitualmente Galeon (en mi desktop) y Epiphany (en mi laptop). Normalmente estoy más que satisfecho con Gecko, pero algunas páginas excesibamente "exploristas" me veo obligado a usar el Konqueror y luego los consabidos "killall kdeinit;killall artsd" para evitar el colapso del sistema.

Por regla general, las páginas se ven mejor con Gecko que con KHTML, pero el problema es que a veces Gecko decide no hacer nada, y KHTML en cambio si que muestra la página, mal pero la muestra.

Por eso el poder usar un motor u otro según sea necesario, sin tener que cambiar de navegador (y siempre que pueda usar motores diferentes en pestañas diferentes de la misma ventana), me parece todo un acierto.

Ya sería cojonudo poder enseñar al navegador: poder decirle que las páginas de tal o cual sitio utilice un motor u otro.

Por cierto, no me convence ninguna de las opciones de la encuesta ;)

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


Usar varios motores en el mismo navegador (none / 0) (#2)
por jorginius ("jorginius" en Google Mail) a las Thu Sep 9th, 2004 at 10:44:22 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Por eso el poder usar un motor u otro según sea necesario, sin tener que cambiar de navegador (y siempre que pueda usar motores diferentes en pestañas diferentes de la misma ventana), me parece todo un acierto.

Sí, esa es una buena idea. En KDE, desde la 2.2, hay una prueba de concepto llamada KMozilla, incluida en los kdebindings, que permite precisamente poder elegir en cualquier momento a Gecko como componente de visualización empotrado de una página, aparte de los "Editor de texto empotrable" y KHTML habituales.

Es una opción potencialmente útil para un editor de páginas web (cómo se verá en tal o cual navegador lo tienes a un click de distancia) o para ver alguna página puñetera.

Pero, pero... No me cuadra que en Epiphany, navegador oficial de Gnome y conforme a Gnome HID, se incluya esa opción. Quiero decir: ¿una entrada de menú dónde te dé a elegir el motor de representación?, honestamente ¿no es eso demasiado complicado para el usuario al que está enfocado Gnome?.

IMO me parece una opción demasiado avanzada para una UI de Gnome. Een todo caso creo que la colocarían en el limbo de GConf, con lo que tendrías que modificar el registro y reiniciar el entorno para cambiar de motor: bastante peor que la solución de arrancar Konqueror ahora.

En realidad esto es especulación pura y dura porque no sé exactamente qué pretenden en Epiphany con KHTML. Quizás alguien que siga el desarrollo de Epiphany de cerca nos pueda iluminar. En el sitio oficial de Gnome y de Epiphany no lo mencionan. También he buscado en la lista de correo de Epiphany "khtml" con poco éxito. En Slashdot no ha salido la noticia (Mucho menos en Barrapunto) y Google no encuentra gran cosa.

[ Padre ]


¿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 ]


 
Puede ser.... (none / 0) (#4)
por nac a las Thu Sep 9th, 2004 at 12:36:16 PM CET
(Información Usuario)

Recuerdo que las razones explicadas por Apple para incorporar Khtml en Safari y no otros motores, era la sencillez de su código y su pequeño tamaño, su compatibilidad con las páginas diseñadas para explorer y su velocidad. Desde que Apple ayuda en el desarrollo de Khtml se nota mucho en su funcionamiento.

Puede que Khtml esté adelantando ya a Gecko y ese sea el mótivo de incluir a Khtml en GNOME. Al final de cuentas, Gecko tampoco es de GNOME.



 
Una cosa y análisis (none / 0) (#12)
por algarcia a las Fri Sep 10th, 2004 at 01:42:20 AM CET
(Información Usuario)

Una primera cosa, ahora casualmente no estoy usando Epiphany sino Firefox porque estoy usando XFCE4. Tengo aplicaciones Gtk, pero no tengo nada relacionado con Gnome, porque estoy probando a ver que tal me va sin él. Los motivos los digo aquí (principalmente es que tengo un equipo limitado y entonces Gnome y todas sus aplicaciones, bibliotecas y dependencias, le chupan muchos recursos).

Vamos a intentar analizar la situación.

Mozilla no sé porque me da en la nariz que no atiende adecuadamente al GtkMozEmbed (la solución de Gecko para Gtk/Gnome) por lo que dijo Xan en su día. No sé si os habeis parado a pensar lo estupido que es tener un navegador que necesita a otro para funcionar. Eso es lo que pasa con Epiphany y Galeon. Esto le está quitando mucho brillo a Epiphany yo creo. Firefox aunque no tan integrado con Gnome, se plantea una alternativa mejor a día de hoy, porque leñe, funciona él solito. Entonces quizás, la gente de Epiphany se hartó un poco de la situación, quien sabe, y quiere probar a terner otro as en la manga para asegurarse de que que su software puede desarrollarse con todo su potencial.

Mi opinión (que naturalmente no vale para nada) es que Mozilla si tanto quiere colaborar con Gnome debería apoyar más a Epiphany (ya lo dije, ¿extensiones de Epiphany a lo Firerefox?, ¿una interfaz de Epiphany que utilice un poco de XUL?, no sé, no soy un técnico) en lugar de intentar gnomificar el Firefox de GNU/Linux/*BSD/Unix, que con ello, aparte de que nunca llegará a integrarse con Gnome como un navegador pensado para Gnome como es lógico suponer, le hace la puñeta a la gente que no usa Gnome, por lo del orden de los botones de aceptar, cancelar, cancelar, aceptar. Pero esa es mi opinión (que como digo no vale para nada), y posiblemente la Fundación Mozilla tenga otra y sea conquistar escritorios de distros de GNU/Linux/*BSD/Unix con Firefox.

Si no, pues no sé me ocurre una explicación, porque Marco Presenti Gritti es un enamorado de Gecko, me parece. Incluso creo que a él le gustaría que se usase GtkMozEmbed en otras aplicaciones de Gnome en lugar de Gtkhtml.

El Ali tiene un navegador llamado Atlantis del que ya comenté algo.

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


Dios (none / 0) (#13)
por algarcia a las Fri Sep 10th, 2004 at 10:24:47 AM CET
(Información Usuario)

Yo haciendo análisis, y hay una aclaración en el primer comentario... Esto me pasa por responder con celeridad a la noticia...

Aunque yo me pregunto, ¿es Mozilla un proyecto con el que realmente merece la pena hacer que dependa una aplicación? Y no lo digo porque sean malas las tecnologías, pesadas, o complicadas de incrustar, sino por como lleva sus asuntos el tío Moz.

--
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 ]


 
Eso no ocurrirá en KDE.....¿o sí? (none / 0) (#19)
por melenas a las Sun Sep 12th, 2004 at 03:04:10 AM CET
(Información Usuario)

es nativo de KDE y sorprende que la gente detrás de Epiphany busque ahora "una segunda opinión" en la "competencia".

No tan extraño, ahora mismo me acabo de enterar que el motor de renderizado de Mozilla ha sido portado a KDE a través de una KPart, ¿podríamos verlo en KDE 3.4?, si fuera así sin duda alguna convertiría a Konqueror en el navegador más potente y versátil no sólo del software libre sino de todos los navegadores en general, pudiendo cambiar fácilmente de motor según funcione mejor con una página u otra, así que la decisión de los de Epiphany me parece más que acertada :-).


FDO. ER_MELENAS No te preguntes sólo que puede hacer el S.L. por ti sino también que puedes hacer tú por él.


Gecko ya era una KPart (none / 0) (#20)
por jorginius ("jorginius" en Google Mail) a las Sun Sep 12th, 2004 at 09:56:17 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Desde la versión 2.2 de KDE, aunque el código se cayó de kdebindings en el salto a la 3.2 por falta de mantenimiento.

La nuevo es que ya no se trata sólo de un wrapper KPart, que funcionaba con Gecko sin modificaciones, sino que han reescrito el motor para que use Qt nativamente. Antes Gecko era una especie de alien cuando lo empotrabas en Konqueror: manejo de cookies, de certificados, etc. todo lo hacía por su cuenta, duplicando funcionalidad que está en el KDE. Ahora se podrá integrar mucho más.

[ Padre ]


 
KHTML para Gnome | 23 comentarios (23 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:

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