tktable-tile-dev — Discussion about tile development

Re: [Tile-dev] treeview bindings

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

On Wed, 16 Mar 2005, Bryan Oakley wrote:

> I assume that [+] is configurable via a style? In the app I'm working on I'd 
> like it to be a right- or down-pointing triangle.

Don't know about it being style-able, but I believe nem was working on 
using disclosure triangles under the Aqua theme.

--
Michael Kirkham
www.muonics.com

Re: [Tile-dev] treeview column widths...

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

Bryan Oakley wrote:

> My first attempt at creating a treeview results in a columns that stop
> short of filling the entire width of the widget. Is there a way to
> configure a particular column to stretch to fill the width, or do I have
> to do the math myself and set each column individually?

I really don't like the current column-sizing behavior,
but am not entirely sure how to make it do the Right Thing.

I've been using a utility routine that takes a treeview widget,
a dictionary of weights, and an overall width, and configures
each display column to have width proportional to its weight.
This has worked OK for the use cases I've encountered, but
still doesn't feel quite right.

Another option is to use -minsize, -weight, and (possibly) -uniform
options as in [grid columnconfigure].

When I get a chance I'll check in some Tcl code implementing
different sizing behaviors for people to play with; once we
figure out what the right approach is we can bake it in.


--Joe English

  jen...@fl...

Re: [Tile-dev] treeview bindings

[Bryan O. <br...@bi...>]

Joe English wrote:
> Bryan Oakley wrote:
> 
>>In playing with the treeview I see that no matter where I click on an
>>item, it opens up that item. That doesn't seem right to me. Don't most
>>trees only open if you click on the indicator, or double-click on the
>>text or image?
> 
> 
> That does seem to be the usual convention.
> 
> 
>>Would this be a better set of bindings?
> 
> 
> Not for me, I can't hit the tiny little expand control
> with the mouse :-), but yeah, it'd be more in line with
> common conventions.  Will fix.
> 

Did you notice the double-1 binding too? That allows you to double-click 
on the entire line. I'll agree, that little [+] is a bit hard to hit.

I assume that [+] is configurable via a style? In the app I'm working on 
I'd like it to be a right- or down-pointing triangle.

BTW: awesome work on the tree widget. It shows a lot of promise.

Re: [Tile-dev] treeview bindings

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

Bryan Oakley wrote:
>
> In playing with the treeview I see that no matter where I click on an
> item, it opens up that item. That doesn't seem right to me. Don't most
> trees only open if you click on the indicator, or double-click on the
> text or image?

That does seem to be the usual convention.

> Would this be a better set of bindings?

Not for me, I can't hit the tiny little expand control
with the mouse :-), but yeah, it'd be more in line with
common conventions.  Will fix.


--Joe English

  jen...@fl...

[Tile-dev] treeview bindings

[Bryan O. <br...@bi...>]

In playing with the treeview I see that no matter where I click on an 
item, it opens up that item. That doesn't seem right to me. Don't most 
trees only open if you click on the indicator, or double-click on the 
text or image?

Would this be a better set of bindings?

49a50
 > bind Treeview	<Double-1>		{ tile::treeview::ToggleFocus %W }
184c185,189
< 	item { BrowseTo $w $where ; ToggleFocus $w }
---
 > 	item { BrowseTo $w $where
 > 	    if {$detail eq "Treeitem.indicator"} {
 > 		ToggleFocus $w
 > 	    }
 > 	}

[Tile-dev] treeview column widths...

[Bryan O. <br...@bi...>]

My first attempt at creating a treeview results in a columns that stop 
short of filling the entire width of the widget. Is there a way to 
configure a particular column to stretch to fill the width, or do I have 
to do the math myself and set each column individually?

Here's an example that should illustrate the problem

     package require tile

     wm geometry . 800x200
     ttk::treeview .tree -columns {modified created}
     .tree heading "\#0" -text "Column 1"
     .tree heading modified -text "Column 2"
     .tree heading created -text "Column 3"
     pack .tree -side top -fill both -expand y

Re: [Tile-dev] New paned window widget

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

On Mon, 14 Mar 2005, Brian Griffin wrote:

> What I meant by "my experience" is that I looked at several non-Tk applications and this is the behavior I saw. I believe most, if not
> all, were 3 pane style layout, where two of the panes would grow/shrink proportionally to their starting size.

FWIW, the paned windowing setup I use with MIB Smithy works like this:

1. There's a top pane and a bottom pane.
2. Each of these are split into left/right.
3. Each can be shown or hidden by the user by selecting options from the 
View menu.
4. When you resize the window, each pane is given exactly the same 
percentage of the window it had before the resize.

So if you have the sash halfway between the left and right edges 
(left/right panes each currently have 50% of the window) and you maximize 
the window, they still each have half the width of the window.  If it's 
1/4 the window's width in from the left before resize, it'll be 1/4 of the 
new size in from the left after resize.

Is this right?  I dunno, but that's what I do currently. :)  As long as 
you don't have to go through hoops to prevent resizing a window smaller 
from completely obscuring a pane and its sash (a la Tk 8.4.*) I think I'm 
fine with whatever method is used.

--
Michael Kirkham
www.muonics.com

Re: [Tile-dev] New paned window widget

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Joe English wrote:
<blockquote
 cite="mid...@dr..."
 type="cite">
  <pre wrap="">Brian Griffin wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Joe English wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">   + Each pane has a -weight option, which is an integer value specifying
     the relative amount to shrink or expand the pane when the
     overall widget is resized. [...]
      </pre>
    </blockquote>
    <pre wrap="">My experience has been that paned views, where there are more than one
pane that was not fixed, the panes would grow or shrink proportional to
their initial size when the window was resized. You can't get this
behavior with -weight.  It's a subtle difference.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Hm.  When experimenting with it, I came to the opposite
conclusion -- it seemed to feel better to me if the extra
space were distributed equally across all panes regardless
of their initial size.  (With one exception: if a pane is
completely collapsed, then it should stay collapsed even
if the overall window grows).  OTOH, I was experimenting
with a contrived example, so I can't say for sure.

By far the most common cases are 2-pane layouts, and 3-pane
layouts with one vertical sash and one horizontal sash;
where in both cases there is exactly one stretchable pane
and the other(s) have fixed size.  Next most common are
"studio"-type applications with multiple, multiply-nested,
user-configurable pane layouts; I confess I really don't
know what's reasonable there.
  </pre>
</blockquote>
<br>
What I meant by "my experience" is that I looked at several non-Tk
applications and this is the behavior I saw. I believe most, if not
all, were 3 pane style layout, where two of the panes would grow/shrink
proportionally to their starting size.<br>
<br>
-Brian<br>
<br>
<pre class="moz-signature" cols="72">-- 
-------------------------------------------------------------
--                 Mentor Graphics Corp.                   --
-- 8005 SW Boeckman Road                  503.685.7000 tel --
-- Wilsonville, OR 97070 USA              503.685.0921 fax --
-------------------------------------------------------------
-- Technical support ............ <a class="moz-txt-link-freetext" href="mailto:su...@mo...">mailto:su...@mo...</a> --
-- Sales and marketing info ....... <a class="moz-txt-link-freetext" href="mailto:sa...@mo...">mailto:sa...@mo...</a> --
-- Licensing .................... <a class="moz-txt-link-freetext" href="mailto:li...@mo...">mailto:li...@mo...</a> --
-- Home Page ........................ <a class="moz-txt-link-freetext" href="http://www.model.com">http://www.model.com</a> --
-------------------------------------------------------------
</pre>
</body>
</html>

Re: [Tile-dev] New paned window widget

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

Brian Griffin wrote:
> Joe English wrote:
> >    + Each pane has a -weight option, which is an integer value specifying
> >      the relative amount to shrink or expand the pane when the
> >      overall widget is resized. [...]
>
> My experience has been that paned views, where there are more than one
> pane that was not fixed, the panes would grow or shrink proportional to
> their initial size when the window was resized. You can't get this
> behavior with -weight.  It's a subtle difference.

Hm.  When experimenting with it, I came to the opposite
conclusion -- it seemed to feel better to me if the extra
space were distributed equally across all panes regardless
of their initial size.  (With one exception: if a pane is
completely collapsed, then it should stay collapsed even
if the overall window grows).  OTOH, I was experimenting
with a contrived example, so I can't say for sure.

By far the most common cases are 2-pane layouts, and 3-pane
layouts with one vertical sash and one horizontal sash;
where in both cases there is exactly one stretchable pane
and the other(s) have fixed size.  Next most common are
"studio"-type applications with multiple, multiply-nested,
user-configurable pane layouts; I confess I really don't
know what's reasonable there.


> On the other hand,
> weight has never been intuitive to me because it's non-linear. Maybe if
> it was a real number it would make more sense.

The ttk::paned widget does use a linear algorithm for resizing,
just that it's linear over the ring of integers modulo total_weight :-)


> >    + There is no -opaqueresize option; opaque resize is always enabled.
> >      As long as performance is not an issue (which it doesn't appear
> >      to be), this is better usability-wise than deferred resize.
>
> This _is_ important when working with slow devices, say VNC over a slow
> or congested network. Window managers still support this kind of option,
> I think for the same reason.

Others have also asked for this, and on further investigation
it turns out that the current implementation _does_ have performance
problems, especially on slow X servers.  These look fixable,
but even then it might still be too slow, so I'll probably add
deferred resize after all.  This will probably be an application-
or desktop-wide option.

> >    + Instead of separate 'paneconfigure' and 'panecget' methods,
> >      the 'pane' method is a generalized accessor like the
> >      ttk::notebook and ttk::treeview widgets use.
>
> I like this notion, but it does not match the core Tk paradigm.

Agreed, it's a departure from the usual Tk idiom, but
I think in this case it's worth it to start a new idiom.
A dictionary is just way more convenient to work with than
a list of 5/2-tuples, and it replaces a pair of nearly-redundant
commands with a single more useful one.  Also, it's not _entirely_
without precedent; [font configure] works this way too.

See also: http://sourceforge.net/mailarchive/message.php?msg_id=9616698


> >~ Default -weight.
> >I'm not sure if the default -weight should be 0 or 1. [...]
> As you point out, a default of 1 is almost never right, therefore, I
> would go with "-stretch last". :-)

If all panes have -weight 0 it's the same effect as if
they all had -stretch last; and since the common case
has exactly one stretchable pane, using -weight 0 as
the default makes the most sense.



--Joe English

  jen...@fl...

Re: [Tile-dev] New paned window widget

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

Joe English wrote:

>Just checked in a new paned window widget, ttk::paned.
>Documentation here:
>
>    <URL: http://tktable.sourceforge.net/tile/doc/paned.html >
>
>The API is designed to match the ttk::notebook widget.
>Basic usage is similar to the core panedwindow and the BWidget
>PanedWindow, but there are a few differences in the details.
>
>~ Differences from the core panedwindow:
>
>    + Each pane has a -weight option, which is an integer value specifying
>      the relative amount to shrink or expand the pane when the
>      overall widget is resized.  This is more flexible and, to me,
>      more intuitive, than '-stretch {first|last|never|always}'
>      as in the Tk 8.5 panedwindow.
>  
>

My experience has been that paned views, where there are more than one 
pane that was not fixed, the panes would grow or shrink proportional to 
their initial size when the window was resized. You can't get this 
behavior with -weight.  It's a subtle difference.  On the other hand, 
weight has never been intuitive to me because it's non-linear. Maybe if 
it was a real number it would make more sense.

>    + There is no -opaqueresize option; opaque resize is always enabled.
>      As long as performance is not an issue (which it doesn't appear
>      to be), this is better usability-wise than deferred resize.
>  
>

This _is_ important when working with slow devices, say VNC over a slow 
or congested network. Window managers still support this kind of option, 
I think for the same reason.  There may not be slow machines any more, 
but networks are still slow for a lot of reasons. This is something the 
application user needs control over since the application author cannot 
predict what the operating environment will look like. Also, you cannot 
predict the complexity of the panes contents.  It may be that a redraw 
takes seconds rather than msec., so you need to give the application 
authors this control.

Note that the Tk panedwindow has both <Button-1> and <Button-2>  
bindings for sash motion so that the user has a choice of opaque or not.

>    + Instead of separate 'paneconfigure' and 'panecget' methods,
>      the 'pane' method is a generalized accessor like the
>      ttk::notebook and ttk::treeview widgets use.
>  
>

I like this notion, but it does not match the core Tk paradigm.  This 
makes teaching Tcl/Tk a bit more complicated, unless we go back and 
retrofit all Tk widgets adding "item configure" and "item cget", etc.

>    + Panes do not have '-before' or '-after' options.  Instead,
>      you can use the [$pw insert] method to specify the initial
>      position or move an existing pane to a new position.
>      (See below for rationale).
>  
>

Yea!  I've never liked the -before & -after as configure options since 
their values are meaningless once the operation is complete.

>
>A couple open questions:
>
>~ Shoving sashes:
>
>In the 8.4 panedwindow, if there are three or more panes and
>the user attempts to drag a sash over an adjacent one, the
>adjacent sash gets "shoved" up or down to make room.
>
>This seemed like a neat idea to me, and that's what I initially
>implemented, but after playing with it some I'm not so sure anymore.
>It's too easy to "overshoot" when dragging a sash, and end up
>shrinking a pane that you didn't intend to shrink.  It feels
>better to me if sash movement is bounded by the adjacent sashes.
>Then again, I'm extraordinarily clumsy with a mouse so this
>could just be me.
>
>You can try it out both ways (change the SHOVE_SASHES #define
>in paned.c); let me know what you think.
>  
>

I think this depends on the application. This should be configurable 
when used.

>~ Default -weight.
>
>I'm not sure if the default -weight should be 0 or 1.
>
>If all panes have -weight 0, then the last pane stretches
>or shrinks to make up the difference when the widget is resized.
>This is the same as the 8.4 behavior [*], and is the Right Thing
>more often than not.  On the other hand, sometimes it's the Wrong
>Thing entirely (a good bad example is tkchat with the "Users Online"
>pane visible -- here you want the _first_ pane to shrink and stretch
>while the last one stays fixed size).
>
>If all panes have -weight 1, OTOH, each pane stretches and shrinks
>equally.  While this is never completely wrong, it's almost
>never exactly right either.
>
>Since it's easy enough for the program to specify appropriate
>weights, this isn't a huge issue.
>
>[*] Except that the ttk::paned window handles conditions
>where the last pane(s) are completely shrunk better.
>  
>

As you point out, a default of 1 is almost never right, therefore, I 
would go with "-stretch last". :-)

>
>~ Stuff that might get added later:
>
>    + "collapse buttons" on sashes, like in the Mozilla sidebar
>  
>

I was contemplating adding this to the Tk panedwindow. It should also be 
possible to bind a menu and balloon help to the sash.

>    + Active / pressed feedback for sashes
>    + Ugly sash separators with a square handle in the classic theme
>
>Stuff that was considered and rejected:
>
>    + -minsize and -maxsize pane options.
>    + proportional resize of all panes when a sash is dragged
>
>
>Anyway, please try it out and pound on it to shake out the bugs.
>(Stuff to look for: horizontal vs. vertical botches, inappropriate
>behavior when there are no panes, geometry propagation glitches.)
>
>
>--Joe English
>
>  jen...@fl...
>
>
>-------------------------------------------------------
>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
>
>  
>

-- 
-------------------------------------------------------------
--                 Mentor Graphics Corp.                   --
-- 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 --
-------------------------------------------------------------

[Tile-dev] Feature Request: combobox text field mousewheel binding

[Mark G. <du...@ya...>]

Another feature which IMHO should be part of tile.
When the text field has the focus, moving the mouse wheel should change the selection. Windows XP combos work this way.
 
Thanks,
 
Mark

		
---------------------------------
Do you Yahoo!?
 Yahoo! Mail - Find what you need with new enhanced search. Learn more.

[Tile-dev] New paned window widget

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

Just checked in a new paned window widget, ttk::paned.
Documentation here:

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

The API is designed to match the ttk::notebook widget.
Basic usage is similar to the core panedwindow and the BWidget
PanedWindow, but there are a few differences in the details.

~ Differences from the core panedwindow:

    + Each pane has a -weight option, which is an integer value specifying
      the relative amount to shrink or expand the pane when the
      overall widget is resized.  This is more flexible and, to me,
      more intuitive, than '-stretch {first|last|never|always}'
      as in the Tk 8.5 panedwindow.

    + There is no -opaqueresize option; opaque resize is always enabled.
      As long as performance is not an issue (which it doesn't appear
      to be), this is better usability-wise than deferred resize.

    + Instead of separate 'paneconfigure' and 'panecget' methods,
      the 'pane' method is a generalized accessor like the
      ttk::notebook and ttk::treeview widgets use.

    + Panes do not have '-before' or '-after' options.  Instead,
      you can use the [$pw insert] method to specify the initial
      position or move an existing pane to a new position.
      (See below for rationale).


A couple open questions:

~ Shoving sashes:

In the 8.4 panedwindow, if there are three or more panes and
the user attempts to drag a sash over an adjacent one, the
adjacent sash gets "shoved" up or down to make room.

This seemed like a neat idea to me, and that's what I initially
implemented, but after playing with it some I'm not so sure anymore.
It's too easy to "overshoot" when dragging a sash, and end up
shrinking a pane that you didn't intend to shrink.  It feels
better to me if sash movement is bounded by the adjacent sashes.
Then again, I'm extraordinarily clumsy with a mouse so this
could just be me.

You can try it out both ways (change the SHOVE_SASHES #define
in paned.c); let me know what you think.

~ Default -weight.

I'm not sure if the default -weight should be 0 or 1.

If all panes have -weight 0, then the last pane stretches
or shrinks to make up the difference when the widget is resized.
This is the same as the 8.4 behavior [*], and is the Right Thing
more often than not.  On the other hand, sometimes it's the Wrong
Thing entirely (a good bad example is tkchat with the "Users Online"
pane visible -- here you want the _first_ pane to shrink and stretch
while the last one stays fixed size).

If all panes have -weight 1, OTOH, each pane stretches and shrinks
equally.  While this is never completely wrong, it's almost
never exactly right either.

Since it's easy enough for the program to specify appropriate
weights, this isn't a huge issue.

[*] Except that the ttk::paned window handles conditions
where the last pane(s) are completely shrunk better.


~ Stuff that might get added later:

    + "collapse buttons" on sashes, like in the Mozilla sidebar
    + Active / pressed feedback for sashes
    + Ugly sash separators with a square handle in the classic theme

Stuff that was considered and rejected:

    + -minsize and -maxsize pane options.
    + proportional resize of all panes when a sash is dragged


Anyway, please try it out and pound on it to shake out the bugs.
(Stuff to look for: horizontal vs. vertical botches, inappropriate
behavior when there are no panes, geometry propagation glitches.)


--Joe English

  jen...@fl...

[Tile-dev] Re: [MACTCL] Bug with TkAqua, panedwindow and ::ttk::notebook

[Jim I. <ji...@ap...>]

This is probably another instance of: 940117.  Basically, Tk doesn't =20
care about drawing widgets if their parents are not mapped, because =20
on X11 & windows the drawing isn't going to show up anyway.  But =20
since subwindows are an entire fiction on Mac OS X, if you tell a =20
widget to draw it will show up regardless of whether it's parent is =20
mapped or not.

One option is to go through all the Draw* routines and make sure that =20=

they aren't drawn if their parents are not mapped.  But I am worried =20
this will mess up pixmaps.  And it seems kind of unclean, it would be =20=

better to figure out a way to do this down in the Mac OS X layer.  =20
That would be more symmetrical with what happens on the other =20
platforms...

Jim

On Mar 11, 2005, at 6:02 AM, Alastair Davies wrote:

> The following script (and instructions) shows up a problem on MacOS =20=

> X (only)
> with using the panedwindow and Tile notebook widgets.  Items drawn =20
> on a
> canvas within a panedwindow on a notebook tab are often visible, =20
> even if the
> tab is not selected.
>
> I _think_ the culprit here is the panedwindow widget on TkAqua, =20
> since we
> have seen similar behaviour using the BWidget notebook, as well as =20
> the Tile
> notebook, but I can't say for sure. (The Tile notebook is such a HUGE
> improvement, we switched as soon as we could!)
>
> Source the following script from Wish Shell (either using the =20
> Terminal or
> the Console, it doesn't matter):
>
> package require tile
> ttk::notebook .n
> pack .n
> panedwindow .n.p1
> .n add .n.p1 -text "Here be p1"
> frame .n.p1.f -width 300 -height 300
> .n.p1 add .n.p1.f -sticky nesw
> pack [canvas .n.p1.f.c] -fill both -expand true
> .n.p1.f.c create rect 40 50 80 90
> panedwindow .n.p2
> .n add .n.p2 -text "I am p2"
> frame .n.p2.f -width 300 -height 300
> .n.p2 add .n.p2.f -sticky nesw
> pack [canvas .n.p2.f.c] -fill both -expand true
> .n.p2.f.c create rect 60 70 100 110
>
> Now shuffle the notebook tabs up and down, leave p1 uppermost and =20
> enter the
> command
>
> .n.p2.f.c create oval 120 120 140 150
>
> The oval is visible, apparently on p1, despite being drawn on p2.  =20
> Shuffling
> the pages again will correct the situation.
>
> In our application, we plot results to several notebook pages
> simultaneously, so we see this a lot. Any advice would be much =20
> appreciated.
> I'll file a bug if confirmed.
>
> Kind regards,
> Alastair
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real =20
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dclick
> _______________________________________________
> Tcl-mac mailing list
> Tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac

[Tile-dev] Bug with TkAqua, panedwindow and ::ttk::notebook

[Alastair D. <ala...@si...>]

The following script (and instructions) shows up a problem on MacOS X =
(only)
with using the panedwindow and Tile notebook widgets.  Items drawn on a
canvas within a panedwindow on a notebook tab are often visible, even if =
the
tab is not selected.

I _think_ the culprit here is the panedwindow widget on TkAqua, since we
have seen similar behaviour using the BWidget notebook, as well as the =
Tile
notebook, but I can't say for sure. (The Tile notebook is such a HUGE
improvement, we switched as soon as we could!)

Source the following script from Wish Shell (either using the Terminal =
or
the Console, it doesn't matter):
=20
package require tile
ttk::notebook .n
pack .n
panedwindow .n.p1
.n add .n.p1 -text "Here be p1"
frame .n.p1.f -width 300 -height 300
.n.p1 add .n.p1.f -sticky nesw
pack [canvas .n.p1.f.c] -fill both -expand true
.n.p1.f.c create rect 40 50 80 90
panedwindow .n.p2
.n add .n.p2 -text "I am p2"
frame .n.p2.f -width 300 -height 300
.n.p2 add .n.p2.f -sticky nesw
pack [canvas .n.p2.f.c] -fill both -expand true
.n.p2.f.c create rect 60 70 100 110

Now shuffle the notebook tabs up and down, leave p1 uppermost and enter =
the
command

.n.p2.f.c create oval 120 120 140 150

The oval is visible, apparently on p1, despite being drawn on p2.  =
Shuffling
the pages again will correct the situation.

In our application, we plot results to several notebook pages
simultaneously, so we see this a lot. Any advice would be much =
appreciated.
I'll file a bug if confirmed.

Kind regards,
Alastair

[Tile-dev] Re: [MACTCL] Re: tile patch

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

Jim Ingham wrote:
>
> Have you played around with whether the double buffering is
> necessary?  The Aqua Tk code does this sometimes, but that is more
> legacy and lack of time to see what we could rip out.  Mac OS X
> already double buffers all drawing, so if you are also drawing into a
> pixmap, everything ends up getting drawn three times.


Experiments show that this is still necessary on X11
and Windows to avoid "blinking".  We can get by without
it OK on X11 on really fast displays, but on older 
hardware and remote $DISPLAYs it's still helpful.
Haven't tried on OSX though; it's worth a shot.

Note that there might be coordinate system issues --
all of the aquaTheme element *Draw routines assume
that the point (0,0) in QuickDraw coordinates corresponds 
to the top left corner of the widget after caling
"SetGWorld(TkMacOSXGetDrawablePort(d), 0);".  
If the Drawable d is the Tk_WindowId of the widget 
instead of an off-screen pixmap, that won't be the 
case anymore.


--Joe English

  jen...@fl...

[Tile-dev] Re: [MACTCL] Re: tile patch

[Jim I. <ji...@ap...>]

Have you played around with whether the double buffering is  
necessary?  The Aqua Tk code does this sometimes, but that is more  
legacy and lack of time to see what we could rip out.  Mac OS X  
already double buffers all drawing, so if you are also drawing into a  
pixmap, everything ends up getting drawn three times.

Jim

On Mar 6, 2005, at 8:22 AM, Joe English wrote:

>
>
> [Cc: tkt...@li... ]
>
>
> On tcl-mac, Mats Bengtsson wrote:
>>
>> I've put a patch for the tile project at:
>> http://sourceforge.net/tracker/index.php? 
>> func=detail&aid=1157739&group_id=114
>> 64&atid=311464
>>
>> This was supposed to be a fix for the pyjamas stripe alignment  
>> glitches
>> on 10.2 but doesn't work. This is either due to an Apple bug or
>> me misunderstanding something fundamental here:
>> *    Apple docs says:
>> *      "ApplyThemeBackground aligns patterns based on the  
>> rectangle passed in
>>  the bounds parameter. This
>> *    is in contrast to the function SetThemeBackground (page 78),  
>> which alig
>> ns patterns based on the
>> *    origin of the current port."
>> */
>>
>> but this doesn't work like this. The pattern offset is always the  
>> same
>> independent of the top of rectangle.
>>
>> Anyone has any ideas...
>
>
> The tile widgets draw everything on a pixmap, (an "offscreen
> graphics world" in QuickDraw terminology) then blit the pixmap
> contents to the screen when finished.
>
> So the origin of the Drawable passed to an element *Draw() routine
> will always be the origin of the widget, not the top-level window,
> and the pinstripes won't always line up.
>
> I don't have any good ideas how to fix this.
>
>
>
> --Joe English
>
>   jen...@fl...
>
>
> -------------------------------------------------------
> 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

RE: [Tile-dev] Feature Request: checkbutton config -justify

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

> Just fixed in CVS, the default for the Label and Text element 
> -justify options is now "left".  This is different from core 
> Tk checkbuttons and radiobuttons, which default to -anchor 
> center / -justify center, but Tile checkbuttons already default to (the 
> equivalent of) "-anchor left" anyway; "-justify left" is arguably 
> a more sensible default too.

I agree that this is a better default, but do we have a definitive
place for "compatability awareness" where things like this should
be listed?

Jeff

Re: [Tile-dev] Feature Request: checkbutton config -justify

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

Mark Garvey wrote:
>
> The subject line says it all. If however the default for multiline
> text in a checkbutton was "left", I could live with  it :-)

Just fixed in CVS, the default for the Label and Text element
-justify options is now "left".  This is different from core Tk
checkbuttons and radiobuttons, which default to -anchor center /
-justify center, but Tile checkbuttons already default to (the 
equivalent of) "-anchor left" anyway; "-justify left" is arguably 
a more sensible default too.

I didn't add a "-justify" option to the checkbutton itself,
but if you need that level of per-widget customization
see demos/snidget.tcl for one way to do it.


--Joe English

  jen...@fl...

[Tile-dev] ANN: TkPNG 0.5 (initial announcement)

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

Well I'm feeling too impatient for the clt announcement to show up so I 
can copy and paste and too lazy to write a full announcement again, but... 
Aqua and Tile users especially will probably be interested in TkPNG - an 
extension that adds PNG photo image support to Tcl/Tk, with full range of 
bit depths and color types (including alpha support).  This is not based 
on libpng, but is a lightweight decoder implementation written 
specifically for Tk.  The only dependency, other than Tcl/Tk its self, is 
on zlib.

http://mini.net/tcl/13760

However, be aware that there's a Tk Aqua bug that will cause it to crash 
if you use images with alpha channels in bevel buttons (labels and 
non-bevel buttons should be okay).  It's not TkPNG's fault - it's the same 
with Img.  Tile doesn't crash if you use alpha images in its buttons, but 
due to a -different- Tk Aqua bug images (with or without alpha) turn to 
white rectangles in disabled widgets.  Both of those are open bugs in the 
Tk tracker, but I just thought I should mention it in case someone tried 
an image with alpha in a bevel button for the first time and thought the 
crash was my fault. ;)

--
Michael Kirkham
www.muonics.com

[Tile-dev] Feature Request: checkbutton config -justify

[Mark G. <du...@ya...>]

The subject line says it all. If however the default for multiline text in a checkbutton was "left", I could live with  it :-)
 
Thanks again for a life(I mean product)-saving extension!

		
---------------------------------
Celebrate Yahoo!'s 10th Birthday! 
 Yahoo! Netrospective: 100 Moments of the Web 

[Tile-dev] Interference from X resource database

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

Tile-enabled applications running under GNOME and KDE
tend to have mixed-up background colors -- most widgets
use the Tile theme background, but others end up with the
background color from the GNOME or KDE system settings.

Here's what's going on:

Neither GTK+ nor Qt use the X resource database themselves,
but both GNOME and KDE have an option to apply their system
color scheme to "legacy" (i.e., Motif, Xaw, and Tk) applications
by munging the X resource database [*].

This doesn't work very well even for standard Tk applications,
(see http://bugzilla.gnome.org/show_bug.cgi?id=130299),
but it's especially bad for Tile apps since only a few
widgets have a -background option.  The ones that do
end up with one color, and the ones that don't end up
with a different one.

Possible solutions:

(1) Remove the -background option from all widgets.

This is undesirable, since for some widgets (entry widgets,
labels, possibly frames) it's sensible and useful to
control the background on a per-widget basis.

(2) Ignore the X resource database.

This is actually my preferred solution.  Unfortunately Tk doesn't
provide a way to do this -- it automagically reloads the RESOURCE_MANAGER
property after [option clear], and there's no way to convince it
not to.  Other possibilities:

(2a) Write a TIP to add this feature to Tk.

Doable, and probably a good idea in any event, but this
won't help Tk 8.4 any.

(2b) Rewrite the Tile widgets to ignore the option database.

Undesirable; the [option] command is still useful even if the
X resource database isn't.

(3) Use different database class and database names.

That is, instead of using -background/background/Background
as the option name/database name/database class, use
something like -background/frameColor/FrameColor,
so '*background' and *Background settings in the xrdb
won't have any effect.

#3 looks like the best approach so far.  Also: things like
labels and frames should have a different default background
than things like entry widgets and listboxes; the Tile widgets
could/should use different dbnames for these instead of
a single "Background" class for everything.

[*] More notes:

In typical KDE fashion, there is a user preference to disable
XRDB munging -- if you can find it.  In typical GNOME fashion,
there is not.  Debian GNOME users won't see this effect, since
the Debian package maintainers wisely patch this feature out.
CDE and VUE do something similar:
<URL: http://tcl.sourceforge.net/faqs/tk/#run/cde >

--Joe English

  jen...@fl...

[Tile-dev] Re: tile patch

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

[Cc: tkt...@li... ]


On tcl-mac, Mats Bengtsson wrote:
> 
> I've put a patch for the tile project at:
> http://sourceforge.net/tracker/index.php?func=detail&aid=1157739&group_id=114
> 64&atid=311464
> 
> This was supposed to be a fix for the pyjamas stripe alignment glitches
> on 10.2 but doesn't work. This is either due to an Apple bug or
> me misunderstanding something fundamental here:
> *	Apple docs says:
> *      "ApplyThemeBackground aligns patterns based on the rectangle passed in
>  the bounds parameter. This
> *	is in contrast to the function SetThemeBackground (page 78), which alig
> ns patterns based on the
> *	origin of the current port."
> */
> 
> but this doesn't work like this. The pattern offset is always the same
> independent of the top of rectangle.
> 
> Anyone has any ideas...


The tile widgets draw everything on a pixmap, (an "offscreen 
graphics world" in QuickDraw terminology) then blit the pixmap 
contents to the screen when finished.

So the origin of the Drawable passed to an element *Draw() routine
will always be the origin of the widget, not the top-level window, 
and the pinstripes won't always line up.

I don't have any good ideas how to fix this.



--Joe English

  jen...@fl...

[Tile-dev] Progress bars -- braindump

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

Long-winded, half-thought-out rationale for why 
the ttk::progressbar currently works the way it does:

As mentioned before, from the program's POV there
seem to be three main modes of operation: "determinate",
"indeterminate", and "autoincrement".  The difference between
the latter two is that "indeterminate" mode can show
how fast something is going, where with "autoincrement"
mode you just want to make something move on the screen at
a steady rate until the operation completes.

On the user feedback side, there are many different variations;
"thermometer" mode, "barberpole" mode, and "cylon" mode
are the main ones.  OSX adds another twist in that there is
additional animation even in  "thermometer" mode (this is what
the ttk::progressbar -phase option is there for).

Sometimes a progress bar isn't a bar at all -- many OSX
programs use a spinning "asynchronous progress indicator" or
"chasing arrows" when space is tight.  Web browsers often use
animated throbbers that also serve a branding function (e.g.,
the throbbing Netscape/MSIE/Mozilla/Firefox logo in the upper
right corner).  Many Windows applications use simple
animations like the "copying files" or "moving to trash"
dialogs.

Animations and branded throbbers aside, Windows applications
tend to use "cylon" feedback for both indeterminate and autoincrement
modes, and never use "barberpole" feedback.  OSX apps on the other
hand don't seem to use "cylon" feedback at all; from what
I've seen they only use "thermometer" and constant-rate
"barberpole" feedback (at least in bar-shaped progress bars).

So: in keeping with the idea of separating function from
appearance, the ttk::progressbar implementation leaves
it up to the theme whether to use "cylon" or "barberpole"
feedback.  It bounces the "*.pbar" element (if present) back 
and forth based on the current -value for cylons, and it 
autoincrements the -phase option for barberpoles and auxilliary 
animation.

All of the current themes use cylon feedback for both
indeterminate and autoincrement modes, except for the
Aqua theme, which uses barberpole feedback for both,
and the step theme, which uses a bizarre combination of
both -- not because it should, but because it can.
(Actually this is mostly because I needed a way to
check if -phase updates were working correctly...)


--Joe English

  jen...@fl...

Re: [Tile-dev] Progress bars

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

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

"Cylon block" is an excellent name :-)  I'm going to
start calling it that instead.

But yeah, with -mode indeterminate -value 0, the block
probably shouldn't appear.  Possibly the trough/track 
shouldn't be visible either.

> 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.

That doesn't sound right -- it worked for me on Aqua when
I last tried it.  Maybe I broke something between then
and now...

> Oh.  And why "ttk::progress::start $w" instead of "$w start"?

Judgment call, mostly; it just seemed to fit together
better that way.

We could make these widget methods instead; it just seemed
better to me to handle this at the script level.  Conversely,
we could also handle the -phase-autoincrement logic at
the script level, but since -phase is part of the interface
between the widget and the theme I think it's better that
the scripting layer not have to worry about it.

More on this next message.


--Joe English

  jen...@fl...

Re: [Tile-dev] Progress bars

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

On Mon, 28 Feb 2005, Michael Kirkham wrote:

> 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.

Oh.  And why "ttk::progress::start $w" instead of "$w start"?

--
Michael Kirkham
www.muonics.com