tktable-tile-dev — Discussion about tile development

Re: [Tile-dev] Release plans

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

Oscar Bonilla wrote:
> On Oct 3, 2006, at 9:43 AM, Jeff Hobbs wrote:
> > problem.  Noone is playing nag-meister.  Another issue is that noone =
is
> > pointing out a "critical" need for 8.5 - feature-wise or company =20
> > backing.  So why nag?
>=20
> So what's the value of 8.5? I mean, if every single feature that is =20
> existent in 8.5 has been back-ported to 8.4. What's 8.5's=20
> raison d'=EAtre?

Exactly - that is the best response so far for Larry's other question.  =
It has
no raison d'=EAtre currently.  It is waiting for Ttk inclusion (which I =
have
mostly sandboxed, but is totally lacking doc and needs more tests) and
(possibly) oo.  Each is a feature-defining release point.  8.5 also has
{expand} and dict, but dict is backported and {expand} is not =
release-defining
in itself.  There are of course many more changes already:
	http://wiki.tcl.tk/10630

While they may fill up a whole, it's nothing earth-shattering to many.  =
8.5
without Tile and/or oo might as well not be (IOW: can wait).

Jeff

Re: [Tile-dev] Release plans

[Damon C. <da...@tc...>]

    Good question.  It's the Windows Vista of Tcl.  Minus the=20
eye-candy.  That was thrown out too.  Wait, it's the Windows 98 of Tcl. =20
Huzzah! 0-]

Damon


> So what's the value of 8.5? I mean, if every single feature that is =20
> existent in 8.5 has been back-ported to 8.4. What's 8.5's raison d'=EAt=
re?
>
>  =20

Re: [Tile-dev] Release plans

[Oscar B. <ob...@bi...>]

On Oct 3, 2006, at 9:43 AM, Jeff Hobbs wrote:

> Larry McVoy wrote:
>> It seems to me that the tcl team needs someone in the role of
>> release manager / Chief Nag-Meister.  To try and get things
>> moving along. Is there anyone doing that role now?
>
> That depends.  I am release manager, but not nag-meister, and maybe =20=

> that's the
> problem.  Noone is playing nag-meister.  Another issue is that =20
> noone is
> pointing out a "critical" need for 8.5 - feature-wise or company =20
> backing.  So
> why nag?

So what's the value of 8.5? I mean, if every single feature that is =20
existent in 8.5 has been back-ported to 8.4. What's 8.5's raison d'=EAtre?=


--
pgp fingerprint: BC64 2E7A CAEF 39E1 9544  80CA F7D5 784D FB46 16C1

Re: [Tile-dev] Release plans

[<lm...@bi...>]

On Tue, Oct 03, 2006 at 09:43:48AM -0700, Jeff Hobbs wrote:
> Larry McVoy wrote:
> > It seems to me that the tcl team needs someone in the role of 
> > release manager / Chief Nag-Meister.  To try and get things 
> > moving along. Is there anyone doing that role now?
> 
> That depends.  I am release manager, but not nag-meister, and maybe that's the
> problem.  Noone is playing nag-meister.  Another issue is that noone is
> pointing out a "critical" need for 8.5 - feature-wise or company backing.  So
> why nag?

Well, there is a fair amount of useful stuff in 8.5.  I'd like to know why
it isn't just wrapped up and tossed over the wall.  People will try it and
if it is busted then you do a 8.5.1 to fix it, repeat until stable.  What's
wrong with that?
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [Tile-dev] Release plans

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

Larry McVoy wrote:
> It seems to me that the tcl team needs someone in the role of=20
> release manager / Chief Nag-Meister.  To try and get things=20
> moving along. Is there anyone doing that role now?

That depends.  I am release manager, but not nag-meister, and maybe =
that's the
problem.  Noone is playing nag-meister.  Another issue is that noone is
pointing out a "critical" need for 8.5 - feature-wise or company =
backing.  So
why nag?

Jeff

Re: [Tile-dev] Release plans

[<lm...@bi...>]

On Tue, Oct 03, 2006 at 09:34:22AM -0700, Jeff Hobbs wrote:
> Larry McVoy wrote:
> > > On the other hand, until we can stop calling Tcl 8.5 an alpha there
> > > will be a number of people who won't or can't touch it (even allowing  
> > > for the definition of alpha).
> > 
> > Yes.  Is there any reason to not just throw 8.5 over the wall 
> > as 8.5.0 and fix the problems as they arise?
> 
> I have the impression that would cause more problems than answers.  We don't
> want a release like 8.1, that everyone wants to forget ... or do we?

I dunno, I wasn't around for 8.1 so far as I know.

It seems to me that the tcl team needs someone in the role of release
manager / Chief Nag-Meister.  To try and get things moving along.
Is there anyone doing that role now?
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [Tile-dev] Release plans

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

Larry McVoy wrote:
> > On the other hand, until we can stop calling Tcl 8.5 an alpha there
> > will be a number of people who won't or can't touch it (even allowing  
> > for the definition of alpha).
> 
> Yes.  Is there any reason to not just throw 8.5 over the wall 
> as 8.5.0 and fix the problems as they arise?

I have the impression that would cause more problems than answers.  We don't
want a release like 8.1, that everyone wants to forget ... or do we?

Re: [Tile-dev] Release plans

[<lm...@bi...>]

> > I know you gave a winky, but I'm not sure if you underestimate the  
> > truth
> > and seriousness of my message.  Who cares about 8.5 when we have tile
> > fully operational in 8.4, dict backported, etc.  What is 8.5 really
> > offering?
> 
> There's a lot of truth in that - in fact I'm somewhat guilty of that  
> viewpoint myself.
> 
> On the other hand, until we can stop calling Tcl 8.5 an alpha there  
> will be a number of people who won't or can't touch it (even allowing  
> for the definition of alpha).

Yes.  Is there any reason to not just throw 8.5 over the wall as 8.5.0
and fix the problems as they arise?
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

Re: [Tile-dev] Release plans

[Steve L. <st...@di...>]

On 03/10/2006, at 1:06 PM, Jeff Hobbs wrote:

> Steve Landers wrote:
>>
>> On 02/10/2006, at 11:18 PM, Jeff Hobbs wrote:
>>
>>> You can also look at this as more reasons to pull people to 8.5,
>>> including our own focus.  Yes, at this point I think some of us  
>>> (very
>>> much myself included) need to find ways to break with the  
>>> attachment to
>>> 8.4, or 8.5 won't see the light of day this decade.
>>
>> I suspect moving it from alpha to beta or even released might be an
>> effective way ;-)
>
> I know you gave a winky, but I'm not sure if you underestimate the  
> truth
> and seriousness of my message.  Who cares about 8.5 when we have tile
> fully operational in 8.4, dict backported, etc.  What is 8.5 really
> offering?

There's a lot of truth in that - in fact I'm somewhat guilty of that  
viewpoint myself.

On the other hand, until we can stop calling Tcl 8.5 an alpha there  
will be a number of people who won't or can't touch it (even allowing  
for the definition of alpha).

Anyway, we're on the same wavelength - another topic for discussing  
over margaritas at the conference.  ISTR that last time we arrived at  
the solutions for world poverty, peace in the middle east and various  
other topics ... but I can't remember the details :)

Steve

Re: [Tile-dev] Release plans

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

Steve Landers wrote:
> 
> On 02/10/2006, at 11:18 PM, Jeff Hobbs wrote:
> 
>> You can also look at this as more reasons to pull people to 8.5,
>> including our own focus.  Yes, at this point I think some of us (very
>> much myself included) need to find ways to break with the attachment to
>> 8.4, or 8.5 won't see the light of day this decade.
> 
> I suspect moving it from alpha to beta or even released might be an 
> effective way ;-)

I know you gave a winky, but I'm not sure if you underestimate the truth 
and seriousness of my message.  Who cares about 8.5 when we have tile 
fully operational in 8.4, dict backported, etc.  What is 8.5 really 
offering?

Jeff

Re: [Tile-dev] Release plans

[Steve L. <st...@di...>]

On 02/10/2006, at 11:18 PM, Jeff Hobbs wrote:

> You can also look at this as more reasons to pull people to 8.5,
> including our own focus.  Yes, at this point I think some of us (very
> much myself included) need to find ways to break with the  
> attachment to
> 8.4, or 8.5 won't see the light of day this decade.

I suspect moving it from alpha to beta or even released might be an  
effective way ;-)

Steve

Re: [Tile-dev] Release plans

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

Joe English wrote:
> Jeff Hobbs wrote:
>>> Main reason for the name change is that it's not
>>> always a bar -- different styles can support different
>>> appearances (OSX-style "chasing arrows", browser-style
>>> "download in progress" throbbers, a "copying file" animation,
>>> ...).  It might end up as two widgets, a general-purpose
>>> ttk::progress widget and a specialized ttk::progressbar ...
>> Hmmm, I would have expected progressbar as well, but your point does make
>> sense.  The problem is that 'progress' is so ... half-sensical from the widge
>> naming perspective.  I'm not sure that progressbar isn't still more
>> appropriate, as throbbers and chasing arrows are "bar-like".
> 
> 
> OK, that sounds like two votes against; the widget
> name will stay as [ttk::progressbar].

FWIW, I was only 0.5 against.

>>> There might be a [ttk::toplevel] in a future release,
>>> but the implementation will involve more changes
>>> than just embedding a ttk::frame in the background.
>> Note that Ttk is likely to hit the 8.5 codebase (finally :/ ) between 0.7.8
>> and 0.8.0.  It will free up some restrictions in code sharing (full Tk core
>> internals access) and may make something things like this easier.
> 
> I'm still committed to maintaining Tile as a separate,
> 8.4-compatible extension (if for no other reason, *I* 
> still need it with 8.4), so deeper coupling with the 
> core internals isn't entirely desirable.
> 
> Besides, I think [ttk::toplevel] as outlined previously
> could be done as a Snidget -- there's no need to dig deeper,
> it can be done by wrapping another layer on top.
> 
> Menus, on the other hand...

I am really on both sides on this one.  On the one hand, 8.4 is very 
important to maintain (and I see this more than most).  However, I think 
it is time to call it "good enough" and break out into new territory.

Consider this - given what you have already planned for 0.7.8, what is 
the difference between calling that "independent end state" and makin 
0.8.0 the true Ttk 8.5 variant?  Solving things like the background 
problem and such could really be reserved for 8.5+ users.

You can also look at this as more reasons to pull people to 8.5, 
including our own focus.  Yes, at this point I think some of us (very 
much myself included) need to find ways to break with the attachment to 
8.4, or 8.5 won't see the light of day this decade.

Jeff

Re: [Tile-dev] Release plans

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

Jeff Hobbs wrote:
> > Main reason for the name change is that it's not
> > always a bar -- different styles can support different
> > appearances (OSX-style "chasing arrows", browser-style
> > "download in progress" throbbers, a "copying file" animation,
> > ...).  It might end up as two widgets, a general-purpose
> > ttk::progress widget and a specialized ttk::progressbar ...
>
> Hmmm, I would have expected progressbar as well, but your point does make
> sense.  The problem is that 'progress' is so ... half-sensical from the widge
> naming perspective.  I'm not sure that progressbar isn't still more
> appropriate, as throbbers and chasing arrows are "bar-like".


OK, that sounds like two votes against; the widget
name will stay as [ttk::progressbar].

> > There might be a [ttk::toplevel] in a future release,
> > but the implementation will involve more changes
> > than just embedding a ttk::frame in the background.
>
> Note that Ttk is likely to hit the 8.5 codebase (finally :/ ) between 0.7.8
> and 0.8.0.  It will free up some restrictions in code sharing (full Tk core
> internals access) and may make something things like this easier.

I'm still committed to maintaining Tile as a separate,
8.4-compatible extension (if for no other reason, *I* 
still need it with 8.4), so deeper coupling with the 
core internals isn't entirely desirable.

Besides, I think [ttk::toplevel] as outlined previously
could be done as a Snidget -- there's no need to dig deeper,
it can be done by wrapping another layer on top.

Menus, on the other hand...


--Joe English

  jen...@fl...

Re: [Tile-dev] Odd error in ttk::entry/ttk::scale

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

Joey Mukherjee wrote:
> Thanks for the help with the treeview!  Adding the break solved it
> since I was, as you surmised, destroying the treeview each time.
>
> Anyway, I wanted to post another oddity I had with Tile, but it would
> be hard to describe so I thought a test case would be easier.  What I
> have is a simple time dialog and when I adjust the day of year, I
> want the month/day of month to auto computed and placed in a scale/
> entry pair.  Seems simple enough and it worked fine when it was not
> tile.
>
> Now that I have tile, when I slide the scale, I can only move a
> little bit before it jumps to the end of the slider!
> [...]
> This is with the 0.7.6 of tile.  You should be able to do a wish
> test.tcl and then slide the "Day of Year" scale until you get to day
> 31.  When it hops over day 31, it is supposed to go to month 2, day
> 1.  Instead it hops over to 12/31, day 365.

OK, here's what's going on:

Start with Day = 31, Month = 1, DOM = 1, and increment the Day slider.

This calls [ScaleChange ... 32] (the scale's -command).
Which calls [SetEntry ... 32]
Which calls [EntryChange StartDay 32] (via the entry's -validatecommand)
Which calls [UpdateString StartDay] (among other things).

Now here's where it gets interesting.  [UpdateString StartDay]
computes Month=2 and DOM=1 from Day=32, then calls
[SetScale ... $Month] and [SetScale ... $Day].  [SetScale]
compares the current value with the new value and returns
immediately if they're the same; but this time the Month
has changed from 1 to 2.

So it calls $scale set $value;
Which calls [ScaleChange ... 2] (this time for the Month slider),
Which calls [SetEntry ... 2],
Which calls [EntryChange StartMonth 2],
Which calls [UpdateString StartMonth].

Now we have Month=2, and DOM is still 31.  [UpdateString StartMonth]
computes a new day-of-year (62) and calls [SetScale] to set the
StartDay slider, and we're back where we started, this time
with Day = 62.

The process eventually reaches a fixed-point, and the recursion
terminates in [SetScale].  You can see this in action with:

    proc entered {cmd op} { puts "ENTERED: $args" }
    proc watch proc { trace add execution $proc enter entered }
    watch TimeDialog::ScaleChange

Starting from Day = 31 and incrementing the slider, we get:

    ENTERED: TimeDialog::ScaleChange StartDay 32.0
    ENTERED: TimeDialog::ScaleChange StartMonth 2.0
    ENTERED: TimeDialog::ScaleChange StartDay 62.0
    ENTERED: TimeDialog::ScaleChange StartDOM 1.0
    ENTERED: TimeDialog::ScaleChange StartDay 32.0
    ENTERED: TimeDialog::ScaleChange StartDay 366.0
    ENTERED: TimeDialog::ScaleChange StartMonth 12.0
    ENTERED: TimeDialog::ScaleChange StartDay 335.0
    ENTERED: TimeDialog::ScaleChange StartDOM 31.0
    ENTERED: TimeDialog::ScaleChange StartDay 365.0


So what I wonder is not "Why doesn't this work with Tile",
but instead "Why did this work in the first place?".

(The answer probably has to do with the fact that core [scale]
widgets call their -command at strange times and for strange
reasons, usually in an idle handler.  It's likely that deferring
the ScaleChange call allows the process to stabilize sooner.)


--Joe English

  jen...@fl...

Re: [Tile-dev] Release plans

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

Joe English wrote:
> > > [ttk::progressbar] will become [ttk::progress] too.

> Main reason for the name change is that it's not
> always a bar -- different styles can support different=20
> appearances (OSX-style "chasing arrows", browser-style=20
> "download in progress" throbbers, a "copying file" animation,=20
> ...).  It might end up as two widgets, a general-purpose=20
> ttk::progress widget and a specialized ttk::progressbar ...

Hmmm, I would have expected progressbar as well, but your point does =
make
sense.  The problem is that 'progress' is so ... half-sensical from the =
widget
naming perspective.  I'm not sure that progressbar isn't still more
appropriate, as throbbers and chasing arrows are "bar-like".

> There might be a [ttk::toplevel] in a future release,
> but the implementation will involve more changes
> than just embedding a ttk::frame in the background.

Note that Ttk is likely to hit the 8.5 codebase (finally :/ ) between =
0.7.8
and 0.8.0.  It will free up some restrictions in code sharing (full Tk =
core
internals access) and may make something things like this easier.

Jeff

Re: [Tile-dev] Release plans

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

Joey Mukherjee wrote:
> On Oct 1, 2006, at 3:15 AM, Joe English wrote:
> > The exceptions: by popular demand, [ttk::paned] will be
> > renamed [ttk::panedwindow]; and as long as we're doing
> > that [ttk::progressbar] will become [ttk::progress] too.
>
> Was ttk::progress really popularly demanded?  IMHO, ttk::progressbar
> is a better name for the same reasons I think panedwindow is a better
> name.

Main reason for the name change is that it's not
always a bar -- different styles can support different
appearances (OSX-style "chasing arrows", browser-style
"download in progress" throbbers, a "copying file"
animation, ...).  It might end up as two widgets,
a general-purpose ttk::progress widget and a
specialized ttk::progressbar ...

Other opinions?

> I never saw a response to the ttk::toplevel question?  Is that going
> to be standard?  I saw a bug report on sourceforge, but no real
> resolution and it only mentioned Aqua.  In addition to Aqua, on
> Solaris, mixing a toplevel and tile widgets look awful.

Sorry, I started writing up a response but never got
around to finishing it.  Short answer: No, not in 0.7.8.

There might be a [ttk::toplevel] in a future release,
but the implementation will involve more changes
than just embedding a ttk::frame in the background.

It won't have -highlightcolor, -highlightbackground,
or -highlightthickness options; -padx/-pady will be
replaced with -padding; the -colormap and -visual options
definitely have to go; ditto -use and -container.

It needs the standard -style option, plus 'state' and
'instate' methods.  It also ought to have '-title',
'-icon', '-iconname' options; a '-closecommand' option;
and 'show' and 'hide' methods (i.e., most of the
things that are currently handled by [wm].)

So no, not in 0.7.8.


--Joe English

  jen...@fl...

[Tile-dev] Odd error in ttk::entry/ttk::scale

[Joey M. <jo...@sw...>]

Thanks for the help with the treeview!  Adding the break solved it  
since I was, as you surmised, destroying the treeview each time.

Anyway, I wanted to post another oddity I had with Tile, but it would  
be hard to describe so I thought a test case would be easier.  What I  
have is a simple time dialog and when I adjust the day of year, I  
want the month/day of month to auto computed and placed in a scale/ 
entry pair.  Seems simple enough and it worked fine when it was not  
tile.

Now that I have tile, when I slide the scale, I can only move a  
little bit before it jumps to the end of the slider!  Its really  
strange.  There is a radio button in there which will allow me to  
switch from day of year to month/day sliding and it works as expected  
(i.e. day of year is auto computed and placed in scale/entry pair).

If I make the entry that is causing problems readonly, it works  
albeit, the entry is not updated correctly.

This may not make a lot of sense, but the test case is attached.   
This is with the 0.7.6 of tile.  You should be able to do a wish  
test.tcl and then slide the "Day of Year" scale until you get to day  
31.  When it hops over day 31, it is supposed to go to month 2, day  
1.  Instead it hops over to 12/31, day 365.

[Tile-dev] Release plans

[Joey M. <jo...@sw...>]

On Oct 1, 2006, at 3:15 AM, Joe English wrote:

> The exceptions: by popular demand, [ttk::paned] will be
> renamed [ttk::panedwindow]; and as long as we're doing
> that [ttk::progressbar] will become [ttk::progress] too.

Was ttk::progress really popularly demanded?  IMHO, ttk::progressbar  
is a better name for the same reasons I think panedwindow is a better  
name.  You could have a progress bar or a progress dialog, like Qt  
does.  ttk::progress seems more ambiguous.  Paned could mean windows  
or widgets, explicitly defining panedwindow I think is better.

> Is there anything else anyone thinks should be done for 0.7.8?

I never saw a response to the ttk::toplevel question?  Is that going  
to be standard?  I saw a bug report on sourceforge, but no real  
resolution and it only mentioned Aqua.  In addition to Aqua, on  
Solaris, mixing a toplevel and tile widgets look awful.

Thanks,
Joey

Re: [Tile-dev] Release plans

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

Alexander Schoepe wrote:
> maybe there is a bug:
> % package require tile
> 0.7.5
> 
> % toplevel .tl
> % ttk::dialog .dlg -buttons ok -message Test -parent .tl
> can't read "parent": no such variable

Already found and fixed in CVS:

    2006-09-13  Joe English  <jen...@us...>
	* library/dialog.tcl: BUGFIX: ttk::dialog -parent option
	didn't work [#1551500]. 

    http://sourceforge.net/tracker/index.php?func=detail&aid=1551500&group_id=11464&atid=111464


--Joe

Re: [Tile-dev] Release plans

[<sc...@us...>]

hi joe,

maybe there is a bug:
I am using ActiveTcl
% info patchlevel
8.4.13
% package require tile
0.7.5

% toplevel .tl
% ttk::dialog .dlg -buttons ok -message Test -parent .tl
can't read "parent": no such variable

regards
alex
> Is there anything else anyone thinks should be done for 0.7.8?

[Tile-dev] Release plans

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

The treeview -selectmode option was the last thing I
wanted to get in for the next release; so once that's done
(just a bit more work left on it), it'll be feature-freeze
time, and 0.7.8 should be ready by the next ActiveTcl release.

After that, the 0.8.X series will go into "break stuff" mode.
This won't affect application code (with two exceptions),
but it will involve reorganizing and rationalizing all the
elements, so third-party themes will need (hopefully minor)
modifications.

The exceptions: by popular demand, [ttk::paned] will be
renamed [ttk::panedwindow]; and as long as we're doing
that [ttk::progressbar] will become [ttk::progress] too.

To smooth the transition, 0.7.8 will alias [ttk::panedwindow]
to [ttk::paned]; in 0.8.0 the widget will be renamed
and [ttk::paned] will be a deprecated alias.

Is there anything else anyone thinks should be done for 0.7.8?


--Joe English

  jen...@fl...

Re: [Tile-dev] ttk::treeview -selectmode option; please review.

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

Jeff Hobbs wrote:
> Joe English wrote:
> > > I used the keywords "single"/"multiple" because that seems more
> > > intuitive than "browse"/"extended" (even though the behavior is closer
> > > to what the core listbox calls the latter).
> >  [...]
>
> But it's now more than just listbox.  It's tktable, treectrl, bwidgets, ...
> If it were one, then it's 50/50, but this would be 1 anomaly out of 5 similar

OK: "browse" / "extended" it is.


--Joe English

  jen...@fl...

Re: [Tile-dev] Error with Treeview

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

Joey Mukherjee wrote:

> I am getting an error when picking the last item in my list when I
> use a tile treeview.
>
> The error is :
> invalid command name ".sourcedialog.options.list2"
> invalid command name ".sourcedialog.options.list2"
>      while executing
> "$w identify $x $y"
>      (procedure "ttk::treeview::Press" line 3)
>      invoked from within
> "ttk::treeview::Press .sourcedialog.options.list2 43 188 "
>      (command bound to event)
>
> The reason I am getting this error is because I override the Button-1
> as follows:
>
>    bind $listname <Button-1> {
>            SourceDialog::OnList [%W item [%W identify row %x %y] -text]
>    }
>
> which makes it call my function that goes to the next list.  If I
> pick any other item but the last, it works fine.

I can't replicate the problem -- but does the "SourceList::OnList"
procedure destroy the treeview widget by any chance?  If so,
you probably want to put a [break] in the binding script:

    bind $listname <Button-1> {
       SourceDialog::OnList [%W item [%W identify row %x %y] -text] ;
       break;
    }

Very few class binding scripts work properly if they're called
after the target widget has been destroyed...


--Joe English

  jen...@fl...

[Tile-dev] Error with Treeview

[Joey M. <jo...@sw...>]

I am getting an error when picking the last item in my list when I  
use a tile treeview.

The error is :
invalid command name ".sourcedialog.options.list2"
invalid command name ".sourcedialog.options.list2"
     while executing
"$w identify $x $y"
     (procedure "ttk::treeview::Press" line 3)
     invoked from within
"ttk::treeview::Press .sourcedialog.options.list2 43 188 "
     (command bound to event)


The reason I am getting this error is because I override the Button-1  
as follows:

   bind $listname <Button-1> {
           SourceDialog::OnList [%W item [%W identify row %x %y] -text]
   }

which makes it call my function that goes to the next list.  If I  
pick any other item but the last, it works fine.

If I put the lassign in a catch from treeview.tcl, I can avoid the  
problem.

proc ttk::treeview::Press {w x y} {

     catch {lassign [$w identify $x $y] what where detail} msg
     if {$msg != ""} {
         return
     }

There is probably a better way to solve this.

Thanks,
Joey

Re: [Tile-dev] ttk::treeview -selectmode option; please review.

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

Joe English wrote:
> > I used the keywords "single"/"multiple" because that seems more=20
> > intuitive than "browse"/"extended" (even though the behavior is =
closer=20
> > to what the core listbox calls the latter).
>=20
> Addendum: consistency with Tk important for Tile, except for=20
> the (rare) areas where Tk's design itself is flawed; and I've=20
> never liked the single/multiple/browse/extended scheme.
>=20
> This was apparently copied from the Motif XmList widget=20
> (which I've always suspected originally just had "single" and=20
> "multiple" modes that didn't work very well so "browse" and=20
> "extended" got added later as "unbreak-my-program" options. =20
> But maybe that's just me...)

But it's now more than just listbox.  It's tktable, treectrl, bwidgets, =
...
If it were one, then it's 50/50, but this would be 1 anomaly out of 5 =
similar.

Jeff