[gull] No dynamic GUI

Daniel Cordey dc at mjt.ch
Wed Aug 30 16:08:19 CEST 2006


On Wednesday 30 August 2006 15:24, Marc SCHAEFER wrote:

> les GUI modernes ont des outils intégrés qui permettent (pendant
> l'utilisation normale) de changer l'aspect du GUI: p.ex. changer la
> taille d'une zone listant les mails d'une boîte dans kmail, quitte à la
> rendre invisible.
>
> Existe-t-il un moyen d'empêcher cela? 

A ma connaissance pas. kmail a justement un ensemble de menus permettant de 
configurer les parametres d'utilisation. Ces parametres sont passes 
aux "widgets" de l'application etc. Peut-etre que ces attributs se retrouvent 
dans les "ressources" X11 que l'on peut obtenir avec xrdb -query ? Mais je ne 
crois pas... je viens d'essayer chez moi et je n'ai rien trouve qui 
s'apparente a des attributs d'applications lies a kde. Seul de vieilles 
applications xpdf, emacs, xdvi... A l'epoque de Motif, cette maniere de faire 
etait assez repandue et tres pratique pour configurer integralement une 
application sans toucher au code. De plus, on pouvait utiliser xrdb -load 
ou -merge pour "charger" des attributs a la volee. C'est exactement ce dont 
tu aurais besoin mais KDE et ses amis ne semble pas avoir pris cette voie. Au 
lieu de cela, les configs des applics se trouvent repartient dans de nombreux 
fichiers residants a partir de $HOME/.kde, en format XML... C'est bien mais 
on a perdu le moyen de pouvoir dynamiser les changements :-(


> L'idée serait d'avoir deux modes, 
> un mode autorisé et un mode interdit.  Un peu ce que fait l'option `Lock
> icons in place' de KDE pour éviter que l'on déplace les icônes sur le
> desktop.

Tant que l'application n'offre pas d'argument du style '--no-change-config' 
mais offre justement les menus pour le faire, on ne peut bloquer quoique se 
soit.

> Jusqu'ici j'avais utilisé la méthode `bateau': à chaque démarrage de
> l'interface, remplacer les fichiers de configuration par les défauts.
> Mais cela pose des problèmes p.ex. face à l'historique des commandes
> tapées, etc (ils n'ont pas pensé à séparer les deux types
> d'information).

Il semble que le tout XML ai fait perdre la notion de souplesse apportee par 
les fichiers de configurations des ressources X11 que l'on trouvait 
sous /usr/lib/X11/app-defaults, etc. et qui permettait de faire exactement ce 
que tu desires. On pouvait ainsi uniformiser le look et le comportement d'une 
application soit pour un utilisateur sur N systemes, soit pour tous les 
utilisateurs d'un meme systeme. Honnetement, je ne suis pas totalement 
convaincu que :

ml*XmToggleButton.marginHeight: 1

Soit moins lisible, ou decodable, que :

<ml>
  <XmToggleButton>
    <marginHeight>
      1
    </marginHeight>
  </XmToggleButton>
</ml>

De plus, ces fichiers de config ont perdu toute la souplesse de Xressources...

> La modification sans contrôle du GUI pose beaucoup de problèmes de
> support technique et j'aimerais les éviter.

Oui, on se vante d'etre "more secure" mais on delaisse completement cet 
aspet ! C'est assez stupide car il y a beaucoup de travail a accomplir dans 
ce domaine. Pensons a des administrateurs de plusieurs centaines de stations. 
Ils doivent developper des solutions hybrides; simplement parceque le 
developpement a negliger ce probleme.

> Quelqu'un a-t-il une idée ?

Eduquer les developpeur en leur expliquant que Qt/Gtk fonctionne bien sous 
X11... qui possede des outils adequats ! +Faire un "request" aupres des teams 
de KDE et Gnome... 

C'est vraiment desolant :-(

dc



More information about the gull mailing list