mrlem a écrit 532 commentaires

Hmmm, pas en phase avec ta vision avant la révolution : là où tu as détaillé les collectivités locales, tu fais fi de la hiérarchie des titres de noblesse (qui constitue aussi un joli bazar).

Assurance Maladie En Ligne

Oui il y a eu des progrès.
Et oui, je suis conscient que c'est sans le moindre doute un gros bourbier : mais pour les nouveau domaines, au moins, ils pourraient faire un effort.

Pour la CNIL et l'Assurance Maladie, c'est effectivement pas directement gouvernemental, MAIS ce sont des organismes publics. Et la CNIL est tout de même un organisme créé par une loi et avec une place dans la loi, on peut ergoter en disant qu'ils ne font pas partie du gouvernement, mais ça a toute sa place dans le .gouv.fr en tant qu'organisme officiel.

D'ailleurs, un nom que je n'ai pas mis, mais dont je trouve particulièrement cocasse qu'il ne soit pas en .gouv :

• gouvernement.fr

;o)

Ca empêche pas de les réserver. Mais ça ne devrait pas être les adresses de référence. Et progressivement, les gens se déshabitueraient de cette mauvaise habitude.

D'ailleurs, plutôt que de me contenter de râler sur linuxfr.org, dans l'esprit du libre, je viens de faire un "bug report" un peu plus poli sur numerique.gouv.fr.

D'ailleurs, je ne sais pas si je suis le seul que ça énerve, le plan de nommage des noms de domaine utilisés par l'état.

Si on veut apprendre au gens à ne pas aller sur n'importe quel site qui se prétend gouvernemental avec un joli logo, je trouve que c'est la pire idée du monde de créer des noms juste en .fr pour tout et n'importe quoi. Quelques exemples parmi une myriade :

• ameli.fr
• monespacesante.fr
• service-public.fr
• sante.fr, ars.sante.fr
• signal-spam.fr
• cnil.fr

Si on veut que se développe de bonnes pratiques chez les usagers services, il faudrait peut-être que les services arrêtent de troubler le jeu ? Pour moi un grand pas en avant serait de décommissionner tous ces domaines au profit de sites en .gouv.fr, comme ça la règle est elle simple : c'est pas en .gouv.fr ? c'est pas l'état.

C'est à la fois paradoxal mais tout à fait compréhensible.

L'identité éditoriale pourrait effectivement se lire au travers :

• sur quels sujets on appuie sur le côté anxiogène
• sur quels sujets on essaie de calmer

C'est aussi la remarque que je me suis fait en arrivant sur la page d'accueil :)

SWT et la plateforme RCP, par contre, dans mon souvenir, ils se tordaient un peu les neurones en terme de patterns, des fois ;-). Pour ma part, j'avais fini par le lâcher pour JavaFX.

Le seul que je connaissais, java-gnome, était un peu moribond, dans mon souvenir (je n'ai pas recreusé, vu que je visais du natif, sans JVM donc).

Mon projet ne peut servir à ça, et n'est pas transposable : il repose sur la cinterop de Kotlin native (en Java, ça passerait par JNI), et pour offrir une API pratique sur les typealias et les extension functions, concepts qui ne sont pas présents en Java (sauf si j'ai raté des choses dans les versions récentes, que je ne suis plus que d'un œil distrait).

Désolé :-P

Les DSL sont vraiment pratiques pour décrire ton UI programmatiquement (les 2 autres bindings en proposent, d'ailleurs), mais ce n'était pas mon objectif premier.

Je voulais bénéficier de l'édition graphique de Glade en priorité : pour pouvoir développer avec IDEA d'un côté et Glade à côté, et que tout se mette à jour tout seul.

Après, je pourrais toujours rajouter un DSL par la suite, mais mes priorités sont Glade et progresser dans la couverture de mon binding GTK (qui est encore ridiculement réduite, j'ai pris plein de raccourcis).

Très bonne question : j'aurais aimé utiliser un binding existant et m'appuyer dessus, mais j'ai finalement choisi de ne pas les faire pour les raisons suivantes :

• la lib https://github.com/kropp/kotlin-native-gtk : est intéressante par le fait qu'elle utilise GIR la génération de binding, mais par contre elle garde je trouve une API trop bas niveau à base de CPointers.

• la lib https://github.com/Doomsdayrs/kotlinx-gtk offre bien des objets de haut niveau, mais il manque quelques éléments pour lesquels il va à mon avis tomber sur des problèmes avec l'approche par wrappers :

  • par exemple, Container.getChildren() n'est pas implémenté (cf https://github.com/Doomsdayrs/kotlinx-gtk/blob/main/nativex/src/nativeMain/kotlin/nativex/gtk/widgets/container/Container.kt#L51). Et sauf erreur, quand il voudra l'implémenter, il va devoir soit regénérer à chaque fois des wrappers, soit en garder une liste parallèle qu'il mettra à jour dans tous les autres appels : son approche actuelle semble être de regénérer les objets wrapper sans arrêt (cf https://github.com/Doomsdayrs/kotlinx-gtk/blob/main/nativex/src/nativeMain/kotlin/nativex/gtk/Application.kt#L43), ça ne me paraît pas efficace
  • autre exemple, pour glade, ce n'est pas fait, et il le prévoit, mais avec les wrappers et son approche des réinstancier à la volée, il aura : une arbo générée par GtkBuilder, ne fournira que les objets wrapper de top-level, et leurs méthodes passeront leur temps à réinstancier des objets wrapper.

• mon objectif était aussi de me faire les dents sur l'interopérabilité avec les libs natives

Pour moi, le binding des fichiers glade est une priorité, parceque c'est ce qui me manque le plus dans le dev GTK actuellement. Or avec des wrappers c'est plus compliqué. Ça laisse le choix entre 1/ réinstancier des objets wrapper sans arrêt, ou bien 2/ créer et maintenir une arbo répliquée d'objets. Je ne trouve ça ni efficace en mémoire, ni élégant, ni pratique en terme d'implémentation. D'où mon expérimentation d'un binding sans objets wrapper.

Effectivement, je comprends qu'on puisse voir ça comme une déclinaison de https://xkcd.com/927/ ;-). Mais ce n'est pas un détail d'implémentation des libs existantes qui me gêne (sinon j'aurais été aider à les compléter / fixer), mais l'approche générale, leur postulat de départ.

Voilà, après, mon plugin gradle de génération de binding glade pourrait sans trop de souci s'adapter à une autre lib de binding.

J'espère que cela répond à ta question.

Sinon il y a l'option JavaFX qui doit être assez versatile pour ce genre de choses.

Moi je préfère la radius, et j'en connais un rayon !

Mon approche intuitive est la même que toi, peut-être un facteur générationnel joue-t-il ?

Mais, je comprends également l'autre point de vue.

Tu le dis-toi même, la proportion de femmes qui étudient en informatique a diminué sans raison évidente. Cela veut simplement dire que des biais sociétaux (durs à identifier de manière formelle) se sont mis en place, qui ont pour effet non pas d'interdire, mais de décourager l'engagement dans cette voie.

Les initiatives engagées des mouvements qui cherchent à encourager l'apprentissage / études / carrières en informatique pour les femmes peuvent en effet être considérées comme une rupture d'égalité de traitement. Mais on peut aussi les voir comme des tentatives d'impulser un mouvement de ré-équilibrage dans la perception sociétale de notre domaine.

En tant que tel, et quel que soit mon propre avis, ça ne me semble pas illégitime du tout.

Ce n'est pas propre, mais c'est hélas requis car freeglut3-dev ne fourni pas de fichier .pc, requis pour pkg-config.

Sinon, pour également pouvoir utiliser les fonctions en glu*, au lieu de faire :

pkg-config --libs gl

on peut faire :

pkg-config --libs glu

… qui génère le -lGL -lGLU mentionné. (ça sert notamment pour certaines fonctions bien pratiques genre gluLookAt, dans mon souvenir)

Damned, grilled!

Tu sembles avoir bien analysé le problème. Regarde donc tes initialisations de min et indmin, et demande toi ce qu'elles impliquent.

Ce que je trouverais intéressant, sans gros changement, ce serait qu'au second tour on puisse :

• Soit voter pour un candidat
• Soit voter contre un candidat

Le vote contre étant au final porté au crédit de l'autre candidat.

Le résultat serait le même en terme de candidat élu, mais on aurait en plus une donnée importante pour évaluer l'adhésion au programme proposé, ce qui empêcherait l'élu de se gargariser d'un pourcentage avec une interprétation que rien ne permet objectivement d'étayer ni d'infirmer.

Je vais me faire l'avocat du diable, mais ce système ne tiendrait qu'à condition d'une certaine stabilité de la monnaie et des prix : en cas d'une forte variation, on pourrait avoir une extrême paupérisation des retraités.

Chaque expérience et chaque histoire est différente, mais j'ai eu des doutes proches il y a quelques années.

J'ai résolu certains problèmes de fond en :

• allant chercher de l'aide auprès d'un psychologue/sophrologue (mais après, whatever works for you) pour détricoter tout un passif accumulé depuis l'enfance
• renouant avec l'activité physique
• mettant une priorité plus grande sur le sommeil : manquer de sommeil peut être une conséquence de tes problèmes perso, mais ça en devient aussi rapidement une cause… C'est un cercle vicieux très destructeur.

Par ailleurs, ayant dû accompagner pendant une longue période, au quotidien, en parallèle d'un travail très exigeant la fin de vie de ma compagne, j'ai une petite idée du genre d'impasse dans lequel on se sent quand la vie perso déborde sur la vie pro est que c'est juste trop. J'avais fait le choix de compter sur l'humanité des gens avec lesquels je travaillais, et c'est ce qui m'a permis de tenir le coup pendant cette période. Je n'étais pas à mon niveau, je le savais, ils le savaient. Je sais que ce n'est pas possible partout, mais bon, à un moment donné, quand la seule issue qui se profile est une dépression qui ne rend service à personne, il est légitime d'utiliser toutes les soupapes qu'on peut.

En tous cas bon courage, et je te souhaite de pouvoir un jour prochain regarder ce que tu vis maintenant de manière apaisée.

C'est différent. Sinon, pour les flemmards, tu peux faire la même chose avec :

• coller (ctrl-v)
• cliquer sur le bouton "Nouveau calque" de l'onglet "Calques"

Sinon pour ce problème spécifique : plutôt que des clics droits un peu partout, tu peux juste faire un clic gauche n'importe où sur le canevas, en dehors du calque flottant. L'utilité de cette étape est de permettre de positionner ce que tu as copié sur le calque cible.

Quand on veut réellement gérer la diversité des affichages qu'on peut trouver sur Android, utiliser les dps ne suffit pas. L'idéal est :

• de ne rien mettre en dimension, sauf les marges / paddings, mais utiliser des layouts plus adaptatives à base de contraintes
• d'avoir des layouts séparés pour les situations très différentes (portrait/paysage, plein de dp/pas beaucoup de dp, etc), le plus dur étant de gérer tous ces cas sans trop alourdir le code

Après, je ne sais pas si Kivy permet de faire ce genre de choses, mais c'est déjà un sujet loin d'être trivial avec les outils de dev Android ^{^}

Zut, c'est pas encore 'dredi, mais j'y vais quand même !
Tant qu'à faire :

• maven -> gradle
• eclipse -> idea

;)

On termine à l'un des pôles après une plus ou moins longue spirale suivant la direction exacte prise ?

(ou alors on tombe au bout de la terre si le complot est avéré, mais là je serais curieux de voir ce qui se passe en terme de gravité : on est attiré vers la tranche ?)