/* Topic des codeurs [6] */

The Uploader · Le 23/12/2011, à 22:27

Rolinh a écrit :

Finalement, pour LinCopier, je n'utilise pas Vala même si j'avais d'abord pensé que ce serait plus facile. Je me contente de Glade pour faire le maximum et le reste en C avec gtk directement. En fait, j'avais vachement du mal à savoir comment interfacer ce que produit vala avec le code de mon programme en C. Du coup bah.... voilà.
C'est beaucoup moins pénible de faire une GUI quand on est tout en OO. Il parait que qt combiné au C++ est nettement plus digeste et mieux fichu.

J'ai testé QT un peu (du temps où QtDesigner était à la fois un designer et un IDE), c'était très, très bon. Sauf que je peux pas blairer le C++ et ses "&", ses ";", et autres pollutions visuelles ( ) et ses erreurs de compilation cryptiques ( ), mais c'était très propre.

moi a écrit :

Puis bon j'aurais aimé allier le logiciel de design GTK Glade (pour pouvoir décrire la fenêtre en XML), et Vala (pour la logique), mais bon j'sais pas trop comment m'y prendre.

J'ai rien dit : http://live.gnome.org/Vala/GTKSample#Lo … m_XML_File

Dernière modification par The Uploader (Le 23/12/2011, à 22:32)

tshirtman · Le 23/12/2011, à 23:11

http://grep.be/blog/en/computer/code/st … with_clang

pour les utilisateurs de Clang qui trainent par ici

The Uploader · Le 24/12/2011, à 09:10

main.vala

using Gtk;

public void onButton_clicked (Button source) {
    source.label = "Thank you!";
}

int main(string[] args) {

    Gtk.init (ref args);

    try {
        var builder = new Builder ();
        builder.add_from_file ("window.glade");
        builder.connect_signals (null);
        var window = builder.get_object ("Window") as Window;
        window.show_all ();
        Gtk.main ();
    } catch (Error e) {
        stderr.printf ("Could not load UI: %s\n", e.message);
        return 1;
    }
    
    return 0;
}

window.glade

<?xml version="1.0" encoding="UTF-8"?>
<interface>
  <!-- interface-requires gtk+ 3.0 -->
  <object class="GtkWindow" id="Window">
    <property name="can_focus">False</property>
    <child>
      <object class="GtkNotebook" id="Notebook">
        <property name="visible">True</property>
        <property name="can_focus">True</property>
        <child>
          <object class="GtkButton" id="Button">
            <property name="label" translatable="yes">button</property>
            <property name="use_action_appearance">False</property>
            <property name="visible">True</property>
            <property name="can_focus">True</property>
            <property name="receives_default">True</property>
            <property name="use_action_appearance">False</property>
            <signal name="clicked" handler="onButton_clicked" swapped="no"/>
          </object>
        </child>
        <child type="tab">
          <object class="GtkLabel" id="label1">
            <property name="visible">True</property>
            <property name="can_focus">False</property>
            <property name="label" translatable="yes">page 1</property>
          </object>
          <packing>
            <property name="tab_fill">False</property>
          </packing>
        </child>
        <child>
          <placeholder/>
        </child>
        <child type="tab">
          <object class="GtkLabel" id="label2">
            <property name="visible">True</property>
            <property name="can_focus">False</property>
            <property name="label" translatable="yes">page 2</property>
          </object>
          <packing>
            <property name="position">1</property>
            <property name="tab_fill">False</property>
          </packing>
        </child>
        <child>
          <placeholder/>
        </child>
        <child type="tab">
          <object class="GtkLabel" id="label3">
            <property name="visible">True</property>
            <property name="can_focus">False</property>
            <property name="label" translatable="yes">page 3</property>
          </object>
          <packing>
            <property name="position">2</property>
            <property name="tab_fill">False</property>
          </packing>
        </child>
      </object>
    </child>
  </object>
</interface>

Build & run

valac --pkg gtk+-3.0 --pkg gmodule-2.0 main.vala && ./main

It works ! \o/

Dernière modification par The Uploader (Le 24/12/2011, à 09:11)

Pylades · Le 24/12/2011, à 22:42

Quand même, des fois, PyGTK ça balance des messages d’erreur franchement cryptiques…

Pylades · Le 25/12/2011, à 14:46

Bordel de fuck, pourquoi va_copy n’est-il disponible qu’en C99 ?

Elzen · Le 25/12/2011, à 19:39

Tiens, quand dans un module, on déclare une variable avec deux undersocre au début, et qu'on décrit une nouvelle classe dans ce module, bah depuis les méthodes de la classe, on n'a pas accès aux variables avec les deux underscore devant.

HP · Le 25/12/2011, à 19:48

Ah ouais… çà c'est une découverte !

tshirtman · Le 25/12/2011, à 20:00

http://docs.python.org/reference/expres … dentifiers
edit: et http://docs.python.org/tutorial/classes … -variables

Dernière modification par tshirtman (Le 25/12/2011, à 20:05)

Elzen · Le 25/12/2011, à 20:16

Yep tshirtman, j'ai bien pigé en l'faisant. C'est juste que sur le coup, quand t'y as pas trop réfléchis avant, ça fait bizarre, comme genre d'erreur, et tu te demandes comment tu peux continuer ça à part en changeant le nom de la variable…

(Finalement, j'me suis rendu compte que vu que ma fonction ne dépendait que d'un des attributs de l'objet, ça pouvait être plus pratique que je déclare une fonction à part qui prenne juste l'attribut en question en paramètre, pour le cas où j'voudrais l'appeler sans avoir d'objet sous la main, et que la méthode de l'objet appelle juste la fonction en question en lui passant son paramètre, donc j'n'ai même pas eu à renommer, et ça m'a donné un meilleur truc après correction que ce que je voulais faire initialement. Ça m'arrive souvent, en ce moment, de tomber sur une erreur bête, et en cherchant à la contourner, de trouver un truc qui soit plus pratique aussi pour autre chose.)

Sinon, tant que j't'ai sous la main : comment je fais pour que

class MonObjet:
    def __init__(self):
        pass # Blabla.

type(MonObjet())

me renvoie « <type 'MonObjet' » ? Pour le moment, ça me renvoie « <type 'instance'> »…

(C'est sûrement tout simple aussi, si j'avais un peu appris sérieusement les bases de Python au lieu d'autodidacter sur le tas, j'pense que je saurais)

tshirtman · Le 25/12/2011, à 21:00

il ne faut pas utiliser "type" pour savoir le type d'une instance, tu peux utiliser instance.__class__ pour savoir ce que c'est, mais ça peut te causer des soucis, à cause de l'héritage, le mieux c'est d'utiliser isinstance(class, instance) pour vérifier que ton instance est bien de la classe que tu pense qu'elle est.

Si tu fais de l'introspection, regarde getattr, et hasattr aussi.

Dernière modification par tshirtman (Le 25/12/2011, à 21:00)

Pylades · Le 25/12/2011, à 21:22

Et surtout tu fais hériter tes classes d’object…

Et /me pense sérieusement à passer à Clang.

tshirtman · Le 25/12/2011, à 21:24

oh, j'avais même pas vu ^^, c'est tellement une évidence pour moi…

Elzen · Le 25/12/2011, à 21:27

Πυλάδης a écrit :

Et surtout tu fais hériter tes classes d’object…

Ah ouais, ça ça suffit. Il me semblait pourtant que si on ne précisait rien, ça héritait implicitement d'object… trop de Java, sûrement.

tshirtman a écrit :

il ne faut pas utiliser "type" pour savoir le type d'une instance, tu peux utiliser instance.__class__ pour savoir ce que c'est, mais ça peut te causer des soucis, à cause de l'héritage, le mieux c'est d'utiliser isinstance(class, instance) pour vérifier que ton instance est bien de la classe que tu pense qu'elle est.

Pourquoi ne faut-il pas, et qu'est-ce que ça change au juste ?

Kanor · Le 25/12/2011, à 21:51

ArkSeth a écrit :

class MonObjet(object):
    def __init__(self):
        pass # Blabla.

Fix si tu veux avoir des objets puissant en python (pas utile sur la version 3 c'est par défaut)

Pylades · Le 26/12/2011, à 00:07

Grillé d’une demie-heure, en fait.

tshirtman · Le 26/12/2011, à 09:45

type ou __class__ ne te donnera pas d'indication sur les classes parentes de la classe que tu récupères, ou il faudra remonter de __super__ en __super__ toi même, c'est moche et vraiment pas terrible pour les performances, utiliser isinstance permet de savoir immédiatement si un objet est de la classe qui t'intéresse. Mais bon, même isinstance est a utiliser avec parcimonie, quand tu utilise ça, c'est que tu as dans l'idée d'outrepasser l'interface normal que tu as vers l'objet, ou de faire des suppositions sur ce qui est disponible, d'ou l'utilisation de hasattr ou getattr plus conseillée, pour vérifier la présence d'un attribut et de requéter une attribut par son nom.

Kanor · Le 26/12/2011, à 12:06

Πυλάδης a écrit :

Grillé d’une demie-heure, en fait.

Ah oui pas réveillé hier

Elzen · Le 26/12/2011, à 13:45

tshirtman a écrit :

type ou __class__ ne te donnera pas d'indication sur les classes parentes de la classe que tu récupères, ou il faudra remonter de __super__ en __super__ toi même, c'est moche et vraiment pas terrible pour les performances, utiliser isinstance permet de savoir immédiatement si un objet est de la classe qui t'intéresse. Mais bon, même isinstance est a utiliser avec parcimonie, quand tu utilise ça, c'est que tu as dans l'idée d'outrepasser l'interface normal que tu as vers l'objet, ou de faire des suppositions sur ce qui est disponible, d'ou l'utilisation de hasattr ou getattr plus conseillée, pour vérifier la présence d'un attribut et de requéter une attribut par son nom.

Bah en l'occurrence, c'est pour un système de boutons pour ma barre d'onglets.
En gros, les onglets peuvent peuvent représenter plusieurs trucs (actuellement, soit une fenêtre, soit un workspace, soit un viewport (ç'pour ça que j'ai du définir mon propre type, il n'y a pas de classe Viewport dans wnck). Et chaque onglet peut afficher différents boutons (ouverture d'un nouveau workspace, fermeture de l'objet concerné, maximisation de la fenêtre, tout ça).
Comme j'ai tenté de faire un truc évolutif, où tu n'as juste qu'à rajouter un nouveau module pour que tes onglets puissent être gérés différemment, bah quel que soit le type réel de l'objet représenté par l'onglet, tout est géré de la même façon.
Du coup, le module gérant le bouton doit pouvoir dire, quand on lui passe un objet donné, si c'est un truc qu'il « connaît » (et donc s'il peut s'afficher correctement et faire son action normale, genre maximiser un workspace ça n'a pas grande signification), ou pas. Donc connaître son type, pour ça.
Dans ce cas-là, j'pense qu'utiliser type est plutôt safe, parce que si vraiment j'avais besoin de dériver un des trois types en question, c'est que j'voudrais changer bizarrement le comportement et que de toute façon, les boutons existants ne seraient probablement plus adaptés.

Mais je note, j'utiliserai isinstance (qui a donc l'air d'être l'équivalent du instanceof en Java) dans les cas où j'en aurais besoin, merci ^^

tshirtman · Le 26/12/2011, à 15:29

pourquoi n'implémente tu pas une interface commune a tes classes et leur délègue l'implémentation des actions spécifiques?

Elzen · Le 26/12/2011, à 16:35

C'est le cas (enfin, c'est une classe mère, pas une interface, vu qu'il y a une partie du comportement qui est fixe et donc implémenté une fois pour toutes). Sauf que ce que j'ai oublié de préciser, c'est que le même mécanisme est en place pour les boutons : j'ai une pseudo-interface (c'est pas super-formel, m'enfin, j'n'ai jamais prétendu faire du code exemplaire, y aurait sûrement plein de trucs à améliorer), et les différents boutons disponibles sont représentés chacun par un module indépendant, comme ça on a juste à ajouter un fichier python pour ajouter un nouveau modèle de bouton. C'est la superclasse qui gère l'affichage des boutons, donc je ne sais pas a priori quels seront les objets à manipuler.
Edit : au départ, j'avais commencé à faire une bibliothèque regroupant les différents boutons pour chaque type d'objet à manipuler, et le gestionnaire d'onglet devait juste préciser quelle bibliothèque de boutons il utilisait. Mais ça me paraissait moins souple et moins facilement extensible, donc j'ai changé pour ce modèle-là.
D'autant que j'ai un type de gestionnaire d'onglets pour lequel le type d'objets à manipuler change régulièrement (un truc qui n'affiche qu'un seul onglet unique, représentant soit la fenêtre active, soit, s'il n'y en a pas, le bureau actif, donc le truc cherche à appliquer la même configuration de boutons soit à une fenêtre, soit à un workspace, donc il faut que le même bouton puisse réagir aux deux.

T'façon ç'n'est qu'expérimental pour le moment : j'compte publier ça dans le courant de la semaine, donc si t'as un peu de temps, tu pourras jeter un œil sur le code et râler ^^

Dernière modification par ArkSeth (Le 26/12/2011, à 16:43)

tshirtman · Le 26/12/2011, à 20:23

Pour l'instant j'ai du mal a suivre tes explications, j'avoue, je pensais pourtant avoir bien éliminé les divers alcools d'hier…

edit: si les interfaces à la java te manquent, y'a la zope component architecture (zca) qui fournis interface et implements, pour ceux qui trouve qu'il manque des bouts de POO à python, mais bon, perso, je trouve que les trucs zope, c'est aussi incompréhensible que le java.

http://bluebream.zope.org/doc/1.0/manua … cture.html

Dernière modification par tshirtman (Le 26/12/2011, à 20:28)

Pylades · Le 26/12/2011, à 21:04

==6416== More than 10000000 total errors detected.  I'm not reporting any more.
==6416== Final error counts will be inaccurate.  Go fix your program!
==6416== Rerun with --error-limit=no to disable this cutoff.  Note
==6416== that errors may occur in your program without prior warning from
==6416== Valgrind, because errors are no longer being displayed.
==6416== 
^C==6416== 
==6416== HEAP SUMMARY:
==6416==     in use at exit: 40 bytes in 2 blocks
==6416==   total heap usage: 9 allocs, 99,413,753 frees, 131 bytes allocated

grim7reaper · Le 26/12/2011, à 21:07

Tu l’as lancé sur quoi ?

Pylades · Le 26/12/2011, à 21:10

Sur un programme de test pour la nouvelle interface de Libstropt.
Mais bon, à voir la sortie, je dois boucler indéfiniment dans un destructeur, rien de bien méchant. Mais j’aime bien le « Go fix your program! », donc je partage. ^^

D’ailleurs, problème résolu, un coup d’œil et un $hhi++^[ZZ plus tard…

Dernière modification par Πυλάδης (Le 26/12/2011, à 21:20)

Pylades · Le 27/12/2011, à 02:40

[master 4686f6f] .gitignore added; new file basic.c for miscellaneous convenience functions; API begins to switch to a new flavor, but still working with the old behavior by compiling defining OLD; now in alpha 3
 10 files changed, 233 insertions(+), 10 deletions(-)
 create mode 100644 .gitignore
 create mode 100644 basic.c

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1976 Le 23/12/2011, à 22:27

Re : /* Topic des codeurs [6] */

#1977 Le 23/12/2011, à 23:11

Re : /* Topic des codeurs [6] */

#1978 Le 24/12/2011, à 09:10

Re : /* Topic des codeurs [6] */

#1979 Le 24/12/2011, à 22:42

Re : /* Topic des codeurs [6] */

#1980 Le 25/12/2011, à 14:46

Re : /* Topic des codeurs [6] */

#1981 Le 25/12/2011, à 19:39

Re : /* Topic des codeurs [6] */

#1982 Le 25/12/2011, à 19:48

Re : /* Topic des codeurs [6] */

#1983 Le 25/12/2011, à 20:00

Re : /* Topic des codeurs [6] */

#1984 Le 25/12/2011, à 20:16

Re : /* Topic des codeurs [6] */

#1985 Le 25/12/2011, à 21:00

Re : /* Topic des codeurs [6] */

#1986 Le 25/12/2011, à 21:22

Re : /* Topic des codeurs [6] */

#1987 Le 25/12/2011, à 21:24

Re : /* Topic des codeurs [6] */

#1988 Le 25/12/2011, à 21:27

Re : /* Topic des codeurs [6] */

#1989 Le 25/12/2011, à 21:51

Re : /* Topic des codeurs [6] */

#1990 Le 26/12/2011, à 00:07

Re : /* Topic des codeurs [6] */

#1991 Le 26/12/2011, à 09:45

Re : /* Topic des codeurs [6] */

#1992 Le 26/12/2011, à 12:06

Re : /* Topic des codeurs [6] */

#1993 Le 26/12/2011, à 13:45

Re : /* Topic des codeurs [6] */

#1994 Le 26/12/2011, à 15:29

Re : /* Topic des codeurs [6] */

#1995 Le 26/12/2011, à 16:35

Re : /* Topic des codeurs [6] */

#1996 Le 26/12/2011, à 20:23

Re : /* Topic des codeurs [6] */

#1997 Le 26/12/2011, à 21:04

Re : /* Topic des codeurs [6] */

#1998 Le 26/12/2011, à 21:07

Re : /* Topic des codeurs [6] */

#1999 Le 26/12/2011, à 21:10

Re : /* Topic des codeurs [6] */

#2000 Le 27/12/2011, à 02:40

Re : /* Topic des codeurs [6] */

Pied de page des forums