Speaker 1: Welcome to the deep dive. Today we're diving into a
Speaker 1: stack of source material all about building graphical user interfaces,
Speaker 1: you know, those clickable windows with buttons and textboxes using Python.
Speaker 2: And our main guide for this journey is the second
Speaker 2: edition of Python gy Programming Cookbook by Burkhard A. Meyer
Speaker 2: from back in twenty seventeen.
Speaker 1: Okay, let's unpack this. This book sounds like it's basically
Speaker 1: a collection of recipes, right, tackling everything from just like
Speaker 1: getting a window to show up, yeah, to making it
Speaker 1: interactive with buttons, text fields, organizing complex layouts, handling data.
Speaker 2: Dealing with slow operations without freezing your app. That's a
Speaker 2: big one.
Speaker 1: Oh yeah, connecting to databases, even thinking about different languages
Speaker 1: and testing. It seems pretty comprehensive.
Speaker 2: It really is. It aims for a practical, hands on feel.
Speaker 2: The author, Burkhard Meyer, has something like seventeen years in
Speaker 2: the software industry, especially with Python and databases. Okay, worked
Speaker 2: at various places. And there was a reviewer input too
Speaker 2: from Mohit who also knows Python and security. So it
Speaker 2: feels grounded in, you know, actually building stuff, right.
Speaker 1: So our mission here is to sift through all these
Speaker 1: recipes and concepts. We want to pull out the really
Speaker 1: essential techniques, the key ideas, so you can get a
Speaker 1: solid grasp of Python gui's without reading well every single line.
Speaker 2: Of code, basically giving you the highlights real.
Speaker 1: Exactly the informed shortcut. So where does one even begin?
Speaker 1: The book starts like any good cookbook with the absolute minimum, right,
Speaker 1: getting your first window on screen?
Speaker 2: Yeah, using pythons built in kinter library. People usually shorten
Speaker 2: it to just TK. Okay, and the starting code is
Speaker 2: surprisingly simple. You import kinter you create an instance of
Speaker 2: the main window class that's TK dot TK usually assign
Speaker 2: it to a variable, say win, and then the absolutely
Speaker 2: crucial bit win dot main loop.
Speaker 1: The main lo Okay, that sounds fundamental. It's like the
Speaker 1: heart of the whole thing totally.
Speaker 2: It's the event loop. It just sits there, kind of
Speaker 2: waiting for things to happen. Button clicks, keypresses, resizing, Oh.
Speaker 1: The events.
Speaker 2: Yeah, the main loop process these. Without it, your window
Speaker 2: might literally just flash up and disappear because the script finishes.
Speaker 2: The main loop keeps it alive and listening.
Speaker 1: Got it. So it's not just displaying, it's running the
Speaker 1: interactive part. And the book mentions a quick tip about
Speaker 1: stopping resizing.
Speaker 2: Yeah, simple one. If you want to fix size window,
Speaker 2: just win dot resizable zero zero zero, easy way to
Speaker 2: lock it down.
Speaker 1: Okay, useful. So we have our basic window frame. But
Speaker 1: an empty box isn't much of a GUI. You need
Speaker 1: stuff inside it. The widgets. What are the first building
Speaker 1: blocks the book introduces.
Speaker 2: Well, the most basic are probably labels. Just text for
Speaker 2: showing information or instructions uses TTK dot label simple text.
Speaker 2: Then entry widgets. Those are your standard single line textboxes
Speaker 2: for getting user input dtk dot.
Speaker 1: Entry right displaying info versus getting input. And the main
Speaker 1: way to trigger.
Speaker 2: Actions buttons dot ttk dot button. And this is where
Speaker 2: callbacks become super important. When you create a button, you
Speaker 2: tell it which Python function to call when it's clicked
Speaker 2: using the command argument. So you'd have my function name
Speaker 2: that links the click event to your code.
Speaker 1: So the click is the event command links it to
Speaker 1: the callback function precisely.
Speaker 2: That function just waits passively until the main loop detects
Speaker 2: a click on that button, and then it gets executed.
Speaker 1: Nice. The book also mentions usability things like putting the
Speaker 1: cursor in the right place automatically YEP.
Speaker 2: Using the focus method on a widget. So if you
Speaker 2: call my entry dot focus, the cursor starts blinking in
Speaker 2: that text box. Little things like that make a.
Speaker 1: Difference and disabling widgets.
Speaker 2: Yeah, you can set a property when you create it,
Speaker 2: like a button, so it appears grayed out and doesn't
Speaker 2: respond to clicks.
Speaker 1: Okay, what about giving users choices not just text entry? Uh?
Speaker 2: Check buttons are covered for simple on off choices like
Speaker 2: a settings toggle right. They hold their state checked or unchecked,
Speaker 2: usually zero or one using a special variable pickenter dot infar.
Speaker 2: You can set the initial state using select an alignment.
Speaker 1: You mentioned sticky before.
Speaker 2: Yes, sticky tk wf and gets used with check buttons
Speaker 2: to make sure they line up nicely on the left
Speaker 2: side within their layout. Cell w for.
Speaker 1: West got it, and radio buttons if for picking just
Speaker 1: one option from a group.
Speaker 2: Exactly radio buttons. The key difference is that a group
Speaker 2: of radio buttons all share the same kintervariable. When you
Speaker 2: click one, its value gets assigned to that variable, and
Speaker 2: the others automatically de select ah.
Speaker 1: So check buttons each have their own variable. Radio buttons
Speaker 1: share one.
Speaker 2: That's the crucial distinction for managing their state and selecting
Speaker 2: A radio button can also trigger a callback immediately, maybe
Speaker 2: to change something else in the GI based on the choice.
Speaker 1: Okay, what about selecting numbers or from a list?
Speaker 2: Spin box controls are good for that. You get a
Speaker 2: little box with up down arrows. Again, cycle through numbers
Speaker 2: or even a predefined list of text items.
Speaker 1: Can you react when the value changes?
Speaker 2: Oh yeah, just like a button, You can attach a
Speaker 2: command callback that fires whenever the stin box value is changed.
Speaker 2: The book shows an example of displaying the selected value
Speaker 2: in say a larger text area.
Speaker 1: Larger text area scroll texts exactly.
Speaker 2: Scroll text really useful for multiline input or display. The
Speaker 2: nice thing is features like word wrapping, wrap ek at
Speaker 2: word and the scroll bars appearing automatically. They just work.
Speaker 2: You mainly just defined its width and height.
Speaker 1: Okay, so we can populate a window with widgets, but
Speaker 1: they'll just pile up, right, How do you organize them?
Speaker 1: Layout management?
Speaker 2: Yeah, that's the next big step arranging things logically. The
Speaker 2: core idea the book uses is nesting. You put widgets
Speaker 2: inside container.
Speaker 1: Fidgets like containers within container pretty much.
Speaker 2: Ttk dot label frame is a key example. It's a
Speaker 2: container that draws a border around its contents and has
Speaker 2: a text label. You put related widgets inside a label frame.
Speaker 2: Then you arrange the label frame itself within the main window,
Speaker 2: maybe alongside other label frames or widgets. It helps break
Speaker 2: down complexity.
Speaker 1: And spacing to avoid everything being crammed together.
Speaker 2: Patting pad X for horizontal space, patty for vertical space
Speaker 2: around each widget. Usually set these when you place the
Speaker 2: widget using the layout manager.
Speaker 1: The book mentions grid mostly Yes.
Speaker 2: The grid layout manager is heavily featured. It arranges widgets
Speaker 2: in well a grid of rows and columns. You specify
Speaker 2: the row and column for each widget.
Speaker 1: And you can tweak padding later too.
Speaker 2: The book points out you can use methods like grid
Speaker 2: Configure after placing a widget to adjust its padding or
Speaker 2: other grid options if needed.
Speaker 1: What about when the user resizes the window. Do widgets
Speaker 1: just stay fixed or can they stretch.
Speaker 2: Ah dynamic expansion. That's where Sticky really comes into play again.
Speaker 2: We saw sticky tk dot W for left alignment, but
Speaker 2: you can use tk E eastwright, TK in north top,
Speaker 2: tks self bottom or combinations like TK dot n SEW
Speaker 2: to make a widget stretch and fill the entire grid cell.
Speaker 2: It's in horizontally and vertically as the window.
Speaker 1: Resizes and spanning multiple cells.
Speaker 2: Also crucial, column span two makes a widget take up
Speaker 2: two columns. Rospan three takes three rows, combining sicki and columns.
Speaker 2: Thin row span gives you really fine grain control over
Speaker 2: how your layout adapts.
Speaker 1: Grid is the main tool here. What if the GUI
Speaker 1: has like tons of options, does it just become one
Speaker 1: giant window.
Speaker 2: That's where TTK dot notebook comes in. It creates tabbed interfaces.
Speaker 2: You put different sets of controls on different tabs, keeps
Speaker 2: the main window much cleaner tabs.
Speaker 1: Okay, that makes sense for complexity. Moving beyond structure, what
Speaker 1: about the look and feel, making it polished? Giving feedback?
Speaker 2: Right? Standard pop up messages are a basic need. Kinder
Speaker 2: has built in message box functions show info for infos,
Speaker 2: show warning for warnings, shower for.
Speaker 1: Errors, and they pause the main GUI.
Speaker 2: Yes, they're modal. The user has to dismiss the message
Speaker 2: box before they can interact with the main window. Again
Speaker 2: important behavior.
Speaker 1: The book mentions independent message boxes. What's that about.
Speaker 2: It's more about maybe structuring your code so the call
Speaker 2: to show a message box is in its own function,
Speaker 2: perhaps for reuse. There's a small code trick mention to
Speaker 2: get the text into the body, not the title. And
Speaker 2: also a reminder if you create a tk instance just
Speaker 2: to use a message box, might need wind dot withdraw
Speaker 2: to hide the blank extra window that kinder.
Speaker 1: Creates little details. What about customizing the main window itself
Speaker 1: title icon pzps.
Speaker 2: Setting the title is just a method call wind dot
Speaker 2: title my app. The icon usually needs a specific file
Speaker 2: format dot ico on Windows, and you might need the
Speaker 2: full paths to the file.
Speaker 1: Any other visual tweaks mentioned like three D effects, Yeah.
Speaker 2: The relief property comes up again. Setting relief sunken or
Speaker 2: relief raised on widgets like frames or labels can give
Speaker 2: them that classic embossed or debossed look adds a bit
Speaker 2: of depth.
Speaker 1: And those little helper texts when you hover over something.
Speaker 2: Tooltips, Yeah, the book shows how to implement them. It
Speaker 2: actually suggests using an object oriented approach creating a tooltip
Speaker 2: class ahop again Yeah, it makes the tooltip logic reusable
Speaker 2: and cleaner to attach to different widgets.
Speaker 1: Okay, And for tasks that take a while showing progress.
Speaker 2: The standard TTK dot progress bar you add it to
Speaker 2: your layout and the book shows how to start its
Speaker 2: animation when a task begins and stop it when done,
Speaker 2: basic visual feedback that something's happening.
Speaker 1: This feels like a natural lead into handling data within
Speaker 1: the dui and maybe where OP really starts to shine definitely.
Speaker 2: First, the book introduces special tinter variable types like stringvar.
Speaker 2: These aren't just normal Python strings.
Speaker 1: How are they different?
Speaker 2: They're designed to be linked directly to widgets. If you
Speaker 2: link a stringvar to an entry widget, changing the string
Speaker 2: bar in your code automatically updates the text in the
Speaker 2: entry box, and typing in the entry box updates the stringvar.
Speaker 1: Oh two way binding kind of yeah.
Speaker 2: Use methods like dot set to put a value into
Speaker 2: the string bar and dot get to recrieve the current
Speaker 2: value from it.
Speaker 1: And the book notes a quirk about needing a TK
Speaker 1: instance even just to create a string bar, even if
Speaker 1: you hide the window.
Speaker 2: Yeah, it's a bit weird. These ticket tenor variables rely
Speaker 2: on the underlying TK machinery being initialized, which happens when
Speaker 2: you create TK. So even for non visual use, you
Speaker 2: might need root ektktk root dot withdrawal.
Speaker 1: So calling dot get on these variables or directly on
Speaker 1: a widgets like entry is how you pull the user's
Speaker 1: input back into your Python logic.
Speaker 2: That's the main way. Once you get the value, it's
Speaker 2: just a standard Python string or number or whatever, and
Speaker 2: you can work with it. The trick is when to
Speaker 2: call dot get, usually inside a callbad function.
Speaker 1: The book mentions using module level global variables for simple
Speaker 1: data sharing, but then pushes towards op pretty strongly.
Speaker 2: Why well, globals are tempting for super simple scripts, quick
Speaker 2: and easy, but as soon as your GUI gets even
Speaker 2: a little bit complex, tracking which function modified which global
Speaker 2: variable becomes a nightmare, really hard to debug OPI. Using
Speaker 2: classes provides encapsulation. You bundle the data as attributes of
Speaker 2: an object, together with the methods functions belonging to the
Speaker 2: object that operate on that data. It keeps things organized,
Speaker 2: prevents accidental modification from unrelated code, and makes the whole
Speaker 2: thing much easier to maintain and extend later.
Speaker 1: So a method is just a function inside a class
Speaker 1: that acts on the classes data.
Speaker 2: Pretty much, and it usually takes self as it's first argument,
Speaker 2: which refers to the specific object instance it's working with.
Speaker 2: The book really emphasizes trying to refactor a messy NONOOPI
Speaker 2: procedural GUI into oop later is painful. It's much better
Speaker 2: to start with an OP structure if your project is
Speaker 2: going to be anything beyond trivial.
Speaker 1: And this connects back to the event driven nature.
Speaker 2: Absolutely, the GUI sits there, an event happens button click,
Speaker 2: the main loop directs it to the callback. That callback
Speaker 2: is often an OP method self dot on button click,
Speaker 2: which then uses self to access the object's data, maybe
Speaker 2: calls dot get on some widgets, does calculations, and maybe
Speaker 2: calls dot set on other widgets to update the display.
Speaker 1: Okay, this next one is where I think a lot
Speaker 1: of people, including me, have hit a wall. Initially, you
Speaker 1: click a button that app needs to do something slow,
Speaker 1: and the whole GUI just freezes.
Speaker 2: Ah. Yes, the dreaded unresponsive GUI. It's a classic symptom
Speaker 2: of doing long running tasks directly in the main GUI thread.
Speaker 2: Why does it happen because basic kinter and many GI
Speaker 2: toolkits runs its event loop main loop in a single thread.
Speaker 2: If that thread gets busy doing something else like downloading
Speaker 2: a big file, running a complex calculation, querying a slow database,
Speaker 2: it can't process other events. It can't redraw the window,
Speaker 2: respond to clicks anything. It's blocked.
Speaker 1: So what's the fix?
Speaker 2: Multi threading? You need to run that long running task
Speaker 2: in a separate thread. The main thread stays free to
Speaker 2: run the main loop and keep the GI responsive while
Speaker 2: the worker thread chugs away in the background.
Speaker 1: Okay, threads. The book distinguishes between threads and processes.
Speaker 2: Briefly, Yes, Processes are more isolated, each with its own memory.
Speaker 2: Threads run within the same process and share memory. For
Speaker 2: tasks within a single GUI application that need to communicate
Speaker 2: back to the GUI, threads are often simpler because sharing
Speaker 2: data is easier.
Speaker 1: Can that worker thread directly update a techer and widget
Speaker 1: like change a labels text when it's done?
Speaker 2: Generally No, that's not thread safe. Directly manipulating taker widgets
Speaker 2: from a background thread can cause crashes or weird behavior.
Speaker 1: So how does the worker thread tell the main GUI thread, Hey,
Speaker 1: I'm done, here's the result.
Speaker 2: The standard safeway is using Python's q Q. It's a
Speaker 2: data structure specifically designed for thread safe communication.
Speaker 1: A que like a waiting line exactly.
Speaker 2: The worker thread puts its result onto the que mi
Speaker 2: que dot dwizzled. The main GUI thread meanwhile periodically checks
Speaker 2: the queue mi qu dot get no weight. If there's
Speaker 2: something there, it safely pulls the result off and updates
Speaker 2: the GUI widgets from within the.
Speaker 1: Main thread, so the Q acts as a safe ordered
Speaker 1: mailbox between threads.
Speaker 2: Perfect analogy. It decouples the threads FIFO first in, first
Speaker 2: out means results are typically processed in the order they finish.
Speaker 2: The book shows how you can pass a Q object around,
Speaker 2: letting different parts of your code, even in separate modules,
Speaker 2: feed results back to the GUI thread without freezing it.
Speaker 1: And common examples of slow tasks shown are things like
Speaker 1: file operations or network calls.
Speaker 2: Yes, using kinter dot request dot a filename is quick,
Speaker 2: but actually reading or writing a large file could block. Similarly,
Speaker 2: using erallib dot request dot eurolopin to fetch web data
Speaker 2: definitely needs a thread if the network is slow where
Speaker 2: the download is large. The book also stresses using try
Speaker 2: except blocks around network code to handle potential errors.
Speaker 1: Gracefully makes sense okay, shifting gears to data persistence. The
Speaker 1: book dives into connecting to my SQL databases, specifically.
Speaker 2: Right, a very common requirement. It uses the miceql dot
Speaker 2: connector library, which is the official driver from Oracle.
Speaker 1: My school, and the first warning is about security absolutely critical.
Speaker 2: The book hammers this home do not put your database
Speaker 2: username and password directly in your Python source code. It's
Speaker 2: a huge security risk if that code ever gets shared
Speaker 2: or exposed.
Speaker 1: So what should you do?
Speaker 2: Store credential separately? Maybe in a configuration file that's kept
Speaker 2: in a secure location, has restricted permissions and is read
Speaker 2: by your application at runtime, or use environment variables or
Speaker 2: a secrets management system, just not hard coded.
Speaker 1: Okay, what basic database operations does it cover?
Speaker 2: The core crwould operations select to fetch data, insert to
Speaker 2: add rows, update to change existing rows, delete to remove rows.
Speaker 2: It also briefly introduces essential database concepts like primary keys,
Speaker 2: unique IDs for rows and foreign keys, linking related tables.
Speaker 1: And is there a tool mentioned for working with the
Speaker 1: database outside of Python.
Speaker 2: Yeah, myseql workbench. It's a free GI tool provided by
Speaker 2: myseql itself, really helpful during development for designing your database schema,
Speaker 2: running test SQL queries, checking data without needing to build
Speaker 2: all that into your Python app.
Speaker 1: First, Okay, let's talk about making apps for a global audience.
Speaker 1: Internationalization and localization I eighteen N and L ten N right.
Speaker 2: Internationalization I eighteen N I plus eighteen letters plus N
Speaker 2: is about designing your app so it can be adapted.
Speaker 2: The main part is separating all user visible text labels,
Speaker 2: button text messages from your code logic. How do you
Speaker 2: do that? The book shows using a simple Python class
Speaker 2: is a I eighteen n that holds dictionaries of strings
Speaker 2: for different language maybe self dot strings and like you
Speaker 2: think kell okay, then in your guy code instead of
Speaker 2: tdk dot label to ttk dot label ticks self dot
Speaker 2: I t and n dot gets string, gets string greeting
Speaker 2: by changing which language dictionary the I eighten n object
Speaker 2: uses eg self dot I ten n dot I ten
Speaker 2: nd low the whole GUI can switch language.
Speaker 1: That's clever and localization L ten N. That's more than
Speaker 1: just language.
Speaker 2: Yeah, L ten N L plus ten letters plus n
Speaker 2: is the actual adaptation to a specific locale. It includes
Speaker 2: things like date time formats M and D d y
Speaker 2: y versus D M M y y, currency symbols, number
Speaker 2: formatting using commas or periods as decimal separators, and crucially,
Speaker 2: time zones.
Speaker 1: Time zones sound tricky.
Speaker 2: They can be. The book shows using pythons built in
Speaker 2: DateTime module along with the third party pits library to
Speaker 2: handle time zone conversions correctly, like displaying a time recorded
Speaker 2: in UTC for someone in say Pacific time.
Speaker 1: What about displaying characters from other languages like German, Lauts
Speaker 1: or maybe Asians.
Speaker 2: Unicode handling Python three is generally pretty good with Unicode strings,
Speaker 2: but sometimes, depending on your operating system, terminal or IDE settings,
Speaker 2: you might run into encoding issues where characters display incorrectly.
Speaker 1: Any solutions mentioned using.
Speaker 2: Python's direct Unicode escapes like U TOFC for you can
Speaker 2: be a robust way, or more commonly, ensuring your source
Speaker 2: code files are saved with UTF eight encoding and that
Speaker 2: your development environment like pit of eclip settings mentioned in
Speaker 2: the book is configured to handle UTFA correctly.
Speaker 1: Okay, building all this is great, but it needs to
Speaker 1: work reliably. Testing. How does the book approach ensuring quality?
Speaker 2: It emphasizes that testing isn't just one thing. It happens
Speaker 2: at multiple levels. There's developer testing just running the code.
Speaker 2: Maybe the IDE catches syntax errors using source control like GIT,
Speaker 2: which helps catch integration conflicts, API testing testing the non
Speaker 2: GUI logic, integration testing, making sure different parts work together,
Speaker 2: and finally end user testing.
Speaker 1: All catch in different kinds of bugs.
Speaker 2: Exactly, you need a mix for debugging when things go
Speaker 2: wrong during development. Buggers, Yeah, using your IDEs debugger is
Speaker 2: key setting break points to pause the code, inspecting the
Speaker 2: values of variables at that point using watches stepping through
Speaker 2: code line by line. The book notes that in GUIs
Speaker 2: you often want to put break points inside your event
Speaker 2: handler functions like button callbacks, because that's where the action
Speaker 2: happens after the mainloop dispatches an event. It also suggests
Speaker 2: setting up your own simple logging using Python's logging module.
Speaker 2: May be configured in the if name equals main part
Speaker 2: of your script.
Speaker 1: Why custom logging.
Speaker 2: It gives you more control than just print statements. You
Speaker 2: can set different logging levels, debug info, warning, error, easily
Speaker 2: switch between logging to the console or a file, and
Speaker 2: filter messages. It's great for tracing what your application is doing,
Speaker 2: especially in response to events.
Speaker 1: And for more formal automated tests.
Speaker 2: Python's built in unitist framework is the standard shown. The
Speaker 2: idea is to write separate test code that imports your
Speaker 2: application code and verifies its behavior.
Speaker 1: Does that work?
Speaker 2: You create test classes inheriting from unitist dot test case.
Speaker 2: Inside you write methods whose names start with test. Within
Speaker 2: these methods, you call parts of your application code and
Speaker 2: use assertion methods like self dot assert equal actual expected
Speaker 2: to check if the results are correct.
Speaker 1: But how do you test gy interactions with unitist. You
Speaker 1: can't easily click a button in a test script.
Speaker 2: Right, You usually don't simulate the physical click. Instead, you
Speaker 2: test the consequences of the click. The book gives an example.
Speaker 2: You directly call the callback function associated with a radio
Speaker 2: button in your test code. Then you check if, say
Speaker 2: a label widget that should have been updated by that callback,
Speaker 2: now contains the expected text. You're testing the logic triggered
Speaker 2: by the event.
Speaker 1: Ah testing the callbacks effect exactly.
Speaker 2: The book also mentions test fixtures set up in tear
Speaker 2: down methods, which let you run code to prepare the
Speaker 2: environment before each test, like creating objects and clean up afterwards.
Speaker 1: Okay, Ticker is built in and clearly powerful, but Python's
Speaker 1: ecosystem is huge. Does the book look at any alternative
Speaker 1: GUI libraries?
Speaker 2: It does. It takes a look at wx Python, specifically
Speaker 2: the Phoenix version, which works with modern Python. It's another
Speaker 2: very popular mature library.
Speaker 1: How's it different from Ticker, Well.
Speaker 2: First, you have to install it separately. It's not built in,
Speaker 2: often done using pipt af files. The basic structure feels
Speaker 2: conceptually similar, though you initialize in wx dot app create
Speaker 2: a main window, wx dot frame, add widgets, and start
Speaker 2: a mainloof the book notes it has good documentation and
Speaker 2: often provides widgets that look more native on different operating systems. Plus,
Speaker 2: things like standard menu mars are easy to set up.
Speaker 1: Can you mix them? Put a wx Python widget inside
Speaker 1: a kinter window or vice versa.
Speaker 2: The book explores this idea, but the conclusion seems to
Speaker 2: be it's usually not a good idea. Trying to embed
Speaker 2: one framework directly inside another often leads to weird rendering issues, crashes,
Speaker 2: or problems shutting down properly.
Speaker 1: So what if you need parts built with different.
Speaker 2: Toolkits, Launching them is completely separate windows? Maybe even separate
Speaker 2: processes seems more stable?
Speaker 1: And how would those separate windows talk to each other?
Speaker 2: Back to our friend, the queue que shared cues are
Speaker 2: presented again as a robust Pythonic way for independent GOI processes,
Speaker 2: even if built with different frameworks, to pass messages or
Speaker 2: data back and forth.
Speaker 1: Okay, cool? What about going beyond two D? Does it
Speaker 1: touch on three D graphics?
Speaker 2: Yep? It introduces libraries for creating true three D scenes,
Speaker 2: primarily PIOPENNGL, which is Python's binding to the standard open
Speaker 2: geographics library.
Speaker 1: You'll need to install that and PILT.
Speaker 2: Pilot is often used alongside or instead of piopen gl
Speaker 2: for handling window creation, event loops, and drawing shapes in
Speaker 2: three D more easily. The book shows an example of
Speaker 2: creating a spinning colored three D cube.
Speaker 1: So you can actually control the three dview with keyboard input.
Speaker 2: Yeah, you can capture keypresses within the pilot open gl
Speaker 2: window and use them to trigger actions like rotating the
Speaker 2: camera or the three D object.
Speaker 1: Can these three D libraries create their own windows without
Speaker 1: needing to kin wx.
Speaker 2: Python, Yes, Absolutely, Pilot or even lower level open gl
Speaker 2: utility libraries like glut can manage their own windows and
Speaker 2: event loops, specifically for rendering the three D graphics and
Speaker 2: handling input for that window. The book even shows simple
Speaker 2: animation examples.
Speaker 1: Okay, one quick step back to two D basics images
Speaker 1: is to kiner good with images out of the box.
Speaker 2: Uh not really. The built in kinter photo image is
Speaker 2: surprisingly limited. It handles formats like GIF and PGMPPM, but
Speaker 2: famously not common ones like JPEG or PNG.
Speaker 1: Previously no JPEGs, nope to.
Speaker 2: Display JPEGs, p and g S and other modern formats
Speaker 2: in kinter, you pretty much need the Pillow library. It's
Speaker 2: the modern successor to the old Python Imaging library PIL.
Speaker 1: So you install pillow right PIP and sall pillow.
Speaker 2: Then you use image tk dot photo image from the
Speaker 2: PIL module. Yes, the import is still often PIL to
Speaker 2: load your image file and that object can be used
Speaker 2: in Kinder labels or buttons.
Speaker 1: Got it. So Pillow is essential for real world image
Speaker 1: handling and teeter that covers a mass of amount of ground,
Speaker 1: from basic widgets to three D and databases. How does
Speaker 1: the book tie this all together with advice on writing
Speaker 1: good gy code best practices.
Speaker 2: It definitely emphasizes writing code that's clean, maintainable, and extendable.
Speaker 2: A big theme is avoiding spaghetti code. Spaghetti code, yeah,
Speaker 2: you know, code that's all tangled up, jumps around unpredictably
Speaker 2: with globals or complex logic flows, impossible to understand or
Speaker 2: modify without breaking something. The opposite is modular, well structured code.
Speaker 1: How do you achieve that structure in a bigger project
Speaker 1: with multiple files?
Speaker 2: The book mentions the role of in it dot pi
Speaker 2: files in making directories into Python packages. It even shows
Speaker 2: some techniques using CIS dot path or site dot ad,
Speaker 2: site deer with an in dot PII to help Python
Speaker 2: find your modules correctly, especially if you're running scripts from
Speaker 2: different locations outside of IT, and the procedural versus OP
Speaker 2: discussion comes back. The strong recommendation is for anything beyond
Speaker 2: a very simple script, use object oriented programming. It just
Speaker 2: scales better and makes maintenance feasible. Procedural is okay for
Speaker 2: tiny utilities.
Speaker 1: What about naming things, files, variables.
Speaker 2: Functions meaningful names? This is stressed. Name your modules based
Speaker 2: on what they do, like guywidgets dot PI or database
Speaker 2: connector dot pi, not mod one dot PI or utilsnew
Speaker 2: dot PI. Same for variables and functions. Make them descriptive,
Speaker 2: avoid cryptic abbreviations. Consistency helps hugely, especially if you're working
Speaker 2: in a team, but even just for your future self.
Speaker 2: Design patterns also get a brief mention, like the factory
Speaker 2: pattern as a way to handle more complex structural problems
Speaker 2: like creating different variations of widgets systematically. It's more of
Speaker 2: an introduction to the idea that these patterns exist to solve.
Speaker 1: Common problems and just generally managing the complexity as you
Speaker 1: add more and more features.
Speaker 2: Yeah, it acknowledges GUIs naturally get complex. Practical tips include
Speaker 2: using label frame containers to visually group related controls, using
Speaker 2: loops to create multiple similar widgets instead of copy pasting code,
Speaker 2: and organizing really large UIs into logical sections using TT
Speaker 2: notebook tabs. These you are always to break down the complexity.
Speaker 1: Wow. Okay, that really was a deep dive into this cookbook.
Speaker 1: We've gone from literally the first import kinter and main
Speaker 1: loop right.
Speaker 2: Up to placing widgets, arranging them with grid sticky label frames.
Speaker 1: Handling user input with string bars and callbacks, making things
Speaker 1: responsive with threads and cues.
Speaker 2: Connecting to my SQL databases, thinking about different languages with
Speaker 2: I eighteen N.
Speaker 1: And L ten N, testing with unit test, debugging, exploring
Speaker 1: alternatives like wx Python, even touching on three D with
Speaker 1: PIOPENNGL and PIGLT, and.
Speaker 2: Finally wrapping up with best practices like OOP and good
Speaker 2: naming to avoid that spaghetti code.
Speaker 1: This book seems to lay out a really comprehensive path
Speaker 1: full of practical examples. It shows Python's power, but also
Speaker 1: points out where you need extra libraries like pillow or pits.
Speaker 2: Yeah, it gives a solid map of the territory for
Speaker 2: building desktop applications with Python. GUIs covering a lot of
Speaker 2: the common challenges you'd encounter.
Speaker 1: So having surveyed this whole landscape, from the cops button
Speaker 1: to networked, database driven apps and even three D, it
Speaker 1: makes you wonder, for you listening, what kind of GUI challenge,
Speaker 1: maybe something you've seen elsewhere or thought about building, are
Speaker 1: you now most curious to try and tackle using Python