Ttk style support (work in-progress)

[jrezai]

Ttk styles in Pygubu Designer

I have started the implementation of Ttk style support in Pygubu Designer. It's currently in its alpha stages. It's working, but more work is needed, such as error handling, testing, etc.

It would be a huge undertaking to support every single element that there is with ttk styles. Having the ability to change ttk styles using some kind of properties editor would make it hard to maintain (in my opinion) due to the versatility and flexibility of ttk styles. Therefore, my proposal is to make Pygubu Designer be aware of ttk styles by reading a user-defined Python script that contains the style definitions and then allowing the user to choose a style of a widget from the Style combobox.

I also think it's very important that the user should not need to restart Pygubu or re-open the UI project every time they make a Ttk style change, because creating Ttk styles is a lot about experimentation. With the new Ttk style implementation (work is in progress!), style changes will be detected automatically and reflected in the Preview canvas in real-time (live) so the user will not need to restart his/her project with every change that they make to the style definition file.

Here is a screenshot of some of the changes. I will share more information as more work gets done.
Any thoughts / comments are welcome.

Regards,
Jobin

[alejandroautalan]

Hello @jrezai,

I have started the implementation of Ttk style support in Pygubu Designer. It's currently in its alpha stages. It's working, but more work is needed, such as error handling, testing, etc.

Great, I already want to see more of your work.

It would be a huge undertaking to support every single element that there is with ttk styles. Having the ability to change ttk styles using some kind of properties editor would make it hard to maintain (in my opinion) due to the versatility and flexibility of ttk styles.

Yes it's hard. I did several attempts but abandoned/postponed for now.

Therefore, my proposal is to make Pygubu Designer be aware of ttk styles by reading a user-defined Python script that contains the style definitions and then allowing the user to choose a style of a widget from the Style combobox.

I like this approach.

I also think it's very important that the user should not need to restart Pygubu or re-open the UI project every time they make a Ttk style change, because creating Ttk styles is a lot about experimentation.

I also agree with this.

Any thoughts / comments are welcome.

It would be nice if you show me some of the contents that will have the files:

Style Definition file: I assume theme definitions here.

Style Population File: what is in this file? Is used to populate the style combobox?

Some things that I would like to have/maintain:

• Style selector should list styles defined by the builder / properties files.

  Some widgets can define custom default values for the style property and made them available with register_custom_property.
  The properties file has one example:

  pygubu-designer/pygubudesigner/properties.py

  Lines 957 to 964 in ab49cf9

  	'style': {
  	'editor': 'dynamic',
  	'params': {'mode': 'ttkstylechoice'},
  	'ttk.Button': {
  	'params': {'values': ('', 'Toolbutton')}
  	},
  	'help': help_for('style')
  	},

• We can change the style combobox editor to make aware of theme changes.

  This will depend of how are you doing the current implementation.

  Please, give more info about Definition and Population files so I can continue with this point.

Regards
Alejandro A.

[jrezai]

Hi @alejandroautalan ,

I've uploaded a YouTube video which explains it in more detail (with audio):
https://youtu.be/I84vGpIDg0M

Style definition file: used for specifying the styles data (normal ttk style code)
Style Population file: used for populating the style combobox and used for specifying which widget classes the style should populate for.

>>Some widgets can define custom default values for the style property and made them available with register_custom_property.

That's interesting. That would explain where the 'Toolbutton' style was coming from for ttk.Button. I wondered where that came from. It's going to require some planning to decide how we can have both the style population file and styles from register_custom_property show up in the same combobox.

I will upload all the changes I've done so far into my GitHub repository once I do some more testing (it's not ready to be considered for merging into your main GitHub page yet). We can maybe use my repository for some beta testing or perhaps we need a new 'testing' or 'beta' branch in your GitHub page?

Any ideas / suggestions welcome.

Thanks,

[alejandroautalan]

Hi @jrezai,

I've uploaded a YouTube video which explains it in more detail (with audio):
https://youtu.be/I84vGpIDg0M

I saw the video, thanks for the explanation. It looks very promising.

It's going to require some planning to decide how we can have both the style population file and styles from register_custom_property show up in the same combobox.

I would like to get rid of the population file.
I already have an idea of how to do that and populate the style combobox using only the styles file.
Once you upload your code I will start to work and see if it is possible.

Regards
Alejandro A.

[jrezai]

Hi @alejandroautalan ,

I've uploaded all my changes to: https://github.com/jrezai/pygubu-designer

I would like to get rid of the population file.
I already have an idea of how to do that and populate the style combobox using only the styles file.
Once you upload your code I will start to work and see if it is possible.

Fantastic! At first, I tried to put it all in one definition file, but I ultimately split it into two files.
It would be much better if it was just one file. I look forward to the changes!

Most of the new style-related code is in a new module file: stylehandler.py

Thanks,

[alejandroautalan]

Hello @jrezai,
I managed to remove the population file.
I created a new branch ttkstyles, feel free to test and propose new changes.

Summary of changes:

• Moved almost all code to stylehandler.py

• Pass only the style object when calling exec function. The definitions file now will look like:

  style.configure('green.TButton', background='green')
  style.configure('mycombo.TCombobox',
              fieldbackground='yellow',
              background='yellow', foreground='blue')
  style.master.option_add('*TCombobox*Listbox.background', 'orange')

• Modified TtkStylePropertyEditor to select defined styles.

• In the code generator, the ttk style code is now include in the setup_ttk_styles method.

More details in the commit history.
Let me know if you have any comments.

Regards
Alejandro A.

[jrezai]

Hi @alejandroautalan,

The latest changes are very good. It's now easier to load styles than before.
I did some tests today and it seems to be working well. I think more testing is required and there are still some "little things" that will help to polish this new feature.

There were a couple of things I noticed and I made pull requests for them.

There are a couple of other things I noticed that will need more time to test and more time to implement:

1. It would be nice if the toplevel preview (Preview in Toplevel (F5)) reflected the style changes too. The reason is: some styles work with mouse hovering and clicking, so the toplevel preview will be the only way to quickly test click styles. I think it used to do it before the code change (the first implementation), but I'll need to find out where in the code it was doing this.

2. If a base style is changed (such as .configure('TButton', background='yellow'), then this will happen:
   
   It will change the style of all similar widgets in Pygubu Designer. I think the only way around this would be to explicitly specify a style for widgets in Pygubu Designer so that it will not use the base styles (because the user might change the base style). This will need some experimentation.

Those are the only two things I noticed. Another test I want to do (as time allows) is to make sure Pygubu Designer can handle unexpected occurrences gracefully; for example: if the definition file all of a sudden gets deleted, if the file gets renamed, if we type incorrect Python syntax in the definition file, etc. I will check this later on too.

Thanks for the new style handling code. It's very exciting.
With a little bit more testing and polishing, I think it will improve the overall user experience.

I'll share more comments/notes as I find new things to mention about this new feature.

Thanks!

[jrezai]

@alejandroautalan Actually, regarding applying the style to the Preview (toplevel F5) window when the combobox style selection changes, I'm thinking it can be a good thing too if the toplevel window doesn't update the style when the combobox style changes, because it will allow the user to compare the 'old style' (toplevel) with the 'new style' (preview canvas).

Do you think it would be better to leave the toplevel window the way it is? So that when the style combobox selection gets changed while the toplevel window is open, it won't change the style of the toplevel window, until the user closes and re-opens the toplevel window? Currently that's the way it is, and I'm starting to think maybe it's not a bad idea. What do you think?
Thanks,

[alejandroautalan]

Hello @jrezai, thanks for your tests and notes.

It would be nice if the toplevel preview (Preview in Toplevel (F5)) reflected the style changes too. The reason is: some styles work with mouse hovering and clicking, so the toplevel preview will be the only way to quickly test click styles. I think it used to do it before the code change (the first implementation), but I'll need to find out where in the code it was doing this.

I think that the problem here is that I'm cropping the full widget functionality in the normal preview (The user cannot even click a button)
Maybe I have to ease this restriction at least for the basic widgets, so the user can interact with the widget and see the style changes.
I will work on that.

If a base style is changed (such as .configure('TButton', background='yellow'), then this will happen:

Yes, it is possible for this to happen. I still don't see a clear solution for this.

Do you think it would be better to leave the toplevel window the way it is? So that when the style combobox selection gets changed while the toplevel window is open, it won't change the style of the toplevel window, until the user closes and re-opens the toplevel window? Currently that's the way it is, and I'm starting to think maybe it's not a bad idea. What do you think?

I think that it would be better to leave the Toplevel window the way it is.
The changes are shown and updated in the Toplevel preview for all widgets that had the style property set before the user hits F5.
If the user adds a new style to a widget using the style combobox, he will need to hit F5 again to see the changes in the toplevel window preview. The following changes to that style in the definition file will be updated in the Toplevel preview window also.

Regards
Alejandro A.

[jrezai]

Hi @alejandroautalan ,

I did some more tests - this is what I found:

These tests were OK:

1. If the style definition file is deleted or renamed, nothing bad seems to occur in Pygubu Designer. It handles it gracefully.
2. If the style definition file contains invalid code, Pygubu Designer handles it fine and doesn't crash (try/except is working fine).

Problems:
3. If a non-default ttk theme is selected, user-defined styles from the definition file won't work.

Speaking of the ttk themes selection menu; I noticed that when I choose a ttk theme, such as 'clam' for example, Pygubu Designer does not remember my theme selection. If I close and re-open Pygubu Designer, it will go back to the default theme. This seems like a bug. My question is: I haven't seen anyone submit a bug report about this bug, so maybe very few users are actually selecting a ttk theme at all? Maybe this option does not get used frequently since no one has reported this bug (as far as I know). So do you think the bug should be fixed and then we find a way of making it work with the new ttk style definition file? Or do you think the ttk themes section should be removed completely?

4. If a ttk style name is typed manually with the keyboard, and the style does not exist, a Python exception will be raised.
   

At first, the error is actually caught gracefully but then raised again by the last line here:
https://github.com/alejandroautalan/pygubu/blob/def3f72ed06956345971ce381abeaf73d22c7e7e/pygubu/builder/builderobject.py#L227-L233

Removing the last line there will make it work gracefully, but I thought I would ask you first to see if you have a better idea about that last line.
logger.exception(e)

Thanks,

[alejandroautalan]

Hello @jrezai, sorry for the late response.

3. If a non-default ttk theme is selected, user-defined styles from the definition file won't work.

I added a fix to this problem. Now the stylehandler class listen to theme changes and reloads the definition file.

Speaking of the ttk themes selection menu; I noticed that when I choose a ttk theme, such as 'clam' for example, Pygubu Designer does not remember my theme selection. If I close and re-open Pygubu Designer, it will go back to the default theme.

This is the default behaviour.

This seems like a bug. My question is: I haven't seen anyone submit a bug report about this bug, so maybe very few users are actually selecting a ttk theme at all? Maybe this option does not get used frequently since no one has reported this bug (as far as I know). So do you think the bug should be fixed and then we find a way of making it work with the new ttk style definition file? Or do you think the ttk themes section should be removed completely?

The 'Preview > ttk theme' menu is used to quickly preview the ui design in different themes.
For example, if you install the ttkthemes module, the list of themes increases and this menu helps you to quickly choose a theme four your design without modifying the pygubu-designer default theme option.

4. If a ttk style name is typed manually with the keyboard, and the style does not exist, a Python exception will be raised.

I modified the line to reduce the amount of output when a TclError occurs (master branch).

Regards
Alejandro A.

[jrezai]

Hi @alejandroautalan

Ttk themes is working great now, thanks!

I did some more testing and didn't notice any issues.
The new ttk style stuff is looking nice and promising!

What is your opinion about this:
I think maybe as a finishing touch, it might be a good idea to have a button in the Ttk Styles section that says 'Create New Definition...' which will prompt to save a .py file to a folder and that .py file contains an example line so the user knows what to do with a style definition file.

Any way, I think we are close to being able to merge this into the master branch, right?

Thanks again!

[jrezai]

@alejandroautalan by the way: I can add the new 'Create New Definition...' button if it's Ok with you as soon as I have some time.
Thanks!

[jrezai]

Hi @alejandroautalan ,

Happy New Year.
I was having a closer look at the recent changes in the code.

I noticed that every time a change is made to the style definition file, the method: check_definition_file() gets executed 3 times instead of 1 time. After looking at it closer to figure out why, I found that this line is causing multiple calls to check_definition_file():

self.mframe.bind('<<ThemeChanged>>', self._on_theme_changed)

So self._on_theme_changed() is causing it. I looked for the virtual event <<ThemeChanged>> but I could not find where that virtual event is linked to. Is that virtual event from ttkthemes? Any way, it's causing check_definition_file() to run multiple times when a change occurs instead of just once.

Thanks,

[rdbende]

<<ThemeChanged>> is a built-in event generated by tk when the theme changes. It's generated on both legacy tk and ttk widgets, but on the main window it's generated not just once, but as many times as many (not just direct!!!) children it has.

import tkinter as tk
from tkinter import ttk


root = tk.Tk()
root.bind("<<ThemeChanged>>", lambda e: print("event on root"))

tk_frame = tk.Frame()
tk_frame.pack()
tk_frame.bind("<<ThemeChanged>>", lambda e: print("event on tk frame"))

ttk_frame = ttk.Frame()
ttk_frame.pack()
ttk_frame.bind("<<ThemeChanged>>", lambda e: print("event on ttk frame"))

# not direct child
ttk_frame = ttk.Button(ttk_frame)
ttk_frame.pack()
ttk_frame.bind("<<ThemeChanged>>", lambda e: print("event on ttk button"))

def ch_theme():
    print("---")
    root.tk.call("ttk::style", "theme", "use", "clam")

# delay is needed, otherwise the bindings won't work
root.after(10, ch_theme)


root.mainloop()

[rdbende]

Oh, this actually meant to be reply on #68 (reply in thread)

[jrezai]

@rdbende Ah I see. Thank you for the explanation about <<ThemeChanged>>.

[jrezai]

@alejandroautalan Based on the explanation above, do you think we should still use <<ThemeChanged>> to force a reload of the definition file (when a theme changes) or should we force a reload only if the theme changes from the Preview menu? (for example: if the user clicks on the ttk theme menu to change it, under the Preview menu).

If <<ThemeChanged>> continues to be used, we could still prevent multiple consecutive reloads of the definition file in the same second by putting in some checks, but I just wanted to verify with you first to see if you prefer <<ThemeChanged>> over the theme menu click event binding. Thanks.

[alejandroautalan]

Thanks @rbende for the explanation, I didn't know that the event was generated by multiple widgets.

@alejandroautalan Based on the explanation above, do you think we should still use <> to force a reload of the definition file (when a theme changes) or should we force a reload only if the theme changes from the Preview menu? (for example: if the user clicks on the ttk theme menu to change it, under the Preview menu).

@jrezai, Instead of using the "ThemeChanged" event I will use a custom event "PygubuDesignerTtkThemeChanged"' generated when the user changes the main theme (I've already uploaded the changes to the repository).

[alejandroautalan]

@jrezai in regard to:

What is your opinion about this:
I think maybe as a finishing touch, it might be a good idea to have a button in the Ttk Styles section that says 'Create New Definition...' which will prompt to save a .py file to a folder and that .py file contains an example line so the user knows what to do with a style definition file.

I agree. Feel free to add this if you have time.

Any way, I think we are close to being able to merge this into the master branch, right?

Yes, when this last functionality is done, I will merge it with the master branch.

Bye!
Alejandro A.