tktable-tile-dev — Discussion about tile development

Re: [Tile-dev] Progress bar

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

Donal K. Fellows wrote:

> Kevin Walzer wrote:
>
>> You were kind enough last month to provide the sample code above to help
>> me get started with the Tile progress bar widget. I've tweaked the code
>> for use in the application I'm working on and it works
>> beautifully...except that I don't know how to back out of the loop I've
>> set up. It cycles for an indefinite period of time (which is exactly
>> what I wanted it to do :-)). Destroying the window containing the
>> progress bar doesn't help because the every and update procedures are
>> still chugging in memory, and I get error messages that loop at the same
>> frequency of the code. And I've looked for a way to kill the procedure
>> itself, by using after cancel, but nothing seems to work. Can you give
>> me any direction in *closing* the loop? Thank you so much.
>
>
> OK, you need a cancel-able [every]. :^) Once you've got this though,
> it's easy to add a <Destroy> binding to clean things up. Here's some
> code (it's also on the wiki at http://wiki.tcl.tk/every of course.)
>
>   proc every {ms body} {
>      global everyId
>      if {$ms eq "cancel"} {
>         after cancel $everyId($body)
>         unset everyId($body)
>      } else {
>         set everyId($body) [after $ms [info level 0]]
>         uplevel #0 $body
>      }
>   }
>   every 250 {Update .p 10}
>   bind .p <Destroy> {every cancel {Update .p 10}}
>
> I'm sure this sort of thing could be improved upon fairly easily, but it
> should at least inspire...


This is a particularly insidious area.  It's possible to end up with 
rouge background task if  you're not careful.  I suggest adding a couple 
lines:

    proc every {ms body} {
       global everyId
       if {$ms eq "cancel"} {
          if {[info exists everyId($body)]} {
              after cancel $everyId($body)
              unset everyId($body)
          }
       } else {
          if {[info exists everyId($body)]} {
             # This makes sure there is only 1 every for this body
             after cancel $everyId($body)
          }
          set everyId($body) [after $ms [info level 0]]
          uplevel #0 $body
       }
    }

Consider this testcase:
    every 250 {Update .p 10}
    every 250 {Update .p 10}


-Brian
"Once bitten, twice shy"

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

[Donal K. F. <don...@ma...>]

Kevin Walzer wrote:
> You were kind enough last month to provide the sample code above to help
> me get started with the Tile progress bar widget. I've tweaked the code
> for use in the application I'm working on and it works
> beautifully...except that I don't know how to back out of the loop I've
> set up. It cycles for an indefinite period of time (which is exactly
> what I wanted it to do :-)). Destroying the window containing the
> progress bar doesn't help because the every and update procedures are
> still chugging in memory, and I get error messages that loop at the same
> frequency of the code. And I've looked for a way to kill the procedure
> itself, by using after cancel, but nothing seems to work. Can you give
> me any direction in *closing* the loop? Thank you so much.

OK, you need a cancel-able [every]. :^) Once you've got this though,
it's easy to add a <Destroy> binding to clean things up. Here's some
code (it's also on the wiki at http://wiki.tcl.tk/every of course.)

   proc every {ms body} {
      global everyId
      if {$ms eq "cancel"} {
         after cancel $everyId($body)
         unset everyId($body)
      } else {
         set everyId($body) [after $ms [info level 0]]
         uplevel #0 $body
      }
   }
   every 250 {Update .p 10}
   bind .p <Destroy> {every cancel {Update .p 10}}

I'm sure this sort of thing could be improved upon fairly easily, but it
should at least inspire...

Donal.

Re: [Tile-dev] Progress bar

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

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

Pat Thoyts wrote:


|
| The progress bar widget has a get and a set subcommand which take the
| value to set the progress bar too. For instance, if we define the
| range of the widget as 0 - 100, then a [$progressbar set 50] will
| cause the bar to fill half the widget.
| eg:
|  pack [tprogress .p -from 0 -to 100]
|  .p set 50
|
| If you want to read the value, either [.p get] or [.p cget -value]
| will do it.
| So to cycle:
|   proc every {ms body} {after $ms [info level 0]; eval $body}
|   proc Update {w interval} {
|      set v [expr {[$w get] + $interval}]
|      if {$v > [$w cget -to]} {
|        set v [$w cget -from]
|      }
|      $w set $v
|   }
|   every 250 {Update .p 10}
|

Pat,

You were kind enough last month to provide the sample code above to help
me get started with the Tile progress bar widget. I've tweaked the code
for use in the application I'm working on and it works
beautifully...except that I don't know how to back out of the loop I've
set up. It cycles for an indefinite period of time (which is exactly
what I wanted it to do :-)). Destroying the window containing the
progress bar doesn't help because the every and update procedures are
still chugging in memory, and I get error messages that loop at the same
frequency of the code. And I've looked for a way to kill the procedure
itself, by using after cancel, but nothing seems to work. Can you give
me any direction in *closing* the loop? Thank you so much.

Regards,
Kevin


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

iD8DBQFBfEbLJmdQs+6YVcoRAgEyAJ9CzyyK5rNcQn37HLrTJsqB1Y3XRwCfZOr+
0Vbupnk89bmiX9qEyEOZt7U=
=SdTK
-----END PGP SIGNATURE-----

Re: [Tile-dev] Tile label disabled on Win32

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

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

Joe English wrote:
| Joi Osoy wrote:
|>Is it possible to have the text appear disabled in
|>labels on Win32? By disabled I mean with the
|>sunken-like relief it has on Win32 (see "Uninstall"
|>button in the image below :
|>
|
| There's some code that tries to do this, but it's currently
| #ifdef'ed out since I couldn't get DrawThemeText() to work properly.
|
| Hopefully someone with a better understanding of (or more
| patience with :-) the Win32 API can get this working.
| Search for BROKEN_TEXT_ELEMENT in win/xpTheme.c for
| a starting point.

Done for Windows classic (non-XP themed). In XP themed windows, disabled
text just looks grey - not embossed. So XP looks ok at the moment.

Pat Thoyts
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQCVAwUBQXwtOGB90JXwhOSJAQHGQgP/XPmKzGOWng2BhlVnbM+KewoZHWzaPP2j
HKRg3kaXy3ZCOG2lpAxbxoAGv/nq11kba52gEOxqp01RhjJLoh4pmW9f+2QGewG/
eIEEBKaBeC5cwEr2zFc9W39NWTcuGGZakoaCJByRE9TDHJQoWVxLqbIMgI0ui+Qc
YsC7MeAN/b8=
=WAmx
-----END PGP SIGNATURE-----

Re: [Tile-dev] Tile label disabled on Win32

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

Joi Osoy wrote:

> Is it possible to have the text appear disabled in
> labels on Win32? By disabled I mean with the
> sunken-like relief it has on Win32 (see "Uninstall"
> button in the image below :
>
> http://www.degutis.com/computers/dotnet/dotnet%20tcpip%20uninstall%20disabled
> .JPG
>
> If not, are there any plans to do so?


There's some code that tries to do this, but it's currently
#ifdef'ed out since I couldn't get DrawThemeText() to work properly.

Hopefully someone with a better understanding of (or more
patience with :-) the Win32 API can get this working.
Search for BROKEN_TEXT_ELEMENT in win/xpTheme.c for
a starting point.


--Joe English

  jen...@fl...

Re: [Tile-dev] Tile label disabled on Win32

[Daniel L. <dan...@gm...>]

Hi Brett

> does the .label configure -state disabled work for
> you?

No, because it just paints the text gray, without giving it the native disabled
look and feel for the text (kind of sunken, see the picture I mentioned)


> --- Joi Osoy <jo...@ya...> wrote:
> 
> > Hi,
> >
> > Is it possible to have the text appear disabled in
> > labels on Win32? By disabled I mean with the
> > sunken-like relief it has on Win32 (see "Uninstall"
> > button in the image below :
> >
> >
> http://www.degutis.com/computers/dotnet/dotnet%20tcpip%20uninstall%20disabled.JPG
> >
> > If not, are there any plans to do so?
> >
> > Thanks!
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> > protection around
> > http://mail.yahoo.com
> >
> >
> >
> -------------------------------------------------------
> > This SF.net email is sponsored by: IT Product Guide
> > on ITManagersJournal
> > Use IT products in your business? Tell us what you
> > think of them. Give us
> > Your Opinions, Get Free ThinkGeek Gift Certificates!
> > Click to find out more
> >
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> > _______________________________________________
> > Tktable-tile-dev mailing list
> > Tkt...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
> >
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
>

Re: [Tile-dev] Tile label disabled on Win32

[Brett S. <bre...@ya...>]

does the .label configure -state disabled work for
you?

--- Joi Osoy <jo...@ya...> wrote:

> Hi,
> 
> Is it possible to have the text appear disabled in
> labels on Win32? By disabled I mean with the
> sunken-like relief it has on Win32 (see "Uninstall"
> button in the image below :
> 
>
http://www.degutis.com/computers/dotnet/dotnet%20tcpip%20uninstall%20disabled.JPG
> 
> If not, are there any plans to do so?
> 
> Thanks!
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> http://mail.yahoo.com 
> 
> 
>
-------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide
> on ITManagersJournal
> Use IT products in your business? Tell us what you
> think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates!
> Click to find out more
>
http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
>
https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
> 

Re: [Tile-dev] Tile label disabled on Win32

[Donal K. F. <don...@ma...>]

Joi Osoy wrote:
> Is it possible to have the text appear disabled in
> labels on Win32? By disabled I mean with the
> sunken-like relief it has on Win32 (see "Uninstall"
> button in the image below :

Yes. Just set the -state option on the button to "disabled" and the
button should adopt the correct disabled look for its theme.

Donal.

[Tile-dev] Tile label disabled on Win32

[Joi O. <jo...@ya...>]

Hi,

Is it possible to have the text appear disabled in
labels on Win32? By disabled I mean with the
sunken-like relief it has on Win32 (see "Uninstall"
button in the image below :

http://www.degutis.com/computers/dotnet/dotnet%20tcpip%20uninstall%20disabled.JPG

If not, are there any plans to do so?

Thanks!

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

RE: [Tile-dev] The Background Problem

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

Joe English wrote:
> Notebook widgets still don't look quite right under
> Windows XP -- more precisely, the stuff inside a notebook 
> doesn't look quite right.  The pane should have a subtle 
> gradient, from white at the top to a very light gray at the 
> bottom.  The Tile notebook can draw this part, but widgets 
> like checkbuttons, radiobuttons, and labelframes, inside a 
> notebook pane are still drawn with the standard background.

With Joe's assistance on some magic styling for the
frames, I was able to get the single frame that I use
as the notebook pane container to adopt the gradient.
Attached is a pic showing this.

This is fine in general - but I have issues where the
guys here complained because on another pane we make
use of a panedwindow.  That uses the standard bg, which
is subtle but visible against the gradient bg.

> I'm still not entirely sure how to solve this, but it's 
> pretty clear that the theme engine will need to treat 
> background elements differently from other elements.  
> Background elements are already something of a special case: 
> every layout has to include one, and it has to be the first 
> element drawn.  (This is only mentioned in a comment buried 
> in the middle of the source code...)

I wonder what effect named colors will have on this as
well?

> Then if someone can figure out exactly how 
> DrawThemeParentBackground() is supposed to work in XP, maybe 
> we can get notebooks to look right too...

I did send that patch that I tried before regarding the
use of DTPB().  It didn't really work, or rather have
visible effect (it compiled and ran just fine) ... :(

Jeff

RE: [Tile-dev] Compatibility options

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

> The Tile widgets are intended to be mostly compatible with 
> their core counterparts; the main difference is that the new 
> widgets have fewer options.  (For example: -activebackground 
> and -disabledforeground are subsumed by [style map]; custom 
> layouts make things like -indicatoron unnecessary; and things 
> like -container, -colormap, and -visual for frames have been 
> left out on purpose.)

I want to make sure that we are careful when transitioning
to styles that we don't ignore the simplicity evident in
Tk through its options.  On the one hand, we want to allow
for theming and styles for improved consistency, OTOH, we
don't want to make it annoyingly complex to have slight
variations (like bg) for single widget instances.
Background is the most common, but it isn't the only case,
and not just for labels (which was mentioned below), but
entries would commonly need this as well (as well as
comboboxes and related things that might derive from the
entry widget).

> There are a few compatibility options that really ought to be 
> "real" ones.  For example, you ought to be able to set the 
> -font, -foreground and -background on [ttk::label]s; this 
> currently has no effect.  The reason for this is, if these 
> are "real" options, they have to have NULL default values so 
> the theme settings will normally be used.  But, if they have 
> a NULL default and you use [ttk::labels] in place of core 
> [label]s, BWidgets and other megawidget packages break.

And to what lengths does one have to go to fix these
older packages?

> You can turn them off now by compiling with -DNO_COMPAT;
> I'd like to make this the default in the next release.

>     + 0.5 release: Compatibility options disabled, but may be
>       reenabled at 'configure'-time.  'tile::*' and 't*'
>       aliases still present but deprecated.
> 
>     + 0.6 release: Compatibility options completely gone.
>       Add selected options back as "real" ones based on
>       feedback from the 0.5 release, or provide equivalent
>       functionality in a different way (see for example
>       demos/repeater.tcl).  'tile::*' and 't*' aliases removed.

I would like to push this out one more release.  As I
mentioned on the chat, I think the value is that you will
be abel to pull more people into tile if the hill to climb
is a hill, not a mountain.

As somewhat related example was my transition to the tile
combobox from the bwidgets combo.  Since the tile cb does
not use numeric indexing (which I hopefully convinced Joe
is a good idea), it took an hour just to convert one cb in
an app over to tile.  I did this to make use tile entries
throughout - which themselves required 0 effort beyond the
namespace import.  My point is though that if we disallow
the compat stuff, it may raise the bar to transition any
app over to tile, discouraging others from making the move.

Then again, the counterpoint was that these options are
going to disappear sometime, so it may be better to force
the conversion once, rather than twice in smaller steps.

However, I currently favor the 2 smaller steps, since we
all know that just a few option add's clean up a lot of Tk
L&F, and that in itself is hard enough to make people do.

;)

Jeff

Re: [Tile-dev] The Background Problem

[Pat T. <pa...@zs...>]

Joe English <jen...@fl...> writes:

>
>Then if someone can figure out exactly how DrawThemeParentBackground()
>is supposed to work in XP, maybe we can get notebooks to look
>right too...

I looked into this a bit. DrawThemeParentBackground is handling
matters at a window level. The prototype is
 DrawThemeParentBackground(HWND hwnd, HDC hdc, RECT *prc);
The idea is that if the theme element has any transparent bits, you
ask the parent window to redraw itself before drawing the themed
element. With HWNDs this is fine as 
 HWND GetParent(HWND hwnd);
returns the parent window. We don't have anything available at the
point where we are drawing elements to request a redraw of the parent
element. Even with this, we would have to construct a clipping region
- we only want the parent to redraw the are covered by _this_ element
after all.

Tile currently always draws elements into a pixmap, so clipping isn't
a problem perhaps - we won't erase siblings. The parent would need to
be able to be offset though. And we need to be able to identify all
ancenstor elements that may be covered by transparent regions in the
current element.


-- 
Pat Thoyts
PGP Fingerprint: 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD

Re: [Tile-dev] Button layout

[Joi O. <jo...@ya...>]

> > I am building a vertical button box and would like
> my
> > buttons to have their text left-justified.
> 
> Do the buttons have images too, or just text?

They have text and images

[snip]

> There are three things that affect where the label
> appears:
[snip]

> (2) The label element has an "-anchor" option that
> determines
> where to place the label inside the parcel.  For
> [ttk::label]
> widgets, you can set -anchor on the widget itself. 
> On other
> widgets like checkbuttons, -anchor is a
> compatibility option,
> so it can only be set on the style:
> 
> 	style default ButtonBox.Button -anchor w

Ahh, that was it.  Using the style to set -anchor did
the trick!

Thanks a lot!





__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Tile-dev] Button layout

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

Joi Osoy wrote:
>
> I am building a vertical button box and would like my
> buttons to have their text left-justified.

Do the buttons have images too, or just text?


> It works fine with regular Tk buttons, but not when
> using tile toolbuttons. I have tried -justify left but
> it does not work (still centered)
>
> I have also tried defining a new layout but no luck
> either


There are three things that affect where the label appears:
(1) The -side and -sticky options in the layout specification
determine where the label element is placed within the parcel.
So you could use:

    style layout Buttonbox.Button {
    	Button.border -children {
	    Button.focus -children {
	    	Button.padding -children {
		    Button.label -side left -sticky w   <== here
		}
	    }
	}
    }

(-sticky nwse is the default, and if -side is omitted it means
"use the entire parcel").

Or, if you want the focus ring to wrap around the label
instead of being inside the border:

    style layout Buttonbox.Button {
    	Button.border -children {
	    Button.padding -children {
		Button.focus -side left -sticky w -children {
		    Button.label
		}
	    }
	}
    }


(2) The label element has an "-anchor" option that determines
where to place the label inside the parcel.  For [ttk::label]
widgets, you can set -anchor on the widget itself.  On other
widgets like checkbuttons, -anchor is a compatibility option,
so it can only be set on the style:

	style default ButtonBox.Button -anchor w

(The way things are organized, there is a choice between getting the
focus ring in the right place or having a working -anchor option.
The first is more important, which is why -anchor isn't a "real"
widget option.)

(3) If there are multiple lines, the text element "-justify" option
determines how they line up.  As with "-anchor", only label widgets
have this option, for checkbuttons &c it can only be set in the style.

Other notes: the label element is actually a combination of the
"text" and "image" elements.  "-wraplength" and "-justify" are
text element options, "-anchor" and "-compound" are handled by
the label element.


--Joe English

  jen...@fl...

[Tile-dev] Button layout

[Joi O. <jo...@ya...>]

Hello

I am building a vertical button box and would like my
buttons to have their text left-justified.

It works fine with regular Tk buttons, but not when
using tile toolbuttons. I have tried -justify left but
it does not work (still centered) 

I have also tried defining a new layout but no luck
either   

style layout Toolbutton {
  Toolbutton.border -children {
    Toolbutton.padding -children {
      Toolbutton.label -justify left -align left
    }
  }
}

Any ideas ?  Is there a simpler way to do this that I
am missing ? 

Thanks!



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Tile-dev] The Background Problem

[Donal K. F. <don...@ma...>]

Joe English wrote:
> I'm still not entirely sure how to solve this, but it's pretty
> clear that the theme engine will need to treat background elements
> differently from other elements.
[...]

Part of the fix is probably for background elements to know where they
are relative to the background of the parent widget. (IIRC, many
toolkits use window-less widgets - gadgets in old Motif terminology,
lightweight components in Java AWT terminology - where getting the
background right is much easier.)

Donal.

[Tile-dev] The Background Problem

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

Notebook widgets still don't look quite right under
Windows XP -- more precisely, the stuff inside a notebook
doesn't look quite right.  The pane should have a subtle
gradient, from white at the top to a very light gray at
the bottom.  The Tile notebook can draw this part, but
widgets like checkbuttons, radiobuttons, and labelframes,
inside a notebook pane are still drawn with the standard
background.

This is a symptom of a more general problem: the correct
background for a widget may depend on what it's contained in,
but the theme engine doesn't have access to this information.
This is especially apparent on Mac OSX.

I'm still not entirely sure how to solve this, but it's pretty
clear that the theme engine will need to treat background elements
differently from other elements.  Background elements are already
something of a special case: every layout has to include one, and
it has to be the first element drawn.  (This is only mentioned
in a comment buried in the middle of the source code...)

As a first step towards a fix, I plan to make TTK_CreateLayout()
automatically include the background element, instead of listing
it explicitly in each layout specification.  This will mostly impact
programs that have defined custom layouts; they'll need to remove
the background element.

Then if someone can figure out exactly how DrawThemeParentBackground()
is supposed to work in XP, maybe we can get notebooks to look
right too...


--Joe English

  jen...@fl...

[Tile-dev] Treeview widget in CVS

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

The treeview widget is now in CVS.

Horizontal scrolling isn't implemented yet, and I'm
not really happy with the column sizing behavior
(it really needs to be smarter about setting the initial
column widths, for one).

Performance seems OK, but I've only tested it on ridiculously
fast machines.  If anyone finds speed issues, let me know;
there's definitely room for optimization.


--Joe English

  jen...@fl...

Re: [Tile-dev] Compatibility options

[Brett S. <bre...@ya...>]

> 
> In more detail:
> 
>     + 0.5 release: Compatibility options disabled,
> but may be
>       reenabled at 'configure'-time.  'tile::*' and
> 't*'
>       aliases still present but deprecated.
> 
>     + 0.6 release: Compatibility options completely
> gone.
>       Add selected options back as "real" ones based
> on
>       feedback from the 0.5 release, or provide
> equivalent
>       functionality in a different way (see for
> example
>       demos/repeater.tcl).  'tile::*' and 't*'
> aliases removed.
> 
> 

I'd like to see them stay in a little longer
personally. I think people will be slowly moving over
to Tile widgets (i.e. not everyone is going to jump
ship right away). Hence, when these late comers look
at what they have to do in order to "port" their code
to Tile, they might be reluctant because of the
changes needed.

My $0.02,

    --brett

[Tile-dev] Compatibility options

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

The Tile widgets are intended to be mostly compatible with
their core counterparts; the main difference is that the new
widgets have fewer options.  (For example: -activebackground
and -disabledforeground are subsumed by [style map]; custom
layouts make things like -indicatoron unnecessary; and things
like -container, -colormap, and -visual for frames have been
left out on purpose.)

In order to test just how compatible the new widgets really are,
Tile currently includes all of the the missing options as
"compatibility options": they can be set and queried, but
have no effect.  This way you can swap out the core widgets
with a single [namespace import] withough having to extensively
modify existing code.

Compatibility options were always intended to be an interim
measure, solely for testing purposes during development.
This strategy has worked OK so far; you can [namespace
import -force tile::*] without _immediately_ breaking
everything.  In fact, many applications don't break for
several minutes if you do this.

There are a few compatibility options that really ought to be
"real" ones.  For example, you ought to be able to set the
-font, -foreground and -background on [ttk::label]s; this
currently has no effect.  The reason for this is, if these are
"real" options, they have to have NULL default values so the
theme settings will normally be used.  But, if they have a NULL
default and you use [ttk::labels] in place of core [label]s,
BWidgets and other megawidget packages break.

Now that an integration strategy has been worked out,
(separate tk::* and ttk::* namespaces), and it looks like
the [namespace import] technique *won't* usually be used
at global scope, I think it's time to phase compatibility 
options out.

You can turn them off now by compiling with -DNO_COMPAT;
I'd like to make this the default in the next release.

In more detail:

    + 0.5 release: Compatibility options disabled, but may be
      reenabled at 'configure'-time.  'tile::*' and 't*'
      aliases still present but deprecated.

    + 0.6 release: Compatibility options completely gone.
      Add selected options back as "real" ones based on
      feedback from the 0.5 release, or provide equivalent
      functionality in a different way (see for example
      demos/repeater.tcl).  'tile::*' and 't*' aliases removed.


Sound OK?


--Joe English

  jen...@fl...

Re: [Tile-dev] Tree API -- selection and focus

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

Bryan Oakley wrote:
> Joe English wrote:
> > A <<TreeviewSelect>> event is generated in all cases
> > (except for [$treeview selection]), even if the selection
> > hasn't actually changed (e.g., adding an item that was
> > already selected still generates the event).
>
> What's the advantage to generating the event when the selection command
> is called, versus only generating it when the selection changes? I'm not
> sure I see it, though I'm betting you've recently thought about this
> more than I have. All things being equal, I think I'd rather have it
> only be generated when the selection actually changes.

What I was thinking is, [$tree selection] is usually called
because of some user action (clicking on an item, navigating
with the arrow keys, etc.), and the <<TreeviewSelect>> binding
is more of a response to the user gesture than it is to the
selection changing.

Also, the listbox widget works this way: with -selectmode single,
clicking the currently-selected item generates a <<ListboxSelect>>
event, even though the selection doesn't change.  (Conversely,
if the application calls [$l selection set] it *doesn't* generate
an event).

What you suggest makes sense though -- generate the event when
(and only when) the selection changes.  I'll implement it that
way initially, we can change it later if warranted.

The widget will probably also need a -command or -browsecommand
callback option; applications can use that to respond to
user gestures.  (The class bindings are getting fairly complicated
and [$tree identify] remains a hairball; the way it stands now
it won't be as easy for applications to define widget instance
bindings as it is with the Listbox, so the Treeview will
need to provide an easy way to do this.)



--Joe English

  jen...@fl...

Re: [Tile-dev] Tree API -- selection and focus

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

Joe English wrote:
> A <<TreeviewSelect>> event is generated in all cases
> (except for [$treeview selection]), even if the selection
> hasn't actually changed (e.g., adding an item that was
> already selected still generates the event).
> 

What's the advantage to generating the event when the selection command 
is called, versus only generating it when the selection changes? I'm not 
sure I see it, though I'm betting you've recently thought about this 
more than I have. All things being equal, I think I'd rather have it 
only be generated when the selection actually changes.

[Tile-dev] Tree API -- selection and focus

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

For consistency with other parts of Tk, it would make sense
to just clone the listbox widget selection command.

On the other hand, that's not a very good match for the tree
widget: the 'set' and 'clear' subcommands operate on ranges,
and tree items don't have a natural linear ordering.
(There are several reasonable linear orders for items, but
it's not always obvious what's in the range "between"
two items, especially if $first and $last don't have the
same parent).  Besides that, I've always found the listbox
selection command somewhat clunky.

I propose the following instead:

    $tree selection --
	Returns the list of selected items.  The list is sorted
	according to the preorder traversal order (that is,
	it doesn't matter in which order items were added
	to the selection).

    $tree selection add $items --
    	Add $items to the selection.

    $tree selection remove $items --
    	Remove $items from the selection.

    $tree selection set $items --
    	$items becomes the new selection.

    $tree selection toggle $items --
    	Toggle the selected state of each item in $items.

And possibly:

    $tree selection clear --
    	Deselect everything.
	This is the same as '$tree selection set {}'.

A <<TreeviewSelect>> event is generated in all cases
(except for [$treeview selection]), even if the selection
hasn't actually changed (e.g., adding an item that was
already selected still generates the event).


Notable differences from [$listbox selection]:

    + There's no separate [$tree curselection] command;
      [$tree selection] with no additional arguments does the same thing.

    + Unlike [$listbox selection set $first $last], [$tree selection set $l]
      *does* affect the selection state of items not mentioned in $l.
      [$listbox selection set] is closer to [$tree selection add].

    + There's no selection anchor.

    + [$tree selection toggle] is included so the common operation
      of toggling the selection state of a single item can be
      done atomically.


There is also a distinguished "focus" item; this is where the
location cursor is drawn, and is the target of most keyboard
operations.  [$treeview focus] returns the current focus item,
and [$treeview focus $item] sets it.

The listbox widget uses an "activate" command and an "active"
index for this concept.  I'm trying to be more consistent with
terminology in the Tile package, and "active" means "the thing
under the mouse pointer" in other contexts; hence "focus" instead
of "active".

The widget ought to support both "single" and "multiple"
selection modes ("browse" and "extended" seem like unnecessarily
subtle distinctions).  I'd rather not add a -selectmode option
if it can be avoided; another way to support this is with distinct
sets of bindtags (which in turn can be selected by setting
the -class option).  Will try both and see how it works out...


--Joe English

  jen...@fl...

RE: [Tile-dev] Tree API draft round 2

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

> Something I just learned recently wrt column resizing on Windows, 
> double-click in the column separator will resize the column to the 
> maximum width of the data in the column, e.g. a double-click 
> on the name 
> column will resize the column to the longest name in the list.  
> Apparently this  has been around in Windows for a long time.
> 
> Once you start using it, you'll find it damn convenient!

This behavior is already in treectrl.  Note that you have
to size the right size for all data in the column, not
just the visible data.

Jeff

Re: [Tile-dev] Tree API draft round 2

[Griffin, B. <bgr...@mo...>]

Something I just learned recently wrt column resizing on Windows, 
double-click in the column separator will resize the column to the 
maximum width of the data in the column, e.g. a double-click on the name 
column will resize the column to the longest name in the list.  
Apparently this  has been around in Windows for a long time.

Once you start using it, you'll find it damn convenient!

-Brian

Joe English wrote:

>
> Bryan Oakley wrote:
> > Joe English wrote:
> > > (I've looked at how other toolkits/widgets implement interactive
> > > resizing, and I'm quite convinced that you *really* don't want to
> > > do anything too clever here.  The ones that try to be clever
> > > are confusing to the user, get confused themselves, or both.
> > > If anyone knows of an exception, let me know...)
> >
> > Mozilla's newsreader has an example of fixed width columns. I have a
> > column with a image (to designate junk mail status), and if I drag the
> > right edge it's the same as if I dragged the left edge (ie: the column
> > to the left grows rather than growing the fixed-width column). It makes
> > sense, but again, it's not strictly necessary.
>
> Hm.  Just checked Evolution, it might also be an exception.
> Dragging a column separator resizes the column immediately
> to the left, columns to the left of that one stay the same size,
> and columns to the right grow and shrink proportionally
> so everything still fits.  Also subject to minimum-width and
> fixed-width column constraints.  This seems better.  (Rhythmbox,
> OTOH, is doing something I can't quite figure out...)
>
>
> --Joe English
>
>   jen...@fl...
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Tktable-tile-dev mailing list
> Tkt...@li...
> https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev
>

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