Tu as une utilisation avancée du proxy et les programmes surchargent le paramétrage global. As-tu vraiment besoin de changer le proxy globalement pour toutes les applications à tout instant, car si elles ont toutes les mêmes proxy à un instant t, c'est bien un paramètre système.
Pour qui est du fond d'écran, je sais que sous gnome c'est nautilus qui fait cela ce qui a mon sens est idiot car n'a rien à voir avec un gestionnaire de fichier et fait dépendre un truc visuel global d'un gestionnaire de fichier particulier. Enfin, cela fait longtemps que j'ai quitté GNOME car je ne suis pas fanat de la direction qu'ils prennent.
Le soucis est que GNOME est conçu en suivant la trace des autres, Windows et MacOSX. Donc si tu veux copier les autres, tu risques de te retrouver dans les mêmes travers.
Rien n'empêche plusieurs programmes de lancer xsetroot ou un équivalent pour changer de fond d'écran, il n'y aucun besoin d'un gestionnaire d'évènement de type variable globale pour cette problématique. Le dernier programme qui paramètre gagne, point final.
Je pense personnellement qu'il y a d'autres voies possibles. Je ne dis pas qu'il ne faut absolument pas de bus de type d-bus couplé à gconf, je pense qu'il ne sers à rien d'en abuser et qu'au final, cela n'apporte pas grand chose si ce n'est de la complexité et beaucoup de dangerosité.
Le modèle de base d'UNIX des processus père fils et des variables d'environnements transmissibles permet de faire beaucoup. Dans les cas pointus, il est possible d'aller au delà de ce modèle simple. Ce n'est pas la peine non plus d'oublier ce modèle simple pour tout mettre en global !
Pour ce qui est du réveil, c'est comme pour un 'ReStart' d'environnement de bureau, tu peux très bien envoyer un signal CONT via kill ou équivalent aux applications pour prendre en compte un réveil.
On avait des choses simples qui marchait bien comme 'newgrp' qui ne sont quasiment plus utilisable dans ce paradigme global, idem avec un gestion de l'umask... On n'a plus cette notion de container et d'héritage de l'OS. Les applications ré-implémentent la gestion des onglets, du threading, du sandboxing... quand à avoir un comportement différent en fonction de la vie de l'application et de l'histoire de ses parents, ce n'est plus guère possible. Personnellement, j'aurais préféré que toute cette énergie soit mise dès le début dans le coeur de l'OS.
[^] # Re: Ce n'est pas nouveau
Posté par Sytoka Modon (site web personnel) . En réponse au journal Qt dans Ubuntu. Évalué à 2.
Pour qui est du fond d'écran, je sais que sous gnome c'est nautilus qui fait cela ce qui a mon sens est idiot car n'a rien à voir avec un gestionnaire de fichier et fait dépendre un truc visuel global d'un gestionnaire de fichier particulier. Enfin, cela fait longtemps que j'ai quitté GNOME car je ne suis pas fanat de la direction qu'ils prennent.
Le soucis est que GNOME est conçu en suivant la trace des autres, Windows et MacOSX. Donc si tu veux copier les autres, tu risques de te retrouver dans les mêmes travers.
Rien n'empêche plusieurs programmes de lancer xsetroot ou un équivalent pour changer de fond d'écran, il n'y aucun besoin d'un gestionnaire d'évènement de type variable globale pour cette problématique. Le dernier programme qui paramètre gagne, point final.
Je pense personnellement qu'il y a d'autres voies possibles. Je ne dis pas qu'il ne faut absolument pas de bus de type d-bus couplé à gconf, je pense qu'il ne sers à rien d'en abuser et qu'au final, cela n'apporte pas grand chose si ce n'est de la complexité et beaucoup de dangerosité.
Le modèle de base d'UNIX des processus père fils et des variables d'environnements transmissibles permet de faire beaucoup. Dans les cas pointus, il est possible d'aller au delà de ce modèle simple. Ce n'est pas la peine non plus d'oublier ce modèle simple pour tout mettre en global !
Pour ce qui est du réveil, c'est comme pour un 'ReStart' d'environnement de bureau, tu peux très bien envoyer un signal CONT via kill ou équivalent aux applications pour prendre en compte un réveil.
On avait des choses simples qui marchait bien comme 'newgrp' qui ne sont quasiment plus utilisable dans ce paradigme global, idem avec un gestion de l'umask... On n'a plus cette notion de container et d'héritage de l'OS. Les applications ré-implémentent la gestion des onglets, du threading, du sandboxing... quand à avoir un comportement différent en fonction de la vie de l'application et de l'histoire de ses parents, ce n'est plus guère possible. Personnellement, j'aurais préféré que toute cette énergie soit mise dès le début dans le coeur de l'OS.