Il semble que certains font de bonnes appli MAC en GTK, par exemple on m'a dit du bien de l'intégration de Xamarin Studio sous cet OS… Jamais testé, juste entendu dire. Certains connaissent ?
Je n'ai rien contre la critique, ou dans tous les cas ce n'est pas ce que je voulais dire. Dire "ce qu'a fait machin c'est pourri" me va très bien, même si encore une fois c'est à prendre, à améliorer soi même ou à laisser.
Cela justifie t-il le fait d'être irrespectueux à l'égard de "machin" ?
Toi, tu n'as sans doute jamais entendu parler d'un truc qu'on appelle le libre…
Hmm ? Qu'est-ce que je rate ? Ah moins que tu ne prennes toi même les choses en main d'une façon ou d'une autre, ton utilisation du bousin repose sur le fait que d'autres en prennent soin.
J'avoue ne pas comprendre ta logique "quand X deviendra chiant niveau 2, tu regretteras d'avoir dit du pas bien sur Y chiant niveau 1000"
Non, je dis juste qu'il faut arrêter d'attendre quoi que ce soit des personnes qui ne vous doivent rien et à fortiori de leur manquer de respect parce qu'ils ne répondent pas à vos attentes.
Je répète la même chose depuis plusieurs commentaires maintenants. Vous être nombreux à ne pas être d'accord avec tout ça (vue comment sont notés mes commentaires), cela fait-il de vous des personnes complètement et détestablement ingrates ou alors il y a une faille dans mon raisonnement que je suis incapable de saisir…
Certains sont maintenant à la merci des mainteneurs de QT, toi à ceux de Xfce… Le jour où ils n'avanceront plus dans la direction qui te convient, j'espère que tu seras un peu moins odieux envers eux que tu ne l'as été dans le cas présent.
Tu as l'air de croire que les choses doivent être maintenues ad vitam aeternam et que quelqu'un doit le faire pour toi. Celui qui fait le boulot décide, et il ne doit de justification qu'à ceux qui travaillent avec lui, pas aux utilisateurs (incluant beaucoup de développeurs d'applications finales). Je ne dis pas que tous les contributeurs au projet GTK+ approuvent les changements fait par ce William Jon McCann, mais globalement si.
Cela s'applique pour la plupart des projets : si ceux qui en plus de travailler gratuitement (ou pour des clients autres que toi) ont le temps, la patience, l'envie et l'énergie pour t'écouter c'est bien, sinon il va peut-être falloir que tu reconnaisses qu'ils ne font qu'appliquer leurs libres arbitres (si ce n'est pas pour leurs employeurs) et qu'ils n'ont pas à ce justifier pour ça. Rendre disponible le travail ainsi réalisé est à mon avis respectable, mais devrait être au pire ignorer.
Le code avec les fonctionnalités que tu regrettes n'a pas disparu, libre à toi et à ceux qui en ont besoin de le maintenir… Si personne ne le fait, c'est bien que c'est chiant à faire.
GIMP 2.10 reste API compatible et au rythme où vont les sorties, 3.0 n'apparaitra pas de si tôt. Et même si à l'heure actuelle 3.0 est la version dans laquelle il est prévu de casser les choses, il s'agit avant tout du port vers GTK+3, qui risque d'être suffisament assez pénible pour que l'API soit oubliée. Par ailleurs il ne s'agit pas de toute l'API, mais uniquement de celle qui permet d'accéder aux pixels, et cette nouvelle API est quand même bien plus simple et souple que l'ancienne.
Par ailleurs, dans l'état, GEGL ne permet pas assez de chose pour pouvoir remplacer les plug-ins GIMP. Typiquement, les plug-ins complexes (qui touchent plusieurs layers, qui accèdent aux parasites, qui ont besoin d'une UI spécifique, etc…) ne peuvent pas être porté comme des "noeuds", et restent donc de simples plug-ins classiques, en remplaçant tous les gimp_pixel_rgn_init, gimp_pixel_rgns_register, gimp_pixel_get/set_*, par gegl_buffer_get/set ou similaires.
Le fait de ne pas être un "noeud" GEGL sera un jour une limitation (preview-on-canvas, travail non destructif, interface unifiée, …), mais n'empechera pas G'MIC de fonctionner comme il fonctionne maintenant, au moins pour un certain temps.
Cela étant je ne connais rien de G'MIC et de comment il s'interface avec GIMP. Mais j'ai l'impression qu'une première étape serait de tout laisser comme tel et de juste remplacer les gimp_pixel_XXX par l'API GEGL (je ne dis pas que c'est trivial pour autant). GIMP et GEGL ne sont de toute façon probablement pas capable d'intégrer un ou plusieurs "noeuds" de la complexité de GEGL au jour d'aujourd'hui.
Petite question au passage, tu trouves pas que #include est surfait et que pour tous les include système, il vaudrait mieux faire des copier coller du code que tu rajoutes pour vraiment savoir comment il fonctionne ? Parce que c'est important de savoir comment tout fonctionne, non ?
Tu es insultant, je souhaite à chacun d'utiliser le langage qui lui convient le mieux pour ce qu'il a à faire, sauf à toi.
Ce n'est ni du semi-objet, ni tarabiscoté, ni de la torture de language. De mon expérience, le combo C + GObject + Glib + GTK+ n'est pas plus difficile à appréhender ni à utiliser que C++ + Qt. Tout dépend de l'utilisation que l'on en a, mais C++ est un language qui reste extremement complexe.
L'idée de "miroir via filtres" a été discutée hier sur IRC (je ne me souviens plus des pour/contre par contre).
De façon général, les opérations non-destructives dans GIMP sont dans les tuyaux. L'infrastructure interne est plus ou moins là (notamment grace à GEGL), mais il manque l'UI et les formats de fichiers qui vont avec. Pour quand ce sera ? Aucune idée, quand quelqu'un s'en occupera et pas pour 2.10 à priori…
Pourquoi pas Qt ? Je pense qu'il faut considérer le rapport quantité de travail / gain. C'est vrai quoi, est-ce que modifier plusieurs millions de lignes de codes pour ajouter une dépendance supplémentaire c'est vraiment une bonne idée ? Et puis pourquoi Qt ? wxWidget est bien aussi…
Bon courage pour montrer que faire un tel changement en vaut la peine…
To clarify, September 15 will be our open-source developer release. At that time, we will open up our github repository, publish our roadmap, and shift our development style to be more community oriented. We intend on launching a consumer facing alpha in October. Join our mailing list to get an invite.
[^] # Re: En entreprises…
Posté par jypaigue . En réponse au journal C++14. Évalué à 1.
Par curiosité, quelles sont les raisons qui font que vous n'utilisez pas des versions plus récentes ?
[^] # Re: Support OS X
Posté par jypaigue . En réponse au journal Pas libre mais dans la tendance. Évalué à 1.
La personne qui m'a parlé de ça a écrit cet article, si tu veux plus de détails :
http://www.lanedo.com/embedding-osx-ui-elements-in-the-gtk-toolkit/
[^] # Re: Support OS X
Posté par jypaigue . En réponse au journal Pas libre mais dans la tendance. Évalué à 1.
Il semble que certains font de bonnes appli MAC en GTK, par exemple on m'a dit du bien de l'intégration de Xamarin Studio sous cet OS… Jamais testé, juste entendu dire. Certains connaissent ?
[^] # Re: Ouch !
Posté par jypaigue . En réponse au journal Au suivant: encore un projet qui va abandonner GTK+. Évalué à -6. Dernière modification le 25 juin 2014 à 22:12.
Je n'ai rien contre la critique, ou dans tous les cas ce n'est pas ce que je voulais dire. Dire "ce qu'a fait machin c'est pourri" me va très bien, même si encore une fois c'est à prendre, à améliorer soi même ou à laisser.
Cela justifie t-il le fait d'être irrespectueux à l'égard de "machin" ?
[^] # Re: Ouch !
Posté par jypaigue . En réponse au journal Au suivant: encore un projet qui va abandonner GTK+. Évalué à -6.
Hmm ? Qu'est-ce que je rate ? Ah moins que tu ne prennes toi même les choses en main d'une façon ou d'une autre, ton utilisation du bousin repose sur le fait que d'autres en prennent soin.
Non, je dis juste qu'il faut arrêter d'attendre quoi que ce soit des personnes qui ne vous doivent rien et à fortiori de leur manquer de respect parce qu'ils ne répondent pas à vos attentes.
Je répète la même chose depuis plusieurs commentaires maintenants. Vous être nombreux à ne pas être d'accord avec tout ça (vue comment sont notés mes commentaires), cela fait-il de vous des personnes complètement et détestablement ingrates ou alors il y a une faille dans mon raisonnement que je suis incapable de saisir…
[^] # Re: Ouch !
Posté par jypaigue . En réponse au journal Au suivant: encore un projet qui va abandonner GTK+. Évalué à -10.
Certains sont maintenant à la merci des mainteneurs de QT, toi à ceux de Xfce… Le jour où ils n'avanceront plus dans la direction qui te convient, j'espère que tu seras un peu moins odieux envers eux que tu ne l'as été dans le cas présent.
[^] # Re: Ouch !
Posté par jypaigue . En réponse au journal Au suivant: encore un projet qui va abandonner GTK+. Évalué à -4.
Si GTK+ ne fait plus preuve d'assez bonne qualité, les gens qui travaillent dessus ne sont pas pour autant à blâmer.
Ingratitude.
[^] # Re: Ouch !
Posté par jypaigue . En réponse au journal Au suivant: encore un projet qui va abandonner GTK+. Évalué à -2.
Tu as l'air de croire que les choses doivent être maintenues ad vitam aeternam et que quelqu'un doit le faire pour toi. Celui qui fait le boulot décide, et il ne doit de justification qu'à ceux qui travaillent avec lui, pas aux utilisateurs (incluant beaucoup de développeurs d'applications finales). Je ne dis pas que tous les contributeurs au projet GTK+ approuvent les changements fait par ce William Jon McCann, mais globalement si.
Cela s'applique pour la plupart des projets : si ceux qui en plus de travailler gratuitement (ou pour des clients autres que toi) ont le temps, la patience, l'envie et l'énergie pour t'écouter c'est bien, sinon il va peut-être falloir que tu reconnaisses qu'ils ne font qu'appliquer leurs libres arbitres (si ce n'est pas pour leurs employeurs) et qu'ils n'ont pas à ce justifier pour ça. Rendre disponible le travail ainsi réalisé est à mon avis respectable, mais devrait être au pire ignorer.
Le code avec les fonctionnalités que tu regrettes n'a pas disparu, libre à toi et à ceux qui en ont besoin de le maintenir… Si personne ne le fait, c'est bien que c'est chiant à faire.
[^] # Re: Ouch !
Posté par jypaigue . En réponse au journal Au suivant: encore un projet qui va abandonner GTK+. Évalué à -10.
Je trouve ton attitude odieuse. Tu pourrais simplement ignorer les contributions qui ne te plaisent pas, William Jon McCann ne te doit rien.
[^] # Re: Bon voisin.
Posté par jypaigue . En réponse à la dépêche G'MIC 1.5.8.3 : Quelques avancées supplémentaires pour le traitement d'image libre. Évalué à 5.
GIMP 2.10 reste API compatible et au rythme où vont les sorties, 3.0 n'apparaitra pas de si tôt. Et même si à l'heure actuelle 3.0 est la version dans laquelle il est prévu de casser les choses, il s'agit avant tout du port vers GTK+3, qui risque d'être suffisament assez pénible pour que l'API soit oubliée. Par ailleurs il ne s'agit pas de toute l'API, mais uniquement de celle qui permet d'accéder aux pixels, et cette nouvelle API est quand même bien plus simple et souple que l'ancienne.
Par ailleurs, dans l'état, GEGL ne permet pas assez de chose pour pouvoir remplacer les plug-ins GIMP. Typiquement, les plug-ins complexes (qui touchent plusieurs layers, qui accèdent aux parasites, qui ont besoin d'une UI spécifique, etc…) ne peuvent pas être porté comme des "noeuds", et restent donc de simples plug-ins classiques, en remplaçant tous les gimp_pixel_rgn_init, gimp_pixel_rgns_register, gimp_pixel_get/set_*, par gegl_buffer_get/set ou similaires.
Le fait de ne pas être un "noeud" GEGL sera un jour une limitation (preview-on-canvas, travail non destructif, interface unifiée, …), mais n'empechera pas G'MIC de fonctionner comme il fonctionne maintenant, au moins pour un certain temps.
Cela étant je ne connais rien de G'MIC et de comment il s'interface avec GIMP. Mais j'ai l'impression qu'une première étape serait de tout laisser comme tel et de juste remplacer les gimp_pixel_XXX par l'API GEGL (je ne dis pas que c'est trivial pour autant). GIMP et GEGL ne sont de toute façon probablement pas capable d'intégrer un ou plusieurs "noeuds" de la complexité de GEGL au jour d'aujourd'hui.
[^] # Re: Qt > Gtk
Posté par jypaigue . En réponse au journal Gtk to Qt - A strange journey. Évalué à -1.
Tu es insultant, je souhaite à chacun d'utiliser le langage qui lui convient le mieux pour ce qu'il a à faire, sauf à toi.
[^] # Re: Qt > Gtk
Posté par jypaigue . En réponse au journal Gtk to Qt - A strange journey. Évalué à 2.
Ce n'est ni du semi-objet, ni tarabiscoté, ni de la torture de language. De mon expérience, le combo C + GObject + Glib + GTK+ n'est pas plus difficile à appréhender ni à utiliser que C++ + Qt. Tout dépend de l'utilisation que l'on en a, mais C++ est un language qui reste extremement complexe.
[^] # Re: Destructif ?
Posté par jypaigue . En réponse à la dépêche Financement participatif de dessin symétrique dans GIMP. Évalué à 2.
L'idée de "miroir via filtres" a été discutée hier sur IRC (je ne me souviens plus des pour/contre par contre).
De façon général, les opérations non-destructives dans GIMP sont dans les tuyaux. L'infrastructure interne est plus ou moins là (notamment grace à GEGL), mais il manque l'UI et les formats de fichiers qui vont avec. Pour quand ce sera ? Aucune idée, quand quelqu'un s'en occupera et pas pour 2.10 à priori…
[^] # Re: Moins bien
Posté par jypaigue . En réponse au journal Libertés numériques : surveiller et punir ?. Évalué à 5.
La difficulté est à mon avis le temps de parole disponible, incompatible avec "une explicitation patiente du domaine qu'il connaît."
[^] # Re: Pas besoin de traqueur
Posté par jypaigue . En réponse au journal TPB AFK. Évalué à 1.
DHT -> Distributed Hash Table… Soyons tatillons. D'ailleurs, ça fait longtemps que ça existe et que ça fonctionne, je pense à Kademlia…
[^] # Re: Pourquoi VCL et automake ?
Posté par jypaigue . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à 5.
Pourquoi gmake et pas automake ?, le problème a été étudié…
Pourquoi pas Qt ? Je pense qu'il faut considérer le rapport quantité de travail / gain. C'est vrai quoi, est-ce que modifier plusieurs millions de lignes de codes pour ajouter une dépendance supplémentaire c'est vraiment une bonne idée ? Et puis pourquoi Qt ? wxWidget est bien aussi…
Bon courage pour montrer que faire un tel changement en vaut la peine…
[^] # Re: linuxo-centré.
Posté par jypaigue . En réponse au journal systemd est un "bloat". Évalué à 2.
Dans ce cas, ce que tu reproches, ce n'est pas le fait que PA ne soit pas fini, mais le fait que ta distribution te l'impose comme choix par défaut.
# Ce n'est pas une version Alpha
Posté par jypaigue . En réponse à la dépêche Diaspora publié sur GitHub et une alpha annoncée pour octobre. Évalué à 6.
To clarify, September 15 will be our open-source developer release. At that time, we will open up our github repository, publish our roadmap, and shift our development style to be more community oriented. We intend on launching a consumer facing alpha in October. Join our mailing list to get an invite.
http://www.joindiaspora.com/2010/08/26/overdue-update.html
Ce n'est donc pas une version alpha