Best Yet Widget Coloring Scheme
May 4, 2023 22:47:41 GMT -8
Post by Uncle Buddy on May 4, 2023 22:47:41 GMT -8
The code below is not far from how I got started almost five years ago, but from that point things got weird. I believe I discovered function-level or even module-level attributes and created my first or second color-changing strategy that way. This was based on glorified global variables and other klunky weirdness, I don't remember the details, but it worked in spite of being horrific code.
As the project grew, I finally learned how to create classes, and I learned how to create subclasses. I fell in love with making my own widget classes and built a new system based on detecting subclasses, such that each widget subclass got its own colorization scheme. This worked better than the previous colorization scheme, and it underwent more than one simplification which I was proud of at that time.
Then I learned how to use class-level variables instead of instance variables for everything, so the most recent improvements of the colorization scheme involved class variables and I was proud of that, but diving ever deeper into reliance on classes.
Recently I asked myself whether I'd taken a wrong turn somewhere, wondering if the original plan had been the right one. In this simple arrangement, widgets were not configured alike based on class, but on what list they were included into. For example, every widget in the lst `bg` would be formatted according to one function, and every widget in the list `bg_fg_out` would be formatted according to a different function. This system starts out very simple, and if you're careful, it can stay pretty simple. I've been playing with it for days and written a few versions of it as models. Here's a quick example.
I don't know if I will finish chapter 2 of Treebard GPS development in Tkinter. It would require rewriting all the formatting again, which I've recently done. Things are getting simpler and better, but it's leading me to wonder why I'm bothering with Tkinter at all. In spite of all the good news, the do list for finishing Chapter 2 of Treebard development grows by the day. One way to deal with this is to start over from scratch so I'm not constantly rewriting things that were done by the me of the past who knew even less about programming that I do today.
The fact is, if you want a widget toolkit that's simple, well-supported, current, extremely capable, easy to use, and flexible, find a way to use HTML and CSS for the user interface. I'll write a separate post about that, maybe soon, maybe later. Keywords: Pyscript, Javascript, Python, SQLite.
The main point of this post is that instantly colorizing every widget in the app is even easier than I thought. When I first got into writing code, I made the usual mistakes anyone would make, and went down some convoluted paths due to seeming cleverness when I should have stuck with the simplest solution every time. Since it's really easy to give the user control over what his app looks like (light, dark, or anything in between), why is it impossible for the user to easily create his own color schemes in every single genealogy app that exists?
Genealogy apps are not casual little tools that someone spends a few minutes with. Genealogists spend a lot of time staring at unconfigurable interfaces or else highly configurable interfaces wherein the user can move all the furniture around till he's blue in the face, but if he wants a blue background on his app, instead of a white one, forget it.
As the project grew, I finally learned how to create classes, and I learned how to create subclasses. I fell in love with making my own widget classes and built a new system based on detecting subclasses, such that each widget subclass got its own colorization scheme. This worked better than the previous colorization scheme, and it underwent more than one simplification which I was proud of at that time.
Then I learned how to use class-level variables instead of instance variables for everything, so the most recent improvements of the colorization scheme involved class variables and I was proud of that, but diving ever deeper into reliance on classes.
Recently I asked myself whether I'd taken a wrong turn somewhere, wondering if the original plan had been the right one. In this simple arrangement, widgets were not configured alike based on class, but on what list they were included into. For example, every widget in the lst `bg` would be formatted according to one function, and every widget in the list `bg_fg_out` would be formatted according to a different function. This system starts out very simple, and if you're careful, it can stay pretty simple. I've been playing with it for days and written a few versions of it as models. Here's a quick example.
import tkinter as tk
formats = {
"bg": "black", "fg": "yellow", "output_font": ('arial black', 16),
"highlight_bg": "magenta"}
root = tk.Tk()
root.geometry('400x300+500+100')
root.columnconfigure(0, weight=1)
root.rowconfigure(0, weight=1)
lab = tk.Label(root, text="Look Ma No Hands")
lab.grid()
ent = tk.Entry(root)
ent.grid()
bg_fg_out = []
bg = []
bgHi_fg_in = []
bg_fg_out.append(lab)
bg.append(root)
bgHi_fg_in.append(ent)
def configall():
OPTIONS = {
"bg": (bg, {"bg": formats["bg"]}),
"bgHi_fg_in": (
bgHi_fg_in,
{"bg": formats["highlight_bg"], "fg": formats["fg"],
"font": ("dejavu sans mono", 16)}),
"bg_fg_out": (
bg_fg_out,
{"bg": formats["bg"], "fg": formats["fg"], "font": formats["output_font"]}),}
for lst in (bg, bg_fg_out, bgHi_fg_in):
for widg in lst:
for style,tup in OPTIONS.items():
if lst == tup[0]:
for option,value in tup[1].items():
widg[option] = value
configall()
root.mainloop()
I don't know if I will finish chapter 2 of Treebard GPS development in Tkinter. It would require rewriting all the formatting again, which I've recently done. Things are getting simpler and better, but it's leading me to wonder why I'm bothering with Tkinter at all. In spite of all the good news, the do list for finishing Chapter 2 of Treebard development grows by the day. One way to deal with this is to start over from scratch so I'm not constantly rewriting things that were done by the me of the past who knew even less about programming that I do today.
The fact is, if you want a widget toolkit that's simple, well-supported, current, extremely capable, easy to use, and flexible, find a way to use HTML and CSS for the user interface. I'll write a separate post about that, maybe soon, maybe later. Keywords: Pyscript, Javascript, Python, SQLite.
The main point of this post is that instantly colorizing every widget in the app is even easier than I thought. When I first got into writing code, I made the usual mistakes anyone would make, and went down some convoluted paths due to seeming cleverness when I should have stuck with the simplest solution every time. Since it's really easy to give the user control over what his app looks like (light, dark, or anything in between), why is it impossible for the user to easily create his own color schemes in every single genealogy app that exists?
Genealogy apps are not casual little tools that someone spends a few minutes with. Genealogists spend a lot of time staring at unconfigurable interfaces or else highly configurable interfaces wherein the user can move all the furniture around till he's blue in the face, but if he wants a blue background on his app, instead of a white one, forget it.