Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Discussion: Themes vs Styles vs LookAndFeel

See original GitHub issue

This is not a bug-report or a report about a missing feature, but a “question/discussion” issue.

This question came up here

about the look and feel, I always wondered the possibility to allow some widgets to have a “style” attribute but I never formalised it.

Current state

I try to summarize the current state (please correct me, if/when my summary has errors):

  1. In TTkCfg there is an attribute theme which points to the “current” theme
  2. Widgets (e.g. a TTkFrame) check some theme-attributes at construction time (e.g. frameBorderColor, frameTitleColor)
  3. Widgets (e.g. a TTkFrame) check some theme-attributes at every call to paintEvent (e.g. TTkCfg.theme.grid)
  4. Widgets (e.g. a TTkFrame) support by keyword arguments to __init__ to not ask TTkCfg.theme for a color but to use the one explicitly given at construction time with an explicit keyword argument (e.g. titleColor=...)

Because of 3. it is possible to switch/change the grids, button-boxes, scrollbars, menubars, etc. dynamically (on the fly); which can be seen in the demo where one can switch from UTF-8 to ASCII theme.

Because of 2. a change in attributes like frameTitleColor has no effect on the widgets that are already constructed, but has an effect on every widget that is created after the theme-attribute(s) changed.

Because of 4. “many” slots are used (per widget) to save “their” colors (either the explicitly given ones from __init__ or the ones that were found in TTkCfg.theme by __init__).

[Some personal note: The asymmetry of 2. and 3. (getting some theme attributes at construction time and some at every paintEvent) is a little bit … disturbing … for me.]


Here is an alternative approach which (in my opinion) simplifies things a bit:

Instead of the many color-slots (per widget) every widget hat only one look_and_feel (laf) slot. There a (reference to an) object is saved that is used at every paintEvent to ask the look_and_fool object for colors, grid-chars, borders-chars, etc. The default look_and_feel object is a “proxy” that “redirects” all the attribute-getters to the current TTkCfg.theme. All the widgets that use the default look_and_feel object see every change in TTkCfg.theme immediately (at the next repaint/update). But this scheme allows for other laf-objects: e.g. a look_and_feel-object that gives for some attributes (e.g. frameBorderColor ) some fixed colors that were chosen at the construction time of the laf-object and all the other attributes are proxied to TTkCfg.theme.

  1. (laf-resolution at paintEvent) So one can have laf-objects that (per default) proxy their attribute requests to TTkCfg.theme but have the ability to prescribe some attributes directly without asking TTkCfg.theme. So it’s possible to use my_frame_laf = LookAndFeelProxy(); my_frame_laf.frameBorderColor = TTkColor.fg("#ff0000#"); as an laf-object for a frame that has (independent of the current theme) a red border, but all the other things (like the chars that are used for the border) are from the TTkCfg.theme.
  2. (colors, chars, etc. may depend on widget-state; method instead of pure values) Becasue laf-objects are objects (and not only stored color values) this allows for the ability to have methods in an laf-object that “computes” colors/chars taking the current state of the widget into account. This is the part that I used in the progressbar-WIP (often people want colors to depend on the “progress”: one uses a progress bar to show how full something is and want to colorize the event, that this thing is nearly empty, below 10%, with some red color, etc.).
  3. (feel-parameters and feel-functions) But wait, there is more … [in this commercial spot] 😃 Why do I call this look_and_feel and not style? Let’s make an example. Think of a PushButton (not a TTkButton) that can be pressed by a keyEvent (e.g. space or return) and shows it was pressed (via key) for some time and then goes automatically back in the unpressed state. This timing may be controlled by an attribute of an laf-object. So the keyEvent sets the pressed state and triggers an update and also starts a Timer to “unpress” the button in the near future. That’s not a style or color but that is a “responsive” feeling.

Pros: less slots per widget; laf-object may “compute” the look-and-feel depending on the state of widget; more parameters possible (without using slots); no additional methods needed at the widgets to prescribe special look-and-feel (e.g. setBorderColor or the missing setTitleColor or setTitleAlign, etc.) for a widget.

Cons: one level of “indirection” (the “laf-Proxy”) more at every paint-Event.

[Sorry for the long text.]

Issue Analytics

  • State:open
  • Created 9 months ago
  • Comments:10 (8 by maintainers)

github_iconTop GitHub Comments

ceccopierangiolieugeniocommented, Dec 21, 2022

@nickandwolf Unfortunately there is no way to include tiles or change the font size, what my library produce are the ANSI codes and UTF-8 chars interpreted by the terminal, so any graphical feature is restricted by what the terminal is capable of. (There are some terminals that support images and/or tiles but this is outside the scope of my project, my final goal is to have a terminal UI that may works via ssh/telnet or serial)

Anyway, about the half-step blocks I am already using them in the rasterizer. in this case you have the restriction of 2 colors (bg/fg) per char/tile:


or in the big font mouse/key input viewer:


I am actually thinking also to support the sextels in order to have 6 blocks resolution per char.

ceccopierangiolieugeniocommented, Dec 21, 2022

Experimenting with the gradient modifier:

Peek 2022-12-21 09-22.webm

Read more comments on GitHub >

github_iconTop Results From Across the Web

How to Set the Look and Feel (The Java™ Tutorials ...
Specifying the Look and Feel:; How the UI Manager Chooses the Look and Feel; Changing the Look and Feel After Startup; An...
Read more >
Java Swing | Look and Feel - GeeksforGeeks
Swing is GUI Widget Toolkit for Java. It is an API for providing Graphical User Interface to Java Programs. Unlike AWT, Swing components...
Read more >
Look & Feel - Qualtrics
The look and feel menu changes how your survey looks to respondents when ... and use the below look and feel settings and...
Read more >
Uniform look for Qt and GTK applications - ArchWiki
Each come with different themes, styles and icon sets by default, among other things, so the "look and feel" differ significantly. This article...
Read more >
Themes overview - MoodleDocs
A Moodle theme allows the user to change the look and feel of a Moodle site. ... {pluginpath}\styles.css e.g. \block\blockname\styles.css or ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found