KDE, ce n’est jamais complètement fini.
J’aimerais bien avoir une notification des mises à jour disponibles. J’aimais bien ce que j’avais sous Gnome, juste une icône orange (ou rouge pour les mises à jour de sécurité).
J’ai donc installé update-notifier-kde mais, même après l’avoir configuré pour “Marquer l’élément dans la barre des tâches”, je n’obtiens qu’un message dans une fenêtre qui disparaît rapidement.
Est-ce que j’ai manqué quelque chose ou bien y a-t-il un autre paquet qui me permettrait d’avoir ce que je cherche ?
Les interventions sont intéressantes sur ce fil. Je voudrais juste demander des précisions à Syam sur son message :
Gnome serait construit n’importe comment à cause du langage utilisé pour le programmer ? Dans quelle mesure ? C’est étrange que ce choix soit si mauvais quand on voit que Gnome est un projet assez important, Xfce, LXDE reprennent aussi GTK, alors tous ces développeurs codent-ils vraiment n’importe comment ?
Je ne suis pas sûr de bien comprendre tout ça.
Sinon pour rester dans en Qt et à l’opposé de KDE, il y a RazorQt, une sorte de LXDE en Qt.
Pour le moment (v. 0.41) c’est ultra basique mais ça permet de profiter de la qualité et de l’homogénéité graphique des applications Qt/KDE tout en se passant de Plasma Desktop qui est vraiment la brebis galeuse de KDE SC (à mon avis).
C’est peut-être HS, mais une Debian SID avec RazorQt/KWin plus des applications KDE, c’est un plaisir à utiliser (du moins sur un PC fixe).
Vous avez des retours ? Peut-être ouvrir un fil dédié pour les intéressés ?
Le C n’a pas de modèle objet donc pas de notion d’héritage ni de polymorphisme, il ne permet que la composition de structures.
Or, GTK utilise un modèle objet (presque) standard. Pour arriver à ce que ça fonctionne, l’héritage et le polymorphisme sont implémentés à coups de macros C qui masquent tant bien que mal les horreurs nécessaires (VTables etc), mais sans pour autant apporter la sûreté d’un langage complet (par exemple, aucune encapsulation puisque le C ne le permet pas).
Le résultat est donc, de mon point de vue, une lib qui demande encore plus de coopération de la part du programmeur qu’un programme C classique (à cause de la complexité ajoutée par le modèle objet qui n’est pourtant pas masquée par le langage), alors que le principe de base d’un design réussi c’est justement de minimiser ces points de friction entre l’environnement et le programmeur.
Faire de la POO en C, c’est comme vouloir enfoncer une vis à coups de marteau : on y arrivera toujours en persévérant suffisamment, mais c’est pas fait pour.
On peut critiquer Qt pour ses extensions au C++ qui nécessitent un précompilateur, mais au moins ils ont eu la décence de faire un précompilateur justement, qui permet de vérifier l’intégrité du code avant de passer ça au compilateur C++.
GTK apporte encore plus de modifications au C que Qt au C++ puisqu’il ne s’agit plus seulement de quelques extensions au langage mais carrément d’un paradigme complet, et pourtant ils l’implémentent avec la pire monstruosité qui existe en programmation : des macros C.
Il faut bien se rappeler que GTK date de 1996 (début du développement) / 1998 (première release stable), à une époque où le C++ n’était pas encore parfaitement au point (le premier standard ISO C++ date justement de 1998, et les compilateurs ont mis un sacré moment à respecter correctement ce standard).
Je ne voudrais pas trop m’avancer là dessus, mais je soupçonne que c’est la principale raison du choix qu’on fait les développeurs GTK (langage C, réinvention de la roue). Le problème c’est que 16 ans plus tard GTK est toujours prisonnier de ces choix alors que les problématiques de l’époque n’ont plus lieu d’être, mais les inconvénients qui en découlent sont toujours bien présents.
Bref, ce qui était justifiable à la fin du précédent millénaire ne l’est plus aujourd’hui.
Au contraire, KDE a fait un pari plutôt culotté pour l’époque (C++, basé sur Qt qui était encore semi-propriétaire) mais le résultat est là aujourd’hui : techniquement ça tient toujours la route.
Je tiens à préciser que tout ça n’est pas parole d’évangile, loin de là, ça ne reflète que mon opinion personnelle…
[size=80](et je ne pourrai probablement pas poursuivre la discussion avant une bonne quinzaine)[/size]
Hihi, ca m’parait aussi sensé que dire “la droite est incompétente” ou encore “la gauche est incompétente”.
C’est du pareil au même
C’est pour ca que gnome promeut le JAVASCRIPT !
En vérité, n’est-ce pas la programmation tout-object qui est maso ?
OpenBox !
[size=50]Uniquement limité par votre imagination et vos capacités cognitive[/size]
Bah, des langages qui ne respectent pas le principe d’encapsulation, y’en a plein, le java par exemple.
Nah, alors la non.
Le #define est une fonctionnalité extraordinaire, qui permet de faire plein de chose (de même que le goto).
Après, mettre des #define partout n’est pas toujours une solution.
gnome est un projet initié par un type qui, en parallèle, a mis sur les rails une implémentation de .net pour Linux. Nothing to say more …
Quand Gnome annonce qu’il invente son propre langage de programmation, il fait honneur à son créateur.
Et quand Gnome annonce qu’après avoir créer son langage de programmation, et avoir tout migré de Python vers machin, il va tout virer pour mettre du JAVASCRIPT, tonton est comptant.
Le C n’a pas de modèle objet donc pas de notion d’héritage ni de polymorphisme, il ne permet que la composition de structures.
Or, GTK utilise un modèle objet (presque) standard. Pour arriver à ce que ça fonctionne, l’héritage et le polymorphisme sont implémentés à coups de macros C qui masquent tant bien que mal les horreurs nécessaires (VTables etc), mais sans pour autant apporter la sûreté d’un langage complet (par exemple, aucune encapsulation puisque le C ne le permet pas).
Le résultat est donc, de mon point de vue, une lib qui demande encore plus de coopération de la part du programmeur qu’un programme C classique (à cause de la complexité ajoutée par le modèle objet qui n’est pourtant pas masquée par le langage), alors que le principe de base d’un design réussi c’est justement de minimiser ces points de friction entre l’environnement et le programmeur.
Faire de la POO en C, c’est comme vouloir enfoncer une vis à coups de marteau : on y arrivera toujours en persévérant suffisamment, mais c’est pas fait pour.[/quote]
Faudra en parler à Linus dont le noyau est en C avec une couche objet
Comme quoi ça arrive très bien à fonctionner.
[quote=“syam”]On peut critiquer Qt pour ses extensions au C++ qui nécessitent un précompilateur, mais au moins ils ont eu la décence de faire un précompilateur justement, qui permet de vérifier l’intégrité du code avant de passer ça au compilateur C++.
GTK apporte encore plus de modifications au C que Qt au C++ puisqu’il ne s’agit plus seulement de quelques extensions au langage mais carrément d’un paradigme complet, et pourtant ils l’implémentent avec la pire monstruosité qui existe en programmation : des macros C.[/quote]
kof kof Q_OBJECT, kof kof SIGNAL() kof kof SLOT()
Désolé j’ai un chat dans la gorge
Il faut bien se rappeler que GTK date de 1996 (début du développement) / 1998 (première release stable), à une époque où le C++ n’était pas encore parfaitement au point (le premier standard ISO C++ date justement de 1998, et les compilateurs ont mis un sacré moment à respecter correctement ce standard).[/quote]
À une époque où le C++ était tellement bien fichu que Qt en réimplémentait une partie. Mince ! Il continue ! (ça ça rend les choses agréables à utiliser un typage statique et des objets qui ont la même finallité mais différents qui se balladent).
[quote=“syam”]Je ne voudrais pas trop m’avancer là dessus, mais je soupçonne que c’est la principale raison du choix qu’on fait les développeurs GTK (langage C, réinvention de la roue). Le problème c’est que 16 ans plus tard GTK est toujours prisonnier de ces choix alors que les problématiques de l’époque n’ont plus lieu d’être, mais les inconvénients qui en découlent sont toujours bien présents.
Bref, ce qui était justifiable à la fin du précédent millénaire ne l’est plus aujourd’hui.[/quote]
T’avance pas trop non plus tu risquerais de te faire mal. Le C++ n’a jamais normalisée son API et il ne le ferra sans doute jamais. Ça signifique que tu n’a aucune garantie de compatibilité des binaires dans le temps. Le C++ c’est tellement facile à binder dans d’autres langages que l’on se coltine deux bibliothèque Qt pour python et qu’en parler est un troll en soit. Le C++ est incroyablement compliqué. C’est extrêmement puissant ça je ne dis pas le contraire, je dis juste, qu’il existe très peu de gens qui peuvent dire « moi en C++ je m’y connais ». Ce que la plupart des gens peuvent dire c’est « le C++ quand on utilise les templates qu’au minimum et qu’on a pas trop de parallélisme je connais bien ».
Mais je pense que si tu veux comparer les deux projets, il va falloir comparer le C+±like de Qt avec Vala.
Et il se trimbale toujours un fork du C++, qu’ils sont doucement entrain de glisser sous le tapis pour du javascript.
Non ce qui est maso c’est d’utiliser un paradigme qu’on maitrise mal (surtout quand on ne veux pas mieux le maitriser).
[quote=“haleth”]Le #define est une fonctionnalité extraordinaire, qui permet de faire plein de chose (de même que le goto).
Après, mettre des #define partout n’est pas toujours une solution.[/quote]
Du mal à rester poli, je voudrais choquer personne, mais les macros c’est l’étape juste après les goto, ça doit être vomi, sinon ça crée des aigreurs d’estomac.
Il y a 3 cas d’utilisation (ça marche aussi avec les goto) :[ul]
[li]tu fais un code d’exemple pensé pour mettre à profit les macros soit mais on s’en fout c’est du code à jeter dès que ta fini de présenter[/li]
[li]tu es obligé de t’en servir, ton langage pourri (ça marche aussi pour le C++) est trop limité donc t’a pas le choix[/li]
[li]tu es entrain de faire n’importe quoi et dans 6 mois quelqu’un te maudira toi et toute ta descendance[/li][/ul]
Bien sûr et bientôt on doit t’expliquer pour quoi t’a debian est en 48bits ?
Ouais, beaucoup de baratin pour rien de concret …
Si tu veux savoir, goto comme #define permet de simplifier le code, de le rendre plus clair.
Après, si t’es fan de function de 500lignes, c’est vrai qu’utiliser goto peut-être une mauvaise idée. M’enfin, mon assertion concernant les connaissances et les capacités en programmation des lecteurs de ce fil est peut-être erronée…
[quote]
Haleth a écrit:
Bah, des langages qui ne respectent pas le principe d’encapsulation, y’en a plein, le java par exemple.
Bien sûr et bientôt on doit t’expliquer pour quoi t’a debian est en 48bits ?[/quote]
Principe d’encapsulation : y’a une boite noire, des traitements sont effectués dedans, mais vu de l’exterieur, il ne se passe rien. Diverses function & variables sont vus de l’extérieur, rien ne dit ce qui est à l’intérieur.
Ca, c’est le principe d’encapsulation, et c’est impossible à faire en java (a minima, j’ai longement cherché et pas trouvé…).
Les fan-boy (toi) vont te dire non, tu peux, suffit de faire de GETTER et des SETTER.
Bawé.
Parcque faire object.function(), ca n’implique pas DU TOUT qu’un traitement est effectué dans l’object. Non, ca ne l’implique pas.
Ce principe est appliqué dans d’autre langage (comme PHP, c’est dire le niveau …).
En php, tu peux demande object.variable, et cependant avoir un traitement derrière. Tu peux lever une exception si ton object.variable = valeur ne correspond pas à ce que tu souhaites.
Au final, sur ce point, PHP est plus un langage object que java.
Tout ca parcqu’une bande de fanatiques obtu déforme la réalité pour faire rentrer les faiblesses de l’être adorée comme des qualités. Les points faibles, comme des points forts. Bon, et puis c’est vrai, être un fan-boy java et avouer que java ne respecte pas l’un des grands fondement de l’Object, c’est un peu difficile, je peux le comprendre.
T’as trop bu de café toi, non ?
Java pas un langage objet … L’encapsulation, je ne sais pas ce que ça représente pour toi, mais entre private, public, protected, static tu devrais trouver ton bonheur !
Ce que Java ne permet pas c’est l’héritage multiple, mais avec les interfaces finalement c’est plus clair.
En passant, je doute que Misterfreez soit un java-boy, je le vois plus jouer avec les ruby,python,perl … Le C++ devant ces langages doit prendre la carte vermeille
[quote=“haleth”][quote]
Du mal à rester poli, je voudrais choquer personne, mais les macros c’est l’étape juste après les goto, ça doit être vomi, sinon ça crée des aigreurs d’estomac.
Il y a 3 cas d’utilisation (ça marche aussi avec les goto) :
tu fais un code d’exemple pensé pour mettre à profit les macros soit mais on s’en fout c’est du code à jeter dès que ta fini de présenter
tu es obligé de t’en servir, ton langage pourri (ça marche aussi pour le C++) est trop limité donc t’a pas le choix
tu es entrain de faire n’importe quoi et dans 6 mois quelqu’un te maudira toi et toute ta descendance
[/quote][/quote]
Ouais, beaucoup de baratin pour rien de concret …
Si tu veux savoir, goto comme #define permet de simplifier le code, de le rendre plus clair.
Après, si t’es fan de function de 500lignes, c’est vrai qu’utiliser goto peut-être une mauvaise idée. M’enfin, mon assertion concernant les connaissances et les capacités en programmation des lecteurs de ce fil est peut-être erronée…[/quote]
Plus ton code est segmenté moins tu as des besoins de goto. Les gotos sont des sauts non conditionnels qui n’apportent aucune sémantique. Si tu n’a pas le choix, tu les utilise mais c’est bien parce que ton langage n’a rien pour gérer ton cas. L’exemple du RIAA en C++ est assez parlant à ce sujet.
Pour ce qui est des macro, c’est d’un autre temps. D’autres langages plus vieux avaient déjà mieux avant que le C ne sortent (lisp es-tu là ?).
[quote=“haleth”][quote]
Haleth a écrit:
Bah, des langages qui ne respectent pas le principe d’encapsulation, y’en a plein, le java par exemple.
Bien sûr et bientôt on doit t’expliquer pour quoi t’a debian est en 48bits ?[/quote]
Principe d’encapsulation : y’a une boite noire, des traitements sont effectués dedans, mais vu de l’exterieur, il ne se passe rien. Diverses function & variables sont vus de l’extérieur, rien ne dit ce qui est à l’intérieur.
Ca, c’est le principe d’encapsulation, et c’est impossible à faire en java (a minima, j’ai longement cherché et pas trouvé…).
Les fan-boy (toi) vont te dire non, tu peux, suffit de faire de GETTER et des SETTER.
Bawé.
Parcque faire object.function(), ca n’implique pas DU TOUT qu’un traitement est effectué dans l’object. Non, ca ne l’implique pas.[/quote]
Comme quoi il faut faire gaffe avec wikipedia. L’encapsulation ça consiste empêcher qui conque de préjuger quoi que ce soit au sujet de l’algorithme sous-jacent. C’est ce qui permet de n’utiliser qu’un interface contractuelle et de ne jamais se pouvoir se pencher sur un détail d’implémentation et donc de diminuer fortement le couplage. Dans cette optique les muttateur sont mals quelque soit la manière dont ils sont implémentés car ils donnent une idée (même si elle peut être fausse, de l’implémentation de l’algorithme).
L’encapsulation ne consiste en aucun cas à cacher qu’il y a un traitement, il cache comment celui-ci est fait.
Tu parle bien de ceux qui ont pondu une page wikipedia toute pourrie là ?
Vois-tu si tu connaissais un peu java, tu saurais qu’en effet il n’est pas complètement possible de faire de l’encapsulation avec java car la réflexion te permet d’accéder à tout. Mais ne t’inquiète pas le C et le C++ le permettent aussi (pas par réflexion c’est un peu plus compliqué mais c’est faisable). Python non plus, javascript n’en parlons pas. Je présume que C# c’est comme java. Il reste quoi ? Le D, peut être perl/moose et probablement smalltalk, peut être ruby aussi.
Juste pour mettre l’enphase dessus. J’ai rien à prouvé et rien à faire de ce que tu peut imaginer. J’aime jongler avec les langages le C, le C++ et le Java sont des langages tellement classiques que faire le tour de leur force et de leurs faiblesses n’est même pas amusant, sauf quand quelqu’un semble avoir écouté des « on dit », lu des pages wikipedia malbranlées et arrivent avec leur gros sabot pleins d’affirmations.
Simplifier l’objet d’un point de vue du dev
J’en oublie ?
Comme écrit j’sais plus où:
Ca possède tout son sens, je trouve …
Bref, implicit getter & setter c’est dla balle.
Les on-dit, c’est plus toi qui les colporte, non ? Des fan-boys, j’en vois tout les jours.
Pour la page wikipedia, j’ai beau me forcer, j’suis toujours pas dans ta tête et je ne sais donc pas de quoi tu parles.
Pour mes sabots, j’pense avec donné par mal d’arguments, non ? J’ai pas l’impression de venir imposer mon point de vue comme étant la parole divine.
Simplifier l’objet d’un point de vue du dev
J’en oublie ?[/quote]
On est d’accord.
[quote=“haleth”]Comme écrit j’sais plus où:
Ca possède tout son sens, je trouve …
Bref, implicit getter & setter c’est dla balle.[/quote]
Du sucre syntaxique qui peut être agréable à utiliser mais qui d’un point de vu design n’apporte rien. Fonctionnellement c’est strictement identique. Tu présente le même niveau d’information sur ton algo avec un machin.truc qu’avec un machin.setTruc() ou machin.getTruc().
Ce que tu cite dis simplement que certains langages permettent de cacher la tambouille interne. Aucun rapport avec ton histoire de muttater implicite.
[quote=“haleth”][quote]
Tu parle bien de ceux qui ont pondu une page wikipedia toute pourrie là ?[/quote]
Nota: j’suis pas dans ta tête …[/quote]
Comme tu cite presque mot à mot la page wikipedia sur le principe d’encapsulation.
[quote=“haleth”][quote]
Vois-tu si tu connaissais un peu java, tu saurais qu’en effet il n’est pas complètement possible de faire de l’encapsulation avec java car la réflexion te permet d’accéder à tout. Mais ne t’inquiète pas le C et le C++ le permettent aussi (pas par réflexion c’est un peu plus compliqué mais c’est faisable). Python non plus, javascript n’en parlons pas. Je présume que C# c’est comme java. Il reste quoi ? Le D, peut être perl/moose et probablement smalltalk, peut être ruby aussi.
[/quote]
T’es dans un nuage de stupéfiants ?
Pour ta gouverne, PHP, Python, Ruby (a minima) permettent de faire des encapsulations pas-à-moitié (ie: properties);[/quote]
J’ai pas parlé de PHP. Ruby j’ai clairement dis que j’en était pas sûr. Mais pour python faut arrêter de dire n’importe quoi.
Python peut éventuellement faire de l’encapsulation avec les “new-style class” (qui n’ont plus rien de nouveau depuis longtemps). Mais pour son modèle objet classique, non il n’y a pas d’encapsulation. Tout simplement parce que je peut moi en tant qu’utilisateur de ta classe venir écraser l’une des méthodes de ton objet et ainsi venir foutre le bordel dans ton code. C’est le principe même de la non encapsulation. C’est la dynamicité du typage qui fait ça. Ça a ses avantages et ces inconvénients.
Voila c’était ma dernière intervention. Je me rappel pourquoi je n’étais pas intervenu (et puis si c’est pour que tu reste accroché à tes mutateurs implicite sans donner d’arguments ça n’a pas grand intérêt).
Hihi, c’est vrai que tu peux modifier les machins, ce qu’interdit le paradigme.
On arrive à l’idée du “je limite le dev parcque j’ai raison et il a tord”, m’enfin c’est un autre sujet …
Btw, merci pour ta participation, c’était très intéressant;
La déontologie (elle ne serait pas la seule, d’ailleurs) voudrait que tu veuilles bien prendre la peine de faire paraître le pseudo d’une personne (Un être ! Vivant ou décédée, qui sait …) lorsque que tu …
De-ci delà, des mots, des phrases, des paragraphes … Qu’en penses tu ? (ce qui, à mon sens, me paraît on ne peut plus répréhensible de part la Loi en vigueur en (dans notre très cher) République Française !
À TITRE PERSONNEL, JE T’EN REMERCIE d’avance …
Nous n’évoquerons même pas les droits d’auteurs, il va s’en dire.
[quote=“BelZéButh”]De-ci delà, des mots, des phrases, des paragraphes … Qu’en penses tu ? (ce qui, à mon sens, me paraît on ne peut plus répréhensible de part la Loi en vigueur en (dans notre très cher) République Française !
À TITRE PERSONNEL, JE T’EN REMERCIE d’avance …
Nous n’évoquerons même pas les droits d’auteurs, il va s’en dire.[/quote]
Il s’agit d’un droit de citation. Je pense que la colocalisation ne rend pas cela attaquable.
Disons que c’est une bonne pratique de mettre le pseudo, mais rien de plus (et rien de grave non plus).
[/size]