/* Topic des codeurs [8] */

Elzen · Le 08/08/2013, à 12:03

The Uploader a écrit :

J'ai rien de tout ça. Juste de quoi créer et virer des onglets, et c'est tout.

Ah, oui, effectivement, je viens de remarquer que le fichier « main.menu » par défaut dans la conf' était vide ><

Vu que j'ai quand même quelques applis de base, j'vais essayer d'arranger ça. En attendant, tu peux éditer ton fichier de config (~/.config/touhydev/toolkits/menus/main.menu) pour rajouter des trucs utiles dedans. Le format de base d'un fichier de menu, c'est :

nom item::icône
commande associée
nom item suivant::icône
commande associée

Sachant que le « ::icône » est optionnel. Il y a des possibilités en plus, j'vais faire un beau fichier d'exemple

The Uploader a écrit :

Je crois que c'est parce que j'ai mis resources au même niveau que le coeur de touhy :
ls /usr/lib/python2.7/touhy 
apputils  images       modules    sysnotif  touhy-daemons   touhy-tabsman
browsers  __init__.py  parsers    system    touhy-deskman   widgets
gtkutils  laptray      resources  toolkits  touhy-launcher  xutils
Sinon ça aurait fait un dossier /usr/lib/python2.7/touhy et un dossier /usr/lib/python2.7/resources ce que je ne trouvais vraiment pas propre.

Yep, le déplacer se tient, mais ce ne serait pas plus logique de mettre ça directement dans /usr/share ? J'ai laissé tout au même endroit pour pouvoir utiliser directement le git, mais dans une installe en propre, il faudrait séparer, je pense.
Vérifie juste que tu as bien indiqué l'emplacement des ressources, c'est à la ligne 19 du fichier touhy/__init__.py (dans les initialisations de base).

Par contre, pourquoi les touhy-* sont-ils dans ce répertoire aussi ? Normalement, ce sont des exécutables si on veut ne lancer qu'un module précis de l'environnement plutôt que tout à la fois.

The Uploader a écrit :

Quoi qu'il en soit, pour quitter, je suis obligé de passer par une TTY (je fais un sudo reboot à la sauvage parce que avec le SSD c'est ce qu'il y a de plus rapide au final ), même le bouton d'extinction ne fait rien. ^^

Tu peux te faire un bouton dans le menu ou dans un panel qui lance « touhy-full --stop »

The Uploader a écrit :

Où est-elle ? Comment on la modifie ? Tu peux me donner la tienne ?

Ah, yep, c'est aussi simple. J't'ai mis un « touhyconf.tar.xz » dans le /tmp de mon serveur Web, comme ça, tu devrais avoir tous les exemples qui vont bien dedans. J'essayerai quand même de faire un menu de base plus sophistiqué.
La conf de touhy se trouve dans ~/.config/touhydev (ou autre si l'utilisateur a spécifié un XDG_CONFIG_HOME particulier) (mais dans l'archive, je t'ai mis seulement le touhydev, sans le .config au dessus ^^)

The Uploader a écrit :

Tant que ça fonctionne, sous Arch on ne modifie pas.

Bah, ce bout-là est vraiment prévu pour être modifié Mais bon, Arch is Arch ^^

Edit :

The Uploader a écrit :

xsession.c :

#include <unistd.h>

void main(void) {
  int i=0;
  while (i==0) {
    usleep(1);
  }
}

J'n'ai même plus le code du mien sous la main, mais il devait faire un while 42 et un sleep(3600).

Dernière modification par Elzen (Le 08/08/2013, à 12:06)

The Uploader · Le 08/08/2013, à 12:05

Rolinh a écrit :

Ou au pire un pkill X même si c'est un peu bourrin aussi.
The Uploader a écrit :
xsession.c :
#include <unistd.h>

void main(void) {
  int i=0;
  while (i==0) {
    usleep(1);
  }
}
=> ghâââ? Le but c'est de voir comment le scheduler arrive à se dépatouiller ou quoi? (et on a parlé au moins 20x du void main ici )

Ben le but c'est d'avoir ça :

Elzen a écrit :

XSession étant un petit programme C qui fait juste une boucle infinie avec un sleep dedans, ça me permet de pouvoir killer xfwm et/ou touhy en cas de besoin sans paumer la session (et comme c'est du C, c'est un vrai truc que j'peux killer facilement si je veux fermer la session).

Et je vois pas l'intérêt de retourner quelque chose quand on n'arrivera jamais au return du fait de la boucle infinie. ^^

Sinon faudrait voir si je peux pas lancer xfce4-session à la place (enfin ce sera pas dans le paquet, ça ferait dépendre touhy de Xfce), mais autant utiliser Xfce à force d"utiliser ses composants. ^^'

Rolinh a écrit :

Sinon, comme je l'ai dit plus haut, je suis prêt à aider pour faire les paquets. Et perso, je ferais plutôt un paquet touhy-core, requis pour tout soft touhy et ensuite plusieurs paquets pour les applis en enfin, un meta-paquet pour installer le tout.

Je veux bien de l'aide pour le méta paquet (un exemple quoi). Le reste, je pense avoir a peu près bien compris, mais tu peux détailler comment tu ferais si ça te dit.
Je pense pas faire de paquet ne se finissant pas par -git dans le pkgname, par contre...

Elzen a écrit :

The Uploader a écrit :
J'ai rien de tout ça. Juste de quoi créer et virer des onglets, et c'est tout.
Ah, oui, effectivement, je viens de remarquer que le fichier « main.menu » par défaut dans la conf' était vide ><
Vu que j'ai quand même quelques applis de base, j'vais essayer d'arranger ça. En attendant, tu peux éditer ton fichier de config (~/.config/touhydev/toolkits/menus/main.menu) pour rajouter des trucs utiles dedans. Le format de base d'un fichier de menu, c'est :
nom item::icône
commande associée
nom item suivant::icône
commande associée
Sachant que le « ::icône » est optionnel. Il y a des possibilités en plus, j'vais faire un beau fichier d'exemple

Ah, merci.
Je ne trouvais pas de fichier de config, rien ne semblait avoir été créé suite au premier lancement.

Elzen a écrit :

The Uploader a écrit :
Je crois que c'est parce que j'ai mis resources au même niveau que le coeur de touhy :
ls /usr/lib/python2.7/touhy 
apputils  images       modules    sysnotif  touhy-daemons   touhy-tabsman
browsers  __init__.py  parsers    system    touhy-deskman   widgets
gtkutils  laptray      resources  toolkits  touhy-launcher  xutils
Sinon ça aurait fait un dossier /usr/lib/python2.7/touhy et un dossier /usr/lib/python2.7/resources ce que je ne trouvais vraiment pas propre.
Yep, le déplacer se tient, mais ce ne serait pas plus logique de mettre ça directement dans /usr/share ?

   python2
Python 2.7.5 (default, May 12 2013, 12:00:47) 
[GCC 4.8.0 20130502 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print sys.path
['', '/usr/lib/python27.zip', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/lib/python2.7/site-packages', '/usr/lib/python2.7/site-packages/PIL', '/usr/lib/python2.7/site-packages/gst-0.10', '/usr/lib/python2.7/site-packages/gtk-2.0', '/usr/lib/python2.7/site-packages/setuptools-0.6c11.egg-info']

Ailleurs, "import touhy" (une des premières choses que fait touhy-full) ne fonctionne pas.

Elzen a écrit :

J'ai laissé tout au même endroit pour pouvoir utiliser directement le git, mais dans une installe en propre, il faudrait séparer, je pense.
Vérifie juste que tu as bien indiqué l'emplacement des ressources, c'est à la ligne 19 du fichier touhy/__init__.py (dans les initialisations de base).

Oui j'ai vu ça. C'est ce que j'allais patcher (c'est trois fois rien à faire).

Elzen a écrit :

Par contre, pourquoi les touhy-* sont-ils dans ce répertoire aussi ? Normalement, ce sont des exécutables si on veut ne lancer qu'un module précis de l'environnement plutôt que tout à la fois.

J'y ai pensé, mais je voulais d'abord tester touhy en modifiant le moins possible de trucs (j'étais pressé de tester ).
Mais je le ferais, oui.

Elzen a écrit :

The Uploader a écrit :
Quoi qu'il en soit, pour quitter, je suis obligé de passer par une TTY (je fais un sudo reboot à la sauvage parce que avec le SSD c'est ce qu'il y a de plus rapide au final ), même le bouton d'extinction ne fait rien. ^^
Tu peux te faire un bouton dans le menu ou dans un panel qui lance « touhy-full --stop »

ok.

Elzen a écrit :

The Uploader a écrit :
Où est-elle ? Comment on la modifie ? Tu peux me donner la tienne ?
Ah, yep, c'est aussi simple. J't'ai mis un « touhyconf.tar.xz » dans le /tmp de mon serveur Web, comme ça, tu devrais avoir tous les exemples qui vont bien dedans. J'essayerai quand même de faire un menu de base plus sophistiqué.

Elzen a écrit :

La conf de touhy se trouve dans ~/.config/touhydev (ou autre si l'utilisateur a spécifié un XDG_CONFIG_HOME particulier) (mais dans l'archive, je t'ai mis seulement le touhydev, sans le .config au dessus ^^)

ok.

Elzen a écrit :

The Uploader a écrit :
Tant que ça fonctionne, sous Arch on ne modifie pas.
Bah, ce bout-là est vraiment prévu pour être modifié Mais bon, Arch is Arch ^^

Modifier des resources dans /usr c'est pas top, touhy devrait pouvoir en trouver dans ~/.local/share par exemple. C'est possible ou pas encore codé ?

Elzen a écrit :

Edit :
The Uploader a écrit :
xsession.c :
#include <unistd.h>

void main(void) {
  int i=0;
  while (i==0) {
    usleep(1);
  }
}
J'n'ai même plus le code du mien sous la main, mais il devait faire un while 42 et un sleep(3600).

Ah ouais, un sleep plus long éviterait de trop embêter le cpu (busy waiting), puis de toute façons il n'est là que pour se faire tuer, y'a pas besoin qu'il réponde...

Dernière modification par The Uploader (Le 08/08/2013, à 12:33)

Rolinh · Le 08/08/2013, à 12:35

The Uploader a écrit :

Ben le but c'est d'avoir ça :
Elzen a écrit :
XSession étant un petit programme C qui fait juste une boucle infinie avec un sleep dedans, ça me permet de pouvoir killer xfwm et/ou touhy en cas de besoin sans paumer la session (et comme c'est du C, c'est un vrai truc que j'peux killer facilement si je veux fermer la session).

OK, mais un délai d'une micro-seconde, à part mettre à genou ton scheduler (et donc carrément mettre à mal le fonctionnement de ton système), je ne vois pas ce que ça apporte...

The Uploader a écrit :

Et je vois pas l'intérêt de retourner quelque chose quand on n'arrivera jamais au return du fait de la boucle infinie. ^^

Parce que la norme ISO/IEC 9899 le recommande? Signatures possibles pour la fonction main.

The Uploader a écrit :

Je veux bien de l'aide pour le méta paquet (un exemple quoi). Le reste, je pense avoir a peu près bien compris, mais tu peux détailler comment tu ferais si ça te dit.

Pour le moment, j'ignore comment faire un meta-paquet puisque je n'en ai jamais eu besoin mais il suffit de regarder les PKBGUILD pour xfce ou KDE par exemple.
Pour comment je ferais, sans rentrer dans les détails car faut que je réflechisse encore un peu: un paquet core qui installe la lib touhy dans /usr/lib/python2.7/site-packages/touhy ainsi que les ressources dans /usr/share/touhy/ressources et chacun des softs (elzaudm, elzlist, etc) dans /usr/bin.

EDIT: accessoirement, je ne vois pas à quoi ça sert de déclarer une variable i puisque tu ne t'en sers même pas...

Dernière modification par Rolinh (Le 08/08/2013, à 12:40)

grim7reaper · Le 08/08/2013, à 12:36

The Uploader a écrit :

Et je vois pas l'intérêt de retourner quelque chose quand on n'arrivera jamais au return du fait de la boucle infinie. ^^

L’intérêt c’est d’avoir un programme qui respecte le standard du C, sachant que ce qui ne respecte pas le standard du C finit souvent en UB ce qui signifie quartier libre pour le compilo’ qui pourra alors te faire sortir des démons du pif.
Le standard du C définit un main valide comme étant :

int main(void)

ou

int main(char argc, char** argv)

+ éventuels prototypes spécifiques à l’environnement, étant sous Linux on peut donc ajouter :

int main(int argc, char** argv, char** envp)

Bon ici ce n‘est pas un UB donc main invalide => code invalide :
- Avec gcc :

attention : return type of ‘main’ is not ‘int’ [-Wmain]

- Avec clang :

error: 'main' must return 'int'
void main(void) {}
^
1 error generated.

Accessoirement, l’intérêt c’est aussi de ne pas passer pour un blaireau qui arrive à se bouffer 1 erreur sur 8 lignes de codes triviales

The Uploader · Le 08/08/2013, à 12:58

Rolinh a écrit :

The Uploader a écrit :
Ben le but c'est d'avoir ça :
Elzen a écrit :
XSession étant un petit programme C qui fait juste une boucle infinie avec un sleep dedans, ça me permet de pouvoir killer xfwm et/ou touhy en cas de besoin sans paumer la session (et comme c'est du C, c'est un vrai truc que j'peux killer facilement si je veux fermer la session).
OK, mais un délai d'une micro-seconde, à part mettre à genou ton scheduler (et donc carrément mettre à mal le fonctionnement de ton système), je ne vois pas ce que ça apporte...

Moi non plus (voir plus haut).
A part ça quand j'ai testé ça n'a pas l'air d'avoir mis grand chose à genoux.

Rolinh a écrit :

The Uploader a écrit :
Et je vois pas l'intérêt de retourner quelque chose quand on n'arrivera jamais au return du fait de la boucle infinie. ^^
Parce que la norme ISO/IEC 9899 le recommande? Signatures possibles pour la fonction main.

Ah, ok, le comportement est indéfini. Mais ça reste bête, vu que le code ne sera jamais executé.
Le voilà modifié :

int main(void) {
  for(;;) {
    sleep(3600);
  }
  return 1;
}

Et Le mieux ce serait un sleep vraiment inifini, pas un truc bricolé avec une valeur vraiment grande pour pas mettre l'ordonnanceur de processus à genoux..

Rolinh a écrit :

The Uploader a écrit :
Je veux bien de l'aide pour le méta paquet (un exemple quoi). Le reste, je pense avoir a peu près bien compris, mais tu peux détailler comment tu ferais si ça te dit.
Pour le moment, j'ignore comment faire un meta-paquet puisque je n'en ai jamais eu besoin mais il suffit de regarder les PKBGUILD pour xfce ou KDE par exemple.

Il ne semble pas y avoir de meta-paquet xfce, ni kde d'ailleurs. C'est juste une histoire de groups= dans le PKGBUILD je pense.

ls /var/abs/extra/xfce*   
/var/abs/extra/xfce4-appfinder:
PKGBUILD  xfce4-appfinder.install

/var/abs/extra/xfce4-artwork:
PKGBUILD

/var/abs/extra/xfce4-battery-plugin:
PKGBUILD  xfce4-battery-plugin.install

/var/abs/extra/xfce4-clipman-plugin:
PKGBUILD  xfce4-clipman-plugin.install

/var/abs/extra/xfce4-cpufreq-plugin:
PKGBUILD  xfce4-cpufreq-plugin.install

/var/abs/extra/xfce4-cpugraph-plugin:
PKGBUILD  xfce4-cpugraph-plugin.install

/var/abs/extra/xfce4-datetime-plugin:
PKGBUILD

/var/abs/extra/xfce4-dev-tools:
PKGBUILD

/var/abs/extra/xfce4-dict:
PKGBUILD  xfce4-dict.install

/var/abs/extra/xfce4-diskperf-plugin:
PKGBUILD

/var/abs/extra/xfce4-eyes-plugin:
PKGBUILD  xfce4-eyes-plugin.install

/var/abs/extra/xfce4-fsguard-plugin:
PKGBUILD  xfce4-fsguard-plugin.install

/var/abs/extra/xfce4-genmon-plugin:
PKGBUILD

/var/abs/extra/xfce4-mailwatch-plugin:
only-call-gnutls-transport_set_lowat-with-gnutls-2.12.patch
PKGBUILD
xfce4-mailwatch-plugin-1.1.0-underlink.patch
xfce4-mailwatch-plugin.install

/var/abs/extra/xfce4-mixer:
PKGBUILD  xfce4-mixer.install

/var/abs/extra/xfce4-mount-plugin:
PKGBUILD  xfce4-mount-plugin.install

/var/abs/extra/xfce4-mpc-plugin:
PKGBUILD

/var/abs/extra/xfce4-netload-plugin:
PKGBUILD  xfce4-netload-plugin.install

/var/abs/extra/xfce4-notes-plugin:
PKGBUILD  xfce4-notes-plugin.install

/var/abs/extra/xfce4-notifyd:
PKGBUILD  xfce4-notifyd.install

/var/abs/extra/xfce4-panel:
PKGBUILD  xfce4-panel.install

/var/abs/extra/xfce4-power-manager:
PKGBUILD
xfce4-power-manager-1.2.0-sync-en-gb-translation.patch
xfce4-power-manager.install

/var/abs/extra/xfce4-quicklauncher-plugin:
PKGBUILD
xfce4-quicklauncher-plugin-1.9.4-desktop-file.patch
xfce4-quicklauncher-plugin-1.9.4-fix-missing-english-translation.patch
xfce4-quicklauncher-plugin-1.9.4-fix-multiscreen.patch
xfce4-quicklauncher-plugin-1.9.4-save-settings.patch
xfce4-quicklauncher-plugin-1.9.4-xfce4-settings-manager.patch

/var/abs/extra/xfce4-screenshooter:
fix_segfault.diff  PKGBUILD  xfce4-screenshooter.install

/var/abs/extra/xfce4-sensors-plugin:
PKGBUILD  xfce4-sensors-plugin.install

/var/abs/extra/xfce4-session:
PKGBUILD  xfce4-session.install

/var/abs/extra/xfce4-settings:
PKGBUILD  xfce4-settings-xml-4.10.0.patch

/var/abs/extra/xfce4-smartbookmark-plugin:
PKGBUILD  xfce4-smartbookmark-plugin-archlinux.patch

/var/abs/extra/xfce4-systemload-plugin:
PKGBUILD

/var/abs/extra/xfce4-taskmanager:
PKGBUILD

/var/abs/extra/xfce4-terminal:
PKGBUILD  xfce4-terminal.install

/var/abs/extra/xfce4-time-out-plugin:
PKGBUILD  xfce4-time-out-plugin.install

/var/abs/extra/xfce4-timer-plugin:
PKGBUILD  xfce4-timer-plugin.install

/var/abs/extra/xfce4-verve-plugin:
PKGBUILD

/var/abs/extra/xfce4-wavelan-plugin:
PKGBUILD

/var/abs/extra/xfce4-weather-plugin:
fix-color-parsing-when-reading-config-file.patch  xfce4-weather-plugin.install
PKGBUILD

/var/abs/extra/xfce4-xkb-plugin:
PKGBUILD

Rolinh a écrit :

Pour comment je ferais, sans rentrer dans les détails car faut que je réflechisse encore un peu: un paquet core qui installe la lib touhy dans /usr/lib/python2.7/site-packages/touhy ainsi que les ressources dans /usr/share/touhy/ressources et chacun des softs (elzaudm, elzlist, etc) dans /usr/bin.

Si c'est plus propre, ça me va (je me demandais justement à quoi servait /usr/lib/python2.7/site-packages et si je devais mettre touhy dedans).

grim' a écrit :

Accessoirement, l’intérêt c’est aussi de ne pas passer pour un blaireau qui arrive à se bouffer 1 erreur sur 8 lignes de codes triviales

gnagnagna
Le pire c'est que par habitude j'ai mis int pour le type de retour et le return 1 à la fin, c'est après que je me suis dit que c'était superflu vu que ce ne sera jamais executé.
Merci pour ce raffraîchissement de mémoire.

Dernière modification par The Uploader (Le 08/08/2013, à 13:00)

Elzen · Le 08/08/2013, à 13:18

The Uploader a écrit :

Ailleurs, "import touhy" (une des premières choses que fait touhy-full) ne fonctionne pas.

Je parlais du répertoire resources

L'idée de base, c'était qu'une install propre mettrait le package touhy dans /usr/lib/python2.7/ et le répertoire resources dans /usr/share(/touhy).

The Uploader a écrit :

Modifier des resources dans /usr c'est pas top, touhy devrait pouvoir en trouver dans ~/.local/share par exemple. C'est possible ou pas encore codé ?

Bah, à part ce truc-là en particulier, tout ce que Touhy utilise est dans le répertoire de config, donc il n'y a pas de soucis. Il y a juste ce truc-là (le fichier qui liste l'image à afficher pour chaque jour et le texte correspondant) qui sont dans les ressources alors que ça pourrait, éventuellement, être modifiable.

Mais il y aurait moyen de modifier la fonction resfile, pour qu'elle regarde d'abord s'il existe un fichier du même nom dans .local/share/touhy, auquel cas elle renverrait celui-là plutôt que celui du répertoire de ressources, ouaip.

Bon, note toutes les trucs qui n'ont pas l'air d'aller, je tâcherai de faire les modifs qui vont bien sur le git ce soir, en descendant du train

Rolinh · Le 08/08/2013, à 13:20

The Uploader a écrit :

A part ça quand j'ai testé ça n'a pas l'air d'avoir mis grand chose à genoux.

Parce que les schedulers de nos jours font des merveilles et que tu as certainement un CPU multi-core.

The Uploader a écrit :

Et Le mieux ce serait un sleep vraiment inifini, pas un truc bricolé avec une valeur vraiment grande pour pas mettre l'ordonnanceur de processus à genoux..

Au pire, tu peux faire attendre sur un sémaphore qui ne sera jamais posté, ce qui t'évite une boucle infinie mais permet que ton programme ne se termine jamais.

The Uploader a écrit :

Il ne semble pas y avoir de meta-paquet xfce, ni kde d'ailleurs. C'est juste une histoire de groups= dans le PKGBUILD je pense.

Il y a bien des meta-paquets pour KDE mais effectivement, on doit pouvoir s'en sortir avec juste des packages groups.

The Uploader a écrit :

Si c'est plus propre, ça me va (je me demandais justement à quoi servait /usr/lib/python2.7/site-packages et si je devais mettre touhy dedans).

C'est pour les libs python 2. Donc oui, la lib touhy (le sous-dossier touhy quoi), doit aller là-bas et sera ainsi automatiquement dans le path python2.

grim7reaper · Le 08/08/2013, à 13:39

The Uploader a écrit :

int main(void) {
  for(;;) {
    sleep(3600);
  }
  return 1;
}
Et Le mieux ce serait un sleep vraiment inifini, pas un truc bricolé avec une valeur vraiment grande pour pas mettre l'ordonnanceur de processus à genoux..

Le mieux c’est encore de ne pas faire d‘attente active, et de laisser le système te réveiller quand un signal arrive.
Au pif, c’est exactement ce que fait pause :

man 2 pause a écrit :

pause() causes the calling process (or thread) to sleep until a signal is delivered that either terminates the process or causes the invocation of a signal-catching function.

Donc ça deviendrait :

#define _POSIX_SOURCE

#include <unistd.h>
#include <signal.h>

static void sig_handler(int signal)
{
    (void)signal;
}

int main(void)
{
    struct sigaction action;

    action.sa_handler = sig_handler;
    sigemptyset(&action.sa_mask);
    action.sa_flags = 0;
    sigaction(SIGTERM, &action, NULL);

    pause();

    return 0;
}

Ici comme on est dans un cas particulier (main ne fait rien, on veux juste quitter l’application en cas de signal), pause est suffisant (pour un cas plus complexe, on préférerait sigsuspend).
On ajoute quand même un gestionnaire de signaux (vide, vu que l’on ne veut rien faire) pour quitter proprement.
Sans gestionnaire, le code se limiterait à :

#include <unistd.h>
int main(void)
{
    pause();
    return 0;
}

Ça fonctionnerait aussi, mais ça invoquerait le gestionnaire par défaut, qui tue plus ou moins violemment le programme (ça dépend du signal, mais pour un SIGTERM en tout cas, le programme se termine avec un code de retour 143, pas 0). Ce qui est quand même un peu crade…

Par défaut, kill, pkill, killall envoie SIGTERM, donc je ne gère que celui-là.
À étoffer si le cœur vous en dit.

Édit : pour être vraiment propre, il faut aussi tester le retour le sigaction.

Dernière modification par grim7reaper (Le 08/08/2013, à 13:55)

The Uploader · Le 08/08/2013, à 14:18

Exactement ce que je voulais : éviter le busy waiting.
T'es génial, grim', merci beaucoup.
Je pense que je vais prendre la première variante.

Elzen a écrit :

L'idée de base, c'était qu'une install propre mettrait le package touhy dans /usr/lib/python2.7/ et le répertoire resources dans /usr/share(/touhy).

Ah oui, c'est plus logique pour des resources.
Je vais prendre la solution :
elz* et touhy-* dans /usr/bin
resources dans /usr/share/touhy
Le reste dans /usr/lib/python2.7/site-packages/touhy (merci Rolinh pour tous tes conseils. )

Elzen a écrit :

Bon, note toutes les trucs qui n'ont pas l'air d'aller, je tâcherai de faire les modifs qui vont bien sur le git ce soir, en descendant du train

De mémoire :
- pas d'intégration avec le DM (tu peux prendre touhy.desktop et touhy-launch.sh pour qu'ils soient upstream, donc chez toi, plutôt que uniquement dans mon [futur] paquet. Je me contenterai de le mettre dans /usr/share/xsessions/ et de mettre touhy-launch.sh dans /usr/bin). Bon après le problème est qu'il faut modifier touhy-launch.sh selon ce qu'on veut lancer avec touhy (nm-applet, xfwm4, ...). Ça me gêne un peu de dire "vous devez modifier un fichier dans /usr/bin pour pouvoir utiliser touhy".
Le mieux serait que touhy-launch.sh se contente de lancer le contenu de ~/.touhyrc par exemple.
Évidemment quand on a pas de DM c'est plus simple (on fait tout avec ~/.xinitrc).
Bref, y'a aussi :
- pas de menu dans la config de base
- pas de quoi sortir non plus
- les resources devraient être dans /usr/share/touhy, et ~/.local/share/touhy devrait être prioritaire, s'il existe.

Dernière modification par The Uploader (Le 08/08/2013, à 15:12)

Elzen · Le 08/08/2013, à 16:41

Train décalé à plus tard, donc j'vais m'occuper de ça maintenant. Ça ne fera pas de mal de rendre le truc un peu plus utilisable

The Uploader a écrit :

tu peux prendre touhy.desktop et touhy-launch.sh pour qu'ils soient upstream, donc chez toi, plutôt que uniquement dans mon [futur] paquet.

J'veux bien, c'est où ?

Pour le touhy-launch.sh, je suggère un nom du genre « touhy-session ». D'ailleurs, j'peux éventuellement faire un exécutable python qui s'appelle « touhy-session » et qui lance le gestionnaire de fenêtres avec et tout ? (du style, je lance x-window-manager, comme ça j'utilise les réglages systèmes, c'est le plus propre)

The Uploader a écrit :

Bon après le problème est qu'il faut modifier touhy-launch.sh selon ce qu'on veut lancer avec touhy (nm-applet, xfwm4, ...). Ça me gêne un peu de dire "vous devez modifier un fichier dans /usr/bin pour pouvoir utiliser touhy".

Je peux rajouter un fichier adéquat dans la conf' pour les trucs que l'utilisateur veut lancer en plus (mais j'le mettrais dans ~/.config/touhydev avec le reste plutôt qu'en ~/.touhyrc, ç'plus propre )

D'ailleurs, en parlant de fichier de conf' : ça utilise le répertoire « touhydev » parce que c'est le contenu de la variable libname dans touhy/__init__.py ; mais il ne faut pas hésiter à changer ça en cas de besoin. Genre, je peux le renommer en touhygit de mon côté, et toi en touhyarch, ou un truc comme ça, pour éventuellement pouvoir avoir une conf' distincte pour chaque ?

The Uploader a écrit :

- pas de menu dans la config de base

D'ailleurs, en parlant de ça, ça fait un moment que je me dis que Touhy pourrait embarquer un vrai menu (le truc qui se remplit automatiquement en fonction des applications installées), mais je ne vois toujours pas comment faire. J'ai bien la liste des applis avec « gio.app_info_get_all() », mais les objets obtenus n'ont pas l'air d'avoir de catégories ni rien qui permette de les ranger automatiquement…

The Uploader a écrit :

- pas de quoi sortir non plus

J'vais essayer de bricoler une interface d'extinction (j'avais trouvé comment faire marcher les options éteindre et redémarrer, fut un temps, j'dois pouvoir retrouver ça).

The Uploader a écrit :

- les resources devraient être dans /usr/share/touhy, et ~/.local/share/touhy devrait être prioritaire, s'il existe.

Les ressources resteront dans le répertoire pointé par respath (je préfère conserver la version git lançable en l'état, sans avoir besoin de lancer d'installation ni rien), mais je vais rajouter un test pour que, si respath commence par /usr/share, la recherche de fichiers ressources commence par vérifier ~/.local/share au cas où (et seulement dans ce cas-là, pour permettre aussi, si on veut, de faire une version de Touhy entièrement portable).

Bon, allez, c'est l'heure de rendre ce truc un peu plus sérieux
(Même s'il continuera de manquer d'outils graphiques de configuration)

Keldath · Le 08/08/2013, à 17:01

Salut,

Elzen a écrit :

Les ressources resteront dans le répertoire pointé par respath (je préfère conserver la version git lançable en l'état, sans avoir besoin de lancer d'installation ni rien), mais je vais rajouter un test pour que, si respath commence par /usr/share, la recherche de fichiers ressources commence par vérifier ~/.local/share au cas où (et seulement dans ce cas-là, pour permettre aussi, si on veut, de faire une version de Touhy entièrement portable).

Tu peux t'aider de python-xdg pour gérer l'emplacement des ressources (/usr/share/, ~/.local/share, etc). Et en dev, tu peux ajouter à la volée des emplacements où récupérer les données avec des variables d'environnement, par exemple :

export XDG_DATA_DIRS=/chemin/vers/projet_en_dev/data/share/:$XDG_DATA_DIRS

Elzen · Le 08/08/2013, à 17:04

Keldath a écrit :

Tu peux t'aider de python-xdg pour gérer l'emplacement des ressources (/usr/share/, ~/.local/share, etc). Et en dev, tu peux ajouter à la volée des emplacements où récupérer les données avec des variables d'environnement, par exemple :
export XDG_DATA_DIRS=/chemin/vers/projet_en_dev/data/share/:$XDG_DATA_DIRS

Yep, j'ai déjà ça pour le répertoire de conf' :

if "XDG_CONFIG_HOME" in os.environ: # Répertoire de configuration…
    cfgpath = os.path.join(os.getenv("XDG_CONFIG_HOME"), libname)
else: cfgpath = os.path.join(os.getenv("HOME"), ".config", libname)

Edit : ç'vrai qu'il y a le paquet python-xdg pour ça, mais je ne vois pas l'intérêt de mettre une dépendance de plus juste pour un truc qui se code en quelques lignes. Il sert à autre chose, ce paquet ?

Le seul autre endroit où j'ai besoin de XDG_*, c'est pour repérer le bureau :

            if "XDG_CONFIG_HOME" in os.environ:
                cfgfile = os.path.join(os.environ["XDG_CONFIG_HOME"],
                                       "user-dirs.dirs")
            else: # On prend le rep par défaut, alors…
                cfgfile = os.path.join(os.getenv("HOME"), ".config",
                                       "user-dirs.dirs")
            if os.path.exists(cfgfile): # Allez, voyons ça…
                f = os.popen(". "+cfgfile+" ; echo -n $XDG_DESKTOP_DIR")
                folder = f.read()
                f.close()
            else: # Mince. Bon, répertoire par défaut, du coup…
                folder = os.path.join(os.getenv("HOME"), "Desktop")

Edit2 : tiens, d'ailleurs, j'avais oublié de virer des parenthèses surnuméraires, ici.

Dernière modification par Elzen (Le 08/08/2013, à 17:15)

Keldath · Le 08/08/2013, à 17:46

Elzen a écrit :

Edit : ç'vrai qu'il y a le paquet python-xdg pour ça, mais je ne vois pas l'intérêt de mettre une dépendance de plus juste pour un truc qui se code en quelques lignes. Il sert à autre chose, ce paquet ?

Il ne fournit que de petites fonctions bien pratiques (que l'on peut copier-coller directement dans son projet si on veut éviter d'ajouter une dépendance), si on regarde un des modules de python-xdg :

_home = os.path.expanduser('~')
xdg_data_home = os.environ.get('XDG_DATA_HOME') or \
            os.path.join(_home, '.local', 'share')

xdg_data_dirs = [xdg_data_home] + \
    (os.environ.get('XDG_DATA_DIRS') or '/usr/local/share:/usr/share').split(':')

xdg_config_home = os.environ.get('XDG_CONFIG_HOME') or \
            os.path.join(_home, '.config')

xdg_config_dirs = [xdg_config_home] + \
    (os.environ.get('XDG_CONFIG_DIRS') or '/etc/xdg').split(':')

xdg_cache_home = os.environ.get('XDG_CACHE_HOME') or \
            os.path.join(_home, '.cache')

xdg_data_dirs = filter(lambda x: x, xdg_data_dirs)
xdg_config_dirs = filter(lambda x: x, xdg_config_dirs)

def save_config_path(*resource):
    """Ensure $XDG_CONFIG_HOME/<resource>/ exists, and return its path.
    'resource' should normally be the name of your application. Use this
    when SAVING configuration settings. Use the xdg_config_dirs variable
    for loading."""
    resource = os.path.join(*resource)
    assert not resource.startswith('/')
    path = os.path.join(xdg_config_home, resource)
    if not os.path.isdir(path):
        os.makedirs(path, 0700)
    return path

def save_data_path(*resource):
    """Ensure $XDG_DATA_HOME/<resource>/ exists, and return its path.
    'resource' is the name of some shared resource. Use this when updating
    a shared (between programs) database. Use the xdg_data_dirs variable
    for loading."""
    resource = os.path.join(*resource)
    assert not resource.startswith('/')
    path = os.path.join(xdg_data_home, resource)
    if not os.path.isdir(path):
        os.makedirs(path)
    return path

def load_config_paths(*resource):
    """Returns an iterator which gives each directory named 'resource' in the
    configuration search path. Information provided by earlier directories should
    take precedence over later ones (ie, the user's config dir comes first)."""
    resource = os.path.join(*resource)
    for config_dir in xdg_config_dirs:
        path = os.path.join(config_dir, resource)
        if os.path.exists(path): yield path

def load_first_config(*resource):
    """Returns the first result from load_config_paths, or None if there is nothing
    to load."""
    for x in load_config_paths(*resource):
        return x
    return None

Il gère aussi la vérification et l'édition de fichiers desktop, menu XDG, ... (jamais utilisé personnellement, je ne peux pas en dire plus).

Dernière modification par Keldath (Le 08/08/2013, à 17:46)

The Uploader · Le 08/08/2013, à 20:30

J'avais pas vu ce post !

Elzen a écrit :

Train décalé à plus tard, donc j'vais m'occuper de ça maintenant. Ça ne fera pas de mal de rendre le truc un peu plus utilisable
The Uploader a écrit :
tu peux prendre touhy.desktop et touhy-launch.sh pour qu'ils soient upstream, donc chez toi, plutôt que uniquement dans mon [futur] paquet.
J'veux bien, c'est où ?

là :
./viewtopic.php?pid=14315961#p14315961

Elzen a écrit :

Pour le touhy-launch.sh, je suggère un nom du genre « touhy-session ». D'ailleurs, j'peux éventuellement faire un exécutable python qui s'appelle « touhy-session » et qui lance le gestionnaire de fenêtres avec et tout ? (du style, je lance x-window-manager, comme ça j'utilise les réglages systèmes, c'est le plus propre)

Ce serait mieux en effet (je connaissais pas ce réglage, x-window-manager ?)

Elzen a écrit :

The Uploader a écrit :
Bon après le problème est qu'il faut modifier touhy-launch.sh selon ce qu'on veut lancer avec touhy (nm-applet, xfwm4, ...). Ça me gêne un peu de dire "vous devez modifier un fichier dans /usr/bin pour pouvoir utiliser touhy".
Je peux rajouter un fichier adéquat dans la conf' pour les trucs que l'utilisateur veut lancer en plus (mais j'le mettrais dans ~/.config/touhydev avec le reste plutôt qu'en ~/.touhyrc, ç'plus propre )

Ce serait nickel.

Elzen a écrit :

D'ailleurs, en parlant de fichier de conf' : ça utilise le répertoire « touhydev » parce que c'est le contenu de la variable libname dans touhy/__init__.py ; mais il ne faut pas hésiter à changer ça en cas de besoin. Genre, je peux le renommer en touhygit de mon côté, et toi en touhyarch, ou un truc comme ça, pour éventuellement pouvoir avoir une conf' distincte pour chaque ?

Je tiens pas à changer par rapport à ton dépôt à moins que cela ne soit absolument nécessaire. ^^

Elzen a écrit :

The Uploader a écrit :
- pas de menu dans la config de base
D'ailleurs, en parlant de ça, ça fait un moment que je me dis que Touhy pourrait embarquer un vrai menu (le truc qui se remplit automatiquement en fonction des applications installées), mais je ne vois toujours pas comment faire. J'ai bien la liste des applis avec « gio.app_info_get_all() », mais les objets obtenus n'ont pas l'air d'avoir de catégories ni rien qui permette de les ranger automatiquement…

^ python-xdg

Elzen a écrit :

The Uploader a écrit :
- pas de quoi sortir non plus
J'vais essayer de bricoler une interface d'extinction (j'avais trouvé comment faire marcher les options éteindre et redémarrer, fut un temps, j'dois pouvoir retrouver ça).

Un bouton sur le bureau ou un raccourci clavier suffira aussi, j'pense. Après, faut voir ce qui te va le mieux.

Elzen a écrit :

The Uploader a écrit :
- les resources devraient être dans /usr/share/touhy, et ~/.local/share/touhy devrait être prioritaire, s'il existe.
Les ressources resteront dans le répertoire pointé par respath (je préfère conserver la version git lançable en l'état, sans avoir besoin de lancer d'installation ni rien), mais je vais rajouter un test pour que, si respath commence par /usr/share, la recherche de fichiers ressources commence par vérifier ~/.local/share au cas où (et seulement dans ce cas-là, pour permettre aussi, si on veut, de faire une version de Touhy entièrement portable).

Ok. Je modifierais respath en /usr/share/touhy_resources/ alors.

Elzen a écrit :

Bon, allez, c'est l'heure de rendre ce truc un peu plus sérieux
(Même s'il continuera de manquer d'outils graphiques de configuration)

\o/

Elzen · Le 08/08/2013, à 20:46

Merci, j'ai été un peu retenu, mais je m'occupe de tout ça

The Uploader a écrit :

^ python-xdg

J'ai joué un peu avec pendant un moment, et il ma semblé que ce serait possible, mais le seul éventuel moyen que j'ai trouvé, c'est xdg.Menu.parse(), qui recherche par défaut un fichier qui n'existe pas chez moi

The Uploader a écrit :

Un bouton sur le bureau ou un raccourci clavier suffira aussi, j'pense. Après, faut voir ce qui te va le mieux.

Bah, j'avais déjà fait le truc, que j'ai retrouvé, et qui était plutôt pas mal, donc je vais tenter de l'adapter correctement. Ce sera chouette

The Uploader a écrit :

Ok. Je modifierais respath en /usr/share/touhy_resources/ alors.

Pourquoi pas « /usr/share/touhy » ? C'est dans /usr/share, donc on sait déjà qu'il s'agit des ressources, pas la peine de le repréciser, si ?

Edit :

The Uploader a écrit :

Ce serait mieux en effet (je connaissais pas ce réglage, x-window-manager ?)

Ah, ouais, ça vient du systèmes d'alternatives de Debian, 'me semble, donc ça ne doit pas être dispo partout… Il y a quoi comme solution générique, à part mettre une valeur en dur par défaut ?

Dernière modification par Elzen (Le 08/08/2013, à 20:49)

The Uploader · Le 08/08/2013, à 21:22

Elzen a écrit :

Merci, j'ai été un peu retenu, mais je m'occupe de tout ça
The Uploader a écrit :
^ python-xdg
J'ai joué un peu avec pendant un moment, et il ma semblé que ce serait possible, mais le seul éventuel moyen que j'ai trouvé, c'est xdg.Menu.parse(), qui recherche par défaut un fichier qui n'existe pas chez moi

http://standards.freedesktop.org/menu-s … c-1.0.html

Example Menu File

          <!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN"
          "http://www.freedesktop.org/standards/menu-spec/menu-1.0.dtd">

          <Menu>
            <Name>Applications</Name>
            <Directory>Applications.directory</Directory>
  
            <-- Search the default locations -->
            <DefaultAppDirs/>
            <DefaultDirectoryDirs/>
          
            <-- Merge third-party submenus -->
            <MergeDir>applications-merged</MergeDir>

            <-- Merge legacy hierarchy -->
            <LegacyDir>/usr/share/applnk</LegacyDir>

            <-- Define default layout -->
            <DefaultLayout>
              <Merge type="menus"/>
              <Merge type="files"/>
              <Separator/>
              <Menuname>More</Menuname>
            </DefaultLayout>

            <-- some random moves, maybe to clean up legacy dirs, 
                   maybe from menu editing -->
            <Move>
              <Old>Foo</Old>
              <New>Bar</New>
              <Old>Foo2</Old>
              <New>Bar2</New>
            </Move>          

            <-- A preferences submenu, kept in a separate file 
                   so it can also be used standalone -->
            <Menu>
              <Name>Preferences</Name>
              <Directory>Preferences.directory</Directory>
              <MergeFile>preferences.menu</MergeFile>
            </Menu>

            <-- An Office submenu, specified inline -->
            <Menu>
              <Name>Office</Name>
              <Directory>Office.directory</Directory>
              <Include>
                <Category>Office</Category>
              </Include>
              <Exclude>
                <Filename>foo.desktop</Filename>
              </Exclude>
            </Menu>
             
          </Menu>

Elzen a écrit :

The Uploader a écrit :
Un bouton sur le bureau ou un raccourci clavier suffira aussi, j'pense. Après, faut voir ce qui te va le mieux.
Bah, j'avais déjà fait le truc, que j'ai retrouvé, et qui était plutôt pas mal, donc je vais tenter de l'adapter correctement. Ce sera chouette

ok

Elzen a écrit :

The Uploader a écrit :
Ok. Je modifierais respath en /usr/share/touhy_resources/ alors.
Pourquoi pas « /usr/share/touhy » ? C'est dans /usr/share, donc on sait déjà qu'il s'agit des ressources, pas la peine de le repréciser, si ?

Non, pas vraiment.

Elzen a écrit :

The Uploader a écrit :
Ce serait mieux en effet (je connaissais pas ce réglage, x-window-manager ?)
Ah, ouais, ça vient du systèmes d'alternatives de Debian, 'me semble, donc ça ne doit pas être dispo partout… Il y a quoi comme solution générique, à part mettre une valeur en dur par défaut ?

Ben sous Arch c'est l'environnement qui lance le wm qui va bien, à sa sauce.
Par exemple pour Xfce ça se configure dans /etc/xdg/xdg-xubuntu/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml (ça plante moins que de utiliser autostart, du moins pour compiz sous Ubuntu. Plutôt que de remplacer xfwm4, on lance directement le wm qui va bien. Par contre ça s'applique à toutes les session Xfce de la machine. ).
(ça se configure peut-être aussi sans passer par /etc, ni autostart "lewm --replace", mais j'ai pas trop cherché).

En tout cas je pensais que l'utilisateur rajouterait son WM au fichier de config de touhy lu par touhy-session, non ?

Dernière modification par The Uploader (Le 08/08/2013, à 21:23)

Elzen · Le 09/08/2013, à 01:41

The Uploader a écrit :

http://standards.freedesktop.org/menu-s … c-1.0.html

J'voulais dire que si ça revient à faire créer un fichier menu à l'utilisateur (vu que le fichier menu par défaut n'a pas l'air d'exister chez moi, il n'existe pas forcément chez les autres), autant leur faire faire des fichiers de ma conf', reconnus directement par Touhy et avec plus d'options
Mais je tâcherai de lire ça un peu plus en détail un de ces jours, merci.

The Uploader a écrit :

ok

Truc en cours d'élaboration, le minimum vital semble marcher, reste à l'étoffer.

Tiens, d'ailleurs, les gens, vu qu'on a tous nos petites manies : qu'est-ce que vous vérifiez, vous, avant d'éteindre la machine ? (Genre, que les fenêtres sont bien fermées, que vous avez coupé les messageries instantanées, qu'il restera de la place dans /tmp au prochain démarrage, autre chose ?)

The Uploader a écrit :

Ben sous Arch c'est l'environnement qui lance le wm qui va bien, à sa sauce.
Par exemple pour Xfce ça se configure dans /etc/xdg/xdg-xubuntu/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml (ça plante moins que de utiliser autostart, du moins pour compiz sous Ubuntu. Plutôt que de remplacer xfwm4, on lance directement le wm qui va bien. Par contre ça s'applique à toutes les session Xfce de la machine. ).
(ça se configure peut-être aussi sans passer par /etc, ni autostart "lewm --replace", mais j'ai pas trop cherché).
En tout cas je pensais que l'utilisateur rajouterait son WM au fichier de config de touhy lu par touhy-session, non ?

Bah, sous Debian, c'est le cas aussi ; sauf qu'il y a /etc/alternatives en plus (qui ne concernent pas que le gestionnaire de fenêtres, genre il y a x-www-browser et x-terminal-emulator, par exemple).

J'pense que je vais faire un truc du genre :
– s'il y a un WM spécifié dans la conf', lancer celui-là.
– sinon, si /usr/bin/x-window-manager existe, lancer ça.
– sinon, si /usr/bin/xfwm4 existe, lancer ça.
– sinon, tant pis pour l'utilisateur qui n'a qu'à régler sa conf'.

Dernière modification par Elzen (Le 09/08/2013, à 01:44)

The Uploader · Le 09/08/2013, à 10:26

Elzen a écrit :

Tiens, d'ailleurs, les gens, vu qu'on a tous nos petites manies : qu'est-ce que vous vérifiez, vous, avant d'éteindre la machine ? (Genre, que les fenêtres sont bien fermées, que vous avez coupé les messageries instantanées, qu'il restera de la place dans /tmp au prochain démarrage, autre chose ?)

Je ferme Firefox/Thunderbird, le reste n'est pas trop gếné d'être vite tué à la déconnexion, en générale.
/tmp est en mémoire (merci systemd), donc est tojours vide au démarrage.

Elzen a écrit :

The Uploader a écrit :
Ben sous Arch c'est l'environnement qui lance le wm qui va bien, à sa sauce.
Par exemple pour Xfce ça se configure dans /etc/xdg/xdg-xubuntu/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml (ça plante moins que de utiliser autostart, du moins pour compiz sous Ubuntu. Plutôt que de remplacer xfwm4, on lance directement le wm qui va bien. Par contre ça s'applique à toutes les session Xfce de la machine. ).
(ça se configure peut-être aussi sans passer par /etc, ni autostart "lewm --replace", mais j'ai pas trop cherché).
En tout cas je pensais que l'utilisateur rajouterait son WM au fichier de config de touhy lu par touhy-session, non ?
Bah, sous Debian, c'est le cas aussi ; sauf qu'il y a /etc/alternatives en plus (qui ne concernent pas que le gestionnaire de fenêtres, genre il y a x-www-browser et x-terminal-emulator, par exemple).

Arch -> en plus = pas KISS = y'a pas de truc en plus (même /etc/rc.conf a été viré).

Elzen a écrit :

J'pense que je vais faire un truc du genre :
– s'il y a un WM spécifié dans la conf', lancer celui-là.
– sinon, si /usr/bin/x-window-manager existe, lancer ça.
– sinon, si /usr/bin/xfwm4 existe, lancer ça.
– sinon, tant pis pour l'utilisateur qui n'a qu'à régler sa conf'.

ok

Dernière modification par The Uploader (Le 09/08/2013, à 10:27)

Elzen · Le 09/08/2013, à 11:17

Tiens, d'ailleurs, tant que je fais un touhy-session, j'vais en profiter pour lui mettre un signal.pause() ('me semble que c'est l'équivalent de la fonction C proposée par grim ci-dessus) dedans, plutôt que de démarrer directement l'environnement dans ce processus-là. Ça permettra de le redémarrer en cours de route sans avoir besoin d'embarquer un truc compilé rien que pour ça, et ça permettra plus de souplesse.

The Uploader a écrit :

Je ferme Firefox/Thunderbird, le reste n'est pas trop gếné d'être vite tué à la déconnexion, en générale.

Perso, je ferme toutes les fenêtres, ne serait-ce que pour éviter qu'elles mémorisent bêtement leur taille maximisée et qu'elles soient énormes à la réouverture.

Ah, et puis j'ai oublié le démontage de supports réseaux, aussi, dans les trucs à potentiellement faire.

The Uploader a écrit :

/tmp est en mémoire (merci systemd), donc est tojours vide au démarrage.

C'est généralisé, ça ?

The Uploader a écrit :

en plus = pas KISS

Sur le principe général, j'emets quelques réserves, il ne me paraît pas aberrant qu'ajouter un lien symbolique (c'est tout ce que fait update-alternatives, ajouter des liens symboliques) puisse parfois rendre les choses plus simples et plus stupides que de laisser dans la situation d'origine. Enfin, c'est une question de point de vue.

Dernière modification par Elzen (Le 09/08/2013, à 11:19)

The Uploader · Le 09/08/2013, à 11:30

Elzen a écrit :

C'est généralisé, ça ?

Par défaut, oui. Après, tout le monde n'utilise pas systemd (même si on peut faire pareil à l'aide de /etc/fstab, sans besoin d'installer systemd), et tout le monde n'utilise pas Arch, of course.

Elzen a écrit :

Sur le principe général, j'emets quelques réserves, il ne me paraît pas aberrant qu'ajouter un lien symbolique (c'est tout ce que fait update-alternatives, ajouter des liens symboliques) puisse parfois rendre les choses plus simples et plus stupides que de laisser dans la situation d'origine. Enfin, c'est une question de point de vue.

Oui, bon, c'était un très gros résumé du principe. ^^

Elzen a écrit :

Tiens, d'ailleurs, tant que je fais un touhy-session, j'vais en profiter pour lui mettre un signal.pause() ('me semble que c'est l'équivalent de la fonction C proposée par grim ci-dessus) dedans, plutôt que de démarrer directement l'environnement dans ce processus-là. Ça permettra de le redémarrer en cours de route sans avoir besoin d'embarquer un truc compilé rien que pour ça, et ça permettra plus de souplesse.

Ok, j'attends avant d'empaqueter tout ça.

Dernière modification par The Uploader (Le 09/08/2013, à 11:31)

Elzen · Le 09/08/2013, à 15:07

Bon, vu que je fais des travaux IRL en même temps, ça avance moins vite, forcément. Mais ça y est, c'est sur le serveur

N'hésitez pas s'il y a autre chose qui ne va pas.

Rolinh · Le 09/08/2013, à 15:24

@Elzen: pourquoi pas de setup.py au fait? Ça faciliterait grandement la tâche des packagers... Et faire des tarballs avec des versions aussi.

@The Uploader: Tu t'en sors pour le packaging? Je peux faire cobaye pour des tests si tu veux.

Elzen · Le 12/08/2013, à 00:46

@The Uploader : bon, j'viens encore de faire un commit de débug. Ça ne touche pas ce que tu patches, normalement

@Rolinh : Bah, la version sur le git, je préférerais qu'elle reste en l'état, directement utilisable sans rien avoir à lancer (c'est l'une des raisons pour lesquelles j'ai choisi un langage interprêté à la base), mais une archive permettant une récupération et une installation facilitée pour les systèmes pour lesquels ce n'est pas packagé (et pour faciliter le boulot des packageurs), ouais, ça pourrait se tenter, en effet. C'est censé faire quoi/ressembler à quoi, un setup.py ?

@tous : bon, pour changer un peu de Touhy, j'me suis lancé là-dedans. C'est un jeu de lasers, exactement le même principe que celui que je vous avais présenté en Java il y a quelques temps, mais recodé (avec les pieds) en PyGTK. Si ça vous tente de contribuer, ce serait avec grand plaisir

Dernière modification par Elzen (Le 12/08/2013, à 00:47)

grim7reaper · Le 12/08/2013, à 02:48

Elzen a écrit :

@tous : bon, pour changer un peu de Touhy, j'me suis lancé là-dedans. C'est un jeu de lasers, exactement le même principe que celui que je vous avais présenté en Java il y a quelques temps, mais recodé (avec les pieds) en PyGTK. Si ça vous tente de contribuer, ce serait avec grand plaisir

ImportError: No module named streng

Tu as encore le code Java accessible quelque part ?

ljere · Le 12/08/2013, à 10:24

bonjour, j'ai un petit souci avec du php (langage que je découvre mais alors complètement)

<?php

$ipnonprotege = "00.00.00.00";
$monip = `dig +short myip.opendns.com @resolver1.opendns.com`;
echo "Mon ip perso: ";
echo $ipnonprotege;
echo " Mon ip actuelle: ";
echo $monip;

if (isset($_POST['button']))
{
    exec('sh scripts/vpn.sh');
}
if (isset($_POST['button3']))
{
    exec('sh scripts/stop_vpn.sh');
}

if ($ipnonprotege !== $monip)
{
    echo "<br />FreedomIP protège la connexion";
    ?>
    <p>
        <button name="button3">Stop VPN!</button>
    </p>
    </form>
    <?php

}
else
{
    echo "<br />FreedomIP ne protège pas la connexion";
    ?>    
    <form method="post">
    <p>
        <button name="button">Lancer le VPN!</button>
    </p>
    </form>
    <?php
}
?>

la comparaison ne fonctionne pas il m'affiche toujours "FreedomIP protège la connexion"
d’après les echo j'ai bien les bon retours

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1676 Le 08/08/2013, à 12:03

Re : /* Topic des codeurs [8] */

#1677 Le 08/08/2013, à 12:05

Re : /* Topic des codeurs [8] */

#1678 Le 08/08/2013, à 12:35

Re : /* Topic des codeurs [8] */

#1679 Le 08/08/2013, à 12:36

Re : /* Topic des codeurs [8] */

#1680 Le 08/08/2013, à 12:58

Re : /* Topic des codeurs [8] */

#1681 Le 08/08/2013, à 13:18

Re : /* Topic des codeurs [8] */

#1682 Le 08/08/2013, à 13:20

Re : /* Topic des codeurs [8] */

#1683 Le 08/08/2013, à 13:39

Re : /* Topic des codeurs [8] */

#1684 Le 08/08/2013, à 14:18

Re : /* Topic des codeurs [8] */

#1685 Le 08/08/2013, à 16:41

Re : /* Topic des codeurs [8] */

#1686 Le 08/08/2013, à 17:01

Re : /* Topic des codeurs [8] */

#1687 Le 08/08/2013, à 17:04

Re : /* Topic des codeurs [8] */

#1688 Le 08/08/2013, à 17:46

Re : /* Topic des codeurs [8] */

#1689 Le 08/08/2013, à 20:30

Re : /* Topic des codeurs [8] */

#1690 Le 08/08/2013, à 20:46

Re : /* Topic des codeurs [8] */

#1691 Le 08/08/2013, à 21:22

Re : /* Topic des codeurs [8] */

#1692 Le 09/08/2013, à 01:41

Re : /* Topic des codeurs [8] */

#1693 Le 09/08/2013, à 10:26

Re : /* Topic des codeurs [8] */

#1694 Le 09/08/2013, à 11:17

Re : /* Topic des codeurs [8] */

#1695 Le 09/08/2013, à 11:30

Re : /* Topic des codeurs [8] */

#1696 Le 09/08/2013, à 15:07

Re : /* Topic des codeurs [8] */

#1697 Le 09/08/2013, à 15:24

Re : /* Topic des codeurs [8] */

#1698 Le 12/08/2013, à 00:46

Re : /* Topic des codeurs [8] */

#1699 Le 12/08/2013, à 02:48

Re : /* Topic des codeurs [8] */

#1700 Le 12/08/2013, à 10:24

Re : /* Topic des codeurs [8] */

Pied de page des forums