Aplicaciones delphi para Linux, excelente

[mamcx]

Primero, no es tanto el # de dispositivos sino sus arquitecturas.

No hay nada en el horizonte cercano que sea más allá de ARM, Intel/AMD y soporte a GPUS (Cuda, Vulcan) que no esta ahora presente. Incluso en embeidos prácticamente ARM es la plataforma dominante a futuro, y lo que sea con rasperry & similares pues no es el mercado de Delphi.

Hay algunas cosas que podrian surgir, como los NVMe y otras cosas un poco esotericas, pero igual no es el mercado de Delphi e igualmente LLVM se porta a esas cosas si hay interes real.

Lo que realmente es un problema no es tanto los procesadores y sus arquitecturas, sino el adaptarse a los OS y en especial a los toolkits graficos.

Eso es un problema que las maquinas virtuales NO RESUELVEN, y es engorroso sea como sea. COn todo si Delphi ya esta en iOS/Android no hay otro toolkit que se vislumbre en el futuro que valga la pena.

---

El problema de fondo aquí es más de enfoque de Embarcadero en calidad vs. nuevas características que en si el compilador.

Aun si fuera mas abierto (open source) igual al ser un nicho no tendría el caudal de apoyo necesario, a menos que otro participante (como por ejemplo MS) le diera por meterle mano. Y sin embargo, no veo que se puede hacer con el problema de la multiplataforma.

Es que la parte no-visual es "trivial" en comparación con el acceso a la GUI/Apis nativas, y no se me ocurre que exista una forma eficaz de resolver el tema aparte de "sudor, lagrimas & mucho esfuerzo".

---
En resumen: Delphi ya esta a medio paso usando LLVM. Mejor back-end para *Delphi* es improbable que exista. El hacer una capa que simplifique portar es "trivial" si ignoramos la parte visual, el acceso a APIs nativas y el entramaje de apis de terceros de esas plataformas y solo estamos hablando del lenguaje como si.

Pero NO HAY solucion para mas alla de la compatibilidad basica de los lenguajes.

[juniorSoft]

El problema de fondo aquí es más de enfoque de Embarcadero en calidad vs. nuevas características que en si el compilador.

Es por donde va mi razonamiento mamcx

Lo que realmente es un problema no es tanto los procesadores y sus arquitecturas, sino el adaptarse a los OS y en especial a los toolkits graficos.

Ahí esta el punto clave, el API funcional y Gráfico de cada sistema operativo a menos que no haya una standardization como si fueran tomas que el SO utilice, encubriendo sus interioridades para encender la parte visual sin mucho sudor y dudo que la haya porque esto también va a depender del hardware del dispositivo, ademas de que cada nueva tecnología en SO no es para acomodar a los programadores sino a los usuarios, si le sumamos que por cuestiones de tiempo de lanzamiento y competitividad mercadotécnica deben lanzar sun invenciones en el menor tiempo posible; seguirá así por mucho tiempo por no decir para siempre

[Ñuño Martínez]

¿Nadie ha nombrado GTK+?

[[Al González]]

Empezado por Ñuño Martínez

¿Nadie ha nombrado GTK+?

Ahora mismo consultando qué es eso. Lo he visto escrito varias veces, pero con el nombrecito que tiene me había dado algo de pereza investigar.

[juniorSoft]

¿Nadie ha nombrado GTK+?

El problema es que comoquiera la estandarización por más esfuerzos que se hagan, existen diferentes criterios, diferentes visiones y hasta diferentes objetivos, para muestra

https://www.systeminside.net/por-que...fa-escritorio/

Observando esa libreria GTK+ es una muy buena iniciativa pero en este mundo donde hay tantos intereses es difícil hacer un mundo mejor.