About the new Bootstyle API #68
israel-dryer
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hey all, I wanted to take some time to explain a bit about what I'm doing with this ttkbootstrap rebuild. It has taken me a lot longer than I expected because I wanted to achieve a few key goals:
Let me explain the reason for these two goals in more detail.
Goal 1: Set the widget style with keywords
This is important. A project associated with the name "bootstrap" should have a styling API that is just as easy as its namesake. While the original project created many pre-defined styles, it was still cumbersome to use because I was constrained by the legacy ttk style API. This resulted in having to remember obscure looking style names like these:
It definitely worked. However, it was very cumbersome for many predefined styles. And having easy access to those pre-defined styles is why this project exists in the first place.
To solve this, I created an API that looks very much like bootstrap. So the above code now looks like this:
With this new API, there is no need to remember all of the ttk widget classes when setting the style. For most widgets, you can simply pass in the widget color and that is all. Even better, the keywords are very flexible. All of the following usages are valid:
Goal 2: Only create themes and styles that are actually used at runtime
While having lots of predefined themes and styles is very convenient, one of the big drawbacks is that ttk loads them all at once. This is why a library such as
ttkthemes, which has fantastic looking themes, can make the application very bulky and slow, because all of those image-based themes are loaded into memory and into your distributable when you create one. This was the same way that ttkbootstrap 0.5 worked. The one exception is that ttkbootstrap 0.5 created images at runtime, so the distributable was not affected.Let me illustrate the problem with a real-life example. If I create a
Scalestyle for each theme..... let's say 12 themes, each theme pre-defines 6 to 8 colors for each widget. Each of those styles may have 2 to 4 widget states, such as "normal", "hover", "pressed", "disabled". For an image-based style I would need to create and load up to 288 images for this single widget. Tkinter has an upper limit of images that can be created... I've hit it... This was not a good architecture. I needed to do something different if I wanted to be more creative with image-based layouts.Fortunately, in this new version, I am doing several things that help me avoid this problem. Styles and themes are only created if they are actually used. A theme skeleton is built when it is called. Then, every time you instantiate a new widget or configure the widget style, the library checks to see if that theme or style has been created yet, and if not, it is created. So, instead of creating 288 images for a single
Scalewidget... I can create just 3 or 4.Conclusion
All this means is that I can get MUCH MORE CREATIVE with the styles that I create. I plan on implementing rounded Scrollbars, for example. I've already created the code, I just haven't put it into this library yet because I'm waiting to convert all the existing stuff first.
I hope you enjoy the changes and can be patient with some of the conversion issue that will inevitably come up. I'm very exciting about what this is turning into, and I hope you are too!
Sample Screenshots
All reactions