Le 06 novembre 2015 à 11:18:21 DuckSauce a écrit :
Mate est compatible GTK3 maintenant?
Depuis la 1.10 MATE à deux versions, une GTK 2 et une GTK 3 ![]()
Le 06 novembre 2015 à 16:17:37 Runnymede a écrit :
Le 06 novembre 2015 à 11:18:21 DuckSauce a écrit :
Mate est compatible GTK3 maintenant?Depuis la 1.10 MATE à deux versions, une GTK 2 et une GTK 3
Oui mais la version GTK3 est toujours considéré comme experimental, j'ai demandé par IRC a Clément Lefèbvre, le créateur/fondateur de Mint quelques infos a ce sujet, voici ce qu'il m'a répondu :
<moi> Avec la version 1.12 de Mate, est-ce qu'il devient compatible GTK3 maintenant ou il faudra attendre la prochaine version ? est ce que pour la version 18 il y aura un changement de version de Mate (par exemple une 1.14) ?
<clem> 1.14 dans 18 --> oui
<clem> pour GTK3... c'est deja plus ou moins compatible
<clem> on build pour GTK2 par contre
<clem> enfin, c'est complique..
<clem> mate-system-monitor par exemple on l'a passe en GTK3
<clem> on en parle au sein de l'equipe, tot ou tard on basculera surement vers GTK3
sinon les nouveautés de Mate 1.12 :
http://mate-desktop.org/blog/2015-11-05-mate-1-12-released/
Les $variables permettent aussi d'améliorer la lisibilité je trouve. On les remarque directement, même sans colorisation ![]()
Mate Desktop est dev par l'équipe de Mint aussi? ![]()
MATE ne fait pas partie de projet Mint, mais l'équipe de Mint y contribue grandement. À la base, c'était un fork de Gnome 2 dans le AUR.
En effet, je viens de tester et c'est assez expérimental.
A terme, ils ont pour objectif de finir la partie GTK3, d'abandonner le support GTK2, et une fois ceci fait, de porter MATE à Wayland.
Ah ok d'où les infos que certains dev ont.
Par contre c'est triste de voir à quel point XFCE est délaissé par les dev et n'avance que très peu ![]()
lvl hard
(Ne postez pas sur le topic
)
Le 06 novembre 2015 à 17:23:31 ShadowwF a écrit :
Les $variables permettent aussi d'améliorer la lisibilité je trouve. On les remarque directement, même sans colorisation
Bah je ne sais pas trop. Je ne suis pas convaincue que sa améliore tant la lisibilité. Et puis il y a vraiment des situations ou tu programme sans coloration (colorisation? Quelle terme est le mieux) ?
ZelteHonor
https://coosoft.wordpress.com/2013/02/24/the-perl-vs-python-debate/
Et des screens de ce que la commu' pense de t'as question:
- 
- 
Le CPAN permet aux utilisateurs de Perl de compiler des librairies et de les installer très facilement, il est mature et extremement complet. Et contient presque tout les modules inimaginables. ![]()
Il est bien pour l'embarqué, stable, et il est spécialement optimisé pour la manipulation de fichier et de chaîne de caractère(c'est lui qui a crée les regexs PCRE). Il sera beaucoup plus rapide que beaucoup d'autre langage dans ce domaine.
Il comprend également quelques features que les shells ont, on peut très facilement, créer un processus, le piper, envoyer des données au travers de ce dernier avec le Perl, utiliser des operateurs des shells classiques comme |, <<, |<< et j'en passe. Ce qui est la raison pour laquelle selon moi c'est LE langage de script pour les administrateurs Linux.
Mais il convient aussi aux autres administrateurs. ![]()
Je le trouve aussi plus fun à utiliser. Avec ces nombreux opérateurs, et tout les chemins par lesquels on peut passer pour arriver au même but. (d'ou son slogan: There Is More Than One Way To Do It), on ne risque pas de se lasser de lui.
Un pro du Perl peut tripler une liste de nombre en faisant:
my @triples = map { $_ * 3 } @nombres;
Mais un débutant va peut-être encore penser impérative et démarrer une boucle for...
Le Perl est multi paradigme. Impérative, Fonctionnel, Générique, OO, tout ce que tu veux. Il n'impose aucun paradigme, ni style de programmation, mais laisse la liberté au programmeur de faire ce qu'il veut.
Et encore, à je ne parle que de Perl 5, mais Perl 6 sera encore mieux, avec de nouvelles features, comme des macros par exemple.
+ bonus: http://perl.developpez.com/tutoriels/perl/interview/perl6/larry-wall-2015-07-14/
rangerprice
Alors j'ai tous lu et c'est en effet très intéressent. Je suis d'accord sur certain point et en désaccord sur d'autre. Je parle du premier lien. Mon langage préféré étant l'Haskell je le gardais en tête pendent la lecture.
La première partit sur les critiques du Perl est intéressante, car j'en avais vue quelque une de critique. Je n'ai pas vraiment grand chose à dire à part que une justification pour le $var c'est que les noms de variable peuvent commencé par autre chose que des caractères alphanumériques. Je ne suis pas sûr que sa sois si important, mais bon. Je vais donner un peu mon avis sur plusieurs point comparatif avec le Python. Si je parle seulement du Python dans une section c'est que je part du principe que ce n'est pas le cas du Perl. C'est un petit pavé, peut-être plein de faute et qui ne contient que mon humble avis.
Batteries Included
Je suis d'accord avec la partit battery included. Je suis d'avis que c'est mieux une base de "package" facile d'accès qu'avoir trop d'outil inclut de base. Bon il faut un minimum d'outil parce que sinon sa peut devenir frustrant. J'utilise quand même Archlinux alors c'est pas dur de voir d'où sa viens. (AUR
) Pareil pour l'Haskell qui a Hackage (qui est un peu une jungle) et Stackage pour ceux qui n'aime pas les jungles. C'est donc un bon point pour le Perl par rapport au Python je l'accord. (Python n'a rien de similaire a CPAN, AUR ou Hackage à ce que je sache non?)
Many Different Versions
Pour le problème de la version de Python je crois que Python 2 a bien commencé a vouloir mourir avec les distributions qui passe a Python 3 par défaut. Donc ça c'est un gros plus.
Syntactic White Space
Je comprends sa critique de cette fonctionnalité, mais je ne suis pas vraiment d'accord. Je n'aime pas vraiment les accolades. Puisque du bon code doit être bien indenté ce n'est pas si grave si c'est obligatoire. J'aurais tendance à dire que sa force un peu le code lisible. Mais son commentaire sur les lignes longues est valide même si idéalement on devrait essayer d'évité les lignes trop longue. L'Haskell se base aussi sur l'indentation, mais de manière moins rigide que le Python. Aussi tu peux utiliser des accolades et des point-virgules si sa te chante. Donc pour le Perl c'est un point neutre, parce que bon les accolades c'est populaire.
Syntax
Bon je trouve sa critique du (:) un peu forte, parce qu'un programmeur Python pour dire la même chose du ($). Pour ce qui est de la façon procédurale de faire les choses (pouvoir faire len(liste) ou liste.length() ) c'est peut-être pour un but éducatif? Je suis dans un cours d'introduction a la programmation (je sais programmé) et l'enseignant a évité systématiquement la notation objet.méthode() jusqu'à ce qu'il ai vraiment parlé d'objet. Mais sinon je dois admettre que sa ne fais pas très objet len(liste).
Non-Standard Scoping
Bon je dois admettre que je trouve que c'est un choix étrange. Le fais, que si je déclare une variable non seulement celle-ci va irrémédiablement resté jusqu'à la fin de la fonction, mais que en plus elle va existé dans toute les fonctions que je vais appeler. Je penses que une fonction ne devrait avoir accès qu'a ses paramètres et les valeurs globals. Il faut dire par contre que les variables qui reste comme ça ne sont par contre accessible que en lecture et que toute tentative de réassignation (sans les keyword global ou nonlocal) va faire en sorte que la variable global va être caché par la nouvelle définition local.
Closures And Anonymous Functions
Bon le fais que les lambda sois limité risque potentiellement de me déranger quand je vais faire du fonctionnelle. Le Perl à l'avantage comme ses fonctions anonymes sont aussi puissante que les normales.
No Data Privacy
Bon... c'est un choix vraiment particulier des créateurs de Python et je dois dire que je suis assez en désaccord. J'aime que les choses sois bien séparer et voir que tous est public me dérange un peu. Je ne sais pas a quel point sa peut être un problème. La convention de visibilité avec les underscores est similaire a celle des constantes toutes en majuscule. Une simple convention, car en pratique sa ne change pas vraiment grand chose. Pour le cas, des fausses constantes considérant que en Haskell tous est une constante, c'est pratiquement une hérésie.
No Variable Declarations
Bon ça je dois dire que sa me démange un peu et que en effet avoir un keyword var sa n'aurais pas fais de mal. C,est une bonne chose que le Perl, ai choisis de déclarer c'est variable. MAIS! Pour le Python, au moins si tu utilise une variable que tu n'a jamais créer sa plante a l'exécution contrairement au PHP qui va créer la variable en l'initialisant a la valeur null.
More Errors Are Detected At Run Time Than Is Desirable
ÇA! Je penses que détecté des erreurs a la compilation est vraiment fabuleux. Aussi le fais que le Perl ai un opérateur pour les Strings différent de celui de l'arithmétique est une excellente idée. Simplement du point de vue de la logique. Idéalement des erreurs devrais être détecté a la compilation et non a l'exécution, car lors de l'exécution il y a un risque que ce bug passe inaperçue tandis que à la compilation c'est inévitable. Le Haskell est un champion dans ce domaine, car une fois un programme compiler il te garantie que a l'exécution il n'y aura pas d'erreur de type ainsi que beaucoup d'autre erreur. En général, si sa compile tu a beaucoup de bonne garantie. C'est un gros défaut des langages comme Python de ne pas pouvoir faire cela.
Data Typing
Là dessus je suis assez difficile et je prône la méthode de l'Haskell. Pas de conversion implicite. MAIS! Le compilateur devine les types a la compilation (ou plante en cas d’ambiguïté qui pourrais provoquer une erreur de type) et donc pas besoin de préciser les type dans plusieurs cas.
Je passe donc à la conclusion. Sa m'a convaincue que le Perl n'est pas mauvais et si on m'en parle un jour je n'aurais pas d'avis vraiment négatif. Par contre, je ne penses pas l'apprendre à moins d'en avoir particulièrement besoin. Merci de ta réponse!
Mon langage préféré étant l'Haskell
Hodor ? ![]()
Le 07 novembre 2015 à 19:41:18 Seasmoke a écrit :
Mon langage préféré étant l'Haskell
Hodor ?
Hein? J'ai pas compris? (Je connais Hodor de Game of Throne, mais là.)
Dîtes une idée de comment changer la langue de transmission-qt? Il ne prend pas en compte ma locale et est en anglais contrairement à la version gtk. ![]()
Hein? J'ai pas compris? (Je connais Hodor de Game of Throne, mais là.)
Laisse tomber, c'était une comparaison qui m'avait longtemps fait sourire. ![]()
Lord-of-Flames
No idea, mais essaie Deluge/rTorrent, ils sont tellement mieux je trouve. ![]()
Après presque 3 jours j'arrive enfin à me connecter , non mais sérieux des captchas google , qui a pu avoir l'idée de mettre ce machin ? ![]()
Bref je crois qu'il est temps que je quitte le navire avant que celui-ci me fasse couler.
Le 07 novembre 2015 à 22:33:25 Yamironin a écrit :
Après presque 3 jours j'arrive enfin à me connecter , non mais sérieux des captchas google , qui a pu avoir l'idée de mettre ce machin ?Bref je crois qu'il est temps que je quitte le navire avant que celui-ci me fasse couler.
Même désagréable découverte...
RIP Seasmoke ![]()
Pourquoi il a supprimé son compte? ![]()
Peut-être qu'on lui a supprimé sans qu'il le demande.
![]()
Ça fonctionne comment la suppression? Tu as du temps entre la demande et la suppression si jamais tu changes d'avis? Et une notification qui s'affiche?
Sinon j'ai trouvé la réponse à ma question pour transmission-qt https://bugs.archlinux.org/task/20982?string=transmission&project=1&type[0]=&sev[0]=&pri[0]=&due[0]=&reported[0]=&cat[0]=&status[0]=open&percent[0]=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=
De ce fait j'aimerai bien ajouter la trad fr en patchant avec https://trac.transmissionbt.com/attachment/ticket/5164/french_translation.patch
Mais le patch the .pro file to add french translation c'est pas très compréhensible pour moi. (jamais utilisé la commande patch et le .pro c'est quoi? )