GuieA_7 a écrit 689 commentaires

Si les experts pour un outil sont déjà rares et concentrés dans peu de boites, la mutualisation est plus ou moins déjà faite! Il ne reste que les bénéfices des actionnaires, ce qui représente moins qu'on l'imagine, du coup il y a peu à gagner économiquement parlant et les clients ne veulent pas devenir gestionnaires de projets logiciels.

C'est vrai, mais reste le risque qu'avec un unique logiciel propriétaire dans un domaine, que l'éditeur se mettent à augmenter les prix des licences sans aucune "vraie" raison (il le peut, c'est tout, car les clients/utilisateurs sont dépendants). Et plus le logiciel va être vieux/gros/complexe/puissant, plus l'écriture d'un logiciel concurrent (et éventuellement libre) va être compliqué, car il va falloir beaucoup d'effort et de temps pour être au niveau, et donc la dépendance va se renforcer au fil du temps.

Il me semble que c'est plutôt pour faire des interfaces de jeux vidéos (donc plutôt à l'intérieur d'un contexte OpenGL par exemple) plutôt que des interfaces classiques de bureau.

Ceci dit les TK classiques (Qt/GTK/…), le Web (où l'IHM est un document qu'on va manipuler par JS) et les jeux vidéos se sont beaucoup inspirés les uns des autres. Par exemple, dans les TK on a vu apparaître des scene graphes inspirés directement du jeu vidéo.

Du coup, on peut imaginer un TK qui permette à la fois de faire des applications classiques de bureau et faire son rendu dans un contexte 3D (en fait ça c'est déjà possible), et qui soit suffisamment puissant pour faire des applications de bureau complexes (ex: LibreOffice) tout en permettant de faire des Widgets avec des rendus très fantaisistes et des animations poussées. Et là pour le coup ça n'existe pas à ma connaissance, et ce n'est peut-être pas possible de faire un tel grand écart de manière satisfaisante. L'avenir nous le dira peut-être.

J'ai hésité à en parler car c'est, il me semble, pour le moment uniquement pour Redox, donc très confidentiel, et donc difficile d'avoir des retours sur sa qualité.

Mais au final c'est bien que tu l'aies cité.

Oui, c'est interdit de base, mais c'est faisable avec un peu de unsafe. En pratique c'est fait par la bibliothèque standard qui fournit moult collections/algorithmes (là où par exemple celle de Go va plutôt fournir des outils haut niveau pour web, mail etc…) qui vont se charger de ça (à savoir faire le très peu de unsafe nécessaires pour avoir de bonnes performances) et du code classique sera bien souvent avec 0 bloc unsafe.

J'aimerai aussi voir un ToolKit de GUI native écrit en Rust ; peut-être pourrait-il utiliser une approche différente de ce qu'on trouve en Qt/GTK. Non pas parce que ce sont de mauvais projets, mais parce que si c'est pour avoir la même approche, autant juste avoir des bindings.

Je ne sais pas quel est l'état du binding GTK pour Rust, mais en l'occurrence quand je m'y intéressais au final pour une GUI en Ada, le mieux était aussi son binding GTK ; ce qui ne remet pas en cause l'utilisabilité de Ada pour autant.

En revanche depuis le temps, mis à part l'IDE libre pour Ada (Gnat), je n'ai jamais croisé de programme de bureau en Ada ; là encore ça ne remet pas en cause les grandes qualités du langage. Mais vu son âge, il y a peu de chance que cela change ; parce qu'il a largement eu le temps de devenir populaire, et que ça n'est pas arrivé (que ce soit pour de bonnes ou de mauvaises raisons).

C'est la force de Rust d'avoir réussi à faire collaborer l'approche fonctionnelle de OCaml/Haskell (pour le typage entre autres) avec une gestion fine des ressources (potentiellement bas niveau). Cette dernière va venir d'autre langage comme Cyclone (l'emprunt de référence notamment) ou C++ (les réflexions sur les closures dans les dernières versions ont été suivies de près par la communauté Rust ; principalement sur la politique de capture de l'environnement—copie contre référence). On trouve d'autres inspirations, et c'est une bonne chose que d'être aller chercher les qualités un peu partout ; par exemple python a inspiré certain élément de syntaxe. Donc le changement de paradigme n'est pas la seule chose importante ; sinon Ocaml avait déjà réussi à unifier impératif et fonctionnel.

À noter que l'inspiration va dans les 2 sens ; par exemple ce papier sur une possible gestion des ressources dans les langages fonctionnels (ici testée dans Ocaml) :
http://lambda-the-ultimate.org/node/5511

j'ajouterai que pour certains Rustafariens, la principale intérêt de faire du Rust ne vient même pas du langage lui-même mais de son environnement, avec cargo et crates.io.

Force est de constater qu'ils ont joué exclusivement avec des distributions "pré-machées" et […]

En même temps s'il y a (c'est un exemple) 100 fois plus d'utilisateurs de Debian que de Slackware, il n'y a rien d'étonnant à ce qu'il y ait 100 fois plus d’incompétents sous Debian. Il y aura aussi 100 fois plus de projets cool basés sur Debian, mais ça tu le mettras sous le tapis car ça ne sert pas ton propos…

Je suis contre l'idée d'une note (et encore plus de seulement une note), mais plutôt une liste de points factuels et vérifiables. Les notes sont pratiques car très synthétiques, mais elles cachent en effet beaucoup trop les nuances sous-jacentes, et vont alors être bien souvent trop subjectives.

Ça serait sûrement perfectible (qu'est-ce qui ne l'est pas ?), mais on nous a parlé de boites qui ne fournissent pas de makefile ou cachent des dépendances propriétaires (ce qui dans mon échelle de valeurs libriste est plus grave que les chemins en dur, pour reprendre ton exemple), mais on attend toujours des exemples.

Je me suis peut-être mal exprimé ; ou tu as lu trop vite. Je réessaie.
Il y a sûrement des gens qui font plus ou moins semblant que faire du libre (ou dont les pratiques derrière annihilent au moins une partie des 4 libertés). Ça serait une bonne chose d'avoir une liste de ces mauvais acteurs.

L'idée n'était pas de taire ces noms (vu que je demande moi aussi des exemples) pour ne pas faire peur aux décideurs, mais plutôt d'avoir une liste de logiciels/boîtes à éviter (liste qui pourrait servir entre autres à rassurer des décideurs sur leur choix, qu'ils viennent eux-même ici ou pas).

J'avoue j'aimerai aussi des exemples concrets. Certes en faisant attention à ce qu'on dit (pas de procès d'intention), j'aimerai éviter aux admins LinuxFR le stress d'une nouvelle mise en demeure, mais des exemples de softs avec des pratiques douteuses à priori constatées.

Parce que c'est déjà difficile de faire passer le message du "logiciel libre c'est bien" aux décideurs ; mais si en plus on rajoute un "attention il y a des arnaques, mais vous devrez vous plonger dans la technique pour les débusquer", ça rend la chose impossible.

Et enfin, j'aurais envie de m'attarder sur le côté théorique plutôt que pratique. Trio propose un nouveau paradigme de programmation, une évolution. Ce n'est pas lié à Python, même si sa proposition concrète est faite avec. Mais qu'est-ce que ça peut donner dans d'autres langage ? Après tout, certains langages possèdent suffisamment de souplesse pour obtenir peu ou prou le même résultat.

Comme dit dans l'article de base, le concept appelé 'nursery' dans Trio n'est pas complètement nouveau (Trio apporte cependant quelques subtilités/variations), et se retrouve plus ou moins ailleurs. Il y a par exemple la lib Rayon pour Rust qui adopte un peu la même approche je crois.

Edit: c'est au commentaire de Glandos que je voulais répondre.

C'est bien le problème ; c'est souvent une mauvaise idée, mais pas toujours. Aussi il vaut mieux dans un premier temps rester sur quelque chose de haut niveau ; d'autant plus que les langages essaient de garder la compatibilité et donc enlever une fonctionnalité utilisée par plein de programmes n'est pas forcément possible (donc on doit garder une erreur de conception ad vitam). Mais à l'usage on voit bien que des entraves aux contraintes s'avèrent "nécessaires" (puisque les performances peuvent être une fonctionnalité).

Par exemple en Rust les contraintes haut niveau amènent des garanties mémoires qu'on n'a pas en C, et certaines optimisations deviennent alors possibles (le compilateur C ne peut pas prendre certaines décisions optimisantes car il pourrait créer des bugs). Mais à côté de ça on a les blocs unsafe qui permettent dans de rares occasions de faire des optimisations qui seraient vues comme des erreurs par le compilateur. Il est évidemment conseillé de s'en servir le moins possible  ; et au final c'est surtout les libs de base (genre les collections) qui vont s'en servir, les programmes classiques s'en passent très bien.

Dans l'absolu tous les langages ont ce genre de déverrouillage des contraintes, vu qu'ils permettent tous de s'interfacer avec du code C. C'est bien souvent pour pouvoir réutiliser du code (ça aurait été faisable dans le langage haut niveau, mais ça prendrait des ressources), mais c'est c'est souvent assumé qu'on va faire une partie critique au niveau performances en C (ou C++, Rust etc…).

Tout à fait. Mais après le diable se cache dans les détails ; sinon antre 2 langages avec la même approche (ex: impératif objet, fonctionnel pur…), celui plus haut niveau serait toujours intrinsèquement le meilleur. Mais pour des questions de performances notamment, ce n'est pas vraiment le cas [*]. L'article en parle lorsqu'il dit que break/continue on été ajoutés à l'idée de base des for/while ; et de même manière ce genre de compromis arrive dans sa propre bibliothèque.

Donc on sait que dans l'absolu on peut toujours faire mieux en rajoutant de la sémantique ; mais il y a une infinité de façon de le faire et reste a trouver les meilleures façons (ce qui est donc difficile).

[*] en pratique on va essayer quand même essayer d'écrire le plus possible dans le langage de plus haut niveau.

J'ai lu l'article de base de l'auteur de Trio il y a quelques jours et je pense qu'il va influencer ma pensée pour le reste de ma vie de codeur. Ce n'est pas tellement la présentation de Trio qui est importante (la lib est sûrement très bien, ce n'est pas la question) mais la réflexion de fond sur la conception des programmes.

C'est très amusant de voir comment l'instruction GOTO est passé d'indispensable ("si on met des contraintes dessus on limite la conception") à inutile/dangereux (les structures de contrôle ajoutent certes des contraintes mais en fait apportent de nouvelles perspectives) ; et que pour la programmation concurrente on en est encore dans la phase 1 (on va naturellement penser que les contraintes vont être des limites).

Si on disait OpenSource c'est quand les sources sont accessibles et FreeSoftware […]

Avec le temps le terme FreeSoftware va avoir une bonne aura (puisque Linux, Apache, PGSQL s'en réclameront) et le terme OpenSource une aura médiocre (parce que sinon les logiciels Shared Source auraient cartonné). Et il y aura des gens qui parleront de leur logiciel OpenSource en le désignant comme FreeSofware afin de bénéficier de cette aura (ils le feront peut-être inconsciemment, mais le feront quand même), et trouveront des prétextes pour le faire ("oui free ça veut dire gratuit et notre bidule est gratuit", "on offre des libertés dont ça peut être compris comme free" …). Et on retombera sur le même problème, puisque dans le fond on aura rien changé (des gens veulent le beurre et l'argent du beurre ; et il faudra toujours des gens vigilants pour empêcher ces abus).

NB: note bien que je n'affirme à aucun moment que c'est que que feraient les gens de NumWorks.

Le fait qu'on ne puisse pas parler de "libre" ou "Open Source" dans ce cas est un fait. Après il y a je pense 2 types de personnes :

• celles qui pensent qu'on peut considérer qu'un projet est "un peu libre", ou "plus libre que les concurrents", et que c'est un pas dans la bonne direction.
• celles qui pensent que c'est soit libre soit pas libre, et que les "vous pouvez voir les sources mais pas modifier/vendre/.." sont juste de la poudre aux yeux hypocrite.

Les 2 positions sont acceptables ; il suffit juste de se faire son propre avis et ne pas partir dans des débats d'opinions stériles.

Certes mais un pote à moi utilisait régulièrement en 2001 un filtre de déformation dynamique sur Toshop. Donc ça me semble techniquement jouable ; mais oui il faut sûrement éviter de le faire de manière naïve.

Mais ça demande du temps de développement ; et Toshop en 2001 avait probablement nécessité plus d'années*hommes que Gimp en 2018.

…je retiens ma respiration et je me roule par terre."

Ah oui en effet je ne l'avais pas vu ; mis à part que je trouve ça globalement moche que after() soit appelée N fois au lieu d'une seule, est-ce que ça ne serait pas là le problème (je précise que je ne connais pas spécialement Tk) ?

J'ai du mal à croire que ton programme fonctionne même avec une seule bille. Pour cela il faudrait quand tu appuies sur ton bouton démarrer créer les billes, puis te débrouiller pour que dans sa boucle infinie TK appelle une autre fonction toutes les 15 ms par exemple (pour 60 images par seconde) qui elle déplace tes billes et demande un ré-affichage. Là ta fonction demarrer() est juste appelée une fois quand tu cliques sur le bouton…

Dans un terminal graphique classique (et de manière général toutes les applications graphiques), le dessin est principalement calculé par le CPU.

Par exemple dans le cas d'un terminal noir & blanc, c'est le CPU qui va dessiner une grande image (qui sera ensuite envoyé à la carte graphique), et va pour chaque pixel décider s'il est noir (fond) ou blanc (il appartient à un glyphe de caractère) ; pour un terminal avec anti-aliasing et une image de fond par exemple, on comprend que ça peut faire encore plus de calculs.

J'imagine que pour un terminal qui utilise la carte graphique, la fonte est convertie en une texture, et chaque glyphe à afficher est un quad (quadrilatère) avec les coordonnées de textures qui vont bien. Du coup, c'est vraiment la carte graphique qui va calculer l'image finale, et on pourra garder un affichage à 60 images par seconde même avec un programme qui génère beaucoup de texte.

On peut penser au browser Web Servo de Mozilla dont le moteur de rendu s'effectue aussi sur la carte graphique (il utilise par exemple un projet nommé 'pathfinder' qui fait le rendu de police sur la carte graphique) et dont les performances sont meilleures que celles des browsers classiques (mais le rendu est encore buggé). On imagine bien que c'est une tâche colossale de gérer tout HTML, alors que pour afficher un terminal c'est bien plus simple.

je pinaille peut-être

Les retours constructifs sont appréciés au contraire.

mais si je suis sur un devis, le bouton créer devis ne sert quasi à rien.

Ce bouton de création est présent dans toutes les fiches de manière à avoir quelque chose de cohérent ; la place qu'il prend serait, en l'état, de toute les façons perdue puisqu'il est à coté du bouton de retour à la liste. Et peut-être qu'il ne vous sert pas mais qu'il sert à quelqu'un qui fait souvent des devis à la suite mais pour qui une duplication serait plus lente (car peu de chose en commun entre les devis).

un bouton permettant de dupliquer serait plus intéressant.

Ça tombe bien, il y en a un. Le bouton "Cloner" est à côté du bouton de suppression, à droite de la 'barre' de titre.
Les boutons au dessus de la barre ('liste' & 'créer') sont en rapport avec le type de fiche, les boutons dans la barre sont en rapport avec la fiche actuelle (donc modification, suppression, clonage, téléchargement…).

car sur cette liste, l'action la plus courante sera d'interagir avec cette liste, et non de créer autre chose.
ce qui est perturbant, c'est qu'on voit à deux endroits sur cette liste de devis des boutons +

Les filtres et les vues de liste sont directement en rapport avec la liste (puisqu'ils permettent respectivement de filtrer les lignes et de choisir les colonnes de ladite liste). Ils correspondent bien à une interaction avec la liste ; les actions (sélection, création, modification, suppression) sur les filtres et les vues sont regroupées ; les boutons + ont bien un tooltip du genre "Créer un filtre personnalisé". Que vous ne connaissiez pas toutes les fonctions les 10 premières minutes ça ne me semble pas aberrants dans un logiciel professionnel qu'on est amené à utiliser ensuite des centaines d'heures.

avoir dans la liste des actions la possibilité en plus de modifier et supprimer, les actions imprimer, envoyer par mail, dupliquer.

La duplication pourquoi pas ; en revanche cela pose un problème si vous voulez rester dans la liste, car selon les règles de filtrage (ou même la pagination) la fiche nouvellement créée pourrait ne pas être affichée (ex: filtre sur la date de création). En revanche on peut aller sur la page détaillée de la fiche créée (comme quand on clone depuis une page détaillée).

Actions imprimer & envoyer par mail sur la liste: là encore pourquoi pas. Personne ne nous a demandé ça en presque 10 ans, mais ça me semble intéressant ; après évidemment chaque fois qu'on ajoute des boutons, ils sont "polluants" pour tous ceux qui s'en fichent (ce qui est toute la problématique des logiciels qui ont beaucoup de fonctionnalités).

Ça illustre bien le fait que tout le monde veut les fonctions qui lui semblent utiles/évidentes ; mais comme les gens ont des besoins différents ces fonctions évidentes sont différentes pour tout le monde (là est tout le challenge).

Évidemment Creme est un logiciel libre (et pas avec un version propriétaire à côté), donc ces modifications peuvent être faites par quiconque le souhaite. Évidemment la meilleure façon de s'assurer que Creme continue à s'améliorer passe par la contribution ; que ça soit en envoyant directement des patches ou en finançant ces améliorations (c'est comme ça que nous vivons).

je suis votre crm depuis un moment. Bravo pour le travail.

Merci.

Cependant, point de vue ergonomie, ce n'est pas limpide.

C'est toujours complexe de faire qu'un logiciel qui a beaucoup de fonctionnalités soit limpide ; c'est loin d'être parfait et nous y travaillons, mais la définition de limpide va différer chez chacun et compliquer encore plus la tâche de satisfaire tout le monde.

Par exemple : Créer un nouveau devis n'est pas si simple.

Dans le nouveau menu, il a une entrée "+ création" avec les type principaux type de fiche, et une entrée "Autre type de fiche" :

Si vous cliquez sur cette dernière entrée une "popup" apparaît :

Vous retrouvez bien une entrée pour les Devis la section "Commercial", et une 2ème fois dans la section "Gestion".

Et si vous êtes sur la fiche d'un devis existant, il y un bouton "Créer un devis" en haut de la page.

Dans les versions précédentes, il y avait bien un bouton de création de devis dans la liste des devis ; nous avons enlevé ces boutons de création dans les nouvelles listes afin de les alléger (ayant en parallèle améliorer le menu de création) et nos clients ne nous ont pas fait de remarques là dessus. Évidemment suivant les retours d'autres changements à ce propos pourront être faits.

Tu peux utiliser un deque avec une taille fixe afin qu'il ne soit pas possible de faire exploser la taille de ta liste.

from collections import deque

t = deque(maxlen=5)

# ... plus besoin du [-5:]

J'ai déjà assisté à des live sur youtube et il y'a bel et bien un chat intégré

Mon commentaire était surtout là pour expliquer qu'un live interactif de code ça peut avoir de l’intérêt, pas spécialement de débattre de Youtube vs Twitch. Comme je l'ai dit Twitch permet aussi les VODs (les lives sont enregistrés automatiquement par Twitch, en gros, et on peut les voir en replay), mais ce n'est pas le mode de fonctionnement le plus mis en avant. Et je l'ai opposé au mode de fonctionnement classique de Youtube (ex: quand on dit que Cyprien a fait XXX vue sur sa dernière vidéo, c'est pas du live) afin de prendre un exemple concret, et pas une plateforme de VOD fictive.