Cita:
Empezado por DarkDudae
Efectivamente. Y ahí viene mi queja hacia el planteamiento "multiplataforma" de firemonkey.
A mi modo de ver la cosa no es tan compleja:
Creo unos componentes "firechicken" (en vez de firemonkey). En Designtime, esos componentes adoptarían el aspecto de los componentes nativos que tenga seleccionado en ese momento en el compilador con un simple combobox (algo parecido a como vemos ahora en los videos del sneak peak de Embarcadero para Android). Es decir, si tengo seleccionada plataforma Android, adoptarían el aspecto de los controles de Android, y si tengo seleccionada la plataforma iOS, adoptarían el aspecto de la plataforma iOS. (Sin necesidad de crear un form para cada plataforma)
|
Pero si esto es así ahora mismo en XE5...
Cita:
Empezado por DarkDudae
Los componentes "firechicken" tendrían todos las mismas propiedades en cualquier plataforma (o prácticamente las mismas). A la hora de dibujar los componentes en pantalla, lo harían usando la API de los controles nativos de la plataforma para la que compilemos (Esto se puede conseguir fácilmente usando varios IFDEFs). A la hora de por ejemplo, programar el evento OnClick de un botón de firechicken, este haría la llamada a la API nativa del componente correspondiente, y si dicho evento no existe en el control nativo, pues se programa.
|
Esto si no se maneja de esta forma ahora, el dibujo lo maneja firemonkey, no nativo.
Cita:
Empezado por DarkDudae
Si firemonkey estuviese diseñado de esta forma, tendríamos prácticamente un único código, con un único formulario y con el rendimiento de los componentes nativos.
|
De nuevo, error de concepto, asi esta diseñado. De lo que vos te quejas es de que el dibujo no sea nativo, porque el resto asi funciona
