A/A Tirwal y Jotas: ¿Código fuente?

[rfog]

Ya sabéis que inicié hace tiempo conversaciones con Juan de Grammata para ver si podía ayudar un poco en el tema del Papyre. Internamente me dio acceso a un SDK y lo instalé en una Ubuntu virtualizada, pero no pasé de ahí porque tuve un apretón de trabajo y luego se me quitaron las ganas...

Veo que vosotros estáis reempaquetando el firmware, y también veo que siguen quedando flecos debido a problemas del software empaquetado, que tiene bugs, o al menos eso es lo que leo entre líneas.

Yo nunca he querido meterme en temas de scripts, ficheros de configuración y demás, y de hecho si puedo, lo evito también en mi trabajo. Lo que a mi me mola es (aparte del análisis) codificar en C y sobre todo en C++. Para mi todo lo demás es paja y son cosas que me llevan a poder tirarme tiempo programando. Tampoco me mola estar grabando/trasteando/probando cosas que no tienen que ver con mi desarrollo (mi propio código sí que lo compruebo, y a nivel laboral sale de mis manos casi sin bugs si el tiempo lo permite). Me refiero a tener que empaquetar/flashear y todo eso.

Sí, ya sé que soy un señoritingo que no caga porque se ensucia el culo. :')

Entonces mi idea es ayudaros con esos problemas estrictamente hablando de software: bibliotecas que no lo hagan bien, programas con problemas. Pero no quiero jaleos de scripts ni de empaquetaciones, y si puede ser también debería contar con un emulador (que creo que trae el SDK). Incluso si esto llega a buen término volvería a comprarme un Papyre para probar las cosas. Mi código sería estrictamente Open Source, y aprovechable no sólo por nosotros, sino por cualquiera (es muy posible que lo publicara en mi blog, y seguro que se lo pasaría a Juan).

Podríamos empezar con algo facilito e ir subiendo las apuestas... Vosotros diréis. Si seguimos con esto podríamos crear una lista de correo pública/wiki (para que quien quiera pudiera leerla) para comunicarnos entre nosotros. Adelanto que yo no mantendría el wiki si no fuera para poner temas técnicos de mis desarrollos.

¿Habéis probado a integrar partes de OpenInkport? Si la respuesta es no, ¿por qué?

PS: Por favor, abstenerse en este hilo de comentarios sobre "molaría que hicieras esto" y similares. Ya sé que muchos estáis deseando solucionar esos problemas, etc, pero me gustaría mantener el hilo a un nivel estrictamente técnico y sin paja (y pediría a Katxan que borrara los posts off-topic).

[LARdT]

Para no contaminar el hilo abro otro con la Lista de los Reyes Magos. En mi blog recibo toos los dias una docena de ideas-peticiones para mejras, etc...

Mucha suerte con la iniciativa RFOG. Creo que Tirwal ha hecho un gran esfuerzo pero con los mimbres que tiene está casi llegando al límite. Asi que la idea de dessarrolar nuevo software en vez de rempaquetar el veijo me parece muy acertada. (aunque más costosa a lo mejor)

[Tirwal]

Hola:

Por mi parte no me importaría mejorar algunas cosas, pero conmigo no se puede contar para programar porque estoy mayor, y recordar el C++ y cómo compilar en linux,buffff. Si te quieres entretener, no me inmporta probar las cosas y comentar lo que he descubierto haciendo probatinas. Tampoco me importaría colocar ese conocimiento en algún sitio, porque como decía Jotas en un mensaje, te pasas todo el día buscando en Inet info que no exsiste, o que existió y desapareció.

Como punto de partida, estaría bien reparar la librería que se encarga de los LIT. En la versión que hay en los firm del último año, los chinos se olvidaron de los acentos y caracteres especiales. Si se utiliza un libro en inglés se ve de categoría (por eso ellos no se quejan). Si se utiliza un libro español, faltan todos los acentos. A continuación cuento mis ingagaciones después de contestar a tu última pregunata: OpenInkpot.

Bueno, en el firm original de Hanlin, los distintos visores de archivo en realidad son librerías dinámicas que se cuelgan sobre un programa genérico llamado viewer. Todas las librerías que manejan los distintos tipos de archivo se encuentran en un directorio, y tienen la terminación so. En el caso de OpenInkpot, por lo que he podido indagar, los programas para ver los tipos de archivo son programas independientes, que o bien se ejecutan sobre la librería, o bien se sale de la librería, se ejecuta el programa y luego se vuelve a la librería en la posición que ocupaba. OI no utiliza librerías dinámicas. Por ello quizá sólo lee 5 tipos de archivo fundamentalmente (PDF y los que lee el CoolReader o FBReader).

En mis indagaciones sobre los LIT, he descubierto que hay 2 librerías dinámicas que se encargan de ellos. Una se llama libopenlit.so, y otra liblit.so. La libopenlit tiene los códigos fuente por ahí, porque está basada en software libre. Creo que se pueden descargar desde la web de BeBook. Al echar un vistazo, parece como que en libopenlit se integre el clit (parser para pasar de LIT a XML). Creo recordar que en la versión clit 1.2 (en su día probé el clit 1.2 compilado para win y me dió algún que otro quebradero, sobre todo con los acentos). Animado por los fallos de la compilación de clit para win, estuve comprobando si era la culpable del lío de los acentos. Después de cambiar varias librerías, me dí cuenta de que no. El tema de los acentos lo controla la librería principal, y debe de ser alguna chorrada como una mala interpretación del XML salido de libopenlit, o alguna tontería como una conversión mal hecha de caracteres. Con versiones antiguas de liblit.so, aparecen los acentos pero después del acento pone un espacio, con lo que lo hace todo muy ilegible, aparte de que presenta la página de pena.

Otra de las cosas que fallan más que una escopeta de feria es el número de páginas que le pasa como valor la librería correspondiente al visor. Nunca se pone de acuerdo consigo misma acerca de cuántas páginas hay.

También sería interesante integrar el FBReader, por lo menos para ver correctamente los CHM. La última versión compilada en forma de librería dinámica que estado probando no es compatible con el visor actualmente integrado, aparte de que es la versión 0.8.6 y ahora el FBReader de OI ya va por la 0.10. Lo que he probado de los CHM da pena. El FBReader viejo los abre de pena, y lo que ganas por un lado respecto a la librería de Hanlin, lo pierdes por otro lado.

Bueno, pues estas son algunas de mis indagaciones, pero ahora tengo que poner una advertencia que siempre circula por los foros cuando hablamos de estas cosas ¿no debería hacerlo jinke/hanlin?. El esfuerzo es tremendo, y en teoría van a sacar una nueva versión con nuevo kernel, que ya he probado y es rapidísima (aunque según comentan es para el nuevo v3+, y lo que está haciendo buggins es intentar adapatarla al viejo).

La verdad, que aunque con el nuevo kernel se gane velocidad, si tuviésemos un sistema estable, aunque un poco más lento, y tuviese resueltas 4 ó 5 puñeteras cosas, estaría fenomenal.

Salu2

[LARdT]

TIRWAL: pero ahora tengo que poner una advertencia que siempre circula por los foros cuando hablamos de estas cosas ¿no debería hacerlo jinke/hanlin?.

Yo les pedí hace ya tiempo en su foro que arreglaran al menos el tema de los enlaces internos para ePUB en ADE, pues sigo sin entender que el programa madre en el PC lo haga y la implementación mobile no. Pero yo, NO SOY NADIE. ¿Y si coordinamos una iniciativa de usuarios para hacer una petición? Posiblemente, a través de GRAMMATA, entiendo.
El tema es que anunciar como funcionalidad del producto la lectura del formato LIT o CHM, por ejemplo, es casi un fraude en las condiciones del firmware oficial, por no decir otra cosa.

Lo que es de aurora boreal es que TIRWAL en 20 días haya sido capaz de lanzar un firmware con más funcionalidades que la media docena de OEMs en 2 años.

[LARdT]

Además creo que se me ha ocurrido como hacerlo:

- Se publicita la iniciativa. El personal que esté de acuerdo se registra dejando su dirección de correo.
- Cuando se tengan las muchicientasmil adhesiones que se quiera. Se envia a la lista de e-mails un correo
con:
- un PDF protegido en Español / Inglés con el texto de la petición
- las instrucciones: enviar un 1 Y SOLO 1 e-mail con el PDF adjunto a la direccion de correo de HANLIN/GRAMMATA o a quién se haga la petición con el RE: "Peticion .... / Petition ...." y por texto:
"Firmado Usuario numero_del_DEVICE_ID que figura en "Acerca de".
Así todo el mundo estaría identificado como usuario legítimo del PAPYRE sin temas de datos personales ni LOPDs, etc... y sería una comunicacion individual desde cada cliente al fabricante.

[PinkPanther]

Perdón si parece offtopic. Técnica no es mi respuesta, tal y como se pide en la entrada originaria.

Yo me apunto a lo de la lista, wiki o lo que sea.

Si escribo es más que nada para hablar de la política envuelta en esto. En otras ocasiones (en un desarrollo que hice para Wenlin y en un diccionario electrónico que hice para los chinos) la cosa se complicó.

Yo creo que hay unas premisas que no debemos olvidar: tanto Grammata como Jinke son empresas, que hacen esto para ganar dinero. Los usuarios que hacemos cosas en código libre, además de un poco locos, queremos mejorar nuestra experiencia como usuarios y, en ocasiones, establecemos sinergias interesantes con empresas. En otras ocasiones les ahorramos dinero.

Me vais a perdonar la intromisión en un tema técnico, a fin de cuentas esta es mi opinión, tal vez un poco comercial. Además, técnicamente, yo no creo estar ni al 1% de vuestro nivel. Si de verdad queréis hacer algo yo lo haría como los yanquis, de forma directa y enfocada a no trabajar gratis. ¿Yo qué haría?

- En primer lugar contactar a Grammata y a Jinke y hablarles de nuestras intenciones y que nos aclaren cúal es la relación actual entre ambas empresas y el futuro del proyecto.

- Dependiendo de sus respuestas, planear los pasos siguientes a dar.

- Si la respuesta de una u otra empresa es cooperativa, amable y con las ideas claras meterse a colaborar con ellos con condiciones. Entre las condiciones, por supuesto, pediría lectores gratis para los desarrolladores envueltos.

- Si las respuestas son poco satisfactorias hay dos caminos: comprar y fabricar nuestro propio lector (me ofrezco para crear una empresa a tal efecto y ocuparme de la parte de China) y meterle nuestro propio software o, bien, no desarrollar software gratis para una empresa china a la que ayudas a que se hagan más ricos con nuestro tiempo. Claro, también hay un tercer camino: que cada uno hace las cosas como le parece, de forma desordenada y cada uno a su aire, una forma muy española de trabajar.

No sé si mis opiniones se verán un poco agresivas y, como dije, perdón por lo poco técnico de mi respuesta.

[jotas]

Buenas,

Primeramente, ¿pero qué hace el refog por estos lares, y sacando la patita de sus dominios, el día UNO del AÑO NUEVO, y desde las DIEZ DE LA MAÑANA, lanzando órdagos? ¡Eso no es humano!

En segundo lugar, gracias por el ofrecimiento y la ayuda, de verdad. Al parecer el bicho que transmite y pica esto es más contagioso que la gripe A

En el resto de lugares, aunque insisto en que esto es inhumano , y desde mi condición actual pobre y penosa...


Para hacer o construir algo, es necesario mancharse las manos a todos los niveles. Desde el usuario final que no sabe, ni tiene por qué saber, qué lleva el cacharro dentro y cómo funciona, y vé y se queja de lo obvio, hasta el programador que modifica la escritura de un puntero en una linea que tira abajo el sistema. Sin embargo está muy bien tu declaración sobre gustos y usos, ideal casi para el caso que nos ocupa, la programación es la paja para otros (ejem), en cualquier lenguaje, la parte que resulta al final la misma, tediosa, repetitiva, aburrida y estresante; es más interesante, como lo llamo yo, hacer de analisto, identificar el problema, la solución, analizar el sistema, las partes a desarrollar o modificar, dónde cambirlas, cómo cambiarlas, cómo llegar a una solución válida, si resulta aceptable para el fin y humano último, etc. Lo de programar, bueno, si no hay más remedio o se le calientan a uno suficiente los casos, vale, un ratito; además [s:83713d7356]casi todos[/s:83713d7356], [s:83713d7356]la mayoría[/s:83713d7356], [s:83713d7356]muchos[/s:83713d7356], algunos programadores viven sólo en su burbuja virtual de código, y sólo se plantean y dan soluciones técnicas poco útiles o que no responden a la petición más básica del primero que toma en sus manos un chisme y ya pide y se queja de algo evidente. En la vida real y trabajos o proyectos idem, por desgracia no suelen darse este tipo de situaciones ideales, ni aisladas, ni blancas o negras totalmente.

Sobre la relación con [s:83713d7356]Grammata[/s:83713d7356] , la verdad es que no tenía idea o creo haber leído nada al respecto, y no me interesa mucho en ningún aspecto para el asunto que nos ocupa, sea esta o cualquier empresa. Sería llevar y convertir esto en algo en que no estamos, ni a lo que nunca hemos pretendido llegar ninguno, español o ruso (creo).

Código, especificaciones, desarrollo, documentación, módulos, etc. Pues, cómo ya te han indicado, por una parte no hay ningún problema, y por otra parte sólo está EL PROBLEMA. Este último es la no existencia de casi nada, near zero, y lo que existe está disperso, a retales, inconexo, mal organizado, etc. por todos (y pocos, sin embargo) lugares y obtenido por entusiastas a base de mucha investigación, tiempo, genialidad y trabajo personal; luego nos encontramos con algunos de los componentes más importantes, como el ADE y el Bookshelf, que parece son casi intocables hasta por los creadores, o de los que simplemente el fabricante/distribuidor no suelta el código fuente porque no le interesa y porque es lo único casi que desarrollan y les hace diferente del resto de clones. Y, con la otra parte y todo el resto, al revés, ningún problema, todo es código público, compilable a la primera, modificable, reusable, etc.

Supongo que el SDK que Jinke proporciona a los OEM/ODM y otros desarrolladores, bajo contrato, ciertas condiciones, restricciones, aceptación, y firma habituales, será posiblemente mucho más útil e incluirá alguna documentación más detallada y utilidades que el SDK accesible para los usuarios. Pero eso a su vez lo hará caer dentro de la influencia e intereses comerciales, algunas restricciones y desarrollos condicionados y no publicables.

Resumiendo, nos encontramos con tres frentes de batalla:

- Código y módulos totalmente comerciales, incluso de terceros, casi intratables, mayormente el ADE.
- Partes cerradas y sin código fuente ni documentación, por interés del fabricante o el revendedor, fundamentales para hacer
funcionar el sistema, y para realizar incluso cambios muy sencillos y de gran utilidad para los usuarios, como el Bookshelf.
- Partes de código libre, Linux, kernel, programas, librerías, fuentes, etc. Sin problema alguno. Wolf, Cool Reader, FBReader, DJVU, etc.


OpenInkpot Claro, el palabro Pero ya estas saltando algunos pasitos, el entretemiento y desafio necesario para conocer como funciona el sistema actual y cómo cambiarlo, etc. Déjenos usted llegar a esa fase, ahora estamos comenzando a calentar y jugar. De hecho, los chinos están ya 'tomando prestadas' montones de ideas y de código en el nuevo kernel y SDK que ha llegado para los Hanlin V3 y V5. Si lo miras bien y de forma muy simple, ¿qué es OpenInkpot? La base, la parte del sistema y un bookshelf propio que no te dan ni les interesa darte (y no es un trabajo pequeño ni trivial), sobre el que montas y lanzas el resto. Ahora bien, el 'resto' sólo pueden ser oficialmente partes libres y maleables, todo GPL, y de forma oficial, ni puede, ni debe, incluir ciertas cosas comerciales y tremendamente útiles, sólo quizá por canales extraoficiales, montajes caseros y moldeables (y aquí no me extiendo más y creo que usted entiende a la perfección dónde y cómo vamos). OpenInkpot ha resultado por otra parte un proyecto caótico, ahora parece por fin bastante bien encaminado, pero en el cual, y se trata por supuesto de opinión y valoración personal, se han obstinado en aplicar ciertas frikadas y ausencias en cosas tan básicas, que puede acabar por cuatro tontás en algo sólo utilizable por cuatro entendidos, los de Linux, y no mucho más. OI podría estar ya hace tiempo con versiones iniciales instalado, funcional, y siendo útil para muchos usuarios. Pero, OI también en insustituible, puesto que esta familia de productos va a llegar en breve al fin de su vida tanto hardware como software, soporte del fabricante, e inclusión de nuevos desarrollos y funciones (libres y comerciales). Complicado. Y si me lee alguien del proyecto OpenInkpot, no pretendo crear ni seguir en este hilo una polémica sobre dicho proyecto, para lo cual existen ya otros muchos lugares.


Según lo veo disponemos de los siguientes caminos:

1) Tomar lo ya existente, y tratar de trastearlo, entenderlo, adaptarlo, modificarlo y actualizarlo a nuestros gustos y posibilidades, que no es poco ni sencillo a veces. En ratos libres y por hobby, curiosidad, desafío, o afán de superación. En eso estamos. Por ejemplo, para tener un firmware al día, añadir unas librerías, o no esperar dos meses a que te saquen la versión para un idioma, el último ADE integrado, el último Cool Reader, arreglar cosas "no necesarias y sencillas" (observen las comillas) como el silabeo, y similares.

2) Trabajar por cuenta ajena o dependiente de alguien con intereses comerciales, con desarrollos y condiciones posiblemente limitadas, para su beneficio. ¿Convertirlo en una obligación? ¿Y si es ya además gratis? Tsk, tsk...

3) Trabajar en las utilidades y apartados de código libre accesibles. Aquí se puede hacer una gran aportación. Y sin extras, condiciones, sistemas o trabajo extra a montar, etc. Por ejemplo, Buggins se traga el sólito todo lo que tenga que ver con el Cool Reader, allí hay montón de mejoras y cambios que se pueden hacer, incluso para ideas o necesidades que él no ve interesantes o urgentes. Desde integrar un silabeo decente, aumentar el número y posibilidades del interface
de usuario, el tamaño de las fuentes o su definición, los formatos soportados y su funcionamiento (txt rtf fb2 *epub*), etc. Idem con FBReader y otras utilidades. Cambios y aportaciones automáticas a SourceForge. Si no gustan o no se integran, se compila uno mismo un nuevo Cool Reader con lo que más le gusta a uno o puede solicitarse.

4) Trabajo en OpenInkpot, abierto. Si se estima conveniente, necesario, al gusto, y se está de acuerdo con la forma e ideas en que se sigue y se va convirtiendo el proyecto.


Y después de esta larga, inesperada, y muy esforzada charla en día tan señalado como el presente, me permitan retirarme a mis aposentos hasta... uhmmm ... buf!!

[rfog]

Bueno, voy a intentar responder...

Lardt, como ya ha dicho Jotas, de tocar cosas privadas ni soñarlo. Ni yo creo estar capacitado para desensamblar un ADE ni creo que tuviera ganas de hacerlo, y tampoco creo que a Adobe le gustara y/o me dejara.

Respecto a las peticiones a los fabricantes, por mi OK.

Pink, básicamente y en mi tónica personal: tu estás soñando. No lo interpretes mal. En primer lugar oficialmente no puedo hacer eso. Tendría que pedir permiso a mi empresa, y seguro que me lo negarían. En segundo lugar: tu no sabes lo que es eso: crear un firm desde cero. Además, en el hipotético caso de que yo participara en ello, olvidaros de Linux y acercaros a Windows CE: ahí sí que puedo ser efectivo.

Por cierto, Jinke, como chinos que son, iban a pasar olímpicamente de nosotros, y Grammata ya me cedió el SDK para que yo hiciera cosas.

[rfog]

Ahora lo que nos interesa.

Jotas, tenemos que ponernos un objetivo. Me mola lo que dices, pero hay que tomar un camino. Realmente me da igual hacer un branch de OpenInkport (bueno, lo haríais vosotros, yo sólo programaría los cambios) o seguir con el tema del SDK de Jinke. Lo que no podemos hacer es ir a salto de mata: ahora uno ahora otro y luego lo de más allá, como han estado haciendo los de OI. Hay que elegir un camino y seguirlo hasta el final.

"Sobre la relación con Grammata , la verdad es que no tenía idea o creo haber leído nada al respecto, y no me interesa mucho en ningún aspecto para el asunto que nos ocupa, sea esta o cualquier empresa. Sería llevar y convertir esto en algo en que no estamos, ni a lo que nunca hemos pretendido llegar ninguno, español o ruso (creo)."

No me malinterpretes con eso, aunque una cosa sí que tengo clara: mi aportación será opensource aunque fuera el parche a un soft privativo y si no aceptamos opensource aquí terminamos el tema.

Entiendo tu postura en lo de mancharse las manos, pero si lo hago yo todo no os necesito, ¿no? Como yo sé programar, y me gano las habas haciéndolo, y encima en cosas parecidas a todo esto, y a vosotros os cuesta, creo que es la solución óptima.

Respecto al tema de la documentación, tampoco estoy pidiendo nada formal, faltaría más. Como ejemplo la petición de Tirwal: las bibliotecas del LIT: buscar qué pasa y corregirlo: vosotros me apuntáis al sitio, me pasáis la forma de integrar/verificar/emular el tema y yo me pongo al asunto.

Si hay algo privativo quizás pudiéramos sustituirlo por algo opensource, es una opción. Lo que creo no es opción es hacerse un programa completo estilo visor ePUB..., o al menos sería como los trabajos de hércules, aunque tampoco le haría muchos ascos, pero no esperéis que esté en quince días.

El primer paso es decidir qué voy a tocar. Y luego que alguien me ponga en descarga su "kit" (y de paso lo comparo con el de Grammata, y si son diferentes y lo vemos bien le pedimos permiso a Juan para que uséis el mío).

[LARdT]

Esto se ha convertido en un OFF TOPIC total (perdón por la parte que me toca RFOG) pero sin embargo muy interesante.

Sin ánimo de nada más y sólo por diversión os quiero contar mis "sospechas" de conspiranoico a ver que os parecen:

A mi este producto y este mercado en general, siempre ma ha parecido un poco disfuncional y raro; sobre todo comparado por donde han ido los tiros con otros productos y tecnologías cuando han entrado en el gran consumo para el entretenimiento.
- Por un lado, hay una tecnología de vanguardia y se supone de mucho futuro (e-ink)
- Que está dando soporte a una demanda de entreteniento como la LECTURA (puede ser algo superior a los viodeojuegos, no tiene frontera de edades, ....)
- Y luego van y lo meten en una cajaplastico negra de diseño tipicamente chino (pero de cuando la revolución cultural) y lo aderezan con un mix de desarrollos opensource (la mayoria de ellos en si mismos de mucho merito y calidad) pero pegados unos con otros con celo.

Todo tiene un tufo a baja tecnologia raro. Y el asunto es que no hay ningun interes en el trapaso y desarrollo de tecnologia porque:

- Por un lado, los chinos cuando menos den, mejor para ellos.
- Por otro los OEM, parece que su estrategia es "coge el dinero y corre"; lo que me el Chino lo coloco tal cual, a ver si vendo varios cientos de miles de unidades; y aquí paz y después gloria, que dentro de 2 años ya venderé batidoras o lo que sea.

Y sobre lo de ir a hablar con los Chinos, pinkPanter, no te creas que no se me ha pasado por la cabeza. Pero JOTAS tiene razón en decir que, aunque puedan seguir vendiendolo durante 3 años más, (que lo intentarán) este PAPY...LIN es un producto perro en fin de ciclo.
Y utilizo perro en sentido técnico (vaca, estrella, perro e incognita).

Y me mola que JOTAS tacha [s:b91cbf971e]GRAMMATA[/s:b91cbf971e] como si fuera un taco. Tiene razón con perdón.

Si TIRWAL tuviera un pocketbook en lugar de un PAPYRE por lo menos ya hubiera ganado uno gratis (ver concurso de desarrollo para PocketBook)