Forum Programmation.autre débutant cherche piste pour apprendre a faire de petite gui

Posté par  . Licence CC By‑SA.
Étiquettes :
10
6
fév.
2013

Que conseillerai vous pour réaliser des applis graphiques ?

Le toolkit m'importe peu, et le langage dessous aussi. Je serai débutant dans tous les langages sauf le shell. Mes seuls contraintes sont de pouvoir l'utiliser "simplement" sous debian stable et que ces applis seront bien souvent des lanceurs (déclanchement d'un rsync ou d'un lftp mirror par exemple, avec récupération du compte rendu d'exécution, un front-end quoi.

Le but étant donc de réaliser de simple applis cliclic. rien de professionnel, juste un passe temps.

  • # pyqt

    Posté par  . Évalué à 10.

    PyQt peut être pas mal, et python ca permet en plus autant de faire du système que du web.

    • [^] # Re: pyqt

      Posté par  (site web personnel) . Évalué à 6.

      Ou PyGTK :)

      • [^] # Re: pyqt

        Posté par  . Évalué à 6.

        Franchement avec le chemin full Qt que prend Blackberry, Ubuntu Phone, Jolla Mobile, et le support natif de Qt sur Mac, ca me parait plus judicieux Qt que GTK+. Personnellement je ne vois plus l'intérêt de GTK+ face à Qt.

        • [^] # Re: pyqt

          Posté par  (site web personnel) . Évalué à 3.

          Personnellement je ne vois plus l'intérêt de GTK+ face à Qt.

          Si plus personne ne fait de GTK, il n'y a plus matière à troller…

          • [^] # Re: pyqt

            Posté par  . Évalué à -1.

            Ah oui vu comme ça en effet .. :)

          • [^] # Re: pyqt

            Posté par  . Évalué à 1.

            ??? Ya plus que le mobile et les MAC dans la vie ?

            Moi j'ai toujours mon FreeBSD et/ou mon NetBSD avec son XFCE a toujours besoin de GTK+.

            • [^] # Re: pyqt

              Posté par  . Évalué à 0.

              Les apps en Qt se lancent bien sous XFCE non ?

              • [^] # Re: pyqt

                Posté par  . Évalué à 2.

                Oui mais si plus de GTK+, plus de xfce ….

  • # Zenity

    Posté par  (site web personnel) . Évalué à 10.

    S'il s'agit juste d'"enrober" des autres commandes, tu peux générer des fenêtres relativement simples avec la commande zenity au sein de scripts shell…

    • [^] # Re: Zenity

      Posté par  (site web personnel) . Évalué à 4.

      Si Zenity te paraît un peu limité, gtkdialog me semble plus complet. Tu peux appeler l'un comme l'autre à l’intérieur de n'importe que script (bash, python, perl…)

      Tiens, si quelqu'un(e) connaît un équivalent qt…

      • [^] # Re: Zenity

        Posté par  . Évalué à 3.

        kdialog?

        Options :
  --yesno <text>            Boîte à message avec les boutons « oui » et « non »
  --yesnocancel <text>      Boîte à message avec les boutons « oui », « non » et « annuler »
  --warningyesno <text>     Message d'avertissement avec les boutons « oui » et « non »
  --warningcontinuecancel <text> Message d'avertissement avec les boutons « continuer » et « annuler »
  --warningyesnocancel <text> Message d'avertissement avec les boutons « oui », « non » et « annuler »
  --yes-label <text>        Utilise le texte comme étiquette pour le bouton « Oui »
  --no-label <text>         Utilise le texte comme étiquette pour le bouton « Non »
  --cancel-label <text>     Utilise le texte comme étiquette pour le bouton « Annuler »
  --continue-label <text>   Utilise le texte comme étiquette pour le bouton « Continuer »
  --sorry <text>            Message d'excuses
  --error <text>            Message d'erreur
  --msgbox <text>           Boîte de dialogue pour l'affichage d'un message
  --inputbox <text> <init>  Boîte de dialogue pour la saisie de texte
  --password <text>         Boîte de dialogue pour la saisie d'un mot de passe
  --textbox <file> [width] [height] Boîte de dialogue pour l'affichage de texte
  --textinputbox <text> <init> [width] [height] Boîte de dialogue de saisie de texte
  --combobox <text> item [item] [item] ... Liste déroulante
  --menu <text> [tag item] [tag item] ... Boîte de dialogue avec un menu
  --checklist <text> [tag item status] ... Boîte de dialogue avec une liste à choix multiples
  --radiolist <text> [tag item status] ... Boîte de dialogue avec une liste à choix unique
  --passivepopup <text> <timeout> Fenêtre automatique passive
  --getopenfilename [startDir] [filter] Boîte de dialogue pour ouvrir un fichier existant
  --getsavefilename [startDir] [filter] Boîte de dialogue pour enregistrer un fichier
  --getexistingdirectory [startDir] Boîte de dialogue pour sélectionner un dossier existant
  --getopenurl [startDir] [filter] Boîte de dialogue pour ouvrir une URL existante
  --getsaveurl [startDir] [filter] Boîte de dialogue pour enregistrer une URL
  --geticon [group] [context] Fenêtre de choix d'icône
  --progressbar <text> [totalsteps] Dialogue de barre de progression, retourne une référence D-Bus pour la communication
  --getcolor                Boîte de dialogue pour sélectionner une couleur
  --title <text>            Titre de la fenêtre
  --default <text>          Entrée par défaut à utiliser pour la liste déroulante, le menu et la couleur
  --multiple                Permet aux options --getopenurl et --getopenfilename de retourner plusieurs fichiers
  --separate-output         Retourner la liste des éléments sélectionnés sur des lignes séparées (pour les listes à choix multiples et les ouvertures de fichier avec --multiple)
  --print-winid             Affiche l'identifiant de fenêtre « winid » de chaque boîte de dialogue
  --dontagain <file:entry>  Fichier de configuration et nom de l'option enregistrant l'état « Ne plus afficher / demander de nouveau »
  --slider <text> [minvalue] [maxvalue] [step] Boîte de dialogue à curseur, retourne la valeur sélectionnée
  --calendar <text>         Boîte de dialogue calendrier, retourne la date sélectionnée
  --attach <winid>          Rend temporaire la fenêtre pour une application X définie par son identifiant de fenêtre (winid)

Arguments :
  arg                       Arguments - options dépendantes de l'option principale

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

        • [^] # Re: Zenity

          Posté par  . Évalué à 3.

          Merci,

          En faite, j'utilise déjà zenity et kdialog. Mais là, je voulais me lancer dans quelque chose de nouveau histoire de.

  • # Tk, averc n'importe quel langage par dessus.

    Posté par  . Évalué à 3.

    C'est moche, mais c'est assez facile à prendre en main pour se lancer.

    Bien qu'à l'origine Tk a été développé plutot pour Tcl, il y a des bindings pour pas mal de langages dont Ruiby, Perl, et Python. Par contre je te conseille Python qui est un langage neuneu par excellence (le Visual Basic du libre en quelque sorte).

    • [^] # Re: Tk, averc n'importe quel langage par dessus.

      Posté par  . Évalué à 4.

      Argh, lancé de troll raté !!!!! Je voulais dire je te déconseille Python. Tant pis, je tenterai une autre fois … :D

      • [^] # Re: Tk, averc n'importe quel langage par dessus.

        Posté par  (site web personnel) . Évalué à 2.

        C'est bête, t'aurais pu éditer ton commentaire discrètement si tu n'y avais pas répondu!

        • [^] # Re: Tk, averc n'importe quel langage par dessus.

          Posté par  . Évalué à 2.

          Non, il y a une tempo il me semble pour modifier le commentaire. En tout cas je n'ai pas vu la possibilité de modifier.

          • [^] # Re: Tk, averc n'importe quel langage par dessus.

            Posté par  . Évalué à 1.

            Alors si tu déconseilles python, tu conseilles quoi ? Car pour l'instant, au regard de ce qui est dit plus haut, le python est largement plébicité, avec qt, mais la je note tk.

            D'ailleurs tk peux désormais avoir le look du bureau via une nouvelle extention.

            • [^] # Re: Tk, averc n'importe quel langage par dessus.

              Posté par  . Évalué à 0.

              Simple : tout SAUF python.

              • [^] # Re: Tk, averc n'importe quel langage par dessus.

                Posté par  . Évalué à 2.

                Plus sérieusement, Ruby est assez sympa avec les inconvénients de Python en moins. Suffisamment explicite pour pouvoir relire ton code ou celui d'un autre sans prise de tête (contrairement à Perl par exemple), mais pas trop contrairement à Python par exemple. De plus tu n'as pas l'aberration de la délimitation de bloc par des indentation (lourd pour débugger : il m'est arrivé de passer plus de 2h à débugger un problème à cause de ça).

                Je viens de voir qu'il y a aussi php/tk Je suis pas fan de PHP, mais je préfère quand même ça a l'immonde serpent.

                • [^] # Re: Tk, averc n'importe quel langage par dessus.

                  Posté par  . Évalué à 0.

                  idem, j'ai appris un peu python, c'est pas si mal mais je n'arrive pas à comprendre pourquoi c'est tant encensé, cette histoire d'indentation est une véritable horreur, ce n'est pas logique de donner une telle importance à ce qui n'est pas visible par définition, et ainsi il y a des conflits suivant si on a une indentation avec une tabulation ou avec 4 espaces.

                  Sans compter le nouveau python3 qui est incompatible avec python2.

                  « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

                  • [^] # Re: Tk, averc n'importe quel langage par dessus.

                    Posté par  . Évalué à 3.

                    Et j'oubliais le fameux self qu'on se traine tout le temps dans la déclaration de méthodes.

                    • [^] # Re: Tk, averc n'importe quel langage par dessus.

                      Posté par  (site web personnel) . Évalué à 2.

                      C'est sa présence dans la liste des paramètres qui te gène, ou bien son utilisation obligatoire pour accéder aux attributs de l'objet ?

                      http://www.python.org/dev/peps/pep-0020/

                      Explicit is better than implicit.

                      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

                      • [^] # Re: Tk, averc n'importe quel langage par dessus.

                        Posté par  . Évalué à 2.

                        C'est sa présence dans la liste des paramètres qui te gène, ou bien son utilisation obligatoire pour accéder aux attributs de l'objet ?
                        Sa présence dans la liste des paramètres

                        Explicit is better than implicit.

                        Ca c'est une grosse connerie. Le fait de déclarer une fonction au niveau d'un bloc définissant un objet est largement explicite pour en déduire qu'il s'agit d'une méthode de l'objet. Il faudrait être complètement demeuré pour déclarer à ce niveau quelque chose qui ne soit pas propre à l'objet. Et globalement, etre explicite à l'excès pousse à se répéter sans cesse, et c'est ce que je reproche justement à Python (Perl quant à lui est dans l'autre extrême, mais ce n'est pas le sujet).

                  • [^] # Re: Tk, averc n'importe quel langage par dessus.

                    Posté par  (site web personnel) . Évalué à 2.

                    Les goûts et les couleurs… l'indentation a pour gros avantage que les blocs de code sont ce que tu vois lorsque tu lis. Tu ne dépends pas d'une paire d'accolades mal placées.
                    Pour le conflit tabulation/espace, tout bon éditeur se paramètre pour que ça ne soit pas un problème (sinon cf tabnanny ou faire une recherche/remplacement).

                    Et pour l'incompatibilité entre les versions 2 et 3 du langage, elle est à la marge, et elle était nécessaire pour corriger certaines choses. Mais rien ne t'empêches de rester avec Python 2.

                    Mais bon, y'a d'autres langages pour d'autres goûts.

                    Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

                    • [^] # Re: Tk, averc n'importe quel langage par dessus.

                      Posté par  . Évalué à 2.

                      Les goûts et les couleurs… l'indentation a pour gros avantage que les blocs de code sont ce que tu vois lorsque tu lis.

                      Je ne suis pas contre l'indentation obligatoire, loin de là, par contre là on est dans un des paradoxes de Python et de sa règle "Explicit is better than implicit." ou justement l'indentation est quelque chose d'implicite, contrairement à une accolade ou un autre délimiteur qui lui est explicite. Autre paradoxe : explicite et duck typing me paraissent comlêtement contradictoires.

      • [^] # Re: Tk, averc n'importe quel langage par dessus.

        Posté par  (site web personnel) . Évalué à 2.

        Pour des gui à la visual neuneu, je conseille l'ensemble java/swing/netbeans gui builder:

        http://linuxfr.org/users/devnewton/journaux/nanimstudio-un-editeur-d-animations-2d

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Tk, averc n'importe quel langage par dessus.

          Posté par  . Évalué à 2.

          Java? Un langage "neuneu"? Et pourquoi pas Ada tant qu'on y est ? On aura tout entendu. Java est loin d'être un langage à neuneu. C'est le langage du "pourquoi faire simple quand on peut faire compliqué en associant le langage à du xml dans tous les sens dans les outils censés augmenter la productivité des développeurs". Après ces idiots vont aller mettre du XML dans tous les fichiers de conf (ah ben oui, pas le temps de développer une GUI ou une CLI afin de faciliter le paramétrage).

          • [^] # Re: Tk, averc n'importe quel langage par dessus.

            Posté par  (site web personnel) . Évalué à 4.

            On a l'habitude des applications java en entreprises J2EE bien bloated, mais en écrivant nanimstudio, j'ai découvert que:

            • swing est une api assez simple.
            • le gui designer de netbeans est très bon.
            • le binding entre les widgets et les données est pratique.

            Bref, faire une petite interface en Java, c'est très facile.

            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

            • [^] # Re: Tk, averc n'importe quel langage par dessus.

              Posté par  . Évalué à 2.

              Peut-être, mais java en lui même est loin d'être un langage que je qualifierais de simple.

              • [^] # Re: Tk, averc n'importe quel langage par dessus.

                Posté par  (site web personnel) . Évalué à 2.

                Oui, mais je vais plus vite avec un langage et une grosse api à tout faire, même compliqués et bloated, qu'en jonglant avec n langages x m apis.

                Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                • [^] # Re: Tk, averc n'importe quel langage par dessus.

                  Posté par  . Évalué à 3.

                  J'en suis pas convaincu, et ce n'est pas ce que je vois tout les jours. Tiens, un exemple

                  En plus de ça ton bloatware va nécessiter 2 CPUs sur 4 pour permettre aux donées de traverser les diverses couches que ces monstres mettent en oeuvre. Ce que tu me dis là, c'est comme si tu me disais que tu connais bien la pelleteuse et que tu vas t'en servir pour creuser toute sortes de trous, alors que parfois, une simple pelle sera bien plus efficace.

                  • [^] # Re: Tk, averc n'importe quel langage par dessus.

                    Posté par  (site web personnel) . Évalué à 3.

                    Exactement! Je suis au commande de ma pelleteuse toute la journée, j'ai juste à tirer un levier pour faire mon trou.

                    Pourquoi devrais-je descendre, aller à l'atelier, trouver une pelle, revenir et me fatiguer?

                    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                    • [^] # Re: Tk, averc n'importe quel langage par dessus.

                      Posté par  . Évalué à 2.

                      Ah, et pour ammener la pelleteuse dans ton jardin, tu vas détruire tout ce qui est autour du trou à creuser ?

                      Sinon, si on reprends la comparaison avec la voiture, c'est comme si tu étais agriculteur et que tu allais faire tes courses ou ton trajet pour aller en vacances en prenant ton tracteur parce que tu passes tes journées dessus …

            • [^] # Re: Tk, averc n'importe quel langage par dessus.

              Posté par  . Évalué à 2.

              Oui, je ne sais pas trop pourquoi tout le monde tape sur Swing quand j'ai utilisé la chose je trouvais que coté conception c'était plutôt bien fait. Bon à l'époque la plateforme Java était buggée jusqu'à l'os, mais c'était il y a très longtemps..

    • [^] # Re: Tk, averc n'importe quel langage par dessus.

      Posté par  . Évalué à 2. Dernière modification le 07 février 2013 à 09:28.

      Franchement à part le troll des puristes qui crient à l'hérésie car les variables ne sont pas typées, vous lui trouvez quoi de mal à python ?

      Je ne suis pas développeur, juste un scientifique qui a besoin de faire des calculs un peu plus complexes que ce qu'un tableur peut faire, parfois une petite Gui pour entrer plus rapidement/facilement des données avant de les traiter, et je ne jure que par du python pour ce genre de truc. C'est simple, rapide, tu peux prototyper rapidement dans une console iPython, etc…

      C'est quoi votre problème avec python ? Pas assez élitiste ?

      • [^] # Re: Tk, averc n'importe quel langage par dessus.

        Posté par  . Évalué à 1.

        Je l'ai indiqué dans un message plus haut : trop explicite : quand tu dois développer du code et te répéter sans cesse, à la longue ça devient usant et tu as l'impression de te répéter sans cesse. Pour ton utilisation, c'est parfait. Par contre quand tu commences à développer du code un peu conséquent, ça devient vite usant.

        Si je résume la philosophie de python par rapport à Perl et Ruby (et en y introduisant la fameuise voiture - c'est pas simple à résumer par écrit) :

        En perl :

        • c'est à moi ( la personne qui dit ça montre la voiture du doigt : le contexte permet de déterminer de quoi il parle)

        • en python : La seule voiture verte de marque XXX, immatriculée YYY, No de série ZZZZZ qui est arrêtée sur le parking servant à garer des véhicules à l'arrêt est ma voiture qui m'appartient à moi (on est obligé de tout préciser parce que la personne en face est trop neuneu pour comprendre)

        • en ruby : La voiture verte garée sur le parking m'appartient.

        • [^] # Re: Tk, averc n'importe quel langage par dessus.

          Posté par  . Évalué à 1.

          Je ne connais pas Perl et Ruby, mais je n'ai pas l'impression de me répéter, peux-tu donner des exemples ?

          Peut-être est-ce aussi la construction du code qui doit être "pythonique".

          • [^] # Re: Tk, averc n'importe quel langage par dessus.

            Posté par  . Évalué à 1.

            Un truc tout bête (mais qui n'est pas propre à Python, mais bien aux langages "objets" : la nécessité de créer des accesseurs spécifiques pour accéder aux attributs d'un objet : ce sont des déclarations répétitives assez lourdes. Autre exemple le self que l'on se traine systématiquement lors de la déclaration des méthodes. Je n'ai pas d'autres exemples en tête parce que ça fait un moment que je n'ai pas fait de python. Je suis passé depuis à Ruby qui permet de se simplifier la vie et d'éviter le code répétitif.

            • [^] # Re: Tk, averc n'importe quel langage par dessus.

              Posté par  . Évalué à 1.

              la nécessité de créer des accesseurs spécifiques pour accéder aux attributs d'un obje

              Je ne comprends pas bien cela, est-ce que tu parles de choses de ce type:

              class Voiture():
    def __init__(self, marque, couleur):
        self.couleur = couleur
        self.marque = marque
    def set_couleur(self, couleur):
        self.couleur = couleur
    def get_couleur(self):
        return self.couleur
    def set_marque(self, marque):
        self.marque = marque
    def get_marque(self):
        return self.marque
ma_voiture = Voiture("Honda", "Verte")
print ma_voiture.get_couleur() # => Verte
print ma_voiture.get_marque() # => Honda
ma_voiture.set_marque("Toyota")
print ma_voiture.get_marque() # => Toyota

              Mais ça me semble équivalent à:

              class Voiture():
    def __init__(self, marque, couleur):
    self.couleur = couleur
            self.marque = marque
    ma_voiture = Voiture("Honda", "Verte")
    print ma_voiture.couleur # => Verte
    print ma_voiture.marque # => Honda
    ma_voiture.marque = "Toyota"
    print ma_voiture.marque # => Toyota

              N'étant pas développeur, je comprends pas bien l'intérêt de ce genre de méthodes "set" et "get" que l'on retrouve souvent.

              • [^] # Re: Tk, averc n'importe quel langage par dessus.

                Posté par  (site web personnel) . Évalué à 1.

                N'étant pas développeur, je comprends pas bien l'intérêt de ce genre de méthodes "set" et "get" que l'on retrouve souvent.

                c'est plutôt bien expliqué ici (SdZ)

                • [^] # Re: Tk, averc n'importe quel langage par dessus.

                  Posté par  . Évalué à 3.

                  Je comprends le concept d'objet, ce que je ne comprends pas c'est pourquoi s'embêter à faire appel aux méthodes get_ et set_ plutôt que directement agir sur la propriété de l'objet ?

                  Si c'est pour cacher une tambouille interne à l'objet qui doit se faire lorsqu'une propriété change, il y a plus adapté que cela en python, avec les properties (ou les décorateurs @property, @x.setter et @x.getter) :

                  class Voiture(object):
    def __init__(self, marque, couleur, taille):
        self.couleur = couleur
        self.marque = marque
        self._taille = taille

    @property
    def taille_m(self):
        """taille de la voiture en mètres"""
        return self._taille

    @taille_m.setter
    def taille_m(self, value):
            self._taille = value

    @property
    def taille_ft(self):
        return self._taille / 0.3048

    @taille_ft.setter
    def taille_ft(self, value):
            self._taille = value * 0.3048

ma_voiture = Voiture("Honda", "Verte", 2)
print ma_voiture.taille_m # 2
print ma_voiture.taille_ft # 6.56167979003

ma_voiture.taille_m = 3

print ma_voiture.taille_m # 3
print ma_voiture.taille_ft # 9.84251968504

ma_voiture.taille_ft = 8

print ma_voiture.taille_m # 2.4384
print ma_voiture.taille_ft # 8.0

                  Cela permet de ne pas écrire de fonction get et set sur chaque propriété qui n'en a pas besoin, et si jamais on doit faire quelque chose sur ces valeur, on ne change pas tout le reste du code.

                  Personnellement je préfère appeler MonObjet.foo et faire des MonObjet.foo = x plutôt que des MonObjet.get_foo() et MonObjet.set_foo(x) en permanence…

                  Je suis à coté de la plaque ?

                  • [^] # Re: Tk, averc n'importe quel langage par dessus.

                    Posté par  . Évalué à 2.

                    Certains langages ne te permettent pas de faire ça facilement (et je croyais que Python en faisait partie), et lèvent une exception si tu ne passe pas par un accesseur pour modifier ou lire la valeur de l'attribut.

                    • [^] # Re: Tk, averc n'importe quel langage par dessus.

                      Posté par  . Évalué à 4.

                      Donc tu ne connais pas le langage mais tu te permets de le décrire comme un langage de neuneu.

                      • [^] # Re: Tk, averc n'importe quel langage par dessus.

                        Posté par  . Évalué à 0.

                        Je connais le langage pour l'avoir pratiqué il y a quelques temps, mais ce détail m'avait échappé. Et je persiste sur le fait que ce langage est un langage "neuneu proof", et totalement pénible à utiliser lorsqu'on développe des trucs un peu conséquents. Je prends bien plus de plaisir à développer en Ruby qu'en Python.

              • [^] # Re: Tk, averc n'importe quel langage par dessus.

                Posté par  . Évalué à 2.

                TILLLT !!!! Je crois que tu viens d'illustrer parfaitement (et malgré toi) un des reproches que je fais à Python. Tu n'auraos pas une indentation en trop dans ton second extrait de code ? :D

                Sinon je viens de tester et il semble que Python ne définit pas d'encapsulation stricte comme en Ruby par exemple. Donc ma remarque vaut pour les langages autres que Python …

                • [^] # Re: Tk, averc n'importe quel langage par dessus.

                  Posté par  . Évalué à 2. Dernière modification le 07 février 2013 à 16:09.

                  Ah j'allais oublier : en Ruby pour définir un accesseur, tu as juste à le déclarer de la façons uivante :

                  class Toto
        attr_accessor :a
end

t=Toto.new
t.a=42
puts("#{t.a}")

                • [^] # Re: Tk, averc n'importe quel langage par dessus.

                  Posté par  . Évalué à 1.

                  Oui il y a une indentation en trop, un copier coller mal passé certainement, je ne sais pas.

                  Personnellement je ne comprends pas les arguments contre l'indentation. J'ai toujours détesté les "{" et les "}" ou autres "endif" ou "fi" ou "end" qui se baladent partout. Il arrive aussi d'oublier une accolade fermante, donc entre oublier l'indentation ou l'accolade, je vois pas ce que ça change…
                  Mon IDE python indente tout seul la plupart du temps, ça ne me dérange pas, de toute façon tu indentes bien les codes que tu fais dans les autres langages non ? Donc du coup au lieu d'avoir uniquement de l'indentation, tu as de l'indentation + un caractère ou une expression fermante… ça fait double emploi je trouve.

                  • [^] # Re: Tk, averc n'importe quel langage par dessus.

                    Posté par  . Évalué à 4.

                    Personnellement je ne comprends pas les arguments contre l'indentation. J'ai toujours détesté les "{" et les "}" ou autres "endif" ou "fi" ou "end" qui se baladent partout. Il arrive aussi d'oublier une accolade fermante, donc entre oublier l'indentation ou l'accolade, je vois pas ce que ça change…

                    C'est plus difficile à voir un oubli d'indentation qu'un oubli d'accolade. Quand tu oublies uune accolade fermante, ton compilo va raler. Quand tu oublies une indentation, parfois ça rale (et il est difficile de voir ou est le problème), parfois ça rale pas parce que le code est syntaxiquement correct, mais il ne fait pas ce que tu veux.

                    de toute façon tu indentes bien les codes que tu fais dans les autres langages non ?

                    Oui, pour la lisibilité. Mais si j'oublie de fermer mon accolade ou de positionner mon délmimituer de bloc, le compilo rale. En python, il peut considérer, si tu oublies une indentation, que tu es en fin de bloc et te faire des choses bizarres difficiles à débugger.

                    Donc du coup au lieu d'avoir uniquement de l'indentation, tu as de l'indentation + un caractère ou une expression fermante… ça fait double emploi je trouve.

                    Non, pas vraiment. Les deux n'ont absolument pas le même rôle. Au début, j'ai été séduit par ce concept. Mais j'ai vite déchanté lorsque j'ai été confrontés à ses inconvénients. Indentation obligatoire, pourquoi pas, pour forcer à la lisibilité, mais il faut un délimiteur de blocs en plus.

                    • [^] # Re: Tk, averc n'importe quel langage par dessus.

                      Posté par  . Évalué à 1.

                      C'est plus difficile à voir un oubli d'indentation qu'un oubli d'accolade.

                      Personnellement c'est plutôt l'inverse, comme l'accolade peut se trouver un peu n'importe où il faut parfois compter le nombre d'ouverture pour en déduire le nombre de fermetures. J'ai typiquement le problèmes avec les parenthèses dans des formules à rallonge dans un tableur.
                      Alors qu'une indentation, avec le bon IDE qui affiche une ligne verticale à chaque saut d'indentation, les blocs sont visible directement.
                      D'ailleurs quand j'ai un problème de parenthèse dans une formule d'un tableur, la première chose que je fait est de la copier dans un document texte et refaire toute l'indentation pour voir où la parenthèse manque.

                      Quand tu oublies uune accolade fermante, ton compilo va raler. Quand tu oublies une indentation, parfois ça rale (et il est difficile de voir ou est le problème), parfois ça rale pas parce que le code est syntaxiquement correct, mais il ne fait pas ce que tu veux.

                      C'est vraiment pas de bol si ça ne crie pas, et ton compilo ne va pas non plus crier si tu as mis l'accolade au mauvais endroit. C'est exactement la même chose.

                      • [^] # Re: Tk, averc n'importe quel langage par dessus.

                        Posté par  . Évalué à 2.

                        C'est vraiment pas de bol si ça ne crie pas

                        Euh …

                        class Toto:

        def __initialize(self):
                a=42

        def test(self):
                if (self.a == 42) :
                        print "a=42"

                self.a=22


t=Toto()

t.test

                        Dans ce cas, Python ne rale pas. Ce genre de truc arrive assez souvent lorsqu'on modifie du code pour par exemple ajouter un test, ou suppression d'un nombre conséquent de lignes.

                        Par contre en ruby :
                        class Toto

                                def initialize
                @a=42
        end

        def test
                if (@a == 42):
                        puts("a=#{@a}")

                @a=22
        end
end

                        t=Toto.new()
                        t.test()

                        La tu as oublié de délimiter la fin de bloc, ça rale.

                        Sinon, tu remarqueras aussi la façon élégante et concise d'identifier une variable d'instance … Ca peut paraitre du détail, mais personnellement je n'aime pas me répéter, et passer mon temps à me trainer un self, ou devoir être explicite à l'excès alors que le contexte permet d'identifier clairement ce que je fais ou veux faire me gave au plus haut point.

                      • [^] # Re: Tk, averc n'importe quel langage par dessus.

                        Posté par  . Évalué à 2.

                        J'ai typiquement le problèmes avec les parenthèses dans des formules à rallonge dans un tableur.
                        Oups, ce point m'a échappé. Comparons ce qui est comparable, il y a un monde entre formules de tableurs et python. C'est comme si je venais à te parler de macros M4 par exemple alors que ça n'a rien à voir.

                      • [^] # Re: Tk, averc n'importe quel langage par dessus.

                        Posté par  . Évalué à 0.

                        Euh, avec « le bon IDE » tu as aussi une coloration des parenthèses/accolades correspondantes … sinon comment les gens pourraient coder en lisp/scheme ? J'irais même jusqu'à dire qu'avec un bon IDE tu ne les tapes pas … (déclenchement par mots-clés de modèles de code récurrents)

                        • [^] # Re: Tk, averc n'importe quel langage par dessus.

                          Posté par  . Évalué à 2.

                          J'irais même jusqu'à dire qu'avec un bon IDE tu ne les tapes pas …
                          Ah non, pitié, pas ça …. Je me bats assez avec ce genre d'horreur qui t'insère des trucs dont tu ne veux pas parce qu'il s'imagine mieux que toi savoir ce que tu veux faire.

                          • [^] # Re: Tk, averc n'importe quel langage par dessus.

                            Posté par  . Évalué à 0.

                            Euh … juste avec gedit, déclenchement d'un modèle de code quand on a écrit le bon mot et utilisé la touche tabulation ensuite, c'est à dire : exprimé explicitement sa volonté de voir ici un modèle être utilisé.

                            Je peux très bien écrire tout ce qui me passe par la tête sans complétion aucune, et comme la tabulation sert juste à la présentation du code (sauf en python …), on utilise très rarement une tabulation après un mot directement, et dans ce cas précis, faire un espace entre ne change pas grand chose.

      • [^] # Re: Tk, averc n'importe quel langage par dessus.

        Posté par  (site web personnel) . Évalué à 2.

        Les variables Python sont typées, tu ne feras pas une addition entre "3" et 4.

        Mais c'est dynamique (associations noms/valeurs).

        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

  • # HTML / JS (ou Qt si vraiment tu veux un client lourd)

    Posté par  . Évalué à 3. Dernière modification le 06 février 2013 à 13:20.

    Je vais me faire moinsser, mais actuellement les techno web, ce sont les technologies que j'utilise à chaque fois dès que je dois faire une IHM, ça fait belle lurette que je n'ai pas codé de client lourd.

    Si ton IHM est simple, avec HTML plus un peu de JS (et les librairies qui vont bien, par exemple jqueryui), tu devrais arriver à faire ce que tu veux. Cela te permet aussi de facilement séparer le fond de la forme. Tu mets la logique métier dans ton serveur HTTP (par exemple j'aime bien mongoose en C ou bien Apache).

    Et si tu veux vraiment faire un client lourd, je te conseillerais directement soit GTK, soit Qt selon ton window manager de prédilection.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.