Tema: Reinventando la rueda

Soy nuevo en este portal y si me lo permitís quisiera dar os mi opinión sobre perfectRaw. De antemano deciros que soy un defensor del software libre desde hace años, desarrollador y creo que conozco un poco el tema de los "reveladores",etc.

En primer lugar felicitaros por tener ganas de pelearos en esto de hacer un soft para el revelado de fotos. No creo que lo estéis planteando bien, pero es muy opinión y puedo estar muy equivocado. Me sabe mal haberme enterado de todo esto ahora y no en mayo cuando salió. He leído casi todos los mensajes sobre el soft. Realmente odio el formato forum, prefiero el mensaje de correo, pero eso es otra historia.

En cuanto al soft y lo que hagáis con el es asunto vuestro, de los desarrolladores, pero yo creo bastante en la filosofíadel soft libre y creo que sacarías más benefício si lo liberarais con una licencia tipo GPL.

Entiendo perfectamente que si la mayoría de desarrolladores utilizan windows, pues que la plataforma de desarrollo sea windows. Pero, ahora bien, pensar que si lo queréis multiplataforma, las herramientas que lo componen también lo han de ser. Si no, os limitáis a esa plataforma.

No sé que tiene de valor el dng sdk de adobe. Yo no soy un fan del dng. dcraw los abre, y a partir de allá a jugar.

Yo creo que dentro del soft libre hay bibliotecas muy buenas para manipular y gestionar fotografías, pero siempre tengo la sensación de que los windoseros les teneis un poco de manía. Pero, pensar que gracias a dcraw la mayoria de programas (libres y algunos comerciales) pueden decodificar nuestras fotos en raw.

Es buena idea lo de hacer un dcraw en bibliteca. Todos lo han acabado haciendo. Ese es uno de los motivos de libraw y tambien de libopenraw y libkdcraw. Me sabe mal que volváis a hacer el mismo trabajo que ya han hecho otros.

Yo no soy partidario de C#, monos, javas etc. Creo que es mucho más eficiente un lenguaje que compilas y generas un binario que ejecutas. No medias tintas, de byte codes, etc, aunque entiendo la filosofia. Pero es una filosofia que tiene exito en soft comercial, no en soft libre, IMHO.

Yo os recomendaria QT. Es una libreria que para hacer ventanas, menus, etc va muy bien. Además ya tiene todo el tema de gráficos de 32, 48, etc bits implementado. Es multiplataforma y funciona de maravilla.

Como sistema de construcción os recomiendo cmake. Todo el entorno de kde ha migrado a cmake y estan todos encantados. Es una maravilla tener un único código y con cmake generar el projecto de vs, o los makefiles de Unix o el xcode de mac.

Bueno, ya he dicho la mía. Espero que no os sepa mal.

Por cierto, la semana que viene, el Dave Coffin, autor del Dcraw está en Barcelona en las Jornades de Programari lliure (http://www.jornadespl.org)

Te contesto por partes:

[quote=lepalom;2221306]Soy nuevo en este portal y si me lo permitís quisiera dar os mi opinión sobre perfectRaw. De antemano deciros que soy un defensor del software libre desde hace años, desarrollador y creo que conozco un poco el tema de los "reveladores",etc.
[quote]
Pues tú y tu opinión sois bienvenidos.

Iniciado por lepalom

En primer lugar felicitaros por tener ganas de pelearos en esto de hacer un soft para el revelado de fotos. No creo que lo estéis planteando bien, pero es muy opinión y puedo estar muy equivocado. Me sabe mal haberme enterado de todo esto ahora y no en mayo cuando salió. He leído casi todos los mensajes sobre el soft. Realmente odio el formato forum, prefiero el mensaje de correo, pero eso es otra historia.

Ten en cuenta que nuestro planteamiento sólo pretende en principio satisfacernos a nosotros mismos, eso sí con la esperanza de que otros también lo encuentren útil. Respecto al método de comunicarnos, si queríamos que quedara constancia de lo que vamos hablando y que pudiera participar y opinar todo el mundo, el formato mensaje de correo no nos habría sido útil. Los que estamos más involucrados en el proyecto también nos comunicamos por mensajes privados, correos electrónicos, messenger y hemos quedado en persona en alguna ocasión.

Iniciado por lepalom

En cuanto al soft y lo que hagáis con el es asunto vuestro, de los desarrolladores, pero yo creo bastante en la filosofíadel soft libre y creo que sacarías más benefício si lo liberarais con una licencia tipo GPL.

El objetivo de perfectRAW no es sacar dinero, en el futuro ya veremos.

Iniciado por lepalom

Entiendo perfectamente que si la mayoría de desarrolladores utilizan windows, pues que la plataforma de desarrollo sea windows. Pero, ahora bien, pensar que si lo queréis multiplataforma, las herramientas que lo componen también lo han de ser. Si no, os limitáis a esa plataforma.

Hemos discutido bastante al respecto, la elección actual nos garantiza la portabilidad, con algo de trabajo que tendrá que hace alguien que trabaje en otras plataformas. No es un objetivo del proyecto hacerlo multiplataforma, pero sí es un objetivo no limitar la portabilidad. Es un compromiso entre lo que podemos hacer ahora y lo que nos gustaría que fuera el proyecto en el futuro.

Iniciado por lepalom

No sé que tiene de valor el dng sdk de adobe. Yo no soy un fan del dng. dcraw los abre, y a partir de allá a jugar.

El tema de los DNGs es sobre todo para perfectBLEND, el (esperamos) siguiente producto. La idea es hacer lo mismo que hace ahora ZeroNoise (bueno más sofisticado en realidad) pero en RAW. El resultado sería un .dng que podría revelar en el programa que tú quisieras, por ejemplo, en perfectRAW .

Iniciado por lepalom

Yo creo que dentro del soft libre hay bibliotecas muy buenas para manipular y gestionar fotografías, pero siempre tengo la sensación de que los windoseros les teneis un poco de manía. Pero, pensar que gracias a dcraw la mayoria de programas (libres y algunos comerciales) pueden decodificar nuestras fotos en raw.

Hemos considerado varias opciones. Utilizamos LCMS para la gestión de color, que es una librería del mundo linux, así que como ves no es una cuestión de manías .

Iniciado por lepalom

Es buena idea lo de hacer un dcraw en bibliteca. Todos lo han acabado haciendo. Ese es uno de los motivos de libraw y tambien de libopenraw y libkdcraw. Me sabe mal que volváis a hacer el mismo trabajo que ya han hecho otros.

No te preocupes, no estamos volviendo a hacer el mismo trabajo que ya han hecho otros, lo hacemos diferente. Todas esas librerías tienen distintas filosofías que las hace no adecuadas para nuestro proyecto, aunque perfectamente válidas para otros proyectos. De hecho te diría que están todas mejor hechas y pensadas que nuestra dcraw.dll sin duda alguna. Sin embargo, nosotros hemos apostado por: primero, no modificar el código original de Coffin a la hora de convertirlo en una DLL y segundo, revelar siempre la imagen completa y poder volver a revelar desde un punto intermerdio del revelado. Lo que conseguimos con estas opciones es garantizar que soportaremos las mismas cámaras que la última versión de Coffin el mismo día que él libere una nueva versión, sin tener que adaptar nuestro código, y ofrecer en la pantalla una versión con idéntica calidad a la que se obtendrá al grabar el TIFF pero revelando lo más rápido posible, aunque asumiendo que siempre será más lento que revelar sólo el trozo de la imagen que está en pantalla. Consideramos que algunos algoritmos actuales que se aplican a la imagen (y algunos que podamos diseñar en el futuro) necesitan trabajar sobre la imagen completa para dar toda la calidad. Como ves, son filosofías distintas, no creo que mejores ni peores. En cualquier caso, no perdemos nada al implementar perfectRAW a nuestro modo, pues ya hay muchos reveladores con la otra filosofía, ¿no crees?

Iniciado por lepalom

Yo no soy partidario de C#, monos, javas etc. Creo que es mucho más eficiente un lenguaje que compilas y generas un binario que ejecutas. No medias tintas, de byte codes, etc, aunque entiendo la filosofia. Pero es una filosofia que tiene exito en soft comercial, no en soft libre, IMHO.

Bueno, sobre eso evidentemente podríamos discutir mucho. Yo tampoco soy un fanático del código interpretado/compilado en tiempo de ejecución. De hecho, las limitaciones de velocidad de .NET nos han obligado a implementar más código C del que esperábamos al principio. Si te fijas en el diseño del proyecto, en C# sólo se ha desarrollado la parte de interfaz y el código que requiere velocidad en C. He programado en muchísimas plataformas, entornos y lenguages y desde el punto de vista de la productividad, C# me parece de lo mejor. Desde el punto de vista de la velocidad de ejecución pogramaríamos todo en ensamblador (espero tener algún día un rato tranquilo y pasar algunas partes del código). Creo que la elección actual es un buen compromiso entre productividad y velocidad, aunque obviamente había otras opciones. También creo que hemos desarrollado lo que llevamos en un tiempo bastante corto y funciona, así que no debemos haber elegido demasiado mal .

Iniciado por lepalom

Yo os recomendaria QT. Es una libreria que para hacer ventanas, menus, etc va muy bien. Además ya tiene todo el tema de gráficos de 32, 48, etc bits implementado. Es multiplataforma y funciona de maravilla. [...]

Lo tendremos en cuenta, muchas gracias. Cuando pueda le echaré un vistazo, pero como dejemos de lado el C# será culpa tuya y tendrás que pagarle a GUI el libro de C# que sea ha comprado .

Iniciado por lepalom

Bueno, ya he dicho la mía. Espero que no os sepa mal.

En absoluto, aunque es cierto que ahora ya es tarde para hacer cambios tan trascendentales en el proyecto, pero quién sabe más adelante.

Iniciado por lepalom

Por cierto, la semana que viene, el Dave Coffin, autor del Dcraw está en Barcelona en las Jornades de Programari lliure (http://www.jornadespl.org)

Sí, creo que GUI iba a intentar quedar con él.

Un saludo:

Gracias lepalom por tus comentarios.
En cuanto a lo de implementar en C# u otro código interpretado ya te lo ha comentado Manuel.
¿Has probado a crear una interface gráfica en C++? Yo sí, antes de aparecer C# y es un verdadero lío y muy dado a errores.
Mi primera interface gráfica fue en OS/2 en C (una especie de precursor del windows) y no te digo el lio que era pelearse con los mensajes de windows y liberar memoria, etc.

C# (o java o visualbasic) permiten desarrollar la interface de manera más robusta y en una fracción del tiempo de lo que se tardaría en un lenguaje tipo C o C++.
Los algoritmos más básicos que se pelean con los pixels, están implementados en C.

De todos los lenguajes con máquina virtual C# es el más robusto (en mi opinión) y elegante.
En cuanto a kde u otros sistemas, no le veo la ventaja, su sistema de ventanas no me parece superior a las de .NET.
Mono consigue la portabilidad del sistema .NET por lo que ese tema estaría resuelto (otra cosa es que alguien tendrá que probarlo en linux y MaC, ya que nosostros no lo utilizamos).
El mismo problema lo tendríamos si usáramos cualquier otro compilador y sólo lo probáramos en windows: habría que probarlo en todos los sistemas para asegurar su funcionamiento.

Como ya dije en su día y como ya se ha dicho, la portabilidad a Linux o Mac es algo deseable pero ni es un requisito, ni vamos a dedicarle tiempo que podríamos invertir en mejorar el programa para Windows.

Por otro lado no sería lógico teniendo en cuenta que los tres tenemos Windows y lo que queremos es un programa que funcione para usarlo nosotros. Con nuestros requisitos particulares, como las opciones para Oly que ha implementado Manuel, los ajustes automáticos que quiere Fernando y mis peticiones sobre el display, zoom y altas luces.

¿Tenéis un Mono trabajando para vosotros?, Joer, que nivelazo.
Estoy siguiendo el nacimiento el programilla con expectación.

Iniciado por ManuelLlorens

Pues tú y tu opinión sois bienvenidos.

Muchísimas grácias.

Iniciado por ManuelLlorens

Ten en cuenta que nuestro planteamiento sólo pretende en principio satisfacernos a nosotros mismos, eso sí con la esperanza de que otros también lo encuentren útil.

Ok, pero solo tengo la impresión que on centráis mucho en windows, pero os lo respeto. És el de la mayoria... :-(

Iniciado por ManuelLlorens

Respecto al método de comunicarnos, si queríamos que quedara constancia de lo que vamos hablando y que pudiera participar y opinar todo el mundo, el formato mensaje de correo no nos habría sido útil. Los que estamos más involucrados en el proyecto también nos comunicamos por mensajes privados, correos electrónicos, messenger y hemos quedado en persona en alguna ocasión.

Disculpa, es mi reniego habitual al los foros. No me gustan nada y me crispo bastante escribiendo en un mavegoador como lo hago ahora. ..

Iniciado por ManuelLlorens

El objetivo de perfectRAW no es sacar dinero, en el futuro ya veremos.

Eps, no me malinterpretes. Beneficio no significa exclusivamente dinero para mi: puede significar colaboraciones, ayuda, comunidad, usuarios, etc. Me referia a eso.

Iniciado por ManuelLlorens

Hemos discutido bastante al respecto, la elección actual nos garantiza la portabilidad, con algo de trabajo que tendrá que hace alguien que trabaje en otras plataformas. No es un objetivo del proyecto hacerlo multiplataforma, pero sí es un objetivo no limitar la portabilidad. Es un compromiso entre lo que podemos hacer ahora y lo que nos gustaría que fuera el proyecto en el futuro.

Os lo respeto. Pero por favor, pensar en la portabilidad. Si es exclusivo para windows yo no puedo hacer nada, si funciona en linux, me arremango y me pongo a colaborar. ...

Iniciado por ManuelLlorens

El tema de los DNGs es sobre todo para perfectBLEND, el (esperamos) siguiente producto. La idea es hacer lo mismo que hace ahora ZeroNoise (bueno más sofisticado en realidad) pero en RAW. El resultado sería un .dng que podría revelar en el programa que tú quisieras, por ejemplo, en perfectRAW .

no lo pillo .... puede que lo hayas explicado però no sé que hace el perpertBlend ... sorry.

Iniciado por ManuelLlorens

Hemos considerado varias opciones. Utilizamos LCMS para la gestión de color, que es una librería del mundo linux, así que como ves no es una cuestión de manías .

Lo sé, i me sabe mal haber me enterado tarde de todo esto. Si hace un par de meses lo hubiese sabido "quizás" podria haber influido ...

Iniciado por ManuelLlorens

No te preocupes, no estamos volviendo a hacer el mismo trabajo que ya han hecho otros, lo hacemos diferente. Todas esas librerías tienen distintas filosofías que las hace no adecuadas para nuestro proyecto, aunque perfectamente válidas para otros proyectos. De hecho te diría
......

ok lo de la libraria. Yo tengo mi particular version sobre como hacer todo esto, pero entiendo todo lo que dices de la libreria. Y, si, por supuesto, no creo que lo esteis haciendo mal del todo... yo habria hecho otro enfoque, pero ok.

Iniciado por ManuelLlorens

Lo tendremos en cuenta, muchas gracias. Cuando pueda le echaré un vistazo, pero como dejemos de lado el C# será culpa tuya y tendrás que pagarle a GUI el libro de C# que sea ha comprado .

Iniciado por ManuelLlorens

Sí, creo que GUI iba a intentar quedar con él.

llevo tres dias con él. Es muy majo.


Leo
_________________________________

Iniciado por ariznaf

Gracias lepalom por tus comentarios.
En cuanto a lo de implementar en C# u otro código interpretado ya te lo ha comentado Manuel.
¿Has probado a crear una interface gráfica en C++? Yo sí, antes de aparecer C# y es un verdadero lío y muy dado a errores.
Mi primera interface gráfica fue en OS/2 en C (una especie de precursor del windows) y no te digo el lio que era pelearse con los mensajes de windows y liberar memoria, etc.

No gracias a vosotros. El colega mio que me apuntó sobre el foro, cuando vio mi mensaje me dijo: chaval, como te pasas!!!
Es que los linuxeros (y yo muchas veces ...) somos un poco "destroyers" por que que muchas gracias por vuestros comentarios.

Si, si que he hecho GUI en C++, con Qt. Y no es tanto lio. Entiendo que si vienes del mundo windows tengas tantos problemas y pesadillas. Y si, és cierto, la mayoria de los programas fallan por la gestión de memoria. Pero los garbage collectors, no sé. ...

Iniciado por ariznaf

C# (o java o visualbasic) permiten desarrollar la interface de manera más robusta y en una fracción del tiempo de lo que se tardaría en un lenguaje tipo C o C++.

No tengo acciones de Nokia, de verdad, pero QT ...

Iniciado por ariznaf

En cuanto a kde u otros sistemas, no le veo la ventaja, su sistema de ventanas no me parece superior a las de .NET.
Mono consigue la portabilidad del sistema .NET por lo que ese tema estaría resuelto (otra cosa es que alguien tendrá que probarlo en linux y MaC, ya que nosostros no lo utilizamos).
El mismo problema lo tendríamos si usáramos cualquier otro compilador y sólo lo probáramos en windows: habría que probarlo en todos los sistemas para asegurar su funcionamiento.

cierto, lo del kde no lo he entendido. A que te refieres?
_________________________________

Iniciado por ariznaf

Gracias lepalom por tus comentarios.
En cuanto a lo de implementar en C# u otro código interpretado ya te lo ha comentado Manuel.
¿Has probado a crear una interface gráfica en C++? Yo sí, antes de aparecer C# y es un verdadero lío y muy dado a errores.
Mi primera interface gráfica fue en OS/2 en C (una especie de precursor del windows) y no te digo el lio que era pelearse con los mensajes de windows y liberar memoria, etc.

No gracias a vosotros. El colega mio que me apuntó sobre el foro, cuando vio mi mensaje me dijo: chaval, como te pasas!!!
Es que los linuxeros (y yo muchas veces ...) somos un poco "destroyers" por que que muchas gracias por vuestros comentarios.

Si, si que he hecho GUI en C++, con Qt. Y no es tanto lio. Entiendo que si vienes del mundo windows tengas tantos problemas y pesadillas. Y si, és cierto, la mayoria de los programas fallan por la gestión de memoria. Pero los garbage collectors, no sé. ...

Iniciado por ariznaf

C# (o java o visualbasic) permiten desarrollar la interface de manera más robusta y en una fracción del tiempo de lo que se tardaría en un lenguaje tipo C o C++.

No tengo acciones de Nokia, de verdad, pero QT ...

Iniciado por ariznaf

En cuanto a kde u otros sistemas, no le veo la ventaja, su sistema de ventanas no me parece superior a las de .NET.
Mono consigue la portabilidad del sistema .NET por lo que ese tema estaría resuelto (otra cosa es que alguien tendrá que probarlo en linux y MaC, ya que nosostros no lo utilizamos).
El mismo problema lo tendríamos si usáramos cualquier otro compilador y sólo lo probáramos en windows: habría que probarlo en todos los sistemas para asegurar su funcionamiento.

cierto, lo del kde no lo he entendido. A que te refieres?
_________________________________

Iniciado por _GUI_

Como ya dije en su día y como ya se ha dicho, la portabilidad a Linux o Mac es algo deseable pero ni es un requisito, ni vamos a dedicarle tiempo que podríamos invertir en mejorar el programa para Windows.

Ok, no sé como intentar hacer os ver otro punto de vista ... pero os respento.

Iniciado por _GUI_

Por otro lado no sería lógico teniendo en cuenta que los tres tenemos Windows y lo que queremos es un programa que funcione para usarlo nosotros. Con nuestros requisitos particulares, como las opciones para Oly que ha implementado Manuel, los ajustes automáticos que quiere Fernando y mis peticiones sobre el display, zoom y altas luces.

Ok, lo de las ompicos de Oly, a que te refieres? Algo nuevo para dcraw?

Iniciado por lepalom

Ok, pero solo tengo la impresión que on centráis mucho en windows, pero os lo respeto. És el de la mayoria... :-(

No lo están haciendo en Windows porque sea el de la mayoría.

Lo hacen porque los tres que lo están haciendo sólo lo necesitan en Windows para usarlo ellos mismos.

Iniciado por lepalom

Os lo respeto. Pero por favor, pensar en la portabilidad. Si es exclusivo para windows yo no puedo hacer nada, si funciona en linux, me arremango y me pongo a colaborar. ...

Puede que me equivoque pero, para hacerlo funcionar en Linux, sólo tienes que compilar la librería para Linux y desarrollar tú mismo una interfaz gráfica.

Creo que no tienes porqué esperar a que lo hagan otros. Lo puedes hacer tú mismo, ¿no?

El usuario PerroVerde estaba mirando a ver si podía hacer algo.

Supongo que mientras no modifiquéis las librerías, podéis hacer una interfaz para Linux en paralelo a la de Windows, ¿no? ¿O me equivoco mucho?

Daniel

A ver, efectivamente, los que lo desarrollamos trabajamos los tres en windows y no tenemos linux ni mac instalado.

De todas formas estamos teniendo cuidado de que sea portable.
No lo estamos desarrollando en windows, sino en .NET y en C, lo cuál no es exactamente lo mismo.

Hay una versión de .NET para linux llamada Mono.
Mono es la librería de .NET desarrollada a partir de las especificaciones de MS como código libre y que funciona en linux, windows y Mac (aunque esto no lo he probado).

Estamos teniendo cuidado de utilizar controles y funciones de .NET que ya estén implementadas en Mono, por lo que no debería de haber problemas para su portabilidad.

Por tanto no hay que desarrollar nada nuevo, ni interface gráfica ni algoritmos. Es suficiente con recompilar el código con las herramientas de linux y quizás hacer pequeños ajustes.
Así que quien quiera probar a compilarlo para linux (y tenga algo de experiencia en ell), será bienvenido.
Como compilador de C servirá el mismo que se ha utilizado en el proyecto (que también lo hay en linux) y para el C# está el MonoDevelop y el SharDevelop.
Así que ya sabes, si quieres colaborar en ello, sólo tienes que ponerte...
Gracias

Iniciado por dgmaga

No lo están haciendo en Windows porque sea el de la mayoría.

Lo hacen porque los tres que lo están haciendo sólo lo necesitan en Windows para usarlo ellos mismos.

Claro hombre. Quizás debería haber sido más fino y haber puesto que lo hacen "para/ o por / o hacia " plataforma windows, quiero decir. Que cada uno desarrolle con lo que crea más oportuno.

Iniciado por dgmaga

Puede que me equivoque pero, para hacerlo funcionar en Linux, sólo tienes que compilar la librería para Linux y desarrollar tú mismo una interfaz gráfica.

Creo que no tienes porqué esperar a que lo hagan otros. Lo puedes hacer tú mismo, ¿no?

bueno, no es tan fácil. Yo creo en la idea de aprovechar el código y que el trabajo hecho sirva para una mayoría de gente. Es un trabajo de muchas, muchas, muchas .... horas.

Y no, yo no espero que lo hagan los otros :-)

Iniciado por dgmaga

El usuario PerroVerde estaba mirando a ver si podía hacer algo.

Supongo que mientras no modifiquéis las librerías, podéis hacer una interfaz para Linux en paralelo a la de Windows, ¿no? ¿O me equivoco mucho?

si, de bastante, pero no pasa nada. En general, en un proyecto de estas características el 75% de código es el gui, por lo que la gracia é compartir *ese* 75%.
_________________________________

Iniciado por dgmaga

No lo están haciendo en Windows porque sea el de la mayoría.

Lo hacen porque los tres que lo están haciendo sólo lo necesitan en Windows para usarlo ellos mismos.

Claro hombre. Quizás debería haber sido más fino y haber puesto que lo hacen "para/ o por / o hacia " plataforma windows, quiero decir. Que cada uno desarrolle con lo que crea más oportuno.

Iniciado por dgmaga

Puede que me equivoque pero, para hacerlo funcionar en Linux, sólo tienes que compilar la librería para Linux y desarrollar tú mismo una interfaz gráfica.

Creo que no tienes porqué esperar a que lo hagan otros. Lo puedes hacer tú mismo, ¿no?

bueno, no es tan fácil. Yo creo en la idea de aprovechar el código y que el trabajo hecho sirva para una mayoría de gente. Es un trabajo de muchas, muchas, muchas .... horas.

Y no, yo no espero que lo hagan los otros :-)

Iniciado por dgmaga

El usuario PerroVerde estaba mirando a ver si podía hacer algo.

Supongo que mientras no modifiquéis las librerías, podéis hacer una interfaz para Linux en paralelo a la de Windows, ¿no? ¿O me equivoco mucho?

si, de bastante, pero no pasa nada. En general, en un proyecto de estas características el 75% de código es el gui, por lo que la gracia es compartir *ese* 75%.

Iniciado por lepalom

si, de bastante, pero no pasa nada. En general, en un proyecto de estas características el 75% de código es el gui, por lo que la gracia es compartir *ese* 75%.

Vale, entiendo. No sé qué porcentaje de código está en la DLL y cuándo en el GUI.

Esperaba animarte a que hicieras una versión para Linux...

Supongo que habrás visto el mensaje de Arinaz, que explica mucho mejor que yo como está lo de la portabilidad.

La cosa es que habrá versión para Linux en la medida que haya alguien a quien le interese usar el programa en Linux y esté dispuesto a portar el código aprovechando lo que se pueda.

Mientras no exista ese interés ni esa disposición para hacerlo, veo que difícil que se haga...

Daniel

Iniciado por dgmaga

Vale, entiendo. No sé qué porcentaje de código está en la DLL y cuándo en el GUI.

Esperaba animarte a que hicieras una versión para Linux...

Supongo que habrás visto el mensaje de Arinaz, que explica mucho mejor que yo como está lo de la portabilidad.

La cosa es que habrá versión para Linux en la medida que haya alguien a quien le interese usar el programa en Linux y esté dispuesto a portar el código aprovechando lo que se pueda.

Mientras no exista ese interés ni esa disposición para hacerlo, veo que difícil que se haga...

Daniel

No dgmaga, ni siquiera habrá que portar nada.
En un principio debería de funcionar tal cuál está, sin tocar nada.
Simplemente recompilando y creando el proyecto de compilación para el compilador utilizado (CSharpDevelop o MonoDevelop).

Claro que eso es en teoría, siempre puede aparecer algún escollo puntual o alguna función no implementada en Mono.
Una vez detectado un problema de ese tipo, nosotros podríamos ver cómo solucionarlo.

Lo que no podemos es dedicarnos nosotros a probarlo en linux, simplemente porque ninguno lo tenemos como nuestro sistema operativo.

Más adelante, cuando ya tengamos unas versiones más o menos estables y finalizadas, podremos ver si funciona con Mono.
Mientras tanto vendría bien que alguien lo probara.

Por cierto, que Mono es un proyecto desarrollado 100% por la comunidad linux y 100% código libre, así que no hay lugar a pensar que el código no se pueda reaprovechar.

Otra cosa es que a uno le guste la plataforma o no.
Ahí cada uno tendrá sus preferencias en función de cuál es su experiencia en programación.
Entornos hay cientos. Y en linux sistemas de ventanas aún mas que en windows (kde,gtk, qt... infinitos).

Iniciado por ariznaf

No dgmaga, ni siquiera habrá que portar nada.
En un principio debería de funcionar tal cuál está, sin tocar nada.
Simplemente recompilando y creando el proyecto de compilación para el compilador utilizado (CSharpDevelop o MonoDevelop).

Muchas gracias por la aclaración...

Pues parece mucho más fácil de lo que yo pensaba.

¡A ver si se anima alguien a probarlo! (súbete las mangas, lepalom, yo puedo testear en Linux)

Daniel

Iniciado por dgmaga

Vale, entiendo. No sé qué porcentaje de código está en la DLL y cuándo en el GUI.

Esperaba animarte a que hicieras una versión para Linux...

:-)

puedo intentarlo pero mi conocimiento de mono es 0 patatero. Y si te digo la verdad me atrae muy poco ... siempre puedo hacer un fork :-)

Supongo que habrás visto el mensaje de Arinaz, que explica mucho mejor que yo como está lo de la portabilidad.

La cosa es que habrá versión para Linux en la medida que haya alguien a quien le interese usar el programa en Linux y esté dispuesto a portar el código aprovechando lo que se pueda.

Mientras no exista ese interés ni esa disposición para hacerlo, veo que difícil que se haga...

Sí, es razonable. Igualmente le hecharé un vistazo haber como queda.
_________________________________

Iniciado por dgmaga

Muchas gracias por la aclaración...

Pues parece mucho más fácil de lo que yo pensaba.

¡A ver si se anima alguien a probarlo! (súbete las mangas, lepalom, yo puedo testear en Linux)

Daniel

:-)

Ok, pero no prometo nada ...

Lepalom, te envie un privado, seguro que no te has dado cuenta.

Esta semana he empezado con el mono a intentar compilar la aplicacion, si te parece podríamos intentarlo juntos.

Salut

Iniciado por tonilupi

Lepalom, (...) podríamos intentarlo juntos.

uyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

ehhhhhhh, que pasa _GUI_, a ver si te me pondras celoso ahora

Ésto se está calentando... ¡ánimo linuxeros! a ver si fichamos un MacOSero y montamos un ménage à trois.

Un saludo: