wxPython Conventions

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Jared Russell

    #1

    wxPython Conventions

    I've recently decided to try my hand at GUI programming with wxPython,
    and I've got a couple questions about the general conventions regarding
    it.

    To mess around with it, I decided to create a small app to check my
    Gmail. I want something that will just sit in my system tray checking
    for new emails every ten minutes or so. As such, I have no need for an
    actual window anywhere. So I'm wondering if I should still use a Frame
    or not. From playing around with it, it seems it's unnecessary, but
    I'm admittedly unfamiliar with what would be considered proper.

    My other question involved the proper location of specific functions.
    Take for instance the functions meant for logging in and actually
    checking for new email. Would it be better to put them in my App
    class, my Frame class (if the answer to the above question is that yes,
    I should use a Frame regardless), or in an entirely separate class? To
    me, it seems most natural to put them in the App class, but I'm not
    sure if it would be better to avoid clutter and stick them somewhere
    else. And if I would stick them in some other class, where should I
    keep the reference to the instance of that class? In my App or Frame?

    Like I said, I'm just beginning my experience with wxPython, so any
    help would be appreciated. I've looked through all the demos and
    searched the group, but nothing else seems to pertain to my specific
    questions.

    Jared

  • akameswaran@gmail.com

    #2
    Re: wxPython Conventions

    I'm also fairly new to wxPython, but I've done GUI's in a variety of
    languages. I'm not sure about putting the systray - haven't had to
    do it. But your second question, put it in it's own class. For
    desktop apps I almost allways do a limited M/V/C pattern - M/VC - ok so
    I mung the view and controller together. Doing that made it easy for
    me to replace tKinter with a newer wxGUI, and if a new toolkit comes
    out - It'll be easy to move. Since I'm a newbie to wxPython - I've
    keep having to change my event handling due to ignorant usage - when
    making these mistakes, it's a lot easier to nuke and recreate a widget,
    or event path if your data and functions are in separate classes. Now
    as for attaching the class, I'm not sure how you've modelled your
    software. Performace considerations are also a real factor - if
    performance is not a driving factor, and the program is simple enough -
    just let each widget have a reference to the objects it talks to.

    Ie, I have a package named GMailAccount, which contains a
    GMailAccountInf ormation class. Now when you create the widget for
    getting this text, maybe a wx.Panel with a couple of textctrl, assign
    the widget a GMailAccountInf ormation.

    When performance starts to matter, probably want to go to some object
    caching scheme in a model class, and have the widgets interface with
    that - but now we're getting into a full M/V/C - and I haven't had to
    do that yet in my playing with wx.

    Hope this helps.

    Comment

    • Magnus Lycka

      #3
      Re: wxPython Conventions

      Jared Russell wrote:[color=blue]
      > My other question involved the proper location of specific functions.[/color]

      Never mix business with plea^h^h^h^hGUI . I'd suggest that you write a
      Python module with all your business logic that you can test from the
      interactive interpreter. Roughly like this:
      [color=blue][color=green][color=darkred]
      >>> import gmailchecker
      >>> def show(text):[/color][/color][/color]
      .... print text
      ....[color=blue][color=green][color=darkred]
      >>> gmailchecker.lo gin('username', 'password')
      >>> gmailchecker.ch eck(show, 10)[/color][/color][/color]

      When you build a GUI, you will pass in some bound
      method of one of your widgets that will alert the
      user instead of the show function above.

      This approach makes your code much more useful. You
      can use it in other contexts than a small GUI app,
      you can swap GUI when you want that, and you can
      easily write unit tests for your logic.

      Comment

      • Iain King

        #4
        Re: wxPython Conventions


        Jared Russell wrote:
        [color=blue]
        > To mess around with it, I decided to create a small app to check my
        > Gmail. I want something that will just sit in my system tray checking
        > for new emails every ten minutes or so.[/color]

        How do you gain access to the system tray?

        Iain

        Comment

        • Johan Lindberg

          #5
          Re: wxPython Conventions


          Iain King skrev:
          [color=blue]
          > How do you gain access to the system tray?[/color]

          Use wx.TaskBarIcon.
          See http://wiki.wxpython.org/index.cgi/FlashingTaskbarIcon for
          snippets.

          /Johan

          Comment

          • Jared Russell

            #6
            Re: wxPython Conventions

            Thanks for all the replies. I'm admittedly new to GUI programming, so
            I'm making sure to read up on the MVC pattern and related things like
            the observer pattern. I appreciate the help.

            Jared

            Comment

            Working...