ttkbootstrap-next previews #733
Replies: 9 comments 10 replies
-
Virtual List WidgetI'm actively working on the virtual list component. There is a lot going on in this video, but let me point out a few things:
virtual.list.mp4Lots more coming soon... |
Beta Was this translation helpful? Give feedback.
-
Entry WidgetsThere are a lot of new specialized entry widgets with built-in validation support. 
from ttkbootstrap import App, TextEntry, DateEntry, Pack, PasswordEntry, PathEntry, NumericEntry
with App("Entry Demo") as app:
with Pack(padding=16, gap=8, direction="column", fill_items='x').attach():
TextEntry("Israel", label="First Name", required=True).attach()
NumericEntry(124000, label="Range", value_format="currency").attach()
DateEntry("March 14, 1981", value_format="shortDate").attach()
PasswordEntry("mypassword", label="Password", show_visible_toggle=True).attach()
PathEntry().attach()
app.run()I'll explain more about the optional context layout system in the future, but "Pack" is a specialized frame implementation. Customizable Entry WidgetsAll of the widgets above are variants of the same widget. You want a custom email widget? no problem.... 
te = TextEntry("israel.dryer@gmail.com", label="Email")
te.insert_addon(Label, text="@", position="left")
te.add_validation_rule("email")
te.attach() |
Beta Was this translation helpful? Give feedback.
-
Virtual List (new features)Today I added a few great features to the Virtual List widget Item DraggingThe item-dragging.mp4Row AlternationThe row-alternation.mp4Search & FiltersThe filtering.mp4 |
Beta Was this translation helpful? Give feedback.
-
|
That surely incredible work! Since now, this library had mostly just been a handy wrapper for TTK, letting you chose between different pre-made themes or create a new one; and with some unique widgets. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
Focus State | Virtual ListHere's a snapshot of the list with just text and icon. I added 
Some thoughtsMy current idea is to leverage this widget for custom menus, app menus, cascading menus, menu buttons, and context menus. The built-in Tkinter menu widget is bound to the OS and not customizable on Windows and Mac OS outside of some coloring. However, this will provide the ability to have very customized menus with modern looking accelerator labels and icons if desired. I will still need to leverage the built in menu for Mac for the app though because it sits outside of the application window. I'm not sure yet about the api.. one option is something like this: with Menu() as m:
with Menu.Cascade("File"):
Menu.Button("New", key="new", accel="Ctrl+N")
Menu.Button("Open", key="open", accel="Ctrl+O")
Menu.Button("Save As", key="saveas", accel="Ctrl+S")
Menu.Separator()
Menu.Button("Exit", key="exit", accel="Alt+F4")
with Menu.Cascade("Edit"):
Menu.Button("Undo", key="undo")
Menu.Button("Redo", key="redo")
Menu.Separator()
Menu.Button("Cut", key="cut", accel="Ctrl+X")
Menu.Button("Copy", key="copy", accel="Ctrl+C")
Menu.Separator()
Menu.Toggle("Show space and tab", key="space_tab", selected=False)
with Menu.Cascade("Encoding"):
Menu.Radio("ANSI", key="encode_ansi", value=0, selected=True)
Menu.Radio("UTF-8", key="encode_utf_8", value=1)
Menu.Radio("UTF-16-BOM", key="encode_utf_16_bom", value=2)
Menu.Separator()
m.on_menu_item_click().listen(lambda e: handle_menu_item_click(e))
def handle_menu_item_click(event):
match event.data['key']:
case "new":
...
case "open":
...
case "saveas":
...
case "exit":
...
case "cut":
...
case _:
...This is a context based approach and is very readable. Another alternative is using a dictionary: menu_items = [
{"text": "File", "items": [
{"type": "button", "text": "New", "key": "new", "accel": "Ctrl+N"},
{"type": "button", "text": "Open", "key": "open", "accel": "Ctrl+O"},
{"type": "button", "text": "Save As", "key": "saveas", "accel": "Ctrl+S"},
{"type": "separator"},
{"type": "button", "text": "Exit", "key": "exit", "accel": "Alt+F4"},
]},
{"text": "Edit", "items": [
...
]}
]
Menu(menu_items)While I like the 'idea' of a dictionary, in practice I'm not sure how great it is because you get no IDE support and there is alot more room for error. Aside from that, it's not really an improvement on readability. There is also the approach of mirroring the current tkinter API, which is not that bad, and is probably closer to the first approach above. I would like to add context support though if I use the legacy api style because it will reduce the amount of code you have to write and keep it more readable. Anyway, I'll keep you posted, and also feel to put in your two cents. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I agree. It will make more sense. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I was thinking that the dictionary method could have the advantage of having an tool to graphically design dialogs, etc., but then I thought of the horrors of Qt (just kidding!) |
Beta Was this translation helpful? Give feedback.
-
|
That makes sense. I think there's room for multiple approaches. |
Beta Was this translation helpful? Give feedback.
-
|
@rojalator
|
Beta Was this translation helpful? Give feedback.
-
|
I had a project in PyQt4 that halfway went to 5 and then to 6. Originally written by someone else in about 2008 that I then maintained. I became somewhat jaded by it: no comment on it's quality. |
Beta Was this translation helpful? Give feedback.
-
Menu ItemsToday I worked on the menu item primitive. I borrowed a lot of logic from the virtual list for this one, but it's a much simpler architecture. There will be a more abstract API around the MenuItem structure, but this is what it looks like built in long-hand. 
Menu Item PrimitiveThis will not be the public API, but you can see what the MenuItem primitive looks like. from ttkbootstrap import App, Pack
from ttkbootstrap.widgets.menu.menu_item import MenuItem
with App() as app:
with Pack(fill_items='x').attach(fill='x'):
MenuItem("New Project...").attach()
MenuItem("Project from Version Control...").attach()
MenuItem("New...", underline=0, shortcut_text="Alt+Insert").attach()
MenuItem("New Scratch File", shortcut_text="Ctrl+Alt+Shift+Insert").attach()
MenuItem("Open...", icon="folder", underline=0).attach()
MenuItem("Save As...").attach()
MenuItem("Recent Projects", item_type="cascade", underline=0).attach()
MenuItem("Close Project").attach()
MenuItem("Rename Project...").attach()
MenuItem("Remote Development...", begin_group=True).attach()
MenuItem("Settings...", icon="gear", underline=2, shortcut_text="Ctrl+Alt+S", begin_group=True).attach()
MenuItem("File Properties", item_type="cascade").attach()
MenuItem("Local History", begin_group=True, underline=6).attach()
MenuItem("Save All", underline=0, icon="floppy", shortcut_text="Ctrl+S").attach()
MenuItem("Reload All from Disk", icon="arrow-clockwise", shortcut_text="Ctrl+Alt+Y").attach()
MenuItem("Repair IDE").attach()
MenuItem("Invalidate Caches...").attach()
MenuItem("Manage IDE Settings", begin_group=True, item_type="cascade").attach()
MenuItem("New Projects Setup", item_type="cascade").attach()
MenuItem("Save File as Template...").attach()
MenuItem("Export", begin_group=True).attach()
MenuItem("Print...", underline=0, icon="printer").attach()
MenuItem("Power Save Mode", begin_group=True).attach()
MenuItem("Exit", underline=1, begin_group=True).attach()
app.run()Item TypesThe menu item types that I'm currently planning to support are:
The ThoughtsI believe I'm going to end up using standard Tkinter menu structures for Mac and the custom ones for Linux and Windows. Mac does not need any help on the menu look & feel from what I can see. As a side note... because I'm customizing the menu, I'm also going to have an opt-in fully customizable title bar which will be a toolbar widget that can be used as the title bar for the window. More on that later though. Next ...My goal tomorrow and the next day will be to add the containing menu structure, the cascading logic, and some of the API abstractions for making it easy to build. |
Beta Was this translation helpful? Give feedback.
-
Migrating From V1 To V2As there are already many repositories depend on V1,
|
Beta Was this translation helpful? Give feedback.
-
|
This is a great question. It will be hard to offer a short reply, but let me try :) V1 to V2This is definitely a breaking change. I do anticipate support for v1 going forward, and I think myself and the community will continue to enhance it. I've been on the fence about this, but the differences are enough to justify it. There will be CLI tools in V2 to help with starting projects, migrating older projects, and providing help for distributing exe or installable programs. Essentially, we are moving from a monkey-patched tkinter extension library to a full UI framework. Tkinter (as a python binding) is 31 years old as of this year. While much has been done to extend its useful life, including the existence of this very library, there are still a lot of features that are clunky, outdated, or simply missing altogether. There is nothing wrong with that; a lot of things have happened over the last 31 years since it was added to the python library. As I mentioned, the original approach of this library was to monkey-patch the tkinter module (I would not even go far as to call it a thin wrapper). This worked as well as it could, and it still works fine. But, enabling modern features on the legacy architecture without fully wrapping the library is quite difficult and I want to be able to offer much more than it can enable. What is changing?Here is a short summary of the major changes Styling systemThe styling system will be completely different. The v1 styling system still exposed the ttk style engine but worked mainly by hand-drawing image based styles on-demand using the Pillow library. This allowed much more variety out-of-the-box than what you would get with vanilla ttk, but still allowed for subclassing styles, and also had the same limitations of ttk as far as various components of the style being unconfigurable, or lack of transparency for image-based components. The V2 styling system works quite a bit differently. Image-based styles are based on a predefined PNG with black, white, and magenta regions, which are recolors based on the users selection-on demand. Each widget has a StyleBuilder that controls and builds the variants that the widget uses. The end-user can extend the style builders by registering their own "variants". The new style engine gives you the flexibility of using any color and with simulated transparency because all widgets inherit their parents background color by default. Additionally, focus colors and ghost buttons use an algorithm to fully blend the various state colors with the parent background color to give the feel of actual transparency. This adjustment alone allows me to create some pretty stunning effects. The video below shows 3 different Pack frames with the same exact buttons, but you'll notice that the buttons have rounded edges, the focus borders and ghost button blends transparency seamlessly with the parent giving a true modern Bootstrap look and feel. Recording.2025-10-23.100024.mp4with App("Demo With Layers Button") as app:
with Pack(padding=16).attach(fill="x"):
Button("Solid", icon="bootstrap").attach()
Button("Outline", variant="outline", icon="bootstrap").attach()
Button("Ghost", variant="ghost", icon="bootstrap").attach()
with Pack(padding=16, surface="background-1").attach(fill='x'):
Button("Solid", icon="bootstrap").attach()
Button("Outline", variant="outline", icon="bootstrap").attach()
Button("Ghost", variant="ghost", icon="bootstrap").attach()
with Pack(padding=16, surface="background-2").attach(fill='x'):
Button("Solid", icon="bootstrap").attach()
Button("Outline", variant="outline", icon="bootstrap").attach()
Button("Ghost", variant="ghost", icon="bootstrap").attach()
app.run()In V2, styles are persisted by a collection of exposed features, such that I an change the background color, foreground color, font style, etc... anything I choose to expose to the style builder for that widget can be configured and configured in the button style. That is simply not possible with the ttk styling system as it is designed today. Icon supportV2 includes built-in stateful icon support. This means that you can specify any of the bootstrap icons to be added with out-of-the-box support. You can specific size, color, state... for example... I can choose to use a different icon on hover.... While I can, and probably will add an Icon class to v1, it will not have the same ability for stateful integration, rather it would be added as an image like any other image on a button or label, and it will not be stateful without manual style building or updates by the user. Modern layout conveniencesThe tkinter layout system can be quite cumbersome and repetitive. Tkinter is child-focused, so the child put's itself on the parent and specifies how it is to be managed. There is no ability of the Frame to provide any kind of guidance (for the most part) on any of those layout options. This results in a LOT of repetitive and inconvenient layout gymnastics to achieve relative straightforward layouts. Consider these two example: The first uses a V2 dedicated Grid frame, the second example uses vanilla tkinter (V1) to create the same exact layout. It's quite contrived, but demonstrates how such a complex layout can be easily created with a V2 Grid frame. V2 API from ttkbootstrap import App, Button, Grid
with App("Demo Grid Layout", geometry="800x500") as app:
with Grid(rows=[0, 1, 0], columns=[0, 1, 0], padding=8, gap=8).attach(fill='both', expand=True):
for x in range(4):
Button(text="Button", icon="house-fill").attach(sticky="nsew")
Button(icon="house-fill", variant="outline").attach(sticky="")
app.run()
V1 API (Vanilla Tkinter) import tkinter as tk
from tkinter import ttk
root = tk.Tk()
root.title("Demo Grid Layout")
root.geometry("800x500")
# Grid container with internal padding (like padding=8)
container = ttk.Frame(root, padding=8)
container.pack(fill="both", expand=True)
# rows=[0,1,0], columns=[0,1,0]
row_weights = [0, 1, 0]
column_weights = [0, 1, 0]
for r, w in enumerate(row_weights):
container.rowconfigure(r, weight=w)
for c, w in enumerate(column_weights):
container.columnconfigure(c, weight=w)
GAP = 8
NUM_COLS = len(column_weights)
# We add 8 buttons total (two per loop like your example)
# 1st button: sticky="nsew"
# 2nd button: sticky="" (no expansion)
buttons = []
for i in range(8):
r, c = divmod(i, NUM_COLS)
# gap: only on non-first col/row
padx = (GAP, 0) if c > 0 else 0
pady = (GAP, 0) if r > 0 else 0
# In plain ttk there’s no `icon=` option; using text only here
text = "Button" if i % 2 == 0 else "Outline"
btn = ttk.Button(container, text=text)
sticky = "nsew" if i % 2 == 0 else ""
btn.grid(row=r, column=c, padx=padx, pady=pady, sticky=sticky)
buttons.append(btn)
root.mainloop()
Users now how the ability to configure the grid structure directly and easily through rows and columns and provide guidance to children through the use of Additionally, using the context manager (optional) means that you don't have to specify the parent on every widget, the widget just knows who it's parent is via the context manager. Other conveniences and goodiesThere many other things that are being included in V2, but I can't elaborate them fully here. I will continue to add this information as well as a full release description in the future. However, here are some highlights of additional featuers:
While there will be breaking changes, my goal in the final release version of V2 is to make the new library as familiar as possible while providing modern features. |
Beta Was this translation helpful? Give feedback.
-
|
I've been thinking about this the last few days as I've been updating v1.... My current thought is that the current library and it's API will continue going forward as the classic API version, with updates and new development when it makes sense, however, keeping to a more classic tkinter feel. Then, the new stuff becomes a separate library "ttkbootstrap-next" where I can be free to experiment and modernize a bit more without losing support on the classic version. Those features that make sense to backport into a more classical API can be put into V1. A prime example is ttkbootstrap-icons, which was an implementation in "next" that I decided could be separated into it's own library and shared with V1 users. I expect there will be other things like this that can be either shared or backported.
|
Beta Was this translation helpful? Give feedback.
-
|
The reason I brought up this topic is because, However, on the other hand,
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hey all! Version 2 has been in development for a while; but I think it will be worth it. Version 2 is a complete rewrite of the library, with a TON of new features, conveniences, and other goodies. Until the final release, I will periodically put in some screenshots and code examples of what I'm working on. It's obviously a work-in-progress, so things will likely change in some areas, but it will give you an idea of what is coming. Screenshots and code examples are coming soon....
!! UPDATE !!
I've decided to continue to support the current classic API in this library. This means moving "v2" to a new library and home
ttkbootstrap-next. This will enable me to continue to support the classic API and existing users while providing a more modern UI and API experience for those who wish for that. https://github.com/israel-dryer/ttkbootstrap-nextI will continue to backport new features to the classic version when they fit into the API structure of the library.
Beta Was this translation helpful? Give feedback.
All reactions