tktable-tile-dev — Discussion about tile development

Re: [Tile-dev] Progress bars

[Michael K. <mi...@mu...>]

On Mon, 28 Feb 2005, Joe English wrote:

> Also just committed some final fixes; the widget is now implemented
> and works more or less as documented.

Some comments:

1. I don't think indeterminate bars should show the cylon block (dunno 
what else to call it :P) when they are not running.

2. The start/stop stuff doesn't work under the Aqua theme.  It turns the 
track to a barber pole (actually the initial version always showed the 
barber pole, but I fixed that) but doesn't animate.  Phase is always 0.

--
Michael Kirkham
www.muonics.com

Re: [Tile-dev] Progress bars

[Joe E. <jen...@fl...>]

Jeff Hobbs wrote:

> The doc still says ttk::progress, and then the util procedures
> are in the tile::progressbar namespace.  Is that right?

Oops!  Missed a spot.  The widget name is ttk::progressbar,
manpage fixed now.

Also just committed some final fixes; the widget is now implemented
and works more or less as documented.  

XP theme still (probably) looks wrong, haven't tested there yet.


--Joe

RE: [Tile-dev] Progress bars

[Jeff H. <je...@Ac...>]

> Anyway, new strawmanpage posted reflecting the above:
> 
>     <URL: http://tktable.sourceforge.net/tile/doc/progressbar.html >
> 
> This version is closer to BWidget's ProgressBar (good),
> but, with the loss of -from, -to, and set, is completely 
> incompatible with the current ttk::progress widget (bad).
> 
> So I've changed the widget name to 'ttk::progressbar'.

The doc still says ttk::progress, and then the util procedures
are in the tile::progressbar namespace.  Is that right?

Jeff

RE: [Tile-dev] Progress bars

[Jeff H. <je...@Ac...>]

> The default -maximum is 100.  That's somewhat arbitrary --
> 1.0 would be more logical from a mathematical point of view 
> -- but 100% will probably be used more often than any other 
> arbitrary number I can think of.

Let's just ensure that whatever value is chosen, we don't get
caught in any double-imprecision traps.  For that reason, I
prefer 100 instead of 1.0 to start with.

Jeff

Re: [Tile-dev] Progress bars

[Joe E. <jen...@fl...>]

Michael Kirkham wrote:

> Would step take an optional argument for the step size?

Yes -- the full synopsis is:

| pathName step ?amount?
|    Increments the -value by amount. amount defaults to 1.0 if omitted.

> What's the
> default increment given that the current default range is 0-1?  Or would
> you make the default step 1, and change the default range to be 0-100?  Or
> add a -stepsize option?

The default -maximum is 100.  That's somewhat arbitrary --
1.0 would be more logical from a mathematical point of view --
but 100% will probably be used more often than any other
arbitrary number I can think of.

> > We could just hardcode this -- pick a value and say "indeterminate
> > progress bars complete one cycle each time the value increments by 100"
> > or something like that.  But for now I'm inclined to use a "-mode"
> > option.
>
> To do that the cap that forces -from <= -value <= -to will have to be
> lifted.

As currently specified, animation is active if:

    (theme supports it) && (-value > 0)
 && (-mode == indeterminate || -value < -maximum)


--Joe English

  jen...@fl...

Re: [Tile-dev] Progress bars

[Michael K. <mi...@mu...>]

On Fri, 25 Feb 2005, Joe English wrote:

>>> And if so, would a 'step' method be useful for indeterminate
>>> progress bars, where [$w step] is equivalent to:
>>>
>>>     $w configure -value [expr {[$w cget -value] + [$w cget -stepsize]}]
>>
>> [$w step] is cleaner.

Would step take an optional argument for the step size?  What's the 
default increment given that the current default range is 0-1?  Or would 
you make the default step 1, and change the default range to be 0-100?  Or 
add a -stepsize option?

> It occurs to me that there is no reason for -from to ever
> be anything other than 0; we could replace -from and -to
> with a single -maximum option.

Mmm... I could probably think of a reason (though perhaps an artificial 
one): suppose you had a listbox of a bunch of records or files you wanted 
to do something on a selection for that takes some time.  One might set 
their range to the minimum and maximum list index.

Of course, it would undoubtedly be better to set the maximum to the number 
of items selected, so it's certainly not a compelling reason.

> I kind of like muonics approach:

Credit where due, it was Pat's idea, though he suggested also having 
-value != 0 be part of the rule that turns on the barber pole.  That's not 
possible without lifting the cap, however, and that cap may be there for a 
good reason (if none other than so that each theme doesn't have to do its 
own capping to not draw more than necessary).

> We could just hardcode this -- pick a value and say "indeterminate
> progress bars complete one cycle each time the value increments by 100"
> or something like that.  But for now I'm inclined to use a "-mode"
> option.

To do that the cap that forces -from <= -value <= -to will have to be 
lifted.

--
Michael Kirkham
www.muonics.com

Re: [Tile-dev] Progress bars

[Kevin W. <sw...@wo...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

D'oh. I built the new Tile correctly, but didn't place it in
/Library/Tcl. Moving things over fixed the problem.

This is really cool, and absolutely perfect for the DarwinPorts GUI I'm
working on. Thanks for putting it together.

Cheers,

Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw...@wo...

Michael Kirkham wrote:
| On Fri, 25 Feb 2005, Kevin Walzer wrote:
|
|> Michael,
|>
|> OK, I think I've gotten the patches applied correctly, and the new
|> version of Tile built. I have written a little script to display the
|> barber pole, and I'm not getting it right (nothing displays but the
|> "trough" where the progress bar should be). Can you take a look and let
|> me know what I'm doing wrong?
|
|
| What you have should work.  I'd have to guess the patches weren't
| applied correctly, or it's using your unpatched version or something.
| Perhaps the attached will work better if the former (unified diff format).
|
|> package require tile
|>
|> ttk::progress .p1 -from 0 -to 0
|> pack .p1
|
|
| This should actually be sufficient to get the barber pole, as currently
| implemented.  It uses timer events to animate, rather than relying set
| calls to refresh.  Otherwise the animation would be anything but smooth.
|
| To turn off the barber pole:
|
| .p1 config -to 1; # anything non-zero, really
|
|> .p1 set 0
|> set i1 0
|>
|> proc showprog {} {
|> global i1
|> incr i1
|> .p1 set $i1
|> after 10 showprog
|> }
|>
|> after 10 showprog
|
|
| This will actually never set the value beyond 0 (with or without the
| patch): the set value gets capped at the -to value.  i.e.,
|
| .p1 config -to 0
| .p1 set 10000
| puts [.p1 get]
|
| ...will print 0.
|
| --
| Michael Kirkham
| www.muonics.com
|
|
| ------------------------------------------------------------------------
|
| Index: generic/scale.c
| ===================================================================
| RCS file: /cvsroot/tktable/tile/generic/scale.c,v
| retrieving revision 1.39
| diff -u -r1.39 scale.c
| --- generic/scale.c	11 Dec 2004 00:36:38 -0000	1.39
| +++ generic/scale.c	25 Feb 2005 22:07:04 -0000
| @@ -18,6 +18,10 @@
|  #define DEF_SCALE_WIDTH "15"
|  #define DEF_SCALE_LENGTH "100"
|  #define DEF_SCALE_SHOW_VALUE "1"
| +#define DEF_SCALE_PERIOD 100
| +
| +#define	DEF_SCALE_STRIPE_WIDTH 10.0
| +#define	DEF_SCALE_STRIPE_PHASES 4
|
|  #ifndef MAX
|  #define MAX(a,b) ((a) > (b) ? (a) : (b))
| @@ -45,6 +49,9 @@
|
|      /* internal state */
|      int orient;
| +
| +    /* Timer handler for animated progress bars */
| +    Tcl_TimerToken timer;
|  } ScalePart;
|
|  typedef struct
| @@ -98,6 +105,8 @@
|  {
|      Scale *scalePtr = recordPtr;
|
| +    scalePtr->scale.timer = (Tcl_TimerToken) NULL;
| +
|      TrackElementState(&scalePtr->core);
|      return TCL_OK;
|  }
| @@ -235,6 +244,11 @@
|      return r;
|  }
|
| +static void
| +AnimateProgress(Scale *scalePtr);
| +static void
| +CancelAnimation(Scale *scalePtr);
| +
|  static int
|  ScaleSetCommand(
|      Tcl_Interp *interp, int objc, Tcl_Obj *CONST objv[], void *recordPtr)
| @@ -279,6 +293,7 @@
|  	    scalePtr->scale.valueObj, TCL_GLOBAL_ONLY);
|      }
|      if (WidgetDestroyed(&scalePtr->core)) {
| +	CancelAnimation(scalePtr);
|  	return TCL_ERROR;
|      }
|
| @@ -466,6 +481,27 @@
|      }
|  }
|
| +/*
| + * ProgressDisplay --
| + *  Display progress bar, possibly with animation.
| + */
| +void ProgressDisplay(void *clientData, Drawable d)
| +{
| +    WidgetCore *corePtr = clientData;
| +    Scale *scalePtr = clientData;
| +
| +    Ttk_DrawLayout(corePtr->layout, corePtr->state, d);
| +
| +    /*
| +     * Set a new timer handler for animation re-display if necessary.
| +     * This is done here so that animation will resume on a progress
| +     * bar that hasn't changed its current value between theme
| +     * changes to/from animated/non-animated themes.
| +     */
| +
| +    AnimateProgress(scalePtr);
| +}
| +
|  /*
|   * ScaleSize --
|   * 	Compute requested size of scale.
| @@ -553,12 +589,56 @@
|   * Progress widget overrides.
|   */
|
| +static void
| +AnimateProgressProc(ClientData clientData)
| +{
| +    Scale *scalePtr = (Scale *)clientData;
| +
| +    WidgetChanged(&scalePtr->core, REDISPLAY_REQUIRED);
| +}
| +
| +static void
| +CancelAnimation(Scale *scalePtr)
| +{
| +    if (scalePtr->scale.timer) {
| +	Tcl_DeleteTimerHandler(scalePtr->scale.timer);
| +	scalePtr->scale.timer = (Tcl_TimerToken) NULL;
| +    }
| +}
| +
| +static void
| +AnimateProgress(Scale *scalePtr)
| +{
| +    double from = 0, to = 0, current = 0;
| +
| +    Tcl_GetDoubleFromObj(NULL, scalePtr->scale.fromObj, &from);
| +    Tcl_GetDoubleFromObj(NULL, scalePtr->scale.toObj, &to);
| +    Tcl_GetDoubleFromObj(NULL, scalePtr->scale.valueObj, &current);
| +
| +    /*
| +     * Cancel pending animation redisplay timer handler, if any
| +     */
| +
| +    CancelAnimation(scalePtr);
| +
| +    /*
| +     * Only animate if the current value is within the from/to range
| +     * or from and to are the same for an indeterminate progress bar.
| +     */
| +
| +    if (((current > from) && (current < to)) || ((from == 0) && (to
== 0))) {
| +    	scalePtr->scale.timer = Tcl_CreateTimerHandler(DEF_SCALE_PERIOD,
| +		AnimateProgressProc, (ClientData)scalePtr);
| +    }
| +}
| +
|  static int
|  ProgressInitialize(Tcl_Interp *interp, void *recordPtr)
|  {
|      Scale *scalePtr = recordPtr;
|
|      scalePtr->scale.showValue = 0;
| +    scalePtr->scale.timer = (Tcl_TimerToken) NULL;
|
|      return TCL_OK;
|  }
| @@ -622,7 +702,7 @@
|      ProgressGetLayout, 		/* getLayoutProc */
|      ScaleSize,			/* sizeProc */
|      ProgressDoLayout,		/* layoutProc */
| -    WidgetDisplay,		/* displayProc */
| +    ProgressDisplay,		/* displayProc */
|      WIDGET_SPEC_END		/* sentinel */
|  };
|
| Index: generic/tkElements.c
| ===================================================================
| RCS file: /cvsroot/tktable/tile/generic/tkElements.c,v
| retrieving revision 1.69
| diff -u -r1.69 tkElements.c
| --- generic/tkElements.c	31 Dec 2004 01:32:57 -0000	1.69
| +++ generic/tkElements.c	25 Feb 2005 22:07:05 -0000
| @@ -9,6 +9,7 @@
|  #include <tcl.h>
|  #include <tk.h>
|  #include <string.h>
| +#include <sys/time.h>
|  #include "tkTheme.h"
|
|  #define DEFAULT_BORDERWIDTH "2"
| @@ -901,6 +902,9 @@
|      Tcl_Obj *reliefObj;      /* the relief for this object */
|      Tcl_Obj *borderObj;      /* the background color */
|      Tcl_Obj *borderWidthObj; /* the size of the border */
| +    Tcl_Obj *fromObj;        /* minimum value for progress range */
| +    Tcl_Obj *toObj;          /* maximum value for progress range */
| +    Tcl_Obj *stripeObj;      /* stripe color for indeterminite
progress */
|  } SliderElement;
|
|  static Ttk_ElementOptionSpec SliderElementOptions[] =
| @@ -917,6 +921,12 @@
|  	DEFAULT_BACKGROUND },
|      { "-orient", TK_OPTION_ANY, Tk_Offset(SliderElement,orientObj),
|  	"horizontal" },
| +    { "-from", TK_OPTION_DOUBLE, Tk_Offset(SliderElement,fromObj),
| +	"0" },
| +    { "-to", TK_OPTION_DOUBLE, Tk_Offset(SliderElement,toObj),
| +	"1.0" },
| +    { "-stripecolor", TK_OPTION_COLOR,
Tk_Offset(SliderElement,stripeObj),
| +	"white" },
|      { NULL }
|  };
|
| @@ -1004,22 +1014,94 @@
|   * A progress bar.
|   */
|
| +#define DEF_SCALE_PERIOD 100
| +#define	DEF_SCALE_STRIPE_WIDTH 10.0
| +#define	DEF_SCALE_STRIPE_PHASES 4
| +
|  static void
|  ProgressElementDraw(void *clientData, void *elementRecord,
|      Tk_Window tkwin, Drawable d, Ttk_Box b, unsigned int state)
|  {
|      SliderElement *slider = elementRecord;
| -    Tk_3DBorder border = NULL;
| -    int relief, borderWidth, orient;
| +    double from, to;
|
| -    border = Tk_Get3DBorderFromObj(tkwin, slider->borderObj);
| -    Ttk_GetOrientationFromObj(NULL, slider->orientObj, &orient);
| -    Tk_GetPixelsFromObj(NULL, tkwin, slider->borderWidthObj,
&borderWidth);
| -    Tk_GetReliefFromObj(NULL, slider->reliefObj, &relief);
| +    Tcl_GetDoubleFromObj(NULL, slider->fromObj, &from);
| +    Tcl_GetDoubleFromObj(NULL, slider->toObj, &to);
|
| -    Tk_Fill3DRectangle(tkwin, d, border,
| -	b.x, b.y, b.width, b.height,
| -	borderWidth, relief);
| +    /*
| +     * Display barberpole-style stripes for an indefinite progress bar
| +     * if the from and to values are both zero.
| +     */
| +
| +    if ((from == 0) && (to == 0)) {
| +	Display *display = Tk_Display(tkwin);
| +        struct timeval tv;
| +        struct timezone tz;
| +	int phase;
| +	int x;
| +	int ofs1 = b.height/2;
| +	int ofs2 = b.height*3/2;
| +    	GC gc;
| +	XGCValues gcValues;
| +	XColor* colorPtr = Tk_GetColorFromObj(tkwin, slider->borderObj);
| +
| +	gc = Tk_GCForColor(colorPtr, d);
| +
| +	XFillRectangle(display, d, gc, b.x, b.y, b.width, b.height);
| +
| +	/*
| +	 * Calculate the phase based on the time of day and hard-coded
| +	 * phase period.
| +	 */
| +
| +        gettimeofday(&tv, &tz);
| +
| +	phase = (((tv.tv_sec * 1000) + (tv.tv_usec / 1000)) / DEF_SCALE_PERIOD);
| +	phase %= DEF_SCALE_STRIPE_PHASES;
| +
| +	/*
| +	 * Start drawing the stripes within the region one stripe width to
| +	 * the left of the visible area so that the stripes don't jump
| +	 * between phase resets.
| +	 */
| +
| +	x = -b.height;
| +	x += ((b.height * 1.5) / DEF_SCALE_STRIPE_PHASES)*phase;
| +
| +	colorPtr = Tk_GetColorFromObj(tkwin, slider->stripeObj);
| +
| +	/*
| +	 * colorPtr = Tk_GetColorFromObj(tkwin, scalePtr->scale.foregroundObj);
| +	*/
| +
| +	gcValues.foreground = colorPtr->pixel;
| +	gcValues.line_width = (int)b.height/2;
| +
| +	gc = Tk_GetGC(tkwin, GCForeground | GCLineWidth, &gcValues);
| +
| +	/*
| +	 * Draw the stripes.
| +	 */
| +
| +	while (x < b.width + b.height / 2) {
| +	    XDrawLine(display, d, gc, x - ofs1, -ofs1, (x + ofs2), ofs2);
| + 	    x += (int)(b.height * 1.5);
| +	}
| +
| +	Tk_FreeGC(display, gc);
| +    } else {
| +	Tk_3DBorder border = NULL;
| +	int relief, borderWidth, orient;
| +
| +	border = Tk_Get3DBorderFromObj(tkwin, slider->borderObj);
| +	Ttk_GetOrientationFromObj(NULL, slider->orientObj, &orient);
| +	Tk_GetPixelsFromObj(NULL, tkwin, slider->borderWidthObj, &borderWidth);
| +	Tk_GetReliefFromObj(NULL, slider->reliefObj, &relief);
| +
| +	Tk_Fill3DRectangle(tkwin, d, border,
| +		b.x, b.y, b.width, b.height,
| +		borderWidth, relief);
| +    }
|  }
|
|  static Ttk_ElementSpec ProgressElementSpec =
| Index: macosx/aquaTheme.c
| ===================================================================
| RCS file: /cvsroot/tktable/tile/macosx/aquaTheme.c,v
| retrieving revision 1.19
| diff -u -r1.19 aquaTheme.c
| --- macosx/aquaTheme.c	11 Dec 2004 00:36:41 -0000	1.19
| +++ macosx/aquaTheme.c	25 Feb 2005 22:07:06 -0000
| @@ -35,6 +35,8 @@
|  #include <tkMacOSX.h>
|  #include "tkTheme.h"
|
| +#define DEF_SCALE_PERIOD 100
| +
|  /*----------------------------------------------------------------------
|   * +++ Utilities.
|   */
| @@ -507,7 +509,25 @@
|
|      switch (data->kind) {
|      case kThemeProgressBar:
| -	drawInfo.trackInfo.progress.phase = 0;	/* 1-4: animation phase */
| +	{
| +	    struct timeval tv;
| +	    struct timezone tz;
| +	    gettimeofday(&tv, &tz);
| +
| +	    /* @@@ Should check -period style setting and divide by
| +             * @@@ period rather than 100 if non-zero, or set phase to 0
| +             * @@@ if period is 0?
| +	     */
| +
| +	    drawInfo.trackInfo.progress.phase =
| +		(UInt8)(((tv.tv_sec * 1000) + (tv.tv_usec / 1000))
| +			/ DEF_SCALE_PERIOD);
| +
| +	    if ((from == 0) && (to == 0)) {
| +		drawInfo.max = 1;
| +		drawInfo.kind = kThemeIndeterminateBar;
| +	    }
| +	}
|  	break;
|      case kThemeSlider:
|      	drawInfo.trackInfo.slider.pressState = 0; /* @@@ fill this in */
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCH6doJmdQs+6YVcoRAsvqAJ41InCX2Bk0VVEkek9cKjW6CIx0VgCghl04
5lyQ2sLiSlQkUIB52DZ3/7U=
=HEga
-----END PGP SIGNATURE-----

Re: [Tile-dev] Progress bars

[Joe E. <jen...@fl...>]

Some more random thoughts:

 * * *

I see three main use cases for progress bars:

(1) the application knows exactly how much work is to be
done and the progress is shown proportionally;
(2) the application doesn't know how much work is to be done,
but can at least provide feedback about how fast it's going
(the "bouncing rectangle"); and
(3) the application just wants to show a throbber to keep
the user from thinking the program has locked up.

Sometimes a progess bar will start out in mode (2) or (3),
then switch to mode (1), so this should be configurable
by widget options; using separate -styles for determinate
and indeterminate progress bars isn't appropriate.

 * * *

Eric Boudaillier wrote:
> Joe English wrote:
> > Questions: Are the 'set' and 'get' methods really needed?
> > They're equivalent to [$w configure -value] and [$w cget -value],
> > respectively; or you can just access the linked -variable.
>
> Isn't there a general rule in tk that options are never changed
> internally, but only via configure subcommand ?
> This is at least what I have observed, with for example [entry].

That's not a hard and fast rule, but it does seem to
be the tendency; don't provide too many redundant equivalent
redundant ways of doing the same thing.

I'm inclined to drop [$w get] and [$w set].

> > And if so, would a 'step' method be useful for indeterminate
> > progress bars, where [$w step] is equivalent to:
> >
> >     $w configure -value [expr {[$w cget -value] + [$w cget -stepsize]}]
>
> [$w step] is cleaner.


You could also use [incr $linkedVar $amount], although having
a separate [$w step] method seems just useful enough to me
to warrant including it.  I'm inclined to add this one.


 * * *

It occurs to me that there is no reason for -from to ever
be anything other than 0; we could replace -from and -to
with a single -maximum option.

That would make the Tile progress bar nearly compatible with the
BWidget one; the main difference would be -mode vs. -type.
(And to be honest, I never really did understand the difference
between -type incremental, -type infinite, and -type
nonincremental_infinite, so this difference might be
a good thing :-)

 * * *

I kind of like muonics approach:

| Indeterminate mode is obtained by setting -from and -to both to 0.  As
| long as both have value 0, it will animate a barberpole.  Change either to
| non-zero and it will switch to a regular progress bar (showing just a
| track if the "set" value is <= -from).

(or, specify "-maximum 0" to get an indeterminate progress bar).
Except that, on most platforms indeterminate progress bars use a
"bouncing rectangle" effect instead of a "barberpole" effect.
This can be used to indicate how fast things are going, but
with '-maximum 0', the programmer doesn't know / can't control 
how much the bar will move when the -value is incrememented 
by a particular amount.

We could just hardcode this -- pick a value and say "indeterminate
progress bars complete one cycle each time the value increments by 100"
or something like that.  But for now I'm inclined to use a "-mode"
option.

 * * *

Anyway, new strawmanpage posted reflecting the above:

    <URL: http://tktable.sourceforge.net/tile/doc/progressbar.html >

This version is closer to BWidget's ProgressBar (good),
but, with the loss of -from, -to, and set, is completely
incompatible with the current ttk::progress widget (bad).

So I've changed the widget name to 'ttk::progressbar'.
If this ends up as the final version, we'll keep the
current [ttk::progress] widget around for one more
release cycle so early adopters will have a chance
to upgrade.


--Joe English

  jen...@fl...

Re: [Tile-dev] Progress bars

[Michael K. <mi...@mu...>]

On Fri, 25 Feb 2005, Kevin Walzer wrote:

> Michael,
>
> OK, I think I've gotten the patches applied correctly, and the new
> version of Tile built. I have written a little script to display the
> barber pole, and I'm not getting it right (nothing displays but the
> "trough" where the progress bar should be). Can you take a look and let
> me know what I'm doing wrong?

What you have should work.  I'd have to guess the patches weren't applied 
correctly, or it's using your unpatched version or something.  Perhaps the 
attached will work better if the former (unified diff format).

> package require tile
>
> ttk::progress .p1 -from 0 -to 0
> pack .p1

This should actually be sufficient to get the barber pole, as currently 
implemented.  It uses timer events to animate, rather than relying set 
calls to refresh.  Otherwise the animation would be anything but smooth.

To turn off the barber pole:

.p1 config -to 1; # anything non-zero, really

> .p1 set 0
> set i1 0
>
> proc showprog {} {
> global i1
> incr i1
> .p1 set $i1
> after 10 showprog
> }
>
> after 10 showprog

This will actually never set the value beyond 0 (with or without the 
patch): the set value gets capped at the -to value.  i.e.,

.p1 config -to 0
.p1 set 10000
puts [.p1 get]

...will print 0.

--
Michael Kirkham
www.muonics.com

Re: [Tile-dev] Progress bars

[Kevin W. <sw...@wo...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael,

OK, I think I've gotten the patches applied correctly, and the new
version of Tile built. I have written a little script to display the
barber pole, and I'm not getting it right (nothing displays but the
"trough" where the progress bar should be). Can you take a look and let
me know what I'm doing wrong?


Thanks.
- ---

package require tile

ttk::progress .p1 -from 0 -to 0
pack .p1


.p1 set 0
set i1 0

proc showprog {} {
global i1
incr i1
.p1 set $i1
after 10 showprog
}

after 10 showprog

- --
Cheers,

Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw...@wo...

Michael Kirkham wrote:
|
| I probably forgot to do the diffs in unified format.  I tend to do that
| a lot. :P  It should be okay, it just requires telling it which files to
| patch when it prompts you to.  And make sure you have the latest sources
| from CVS HEAD.
|
| cd /your/tile/src/dir
| patch < /wherever/is/progressanim2.diff
|
| At each prompt, type in the name of the file to patch that it shows you.
| e.g. "generic/scale.c" when it tells you about scale.c and asks you
| which file to patch.
|
| Looking at the diffs, It'll want to patch generic/scale.c,
| generic/tkElements.c, aquaTheme.tcl and aquaTheme.c.  You can skip
| aquaTheme.tcl - that shouldn't be in the rev 2 patch, but it doesn't
| matter.  It just specifies a theme setting for the period between
| animation frames which is unused in the 2nd rev and will be ignored.
|
| On Fri, 25 Feb 2005, Kevin Walzer wrote:
|
|> Date: Fri, 25 Feb 2005 15:37:02 -0500
|> From: Kevin Walzer <sw...@wo...>
|> To: Michael Kirkham <mi...@mu...>
|> Cc: Joe English <jen...@fl...>,
|>     tkt...@li...
|> Subject: Re: [Tile-dev] Progress bars
|>
| Forgive my ignorance--I downloaded this patch and am trying to apply it,
| but I'm not getting the correct results. There actually seem to be
| patches/diffs for several files here. Can someone outline the steps I
| sohuld take to apply it?
|
| Cheers,
|
| Kevin Walzer, PhD
| WordTech Software--Open Source Applications and Packages for OS X
| http://www.wordtech-software.com
| http://www.smallbizmac.com
| http://www.kevin-walzer.com
| mailto:sw...@wo...
|
| Michael Kirkham wrote:
| |
| | On Thu, 24 Feb 2005, Joe English wrote:
| |
| |> + Animation.  On Aqua and on some KDE themes (depending on
| |>  the user's preferred eye candy level) thermometer-style
| |>  progress bars have an additional pulsing/throbbing effect,
| |>  presumably to let the user know that the program hasn't
| |>  locked up even if the bar isn't otherwise moving.
| |>  Michael Kirkham (muonics) has a patch that implements this
| |>  on OSX.
| |
| |
| | The latest version of the patch submitted a little while ago implements
| | barber-pole style indeterminate progress bars for other themes except
| | clam (any that doesn't already have its own progress widget, I think),
| | too. Still needs a few tweaks, but it's functional.
| |
| | Indeterminate mode is obtained by setting -from and -to both to 0.  As
| | long as both have value 0, it will animate a barberpole.  Change either
| | to non-zero and it will switch to a regular progress bar (showing
| just a
| | track if the "set" value is <= -from).
| |
| | If anyone wants to play with it the current patch is at:
| |
| |
|
https://sourceforge.net/tracker/index.php?func=detail&aid=1144673&group_id=11464&atid=311464

|
|
| |
| |
| | --
| | Michael Kirkham
| | www.muonics.com
| |
| |
| | -------------------------------------------------------
| | SF email is sponsored by - The IT Product Guide
| | Read honest & candid reviews on hundreds of IT Products from real
| users.
| | Discover which products truly live up to the hype. Start reading now.
| | http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
| | _______________________________________________
| | Tktable-tile-dev mailing list
| | Tkt...@li...
| | https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
| |
| |
|>
|>
- -------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Tktable-tile-dev mailing list
Tkt...@li...
https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
|>

| --
| Michael Kirkham
| www.muonics.com


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCH5+JJmdQs+6YVcoRAuVxAJ9Xn6OnOv4ilqVzRntYIzPuzWPo1ACgiav9
XXQQaAm8ESfmN0UbEl/7RAw=
=TSXj
-----END PGP SIGNATURE-----

Re: [Tile-dev] Progress bars

[Michael K. <mi...@mu...>]

I probably forgot to do the diffs in unified format.  I tend to do that a 
lot. :P  It should be okay, it just requires telling it which files to 
patch when it prompts you to.  And make sure you have the latest sources 
from CVS HEAD.

cd /your/tile/src/dir
patch < /wherever/is/progressanim2.diff

At each prompt, type in the name of the file to patch that it shows you. 
e.g. "generic/scale.c" when it tells you about scale.c and asks you which 
file to patch.

Looking at the diffs, It'll want to patch generic/scale.c, 
generic/tkElements.c, aquaTheme.tcl and aquaTheme.c.  You can skip 
aquaTheme.tcl - that shouldn't be in the rev 2 patch, but it doesn't 
matter.  It just specifies a theme setting for the period between 
animation frames which is unused in the 2nd rev and will be ignored.

On Fri, 25 Feb 2005, Kevin Walzer wrote:

> Date: Fri, 25 Feb 2005 15:37:02 -0500
> From: Kevin Walzer <sw...@wo...>
> To: Michael Kirkham <mi...@mu...>
> Cc: Joe English <jen...@fl...>,
>     tkt...@li...
> Subject: Re: [Tile-dev] Progress bars
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Forgive my ignorance--I downloaded this patch and am trying to apply it,
> but I'm not getting the correct results. There actually seem to be
> patches/diffs for several files here. Can someone outline the steps I
> sohuld take to apply it?
>
> Cheers,
>
> Kevin Walzer, PhD
> WordTech Software--Open Source Applications and Packages for OS X
> http://www.wordtech-software.com
> http://www.smallbizmac.com
> http://www.kevin-walzer.com
> mailto:sw...@wo...
>
> Michael Kirkham wrote:
> |
> | On Thu, 24 Feb 2005, Joe English wrote:
> |
> |> + Animation.  On Aqua and on some KDE themes (depending on
> |>  the user's preferred eye candy level) thermometer-style
> |>  progress bars have an additional pulsing/throbbing effect,
> |>  presumably to let the user know that the program hasn't
> |>  locked up even if the bar isn't otherwise moving.
> |>  Michael Kirkham (muonics) has a patch that implements this
> |>  on OSX.
> |
> |
> | The latest version of the patch submitted a little while ago implements
> | barber-pole style indeterminate progress bars for other themes except
> | clam (any that doesn't already have its own progress widget, I think),
> | too. Still needs a few tweaks, but it's functional.
> |
> | Indeterminate mode is obtained by setting -from and -to both to 0.  As
> | long as both have value 0, it will animate a barberpole.  Change either
> | to non-zero and it will switch to a regular progress bar (showing just a
> | track if the "set" value is <= -from).
> |
> | If anyone wants to play with it the current patch is at:
> |
> |
> https://sourceforge.net/tracker/index.php?func=detail&aid=1144673&group_id=11464&atid=311464
>
> |
> |
> | --
> | Michael Kirkham
> | www.muonics.com
> |
> |
> | -------------------------------------------------------
> | SF email is sponsored by - The IT Product Guide
> | Read honest & candid reviews on hundreds of IT Products from real users.
> | Discover which products truly live up to the hype. Start reading now.
> | http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> | _______________________________________________
> | Tktable-tile-dev mailing list
> | Tkt...@li...
> | https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
> |
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFCH4xtJmdQs+6YVcoRAu5QAJwL8RvFzPvrKluiyVctKWWSRo3bRACgiOPQ
> NsxIQ8fqe6O+TTLxMKqanbo=
> =yeaU
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
>

--
Michael Kirkham
www.muonics.com

Re: [Tile-dev] Progress bars

[Kevin W. <sw...@wo...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Forgive my ignorance--I downloaded this patch and am trying to apply it,
but I'm not getting the correct results. There actually seem to be
patches/diffs for several files here. Can someone outline the steps I
sohuld take to apply it?

Cheers,

Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw...@wo...

Michael Kirkham wrote:
|
| On Thu, 24 Feb 2005, Joe English wrote:
|
|> + Animation.  On Aqua and on some KDE themes (depending on
|>  the user's preferred eye candy level) thermometer-style
|>  progress bars have an additional pulsing/throbbing effect,
|>  presumably to let the user know that the program hasn't
|>  locked up even if the bar isn't otherwise moving.
|>  Michael Kirkham (muonics) has a patch that implements this
|>  on OSX.
|
|
| The latest version of the patch submitted a little while ago implements
| barber-pole style indeterminate progress bars for other themes except
| clam (any that doesn't already have its own progress widget, I think),
| too. Still needs a few tweaks, but it's functional.
|
| Indeterminate mode is obtained by setting -from and -to both to 0.  As
| long as both have value 0, it will animate a barberpole.  Change either
| to non-zero and it will switch to a regular progress bar (showing just a
| track if the "set" value is <= -from).
|
| If anyone wants to play with it the current patch is at:
|
|
https://sourceforge.net/tracker/index.php?func=detail&aid=1144673&group_id=11464&atid=311464

|
|
| --
| Michael Kirkham
| www.muonics.com
|
|
| -------------------------------------------------------
| SF email is sponsored by - The IT Product Guide
| Read honest & candid reviews on hundreds of IT Products from real users.
| Discover which products truly live up to the hype. Start reading now.
| http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
| _______________________________________________
| Tktable-tile-dev mailing list
| Tkt...@li...
| https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCH4xtJmdQs+6YVcoRAu5QAJwL8RvFzPvrKluiyVctKWWSRo3bRACgiOPQ
NsxIQ8fqe6O+TTLxMKqanbo=
=yeaU
-----END PGP SIGNATURE-----

Re: [Tile-dev] Progress bars

[Pat T. <pat...@us...>]

-----BEGIN PGP SIGNED MESSAGE-----

Joe English wrote:
| We've had a progress bar widget for a while now,
| but it's lacking documentation and is missing a few
| features.  Some things I can think of that it needs:
|
|
| + An "indeterminate" (aka "barber-pole") mode.  Currently
|   only the "determinate" (aka "thermometer") mode is supported.

muonics is currently dealing with this.

| Questions: Are the 'set' and 'get' methods really needed?
| They're equivalent to [$w configure -value] and [$w cget -value],
| respectively; or you can just access the linked -variable.

If I remember correctly, I basically just copied the interface from the
scale widget here. I see no problem rationalising the interface.

| The current implementation also has -font, -foreground,
| and -showvalue options (which don't do anything at the moment);
| and -command and -width options, which I don't think are
| needed either -- -width should be taken from the style,
| and -command isn't really useful for output-only widgets
| like this one.

As above. Its got these only because Tk's scale has them.

Pat Thoyts.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)

iQCVAwUBQh+IzmB90JXwhOSJAQFztgP/VIUc3ymniX9+BjeCK5UHbujfNH4FGmn/
rEdTrel5WW5SArmuglLIe1Gx2il1CFQGj9VAh6/hdY9OjKZvt8nj/v0u5WQxzNSW
6xn+CDYhnNHDS/zVzFbkROVzyGql0df0XDhJMS5OTjyvVmt2T/01IOjzvOhvpHZT
e7gxxlsC8kk=
=f93T
-----END PGP SIGNATURE-----

Re: [Tile-dev] Progress bars

[Brian G. <bgr...@mo...>]

Eric Boudaillier wrote:

> Joe English wrote:
>
>> Questions: Are the 'set' and 'get' methods really needed?
>> They're equivalent to [$w configure -value] and [$w cget -value],
>> respectively; or you can just access the linked -variable.
>
>
> Isn't there a general rule in tk that options are never changed
> internally, but only via configure subcommand ?
> This is at least what I have observed, with for example [entry].


Actually, if you look at a label widget, the -text option changes to 
match the -textvariable variable contents.

-Brian

-- 
-------------------------------------------------------------
--                 Model Technology Inc.                   --
-- 8005 SW Boeckman Road                  503.685.7000 tel --
-- Wilsonville, OR 97070 USA              503.685.0921 fax --
-------------------------------------------------------------
-- Technical support ............ mailto:su...@mo... --
-- Sales and marketing info ....... mailto:sa...@mo... --
-- Licensing .................... mailto:li...@mo... --
-- Home Page ........................ http://www.model.com --
-- AIM ........................................ bgriffin42 --
-------------------------------------------------------------

Re: [Tile-dev] Progress bars

[Eric B. <eri...@fr...>]

Joe English wrote:

> Questions: Are the 'set' and 'get' methods really needed?
> They're equivalent to [$w configure -value] and [$w cget -value],
> respectively; or you can just access the linked -variable.

Isn't there a general rule in tk that options are never changed
internally, but only via configure subcommand ?
This is at least what I have observed, with for example [entry].

> And if so, would a 'step' method be useful for indeterminate
> progress bars, where [$w step] is equivalent to:
> 
>     $w configure -value [expr {[$w cget -value] + [$w cget -stepsize]}]

[$w step] is cleaner.

-- 
-eric

Re: [Tile-dev] Progress bars

[Michael K. <mi...@mu...>]

On Thu, 24 Feb 2005, Joe English wrote:

> + Animation.  On Aqua and on some KDE themes (depending on
>  the user's preferred eye candy level) thermometer-style
>  progress bars have an additional pulsing/throbbing effect,
>  presumably to let the user know that the program hasn't
>  locked up even if the bar isn't otherwise moving.
>  Michael Kirkham (muonics) has a patch that implements this
>  on OSX.

The latest version of the patch submitted a little while ago implements 
barber-pole style indeterminate progress bars for other themes except clam 
(any that doesn't already have its own progress widget, I think), too. 
Still needs a few tweaks, but it's functional.

Indeterminate mode is obtained by setting -from and -to both to 0.  As 
long as both have value 0, it will animate a barberpole.  Change either to 
non-zero and it will switch to a regular progress bar (showing just a 
track if the "set" value is <= -from).

If anyone wants to play with it the current patch is at:

https://sourceforge.net/tracker/index.php?func=detail&aid=1144673&group_id=11464&atid=311464

--
Michael Kirkham
www.muonics.com

[Tile-dev] Progress bars

[Joe E. <jen...@fl...>]

We've had a progress bar widget for a while now,
but it's lacking documentation and is missing a few
features.  Some things I can think of that it needs:


+ An "indeterminate" (aka "barber-pole") mode.  Currently
  only the "determinate" (aka "thermometer") mode is supported.

  Note that "barber-pole" mode doesn't always look like
  a barber pole; Windows and GTK+ display a rectangle that
  bounces back and forth instead.

+ Linked -variables.  The current implementation has a
  -variable option, but it goes in the wrong direction --
  setting the progress bar updates the -variable, but
  setting the variable doesn't change the widget value.

+ Animation.  On Aqua and on some KDE themes (depending on
  the user's preferred eye candy level) thermometer-style
  progress bars have an additional pulsing/throbbing effect,
  presumably to let the user know that the program hasn't
  locked up even if the bar isn't otherwise moving.
  Michael Kirkham (muonics) has a patch that implements this
  on OSX.

Anyway, I've put up another strawmanpage describing a
possible interface:

    <URL: http://tktable.sourceforge.net/tile/doc/progress.html >

Questions: Are the 'set' and 'get' methods really needed?
They're equivalent to [$w configure -value] and [$w cget -value],
respectively; or you can just access the linked -variable.

And if so, would a 'step' method be useful for indeterminate
progress bars, where [$w step] is equivalent to:

    $w configure -value [expr {[$w cget -value] + [$w cget -stepsize]}]

or

    incr $linkedVariable $stepSize


Anything else missing?

The current implementation also has -font, -foreground,
and -showvalue options (which don't do anything at the moment);
and -command and -width options, which I don't think are
needed either -- -width should be taken from the style,
and -command isn't really useful for output-only widgets
like this one.


--Joe English

  jen...@fl...

[Tile-dev] ANN: VuMan 0.3; TkAqua Help Viewer 0.1

[Kevin W. <sw...@wo...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'd like to announce the release of VuMan 0.3 and TkAqua Help Viewer
0.1, two TkAqua applications that make use of the Tile widget set.

VuMan is a man page viewer; 0.3 is a major upgrade. The changes include
a rewritten interface, a new conversion engine, the ability to jump to
new man pages, the ability to configure font and print preferences, and
more.

For information, see http://www.wordtech-software.com/vuman.html

TkAqua Help Viewer is a help document viewer based on TkHTML, intended
primarily for Tk developers looking for a lightweight solution to deploy
help documents in their OS X/TkAqua applications.

For more information, see http://www.wordtech-software.com/tk-help.html

Both programs are released under the Tcl license.

- --
Cheers,

Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:sw...@wo...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCHQcqJmdQs+6YVcoRAtk4AJ4s3TjhYF5g+HNjTQZ84W2LXocjDQCeNj1i
o/sdZXl3diGXodJQrYaEm6Y=
=I/ba
-----END PGP SIGNATURE-----

Re: [Tile-dev] Combobox height

[Joe E. <jen...@fl...>]

> [Eric Boudaillier]
> > I just begin to use tile for a new application under Windows
> > 2000. I notice that ttk::entry and ttk::combobox are not the
> > same height: the combobox is taller, which don't give a nice
> > visual effect when both are mixed. I did not notice that on
> > other win32 application. This might be due to the selection rectangle.

Could be.  Is the combobox too tall, or is the entry widget
too short, as compared to other applications?

> > Is there a way to make them the same height ?

Please file a bug report at SF and I'll take a look at it
next time I boot into Windows.


[Jeff Hobbs]
> It may be that the combobox is sizing to the dropdown button
> next to it.

That's also possible.  Another possibility is that the
internal padding is different.  I haven't looked at it
too closely except on Windows XP, and even there most
of the measurements were determined by eyeballing other
Windows apps (not all of which are consistent either).

> If you have them in the same grid row, then you
> just need to set the resize parameters appropriately to get
> the effect you want.

The dropdown button is built into the combobox, it's not
a separate widget.  But using '-sticky ns' for entries and
comboboxes on the same row migh a good idea in any case,
since they are likely to have different natural heights
in other themes.  (In the default X11 theme, for instance,
comboboxes are _shorter_ than entries.  Probably ought to
fix that too...)


--Joe English

  jen...@fl...

Re: [Tile-dev] Combobox height

[Eric B. <eri...@fr...>]

Jeff Hobbs wrote:

>>I just begin to use tile for a new application under Windows 
>>2000. I notice that ttk::entry and ttk::combobox are not the 
>>same height: the combobox is taller, which don't give a nice 
>>visual effect when both are mixed. I did not notice that on 
>>other win32 application. This might be due to the selection rectangle.
>>
>>Is there a way to make them the same height ?
> 
> 
> It may be that the combobox is sizing to the dropdown button
> next to it.  If you have them in the same grid row, then you
> just need to set the resize parameters appropriately to get
> the effect you want.

Hi Jeff,

No, they are stacked vertically. I can use -uniform on each row,
but I really find combobox too tall.
The cool thing is that I just tried under XP, and they have the same
height.

-- 
-eric

RE: [Tile-dev] Combobox height

[Jeff H. <je...@Ac...>]

> I just begin to use tile for a new application under Windows 
> 2000. I notice that ttk::entry and ttk::combobox are not the 
> same height: the combobox is taller, which don't give a nice 
> visual effect when both are mixed. I did not notice that on 
> other win32 application. This might be due to the selection rectangle.
> 
> Is there a way to make them the same height ?

It may be that the combobox is sizing to the dropdown button
next to it.  If you have them in the same grid row, then you
just need to set the resize parameters appropriately to get
the effect you want.

Jeff

[Tile-dev] Combobox height

[Eric B. <be...@us...>]

Hello Tile'rs,

I just begin to use tile for a new application under Windows 2000.
I notice that ttk::entry and ttk::combobox are not the same height:
the combobox is taller, which don't give a nice visual effect when
both are mixed.
I did not notice that on other win32 application.
This might be due to the selection rectangle.

Is there a way to make them the same height ?

-- 
-eric

[Tile-dev] Re: [ tktable-Patches-1144673 ] Supporting animated progress bars (aqua, mainly)

[Michael K. <mi...@mu...>]

On Tue, 22 Feb 2005, Michael Kirkham wrote:

> I didn't see a way to pass information down from the general widget to where

D'oh.  I spaced.  Obviously there's a way since the from/to info has to 
get passed down. ;)  Should be able to pass down the timing too..

--
Michael Kirkham
www.muonics.com

[Tile-dev] Re: [ tktable-Patches-1144673 ] Supporting animated progress bars (aqua, mainly)

[Michael K. <mi...@mu...>]

> Comment By: Joe English (jenglish)
> Date: 2005-02-21 09:51
>
> This feature is definitely a good idea, and the programmatic
> interface seems reasonable (if I'm reading the patch right
> -- the progressbar automagically animates whenever the
> -value is between -from and -to noninclusive, if the current
> theme supports it, right?)

Yes.  It only generates the timer events if it's between -from and -to, 
noninclusive.  It should also cancel any pending timer event if you do a 
call to set which sets it outside the range.  Right now, it basically 
always schedules the next update for <theme's delay> since the last one - 
whether that update came from a set or through a timer event.

> A couple design issues:  should there be explicit widget
> commands to start and stop the animation instead?  I
> normally don't like magic DWIM behavior, but the one above
> seems like it will always do the right thing.

I didn't see a way to pass information down from the general widget to 
where the it's drawn in the theme.  That's part of the reason that the 
phase period is hard coded in aquaTheme.c rather than using the theme 
setting (which controls how often WidgetChanged notifications happen). 
There would need to be a way to do that to turn on/off animation, though I 
don't think turning it on and off programattically is necessary exactly 
(more below).

> There's an unwritten Tile policy that things like autorepeat
> delays and cursor blink rates are set on a system-wide basis
> instead of on a per-widget or per-theme basis.  (Actually,
> the current policy is that these things are just hardcoded
> to something hopefully reasonable, but the eventual intent
> is to allow end-users to control them globally).  Anyway, I
> think the animation refresh rate falls into this category.

I don't know that I agree, but I don't have enough information to 
disagree.  I haven't seen a lot of animated progress bars or barber poles 
other than on the mac, but my gut tells me it'd be a poor assumption that 
all of them animate with the same number of frames and same speed.  If one 
uses 5 frames where Aqua uses 4, and it's a hard coded delay, then it's 
Tile's may look right but animate slowly compared to other applications; 
or if it uses 2 it will animate really fast.

I don't really like that I hardcoded the phase period in aquaTheme.c, 
though; things get really weird if you change the theme's WidgetChanged 
notification period to not match the hard-coded phase period.

But I also think that having them all update at once would cause
unnecessary updates (which could be a problem over X/Windows).  Either
you'll wind up redrawing when a "set" call is made and then very shortly
after redrawing again because the global timer came up, or you'll skip a
timer based update and the redraw might come too late.  Unless, for
animated progress bars, you never redraw on a "set" but only when the
timer dings.  But -then- the non-theme-specific progress bar code would
have to have knowledge of whether or not it's animated in the particular
theme, and it sounds messy.  (You don't want to redraw non-animated
progress bars as if they're animated under X/Windows.)

> More notes: we also need to support "indeterminate" (aka
> "barber-pole")  style progress bars as well as animation.
> I'm not sure what a good interface would be -- BWidgets
> supports this, but the API doesn't make much sense to me.

I think a simple widget configuration option would be fine, provided 
there's a way to get that option down to the draw routine.

> I kind of like how the Gtk progress bar works - there's a
> separate boolean option "activity_mode" that specifies
> determinate / indeterminate mode, and a "pulse" method that
> increments the value by a fixed amount (specified by the
> "pulse_step" option).

Relating to the start/stop command..  I don't think the animation should 
be tied directly to the Tcl script.  If it's required to pulse to redraw, 
then it will animate poorly if the resolution is too low.  The length of 
the progress bar should be the indicator of how far along it is, while the 
animation should only show the user that the application hasn't hung.

However, something that might be good as an alternative would be to have 
some sort of timeout.  Have it keep animating like it does now without any 
"set" calls, but if after 5-10 seconds (or some configurable setting) 
there have been no "set" calls then it can stop animating.  You'd want it 
long enough that the animation is smooth, but short enough that the script 
would need to say "I'm still alive" every now and then so the animation 
isn't lieing to the user.

> Another option would be to just let indeterminate progress
> bars spin on their own without any programmatic intervention
> (you can get this behaviour on Aqua with progressanim.patch
> by using kThemeIndeterminateBar instead of kThemeProgressBar).

I think either letting them spin freely or having a "keep-alive" timeout 
would be okay, but having the animation tied directly to "set" would be 
bad.  A keep-alive would be easy to cheat, though: if the application is 
not entering the event loop (which has to happen for animation to occur), 
pinging it isn't going to get the animation running.  If it is entering 
the event loop, then one could just send continuous
"after 100 ping_progress" calls that aren't tied in any way to the actual 
thing they're doing that the progress bar is supposed to reflect.  So it 
seems kind of pointless.  If the script falls into an infinite loop with 
no updates, the animation is going to stop whether there's some sort of 
keep-alive or not.  (That and the rest of the GUI.)

--
Michael Kirkham
www.muonics.com

[Tile-dev] Re: [MACTCL] Problems building Tile from CVS

[Michael K. <mi...@mu...>]

Tile expects to have access to the private Tcl/Tk headers, some of which 
aren't installed.  It should be able to find them if the sources are still 
where they were installed from, I think.  Do you still have the sources 
there?

In any case, a quick temporary workaround would be to edit the makefile to 
add to the include directories, or copy the needed private headers into 
the appropriate framework's Headers directory.

There's a NO_PRIVATE_HEADERS #define that can be used to avoid using some 
of the private headers, but it doesn't look like that has any affect on 
whether or not tkMacOSX.h (and thus tkInt.h) gets included.  I always 
build with the sources still present (everything gets built from what's 
checked out of CVS, including Tcl/Tk, instead of what's installed on the 
system) and don't run up against this.

On Sat, 19 Feb 2005, Kevin Walzer wrote:

> Date: Sat, 19 Feb 2005 05:20:34 -0500
> From: Kevin Walzer <sw...@wo...>
> To: tc...@li...
> Subject: [MACTCL] Problems building Tile from CVS
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> Trying to update Tile from CVS to reflect some recent improvements and
> can't get it built. I ran configure with these arguments per the wiki:
>
> ~   ./configure \
> ~         --prefix=/usr/local --libdir=/Library/Tcl \
> ~         --with-tcl=/Library/Frameworks/Tcl.framework \
> ~         --with-tclinclude=/Library/Frameworks/Tcl.framework/Headers \
> ~         --with-tk=/Library/Frameworks/Tk.framework \
> ~         --with-tkinclude=/Library/Frameworks/Tk.framework/Headers \
> ~         --enable-threads
>
> The build crashes with this error:
>
> In file included from macosx/aquaTheme.c:32:
> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkMacOSX.h:19:19:
> tkInt.h: No such file or directory
> In file included from
> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkMacOSX.h:32,
> ~                 from macosx/aquaTheme.c:32:
> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkPlatDecls.h:107:
> error: parse error before '*' token
> /Library/Frameworks/Tk.framework/Versions/8.4/Headers/tkPlatDecls.h:152:
> error: parse error before '*' token
> make: *** [aquaTheme.o] Error 1
>
>
> I did apply Daniel's patch from CVS that is included in the BI distro.
>
> Any advice?
>
> - --
> Cheers,
>
> Kevin Walzer, PhD
> WordTech Software--Open Source Applications and Packages for OS X
> http://www.wordtech-software.com
> http://www.smallbizmac.com
> http://www.kevin-walzer.com
> mailto:sw...@wo...
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFCFxLyJmdQs+6YVcoRAoWEAJ0QuK7j6yfO+TcSaE83I65ahfWnIQCfa4Vw
> ZzxO5ieDYeMKoWF09UcUsPc=
> =qGSd
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
>

--
Michael Kirkham
www.muonics.com