Forum Programmation.python PyGTK, taille et position des fenêtres

• # bizarre

  Posté par Brahici le 23 mars 2005 à 17:38. Évalué à 2.

  

  je ne vois pas pourquoi tu travailles sur la fenêtre gdk et pas sur la fenêtre gtk.
  c'est aussi simple de prendre directement la fenêtre de ton application et de lui demander sa position et sa taille
  
  w=gtk.Window(gtk.WINDOW_TOPLEVEL)
  w.get_position()
  w.get_size()
  
  ce qui dans ton cas pourrait donner
  
  xml_out += '%d' % w.get_position()[0]
  xml_out += '%d' % w.get_position()[1]
  xml_out += '%d' % w.get_size()[0]
  xml_out += '%d' % w.get_size()[1]

  • [^] # Re: bizarre

    Posté par rangzen (site web personnel) le 23 mars 2005 à 17:46. Évalué à 2.

    

    Parceque get_position et get_size ne correspondent pas à ce que je veux :)
    J'ai besoin d'enregistrer la position et la taille de chaque note dans un reminder.
    
    En fait il suffit d'utiliser le raccourci self.window qui permet d'acceder aux fonction de gtk.gdk.Window depuis les fenêtres gtk.Window
    
    Pourquoi self.window ??? Aucune trace dans la doc ...
    
    Ca donne :
    x = self.window.get_origin()[0]
    y = self.window.get_origin()[1]
    width = self.window.get_geometry()[2]
    height = self.window.get_geometry()[3]
    
    Un gourou de GTK dans la salle ?

    • [^] # Re: bizarre

      Posté par Brahici le 23 mars 2005 à 18:10. Évalué à 2.

      

      self.window est hérité de Widget
      >>> help(gtk.Window)
      (...)
      | Data and other attributes inherited from Widget:
      (...)
      | window = <attribute 'window' of 'gtk.Widget' objects>
      (...)
      
      je suppose que l'utilité est d'avoir un lien direct sur la fenêtre gdk sans passer par get_parent_window, mais il est vrai qu'il n'y a pas trop d'info sur cela dans la documentation. il faudrait peut-être jeter un oeil sur l'API gtk. un volontaire ?
      
      enfin si les informations de la fenêtre gdk font ton bonheur, alors je ne vois pas de manière plus concise de coder que ce que tu proposes.

      • [^] # Re: bizarre

        Posté par rangzen (site web personnel) le 23 mars 2005 à 18:24. Évalué à 2.

        

        Et ben aujourd'hui, j'aurais aussi apris help() !
        Merci monsieur !

• # re

  Posté par Sylvain (site web personnel) le 23 mars 2005 à 17:43. Évalué à 1.

  

  J'ai du mal a comprendre l'interet de PyGTK, puisque tu peux avoir WXPython en GTK ou GTK2 : /.
  
  De plus les interfaces que tu feras en wxpython seront en GTK sur les linux mais marcheront aussi sur les autre plateforme (OSX, windows) sans changer une ligne de code :).
  
  Je dis ca car je voulais t'aider mais je connais pas du tout PyGTK mais seulement TK et WXWindows
  
  Et que le bout de code que tu a ecrit en haut comparer au bout de code sur wxwindows pour la position je me dis que wow je vais rester sur WXWindows :)
  
  self.Configure(pos=50,50) (un truc du genre).
  
  Ou meme plus audacieux , centrer automatiquement une fenetre dans l'ecran self.CenterOnScreen()
  
  Surtout que je pige pas ta question puisque les attribut des objets sont automatiquement validés si tu les changent.
  Et pour y acceder un self.GetPosition peux te retourner le tuple de la position en question.
  
  Tu voudrai resauvegarder dans une variable a part les valeurs des positions ? Au lieu de les consulter quand tu en a besoin ?

  • [^] # Re: re

    Posté par rangzen (site web personnel) le 23 mars 2005 à 17:48. Évalué à 2.

    

    J'en viens de Wx et ben après quelques jours sous gtk, hors de question d'y retourner :D
    
    cf : http://linuxfr.org/~cursor/17206.html

  • [^] # Re: re

    Posté par Brahici le 23 mars 2005 à 17:54. Évalué à 2.

    

    personnellement je fais du pygtk portable linux/win32 sans changer une ligne de code ...
    mais il peut sembler plus naturel de choisir wx ou tk pour du vrai multiplateforme; c'est peut-être aussi une question de goût, j'ai toujours beaucoup de mal à positionner correctement mes widgets avec wx car je suis trop habitué à gtk.

    • [^] # Re: re

      Posté par Sylvain (site web personnel) le 23 mars 2005 à 18:16. Évalué à 2.

      

      Et sur Mac OS aussi ? :)
      
      Mais je t'avoue que les sizer/panel m'on donner bcps de fil a retordre :/.
      Mais cela permet un control absolue sur les tabulations interchamps par exemple :).
      Une fenetre bien decrite, peut eviter de se faire a la mano les binds de tabulations pour des ensemble de widgets.
      
      C'est a dire, si tu veux que le curseur fasse un parcours de widget bien definie lors de la tabulation, une bonne definition des sizers/panel peut automatisé cela sans rajouter une ligne de code pour definir le bind et la prochaine position du curseur.
      
      C'est le seul interet pour l'instant que je vois des panel, les sizers eux autoadapte la position/taille des widget en fonction de la taille de la fenetre (agrandi,retreci,et maitriser les elements qui vont s'expand).
      
      Pour ce qui est du TK je suis relativement mitigé, comme par le fait de pas avoir par defaut le moyen de binder l'evenement OnChange sur les PMW ComboBox.
      
      Et surtout la position des widget n'est pas exactement la meme quand tu execute ton apllication en TK d'une plateforme a une autre (pour moi c'etait de linux à windows), j'avais les widget qui se chevaucher sur windows et pas sur linux, obliger de changer la position des widget pour compiler d'une plateforme a une autre.
      
      Alors que apres j'ai decouvert le WXWindows et fini les surprises interplateforme (hormis quand je connaissais pas le fait de creer des nouveaux event lors d'un programme multithread, ce qui creer des figes ), mes description de fenetre pour l'instant ( je dis pas qu'il y est pas des exceptions) ont été _respectées_ d'une plateforme a une autre sans aucun probleme mais alors vraiment aucun ( a part sur win32 ou le PNG n'a pas de canal transparent ).

Suivre le flux des commentaires

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