Gestinux Forum

Bonjour,

Une question sur le choix d'interface avec des fenêtres indépendantes. Pourquoi ne pas les intégrer dans la fenêtre principale?

Autre problème que on n'est peux minimiser que la fenêtre active, car les fenêtres par défaut s'ouvrent en mode modal.
Dans mes applis j'utilise deux méthodes pour ouvrir la fenêtre avec la liste, une en mode modal pour select et l'autre en mode modeless pour browse.
Si ce model vous intéresse je peux me pencher sur la question. Ce n'est que la question d’ergonomie.
On n'est pas obligé fermer la liste en cour pour pouvoir accéder au bureau ou déplacer la fenêtre principal.

Cdt,

talexone

Bonjour,

Oui, je suis absolument d'accord que cela pourrait être amélioré, et que ce serait très utile.

Au début, il y a déjà quelques années, on ne pouvait pas du tout afficher de fenêtre non modale sous Linux, suite à un bug qui est maintenant résolu et c'est pour cela que j'ai choisi l'interface la plus simple possible qui est, c'est vrai, plutôt rigide. Il y a encore un petit bug qui empêche de réduire une fenêtre sous Linux dans certains cas, et qui serait corrigé avec Lazarus 1.2 mais je n'ai pas vérifié.

Si on change le type d'interface, il faudra tester à fond sur beaucoup de systèmes et de widgetsets. Actuellement j'essaie de faire fonctionner Gestinux sur Mac OSX, et je ne sais pas encore lequel des 3 widgetsets on pourra retenir, ils ont tous leurs inconvénients. Après il y aura Android et c'est encore un autre widgetset, pas assez abouti pour l'instant.

Un autre point à prendre en considération avec les fenêtres non modales, c'est le risque d'incohérence entre les données. Si vous créez une facture avec un article, et que vous pouvez modifier ou supprimer cet article avant de valider la facture, il va se passer des choses bizarres. Je pense que cela demande des précautions qui peuvent être compliquées, et sinon être à l'origine de méchants bugs...

Enfin, je crois qu'il serait bon de livrer d'abord assez vite une version 1.1 qui corrige notamment les bugs que vous avez signalé avec PostgreSql. Elle supprimera aussi des champs inutiles dans la base, présents pour des raisons "historiques", mais ne devrait pas comporter de modifications aussi radicales que celles de l'interface. Il faudrait donc attendre encore un peu pour que je tire une branche 1.1 et qu'on puisse attaquer ces grosses modifications sur le trunk.

En attendant, vous pouvez tout à fait préparer l'évolution et la valider sur un exemple simple, et aussi faire un ticket pour cela.