Menu
▾
▴
#229 Fire Event when a used font changes
When a named font is used by a widget:
% font create Custom -size 8
% label .l -font Custom
and the font is reconfigured:
% font configure Custom -size 17
all core widgets automatically change their size.
If a megawidget uses a named font and does some position calculations on the font size,
there is no way to get notified if the font size change to trigger a size change.
In consequence, widgets look corrupted after a font size change.
Example megawidgets are: NoteBook from BWidgets, TableList
The demanded feature is to send an event if the size of the font changes.
Example:
bind .l <FontChange> reConfigure
This would be similar to the Configure event.
- Information provided by tclguy on clt:
-1-
This would mean exporting the WorldChanged proc to a virtual event. WorldChanged is one of the class procs introduced in Tk 8.4 for (C-based) widgets to be made aware of just such changes. I don't think it would hard to cause a virtual event visible in Tcl to be triggered in the same low-level machinery.
-2-
> So the point is that tkFont::TheWorldHasChanged would in addition generate an event ?
WorldChanged happens already at the C level, and fonts is just what 90%
of people care about (e.g it's the only thing tktable really watches
this for). As a C level per-widget thing, it would be a per-widget
<<WorldChange>> event to watch for on (mega)widgets that care (at least,
that's my design in head without looking at code).
- tcl core list communications about this feature:
-tclguy-
Following up on this previous question, it appears that actually the
WorldChange is a push sort of event. In tkFont.c:TheWorldHasChanged,
you will see the one place that calls it, but getting the
worldChangedProc of the main window of the current application and
calling it on every descendant widget.
If we are to generate a virtual <<WorldChange>>, when would be a good
time to do it?
1. Places that cause WorldChange generate it, e.g.
tkFont.c:TheWorldHasChanged.
2. Each consumer with a worldChangedProc generates itself, if it wants?
(this would require a change to each WorldChangedProc, but would allow
specificity)
The other option is to turn this into a special wm protocol or main
window only style event. However, main window might not be quite right
as you can technically have toplevels on different displays that might
need to react differently.
-Brian Griffin-
This is an interesting problem. The WorldChanged event is a broadcast event. Every widget must receive it and it cannot have any event chain or parent/child dependancies in the way. Currently Tcl/Tk does not have any broadcast mechanism. The "all" class is the closest thing to a broadcast, but it is subject to [break] short-circuiting.
This may call for a new event handling protocol. If a widget binds <<WolrdChanged>>, it will receive the event regardless of [focus] or [bindtags] behavior. It would be nice if there where a general purpose broadcast event that had this focus-less, break-less behavior.
Actually, I think that what we need is a <<NamedFontChanged>> virtual event, which could be implemented and handled just like <<ThemeChanged>>.
IIRC, there are also plans (or at least proposals) for named colors support. That would require another virtual event, called, e.g., <<NamedColorChanged>>.
I'm not sure a generic <WorldChange>> virtual event would be the right solution.