13 respuestas en este tema

[cram]

Propongo a la comunidad brindar ideas para mejora nuestro querido RAD Studio.
Supongo que existirá alguna manera de hacer llegar las propuestas correctamente traducidas a la gente de Embarcadero.
Existen muchas tendencias que actualmente se están barajando para dar con lo que será el nuevo paradigma. Creo que estamos en un momento de cambio.
Hace unos años:
- los fotógrafos no pensaban que la fotografía digital superaría a la tradicional.
- los artistas gráficos no pensaban pasarse a las tabletas gráficas para pintar.
- los lectores no creyeron que los libros de papel pudieran ser reemplazados (aun no lo son, pero esperen a que se abarate el OLED).
- Cuando salió Delphi muchos querían seguir picando más que pinchando y picando menos (Yo fui uno).

¿Con qué creen que podríamos empezar?
Diría que:

1. El inspector de objetos.
Actualmente está separado en propiedades y eventos. Debajo puede verse aquello que se agregó recientemente como "New LiveBinding"
A las propiedades se las puede agrupar por categorías. Aun sigue siendo largo el proceso de búsqueda.
Lazarus incorpora una pestaña de favoritos que es interesante.
Los iconos de componentes no visuales que se incorporan a la ventana (TForm), a veces entorpecen su modificación. Yo los colocaría en una tercer categoría llamada componentes. Ed decir: Propiedades, Eventos y Componentes.

2. La paleta de herramientas
Actualmente llena, más si se instalan componentes de terceros.
Standard, sería lo más usado, pero no es así.
Comúnmente no se mezcla BDE, ADO, IB, etc. Pues sería práctico que se pueda elegir cuál de estos usar y ocultar el resto, esto para cada proyecto.
Por otra parte, creo que en un proyecto se elige ciertas herramientas, es buena idea elegirlas de antemano antes de empezar a constuir el proyecto, en una manera de configuración del entorno de trabajo.

3. Messages
Reducen continuamente el espacio de las pantallas, actualmente son más anchas que altas y eso empeora más aún las cosas. Ya que no podemos colocarlo al costado y debajo se hacen molestos.

4. Los menús descolgables deben formar parte de la historia a menos que se limiten en longitud y niveles de profundidad. Existen otras formas de acceder a las características de un software.

5. VCL Designer
Anclar un control para evitar su movimiento en Firemonkey es posible en VCL no, al menos en la version que conozco.
Sería posible agregar una herramienta de ampliación/reducción (cambiando el los pixels por pulgada).
Además no vendría mal agregar líneas guía.
Acceder a las propiedades o eventos de los controles visuales mediante un clic secundario sobre el mismo.

Perdón si desconozco características existentes. Sabrán corregirme.


Y bueno es mi punto de vista. Y no es todo. Si Embarcadero no se actualiza, lo hará Lazarus. 

Vi más de una vez la pregunta ¿qué es mejor C++ o Delphi? Eso habla muy bien de Delphi, más allá de la gran confusión que tenga el que pregunta. Lo triste sería escuchar la pregunta ¿cuál es mejor VisualBasic o Delphi?.
El lenguaje está mu bien definido y el compilador hace bien su trabajo. Solo nos queda hacer lo que podamos por mejorar: IDE y bibliotecas (librería es una muy mala traducción para library)

Saludos.

[Marc]

Personalmente lo que más urgente me parece es poder poner componentes no visuales (querys, datasources, ... ...) fuera del formulario.

Tengo formularios con decenas de componentes de este estilo, y ya no sé como organizarlos para que no me tapen y pueda seguir accediendo a los controles visuales en el formulario.

[poliburro]

Personalmente lo que más urgente me parece es poder poner componentes no visuales (querys, datasources, ... ...) fuera del formulario.

Creo que esa es la razón del que existan los DataModules. Pero aún así es engorroso tenerlos todos amontonados.

[genriquez]

En el caso de los query yo opté por crear al vuleo los que no necesito permanente, con la ventaja que se puede depurar más fácil ya que se ve en el código directamente, obviamente algunos componentes deben ser permanentes.

Saludos.

[Jhonny]

Personalmente lo que más urgente me parece es poder poner componentes no visuales (querys, datasources, ... ...) fuera del formulario.

Tengo formularios con decenas de componentes de este estilo, y ya no sé como organizarlos para que no me tapen y pueda seguir accediendo a los controles visuales en el formulario.

Recuerdo que en la versión 2005 de Delphi habían incorporado esa cualidad y no comprendo la razón de quitarla.

[cram]

Creo que esa es la razón del que existan los DataModules. Pero aún así es engorroso tenerlos todos amontonados.

Pero aún sigue siendo engorroso. Y además, el tema es que debe existir alguna otra manera. Por ejemplo con un botón debajo o una ventana extra, como lo son la historia (comparación) y el código.
Visual Studio los coloca debajo, pero su solución tampoco me agrada, pues se hace más difícil de seguir aún.
La resolución de los monitores que se usan por aquí no pasan los 768p a 900 p verticales (Tengo un CRT que me permite ver 1024 a 75Hz, pero es como haber pertenecido a la tripulación del K-19). Si sumas todos los componentes además de tener en cuenta que te separa las líneas, etc. Aun es insuficiente.
Quizá realizando una mejora a la interfaz del DataModule. Por lo pronto se me ocurre una grilla (matriz) en donde se reduzca el tamaño del icono y se lo ubique a la izquierda como el caso de un botón. Entonces sería posible al menos clasificarlos.

[poliburro]

Y además, el tema es que debe existir alguna otra manera. Por ejemplo con un botón debajo o una ventana extra, como lo son la historia (comparación) y el código.

Fijate que yo para evitarme en parte ese engorroso problema me he creado una calse que encapsula la conexión a la base de datos. Es una clase conexión que tiene dos propiedades un TAdoConnection y un TadoStoredProc. La clase se encarga de crear parámetros de manera automática, cargar la cadena de conexión desde un ini y realizar operaciónes de validar conexión y establecerla. De esa manera me ahorro mucho código y el colocar componentes en pantalla.

[cram]

Poliburro, sin contradecirte, ya que me parece excelente esa postura, por un lado. Según comprendí es una especie de framework o al menos una parte de él. Pero el paradigma de objetos va muy de la mano con la interfaz visual y por supuesto que podemos hacer bibliotecas muy buenas que trabajen todo desde código, incluso se puede hacer desaparecer a cualquier componente visual, incluso los botones, cajas de texto, etc., pero la tendencia tira hacia el otro lado y a lo que me refiero es tirar en el sentido del vector más importante.
Como dicen, una imagen vale más que mil palabras. En este sentido un componente visual tiene el poder de síntesis.
¿Y sobre los menús?, las cintas son su evolución, pero no se ve algo parecido en las IDEs de desarrollo.

[poliburro]

Poliburro, sin contradecirte, ya que me parece excelente esa postura, por un lado. Según comprendí es una especie de framework o al menos una parte de él. Pero el paradigma de objetos va muy de la mano con la interfaz visual

Cierto lo que dices. En ese sentido creo que lo que propones en el inspector de objetos suena muy aceptable.

¿Y sobre los menús?, las cintas son su evolución, pero no se ve algo parecido en las IDEs de desarrollo.

No conocía sobre ello. ¿Qué son las cintas?

[egostar]

¿Y sobre los menús?, las cintas son su evolución, pero no se ve algo parecido en las IDEs de desarrollo.

Cintas = Ribbon ¿?

¿ Será porque las cintas están monopolizadas por MicroSoft ?

Saludos

[poliburro]

Cintas = Ribbon ¿?

¿ Será porque las cintas están monopolizadas por MicroSoft ?

Saludos

vaya, de qué cosas se entera uno...

La nueva de Microsoft y mas sobre patentes
2 Replies
Despues de crear el post anterior sobre las patentes me encontre con una noticia que me vino como anillo al dedo para seguir hablando del tema.

Como muchos ya saben, la nueva version de Office (2007) incorporara una “nueva” manera de interactuar con el usuario, el ya tan mencionado “ribbon“. El cual, basicamente son botones grandes que reaccionan segun el contexto, agrupados en tabs.


Imagen del ribbon, click para agrandar

Pues resulta que antier, en el blog de Jensen Harris nos salieron con la noticia de que microsoft esta patentando la interfaz y que ademas, en toda su bondad, nos dejara usarlo gratis, pero solo si lo pedimos por favor. Ademas debemos seguir una serie de guias (120 paginas, por cierto) para que Microsoft nos de el visto bueno.

El problema, y como muchos ya comentaron es que mediante ese “contrato” riguroso, implicitamente estas aceptando que la propiedad intelectual del concepto del ribbon es de microsoft, cuando esto no es necesariamente cierto.

En primer lugar muchas otras aplicaciones ya hacen cosas muy parecidas, por lo que se puede aplicar la figurar del “prior art“. La primera que me viene a la mente es dreamweaver, aunque conceptos como las tabs son usados ampliamente en muchisimos productos (si no, vean su navegador ).


Menus de dreamweaver, click para agrandar

En segundo lugar, la patente esta en proceso aun, es patente pendiente. Basicamente te “venderian” algo que no les pertenece aun. A mi me suena a algo llamado fraude.

En tercer lugar, Microsoft “prohibira” el uso del ribbon en aplicaciones que compitan directamente con Office (te lo digo Juan para que me entiendas OpenOffice).

Microsoft alega que invirtio billones (si, con b) de dolares en la creacion del concepto y de hecho ya estan en proceso de patentarlo. El problema es que no se pueden patentar conceptos, sino solamente implementaciones. Entonces aun cuando se les concediera la patente (que sinceramente lo dudo y lo espero), con cambiar el mas minimo detalle, esta dejaria de ser valida.

Es interesante ver como la historia se repite. Hace años Borland intento hacer lo mismo y fallo miserablemente. Apple demando a Microsoft por algo similar y adivinen… fallo tambien. Ahora microsoft es el que lo intenta. No veo porque el resultado deba ser diferente.

Lo repito, el sistema de patentes esta dañado de raiz. No sera la ultima vez que oigamos de este tipo de “detalles”…

Enlace a la nota

[Marc]

Personalmente lo que más urgente me parece es poder poner componentes no visuales (querys, datasources, ... ...) fuera del formulario.

Creo que esa es la razón del que existan los DataModules. Pero aún así es engorroso tenerlos todos amontonados.

Es que en los DataModules ya tengo un centenar de componentes. Aún así necesito también algunas docenas en los formularios principales.

Personalmente me gustaría poder ubicarlos libremente alrededor del formulario.

[egostar]

Personalmente lo que más urgente me parece es poder poner componentes no visuales (querys, datasources, ... ...) fuera del formulario.

Creo que esa es la razón del que existan los DataModules. Pero aún así es engorroso tenerlos todos amontonados.

Es que en los DataModules ya tengo un centenar de componentes. Aún así necesito también algunas docenas en los formularios principales.

Personalmente me gustaría poder ubicarlos libremente alrededor del formulario.

Lo que yo hago es crear los componentes en tiempo de ejecución, y les paso el nombre del componente de conexión a la base de datos y las propiedades necesarias para su utilización (usuario, contraseña, clausulas SQL, etc.

Saludos

[cram]

Lo que yo hago es crear los componentes en tiempo de ejecución, y les paso el nombre del componente de conexión a la base de datos y las propiedades necesarias para su utilización (usuario, contraseña, clausulas SQL, etc.

Saludos

Los DataModules fueron creados o, al menos, la idea de usarlos, es para aislar la lógica de negocio para una aplicación N-Capa.
Escribir todo en el código es otra modalidad de programación y tiene la gran ventaja del aislamiento.
Pero aún así, el DataModule es bastante incómodo. Además, a veces se tienen los componentes del DataModule y de cada ventana que utiliza aquellos solo en ese lugar (y por eso no figuran en el DataModule).
La idea de mejorar la cuestión visual y creo que por esto se creó UML y la característica de modelado en el RAD.
A mí en este sentido lo que me interesa es poder tener una visión global de todas las interrelaciones, cosa que realmente, es mucho pedir y que un DataModule, obviamente, no cumple. Por otra parte el modelado no tiene niveles de aislamiento (o al menos lo desconozco) y tampoco me sirve para dicha cuestión.