Re: Problem with ttk::spinbox button size




On 30 Jan., 08:16, Zoltan Kocsi <zol...@xxxxxxxxxxxxx> wrote:
Pat Thoyts <pattho...@xxxxxxxxxxxxxxxxxxxxx> wrote:
Zoltan Kocsi <zol...@xxxxxxxxxxxxx> writes:

To cater for hugely varying display sizes and resolutions, in an app I
allow the user to change the default font sizes used by Tk.

If I have a classic Tk listbox and I increase the font size, then the up
and down arrows which spin the box are enlarged proportionally, as
expected.

However, ttk::listbox (and, for that matter, ttk::combobox) enlarge the
entry field but the buttons stay the same size as before. If you enlarged
the font because you have a very high resolution display, then you end up
with a nicely lookung text field, with two tiny buttons crunched up on the
right hand side.

what buttons. listbox has no buttons.

Sorry, it was a mindburp. As the subject and the rest of my comment say, it
is ttk::spinbox.

When talking about themeing issues it makes a great deal of difference
what theme you are talking about and what system. On Windows, for some
[...]

Linux, default theme, although it behaves identically with clam, alt and
classic themes.

However, I've found the bug already on bugzilla reported by a Windows user,
the bug is classified 'obsolete', as it refers to the 8.5.9 patchlevel. I
will check whether anything changed with 4.5.11 or 4.6.

The problem is that if I allow the user to change the default font for the
application, as I should, then the application looks ugly. It looks ugly
because ttk::spinbox and ttk::combobox resize their entry field to
accomodate the old font, but leaves the buttons the same size as they were.
Which, from the user's perspective, results in normal text size and either
oversized buttons or tiny ones. The old spinbox resized its button according
to the font size, the themed one does not. I think the old spinbox's
behaviour is the correct one: the default look of the spinbox is a text entry
field and two buttons, which are square and half as high as the text entry
field each. If I change the font, the buttons change proportionately, keeping
the look of the whole widget the same.

If I have to calculate the number of pixels for a spinbox button from the
user's font selection, then I will need to know the exact details of the
spinbox size calculations, how large its entry field will be for any given
font and the like. Then I will have to check every other kind of widget
whether it scales itself with the font or not, and if not, I will have to go
through the docs and work out their subwidgets and how to calculate and set
their size in pixels.

At which point the whole themed toolkit loses its advantages over the classic
one.

The whole issue is further complicated by the fact that there *are* unix
people around who use simple window managers like fvwm2 or maybe even twm and
do not run any desktop. On those machines there's no such thing as system
theme settings, at least not one that the user is aware of. Thus, you *must*
allow the user to set font sizes.

I might be on a completely wrong track, but I think the way to calculate
widget sizes (unless the geometry manager options override it) is that widgets
should be scaled according to the default font. If a widget is a composite
widget, then its components should scale together while retaining their
overall shape (i.e. a scrollbar's arrow buttons remain square, the spinbox's
up and down buttons remain square and half as high as the entry field and so
on). If a widget uses a font other than the default font, then it should be
scaled according to the font it uses.
That way by changing the default font size the whole application will scale
proportionately, simply enlarging or shrinking elements by an equal amount.

The reasoning behind basing everything on the default font size is simple: it
is a very good indication about the size of things which the user finds
convenient to use on the screen. It is very subjective, depending on monitor,
resolution and the eyesight of the user. The only indication you have about
all those is the font which (s)he finds comfortable to read all thay long. An
arrow button which is smaller than the height of a lowercase letter is
probably too small, one which is larger than the entire line height is
probably unnecessarily large.

All of this is of course theoretical, as ttk:: does not seem to care about the
default font size at all.

Thank you, Zoltan, bringing this up.
ttk is young, brilliant and has many rough edges. The first time you
see them, you might say "this is not possible", or even "this worked
with tk, and now?".
The font size (and resize) handling is a big issue and AFAIK there are
fundamental unsolved issues (world change callback on tcl level).
I generally use runtime resizable fonts which is a brilliant thing for
the user.
It is a pity that the spinbox buttons do not resize. But it is as it
is.

Here are some funny tries by me on a similar issue:
http://wiki.tcl.tk/27485

-Harald
.



Relevant Pages

  • Re: Problem with ttk::spinbox button size
    ... allow the user to change the default font sizes used by Tk. ... If I have a classic Tk listbox and I increase the font size, ... entry field but the buttons stay the same size as before. ... Then I will have to check every other kind of widget ...
    (comp.lang.tcl)
  • Re: Demonstrate ttk possibility
    ... Menu unpost upon mouse leaving the menu, ... Same height across a row of widgets using pack (with font size ... To achieve the same with [grid] replace the pack calls with: ... Note that for the above size example, if you manually resize the widget ...
    (comp.lang.tcl)
  • Re: change font in the ctext widget
    ... > wiki that it's built on top of the standard Tk text widget. ... I had a general font problem with the entire ased application on my Debian ... I found some option add statements on wiki that changed the menu fonts ...
    (comp.lang.tcl)
  • keeping aesthetics with font size change
    ... decrease font size. ... text widget is ... grid .lf.l1 .lf.c -sticky w ... incr::fontSize $1 ...
    (comp.lang.tcl)
  • Re: "booster-label" - why does it work such way? (8.4.12 on Debian Etch)
    ... perfectly valid way to achieve the desired behaviour. ... A widget has been created. ... Immediately then a default font is loaded "just in case". ... possibly breaking those scripts. ...
    (comp.lang.tcl)