Search code examples
pythontkinterwxpythonpyqtpygtk

Considerations for python gui toolkit for app that queries remote database?


I know this question has been asked before but those questions typically lack specific details and result in answers that say something like "It depends what you are trying to do..." so the main gist of this app is that it retrieves remote data (ex. text) and object (ex. images).

Since PHP and python are the two programming languages I feel comfortable with I felt python was more suited for desktop gui apps. I'm creating a desktop music player and here are some of the technical specs I want to include:

  • A sign in construct that authenticates user credentials (Like spotify, skype, league of legends) against a remote database (This will be in mysql.) My thinking is to create a web api for the client to query via HTTP/HTTPS GET/POST
  • A client side SQLite database that stores the filename, filepath and id3 tags of the song so upon launching, the application displays each song in a row with the song length, artist, album, genre (Like iTunes)
  • Retrieve remote images and display them within the application's frame (Like skype displays a person's profile picture.)
  • Must be cross-platform (At least in Windows and Mac), look native in different OS's but the native look and feel should be easily overridden with custom styles (Ex. rounded buttons with gradients.)
  • Compilation for Windows and Mac should be relatively straightforward

Of the popular python gui toolkits like PyQt, PyGTK, Tkinter, wxPython, Pyjamas, PyGObject and PySide which are well suited for my application and why? Why are the others not well suited for these specs? Which have good documentation and active communities?


Solution

  • Welcome to a fun area:

    1. Watch out for urllib2: it doesn't check the certificate or the certificate chain. Use requests instead or use ssl library and check it yourself. See Urllib and validation of server certificate Sometimes a little ZeroMQ (0mq) can simplify your server.

    2. You should consider shipping a self signed certificate with your application if you are a private server/private client pair. At that point, validating the certificate eliminates a host of other possible problems.

    3. While you could read a lot about security issues, like Crypto 101, the short version is use TLS (the new name for SSL) to transmit the data and GPG to store the data. TLS keeps others from seeing and altering the data when moving it. GPG keeps others from seeing and altering the data when storing or retreiving it. See also: How to safely keep a decrypted temporary data? Enough about security!

    4. SqlLite3, used with gpg, is fine until you get too large. After that, you can move to MariaDB (the supported version of MySQL), PostGreSQL, or something like Mongo. I'm a proponent of doing things that don't scale and getting something working now is worthwhile.

    5. For the GUI, you'll hate my answer: HTML/CSS/JavaScript. The odds that you will need a portal or mobile app or remote access or whatever are compelling. Use jQuery (or one of its lightweight cousins like Zepto). Then run your application as a full screen application without a browser bar or access to other sites. You can use libraries to emulate the native look and feel, but customers almost always go "oh, I know how to use that" and stop asking.

    6. Still hate the GUI answer? While you could use Tcl/Tk or Wx but you will forever be fighting platform bugs. For example, OS/X (Mac) users need to install ActiveState's Tcl/Tk instead of the default one. You will end up with a heavy solution for the images (PIL or ImageMagick) instead of just the HTML image tag. There is a huge list of other GUIs to play with, including some using the new 'yield from' construct. Still, you do better with HTML/CSS/JavaScript for now. Watch the "JavaScript: the Good Parts" and then adopt an attitude of ship it as it works.

    7. Push hard to use either Python 2,7 or Python 3.3+. You don't want to be fighting the rising tide of better support when you making a complicated application.

    I do this stuff for FUN!