Sébastien Wilmet a écrit 683 commentaires

Avec LaTeXila tu peux créer tes propres modèles, pas besoin de faire des copiers/collers à chaque fois ;)

Je ne connais pas TeXshop, et je n'ai pas de MacOS X sous le coude pour pouvoir le tester, mais quand les fonctionnalités principales de LaTeXila seront implémentées je me pencherai sur les autres dialectes de TeX.

Ce ne serait pas vraiment un changement d'orientation, mais plutôt plus d'ouverture. Il faudrait ajouter quelques modèles par défaut, voir si la coloration syntaxique tient la route, rajouter des outils de construction pour avoir son PDF en un clic, rajouter des mots-clés pour l'auto-complétion, et peut-être créer un nouveau menu avec les commandes principales.

Et pour ne pas que ça devienne trop usine à gaz, le support de ConTeXt etc serait sous forme de plugin, comme ça tout le monde est content :)

Oui c'est tout à fait prévu, même que jaliste, l'auteur du blog dont tu donnes l'url, va peut être faire la même chose pour LaTeXila (il a d'ailleurs déjà fait un fork sur GitHub).

Le plus simple pour que LaTeXila supporte ConTeXt, XeLaTeX et compagnie est de rajouter le support dans Rubber.

Rubber supporte déjà plusieurs compilateurs :

Aleph (commande lamed), etex (commande elatex), omega (commande lambda), vtex (commande vlatex).

En attendant il y a moyen de personnaliser les commandes exécutées pour la compilation, pour l'instant il faut passer par le fichier XML (data/build_tools-en.xml), mais plus tard il y aura une interface graphique.

Pour ce qui est de la coloration syntaxique, je pense qu'il n'y a pas de gros changements par rapport à (La)TeX donc ça ne devrait pas poser trop de soucis.

Merci en tout cas de m'avoir fait découvrir ConTeXt, je ne connaissais pas (je ne suis pas un gourou en LaTeX non plus...).

C'est en lisant La cathédrale et le bazar [1], où cette citation est aussi présente, que m'était venu l'idée de mettre ça comme signature :)

[1] http://www.linuxfr-france.org.invalid/article/these/cathedrale-bazar/c(...)

Et c'est marrant de voir que certains devs ont fait plus de commit à eux seuls que l'ensemble de Canonical :

http://0pointer.de/blog/projects/i-am-more-awesome-than-cano(...)

(Lennart Poettering, développeur de PulseAudio et de systemd notamment)

Personnellement je prononce les voyelles de « brum », « pain » et « brin » différemment : de plus en plus aigu.

« Lundi » étant équivalent à « pain ».

Le site du zéro c'est bien pour les débutants, mais dès qu'on commence à toucher à des choses plus spécifiques ou plus pointues c'est mieux de poser ses questions sur des forums ou mailing lists plus orientés dans ce qu'on fait.

En fait c'est le cas de nombreuses applications qui utilisent la bibliothèque GtkSourceView : Gedit, Anjuta, LaTeXila (de ce que j'ai testé).

Par contre, chose étonnante, MonoDevelop, qui utilise aussi GtkSourceView, n'a pas ce problème, mais ce n'est pas parfait non plus : il ne faut faire aucune modification du fichier pour pouvoir coller le texte précédemment sélectionné dans le même fichier. Je lirais bien le code source pour voir comment ils ont fait, et éventuellement écrire un patch pour GtkSourceView. Mais bon ce ne serait que contourner le problème, le mieux étant de le corriger à la source (sans doute du côté de GTK).

Bon, pas de réponse, lien toujours invalide... Et en fait le fichier valide-0.7.0.tar.gz existe, mais il y a un répertoire debian dedans qui prend beaucoup de place et qui est inutile dans le tarball.
Bref ça fait pas très sérieux...

[mode=coup de gueule]
Et ah oui, on peut lire sur un de ses tutoriels GTK [1] (que j'ai suivi pour faire LaTeXila... et après je m'étonne que la structure du code est pourrie...) :

« Une solution plus simple est de créer une variable globale à l'ensemble du programme. Ceux qui passe régulièrement sur le forum C savent que c'est fortement déconseillé, mais ici nous nous trouvons dans l'une des rares exceptions à la règle. De toute façon cela revient au même que de passer l'adresse de notre structure à toutes les fonctions callback. »

Bon OK pour le petit logiciel de démonstration qui était construit pas à pas dans le tutoriel ça peut convenir, mais c'est quand même pas très propre. Mais le problème est qu'il n'y a aucune mention de GObject, et le fait que c'est beaucoup mieux d'organiser son code en classes au lieu d'utiliser une variable globale... Ça parait anodin comme ça mais pour quelqu'un qui n'a jamais été vraiment initié à la manière de bien programmer en C/GTK+, ça peut faire toute la différence !

Bref, j'aurais dû acheter dès le départ le livre « Foundations of GTK+ Development » qui est génial pour débuter.
[/mode]

[1] http://nicolasj.developpez.com/gtk/cours/?page=page_7

Depuis quelques semaines mon asus qui n'a que 1 an et demi surchauffe, impossible de faire tourner un programme qui prend 100% des 2 processeurs pendant plus de 10 minutes... Avec certains jeux ou sites web en flash c'est pareil.

Je suis sur que c'est pas un problème logiciel car j'ai pris un vieux live-cd pour lequel je sais que le problème n'existait pas, je lance deux petites boucles infinies (dual core), et même résultat : le ventilo se met à faire de plus en plus de bruit, et au bout d'un certain temps l'ordi s'éteint pour cause de surchauffe.

J'ai dévissé l'arrière de l'ordi pour voir si c'était pas à cause des poussières, mais il n'y en avait que très peu et le problème est toujours là...

Donc après mes exams je suis bon pour l'apporter au magasin, et utiliser mon vieux acer qui lui au moins fonctionne toujours (c'est étonnant puisqu'on dit généralement que les asus sont meilleur que les acer, mais bon).

En utilisant un logiciel en GTK+ 1 avec un Gnome actuel, on peut aussi voir qu'il y a détérioration. Pas le logiciel en lui-même, mais l'environnement qui est autour qui a complètement changé fait que le logiciel est beaucoup moins bien intégré.

Autant pour des mots comme oignon -> ognon et nénuphar -> nénufar je peux comprendre, mais là je préfère évènement puisqu'on prononce comme ça.

J'ai pas trouvé de liens pour télécharger les *.iso en bittorrent... J'ai pas essayé de chercher à fond non plus en me disant qu'il n'y aurait de toute façon pas grand monde puisqu'apparemment aucun lien direct n'existe.

Je me suis donc résolu à télécharger le *.iso en http, et la vitesse est très bonne : 1,5Mo/s (ça doit pas être loin du maximum possible avec ma connexion).

Il y a des serveurs répliqués un peu partout dans le monde j'image, en tout cas ça tient très bien la charge !

J'ai installé F13 il y a déjà quelques semaines sur le nouveau sony vaio de ma mère (noyau 2.6.34 nécessaire pour la prise en charge du son et du wifi), et j'ai été étonné de sa stabilité, je n'ai eu aucun bug, et ma mère ne se plaint pas.

Avec F12 sur mon ordi, au début j'avais quelques bugs avec Firefox et une ou deux applications gnome, mais avec les mises à jour je n'ai plus aucun problème.

Dans les gestionnaires de paquets le (a) est enlevé pour donner « valide », donc je suppose que c'est mieux de prononcer « valide » comme le mot en français, ce qui fait un petit jeu de mot.

C'est comme les gens dans mon entourage qui prononcent LaTeXila avec un X au lieu d'un K, ça enlève tout le charme ;)

Le lien pour télécharger valide-0.7.0.tar.gz pointe vers l'ancienne version 0.6.1.

Étant donné que je compte aussi réaliser un IDE GTK+ en Vala [1], je m'intéresse beaucoup à la façon dont tu as organisé le code source.
Ne trouves-tu pas que ce serait intéressant que GtkSourceView soit de plus haut niveau, notamment pour tout ce qui est la gestion de documents ? Il y a beaucoup de choses de Gedit qui valent la peine d'être intégrée dans une bibliothèque je trouve.

[1] Voir mon dernier journal à propos de LaTeXila [2] : http://linuxfr.org/~darkagonik/29652.html
[2] http://latexila.sourceforge.net/

#include <stdio.h>

#define SIX 1 + 5
#define NEUF 8 + 1

int
main (void)
{
printf ("%d * %d = %d\n", SIX, NEUF, SIX * NEUF);
return 0;
}

$ gcc -o 42 42.c
$ ./42
6 * 9 = 42

Comme quoi il faut toujours mettre des parenthèses dans les define.

C'est clair qu'avoir seulement quelques commentaires dans le code n'aide pas à attirer de nouveaux développeurs. Même s'il y a beaucoup de commentaires, il n'est parfois pas facile de comprendre la structure générale du code, et on ne sait pas vraiment par où commencer la lecture (le main() est toutefois un bon point de départ, généralement).

Mais écrire d'abord la documentation (pour développeurs) avant le code, ça me parait une perte de temps si on s'aperçoit en codant qu'on n'a pas prévu tous les cas possibles et où une réécriture en profondeur de la documentation est nécessaire...

Pour ce qui est de la documentation pour utilisateurs, autant le faire après le code pour pouvoir insérer des captures d'écran, faire référence à telle ou telle option bien spécifique dans les préférences, etc.

Rien n'empêche d'avoir un dossier contenant le code source qu'on pourrait facilement modifier, compiler puis installer dans le répertoire contenant les binaires.

Et ça permettrait un temps de démarrage beaucoup plus rapide, car notamment moins de processus sont créés (dans l'article un ordre de grandeur est donné avec la commande « echo $$ » exécutée juste après le démarrage : Linux PID 1823; MacOS PID 154).

Pour systemd c'est prévu de réécrire tous les scripts d'init en C au lieu de simples scripts shell (contenus dans /etc/init.d/).

Un autre billet un peu plus récent où il se déchaine (concernant l'intégration de PulseAudio dans Ubuntu 9.10) :
http://0pointer.de/blog/projects/pa-in-ubuntu.html

Faut espérer que la situation s'est améliorée pour la 10.04...

Je pense qu'il voulait plutôt faire référence à l'article :

« For a fast and efficient boot-up two things are crucial:

* To start less.
* And to start more in parallel.

What does that mean? Starting less means starting fewer services or deferring the starting of services until they are actually needed. There are some services where we know that they will be required sooner or later (syslog, D-Bus system bus, etc.), but for many others this isn't the case. For example, bluetoothd does not need to be running unless a bluetooth dongle is actually plugged in or an application wants to talk to its D-Bus interfaces. Same for a printing system: unless the machine physically is connected to a printer, or an application wants to print something, there is no need to run a printing daemon such as CUPS. Avahi: if the machine is not connected to a network, there is no need to run Avahi, unless some application wants to use its APIs. And even SSH: as long as nobody wants to contact your machine there is no need to run it, as long as it is then started on the first connection. (And admit it, on most machines where sshd might be listening somebody connects to it only every other month or so.) »

« Dénuée de mono, et pas mal d'autres choses ! ;) »

Ce serait bien de remplacer Tomboy par Gnote, F-Spot par Shotwell et Gwibber par Pino.

C'est une des raisons pour lesquelles j'apprécierai Fedora 13 qui inclura tous ces logiciels par défaut pour éviter d'avoir des applications Mono.

Il me semble que cette loi ne prend pas en compte si la cible est sur un bord ou pas.

Ce que tu voulais sans doute dire, c'est que mettre le bouton de fermeture juste au-dessus du menu fichier n'est pas une bonne idée, car les gens doivent faire plus attention à l'endroit où ils cliquent : « oups j'ai fermé la fenêtre alors que je voulais aller dans le menu fichier... »

J'aime bien la syntaxe de Vala, surtout pcq je suis habitué au C et au Java. Mais la syntaxe de Python ne me dérange pas non plus, mais là Genie (qui est un mélange de Python, Boo, D et Delphi) ne m'attire pas.

En plus, Vala est bien plus documenté, il y a plein d'exemples de code en GTK par exemple. Et je pense que Vala est plus répandu que Genie, donc je peux lire le code source de logiciels comme Val(a)IDE, qui est un IDE écrit en Vala, pour Vala (donc ça peut être intéressant de s'inspirer de ce logiciel, en plus de Gedit).