Tk Source Code

Hi,
i would find very useful to have an -anchor option for ttk::progressbar in -mode determinate.
for horizontal progressbar, the cursor is moving from left to right, like an -anchor w
with -anchor e, the cursor could move from right to left

same for vertical progressbar:
-anchor n, the cursor would move from up to down
-anchor s, the cursor would move from down to up

best regards,
Nicolas

as Marc said, won't be Enhanced

It would be possible to draw a reversed progress bar on newer releases of
macOS (for which the HIToolbox is not used).  It would be a bit of work because
the colored portion has two rounded corners and two square corners.  Probably
it would be easiest to apply an affine transform that reflects across a vertical
line before drawing.  That might even work with HIToolbox if the graphics
context were modified before calling the HIToolbox routine.

However, I do not think such a thing belongs in the Aqua theme.  There is no
reversed progress bar available in XCode and no mention of such a thing in the
Human Interface Guidelines.  So no "native" macOS app would ever have a reversed
progress bar.

To be honest, I don't recall ever seeing a reversed progress bar on any
platform. That doesn't mean that they don't exist and it doesn't mean that Tk
shouldn't have one.  But I am quite certain that the Aqua theme should not have
one.

Tested with 'radiance' theme on Linux, seems ok.

A test with a theme with graphical progress bars will be needed.

My -reverse code works on Windows for all the available themes returned by [ttk::style theme names], i.e:

- winnative - clam - alt - default - classic - vista - xpnative

Also on macOS, it works for all avalable themes, except aqua:

- clam - alt - default - classic

(I didn't try on Linux.)

Regarding the aqua theme implemented in ttkMacOSXTheme.c, I think the reason it does not work is already described in the <<NOTE-TRACKS>>:

     * In some themes the Layouts for a progress bar has a trough element and a
     * pbar element.  But in our case the appearance manager draws both parts
     * of the progress bar, so we just have a single element called ".track".

Therefore it seems we cannot change the grow direction of a progressbar since it's not possible on that platform. This is not really a problem, we could document that -reverse is ignored by some themes on some platforms, which is just plain OK since after all ttk tries to mimic the platform behaviour.

In light of that, BTW, which platform do we know that has a reversed progressbar?

We could also look at PbarElementDraw in ttkMacOSXTheme.c,if there is any way to make it honor -reverse.

if it's not themable, let's forget about it then...
I'll find another way.

still, I think it would be a nice visual effect in both orientations.

++

Good point!  Please read "Aqua" everywhere that I said "macOS".

@marc:
> I don't see how this can possibly work on macOS (and in my test there was no
> change when the -reverse option was set).  I don't think that
> ProgressbarDeterminateLayout is ever called on macOS.

It apparently depends on the theme.
Indeed it does not work with the 'aqua' (macOS default) theme, but it definitely works with 'alt'. I had actually tried on Catalina, but didn't notice that ProgressbarDeterminateLayout() is theme-specific code.

Here are my thoughts on this.  As I have been toiling away in my dungeon working
on the Aqua theme I have had a guiding philosophy.  That is that the purpose
of the Ttk Aqua theme should be to allow people to write Tk applications which
look like XCode applications.  So the theme should provide as many of the XCode
UI components as possible.  But it should avoid providing UI components which
do not exist in XCode, or in Apple's Human Interface Guidelines.

I think a similar philosophy should apply to other themes that attempt to
replicate an existing user interface.  That is not to say that Apple's UI,
or the Windows 10 UI, or whatever, is perfect and can not be improved.  Just
that the improvements belong in a theme of their own.  There should be nothing
to prevent developers from mixing UI components from different themes and adding
new components of their own.  But someone who wants to create a potpourri UI
like that should take responsibility for writing it and presenting it under its
own name.

A question that *might* be worth asking is how would your delay time be
presented to your user if you were forced (God forbid!) to write your
application in XCode?  Would there perhaps be two progress bars, one for the
delay time and one for the execution time?  Or would you perhaps use a
"determinate progress circle" consisting of a circle with an expanding
colored sector, presented next to the progress bar, and make the progress
bar not start moving until the entire circle was filled in?

in my application i use horizontal ttk::progressbar to display elapsed time of an action.

the user push a button to start an action, the action must last 2 seconds, the ttk::progressbar cursor is moving from 0 to max (from left to right) during 2 seconds.

the button can also trigger a 'delayed action'.
in that case, I would like the cursor of the ttk::progressbar to move in -reverse (from right to left) during delay time.

I've started using ttk::progressbar in determinate mode to display elapsed/remaining time since I've notice a good integration of this widget with aqua theme.
before that, I was using a canvas / canvas rectangle and itemconfigure coords to move it

++

Nicolas, can you please describe a use case for one of these reversed progress bars?

should read after Marc's remark...
++

Hi,
after Marc, if this is still possible here's what I wrote for the TIP.
please tell me if it's ok.

Abstract
This tip proposes adding an option to ttk::progressbar in determinate mode to control cursor’s direction.

Rationale
Actually ttk::progressbar is going form West to East in Horizontal orientation and from North to South in Vertical orientation.
A new boolean option named -reverse could let user to control the direction of the ttk::progressbar, from South to North in Vertical orientation and East to West in Horizontal mode.

Implementation
An implementation of this TIP is present in the rfe-71107a79fa branch.

Expected Feature
Control the direction of cursor’s direction

Copyright
This document is placed in public domain

I don't see how this can possibly work on macOS (and in my test there was no
change when the -reverse option was set).  I don't think that
ProgressbarDeterminateLayout is ever called on macOS.  Apart from code
for parsing options, the only substantive change seems to occur in that
function.

modified title

Forgot to mention: the existing -anchor option is actually used (and working), see here

I have proposed an implementation, see branch rfe-71107a79fa.

Needs a TIP, of course.

From a quick glance at the code, this is very easy to implement.

A few thoughts:

• I'm not sure using -anchor for the proposed purpose is most straightforward. Standard Tk anchors can have many values (n, ne, e, se, s, sw, w, nw, and center). Using this option would mean having to deal with meaningless combinations. What would we do for instance with -anchor w -orient vertical, or with -anchor center? I suggest we rather resort to a boolean option, and I suggest we name it -reverse.

• ttk::progressbar already has an -anchor option documented. The widget accepts it, but this option is not used for anything at the moment. If we're not going to use it to implement the present RFE, I will remove it.