Menu
▾
▴
tktable-tile-dev
|
From: Joe E. <jen...@fl...> - 2006-10-01 08:15:11
|
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... |
|
From: <sc...@us...> - 2006-10-01 09:08:34
|
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? |
|
From: Joe E. <jen...@fl...> - 2006-10-01 17:57:17
|
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
|
|
From: Joey M. <jo...@sw...> - 2006-10-01 19:37:35
|
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 |
|
From: Joe E. <jen...@fl...> - 2006-10-02 05:06:37
|
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... |
|
From: Jeff H. <je...@ac...> - 2006-10-02 05:23:58
|
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 |
|
From: Joe E. <jen...@fl...> - 2006-10-02 14:40:34
|
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... |
|
From: Jeff H. <je...@ac...> - 2006-10-02 15:18:25
|
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 |
|
From: Steve L. <st...@di...> - 2006-10-03 00:00:27
|
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 |
|
From: Jeff H. <je...@ac...> - 2006-10-03 05:06:21
|
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 |
|
From: Will D. <Wil...@jp...> - 2006-10-04 15:46:13
|
oo:: namespace ensemble namespace path Snit 2.0 I'm eager to move to 8.5 once it's stable. Will On Oct 2, 2006, at 10: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? > > Jeff > > ----------------------------------------------------------------------- > -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Tktable-tile-dev mailing list > Tkt...@li... > https://lists.sourceforge.net/lists/listinfo/tktable-tile-dev > > ------------------------------------------------------------------------ Will Duquette, JPL | Wil...@jp... But I speak only | http://eis.jpl.nasa.gov/~will (JPL Use Only) for myself. | It's amazing what you can do with the right tools. |
|
From: Steve L. <st...@di...> - 2006-10-03 06:39:27
|
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 |
|
From: <lm...@bi...> - 2006-10-03 12:52:06
|
> > 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 |
|
From: Jeff H. <je...@ac...> - 2006-10-03 16:35:31
|
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? |
|
From: <lm...@bi...> - 2006-10-03 16:39:09
|
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 |
|
From: Jeff H. <je...@ac...> - 2006-10-03 16:44:53
|
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 |
|
From: <lm...@bi...> - 2006-10-03 16:48:31
|
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 |
|
From: Oscar B. <ob...@bi...> - 2006-10-03 16:53:30
|
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 |
|
From: Jeff H. <je...@ac...> - 2006-10-03 16:59:33
|
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
|
|
From: <lm...@bi...> - 2006-10-03 17:05:39
|
On Tue, Oct 03, 2006 at 09:58:29AM -0700, Jeff Hobbs wrote:
> Oscar Bonilla wrote:
> > On Oct 3, 2006, at 9:43 AM, Jeff Hobbs wrote:
> > > problem. Noone is playing nag-meister. Another issue is that noon=
e 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?
>=20
> 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-d=
efining
> in itself. There are of course many more changes already:
> http://wiki.tcl.tk/10630
There is a fair amount of stuff there.
Personally, I'd vote for getting Tile in there and calling it a release.
If the community focussed on that it could get done and there would at
least be some visible forward progress.
--=20
---
Larry McVoy lm at bitmover.com http://www.bitkee=
per.com
|
|
From: Oscar B. <ob...@bi...> - 2006-10-03 17:28:08
|
On Oct 3, 2006, at 9:58 AM, Jeff Hobbs wrote:
> Oscar Bonilla wrote:
>> On Oct 3, 2006, at 9:43 AM, Jeff Hobbs wrote:
>>> 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
>>> backing. So why nag?
>>
>> So what's the value of 8.5? I mean, if every single feature that is
>> existent in 8.5 has been back-ported to 8.4. What's 8.5's
>> raison d'=EAtre?
>
> Exactly - that is the best response so far for Larry's other =20
> question. It has
> no raison d'=EAtre currently. It is waiting for Ttk inclusion (which =20=
> 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 =20=
> has
> {expand} and dict, but dict is backported and {expand} is not =20
> 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 =20
> many. 8.5
> without Tile and/or oo might as well not be (IOW: can wait).
But while it waits it's dragging considerable resources to backport =20
stuff to 8.4. That's a hidden but measurable cost. So the "can wait" =20
part is really costly.
--
pgp fingerprint: BC64 2E7A CAEF 39E1 9544 80CA F7D5 784D FB46 16C1
|
|
From: Joe E. <jen...@fl...> - 2006-10-03 19:17:04
|
Jeff Hobbs wrote:
> It is waiting for Ttk inclusion (which I have
> mostly sandboxed, but is totally lacking doc and needs more tests)
^^^^^^^^^^^^^^^^^^^
People keep saying that. "Tile is totally undocumented!",
I keep hearing. I don't get it. Given that there is
documentation for every widget (including all options and
every subcommand), documentation for the [style] command --
sparse, to be sure, but it's there -- documentation
for a good chunk of the low-level C API, plus a white paper
giving an overview and rationale, people must be using some
definition of the term "totally" with which I am unfamiliar.
RTFM here: http://tktable.sourceforge.net/tile/doc/
--Joe.
|
|
From: Joey M. <jo...@sw...> - 2006-10-09 15:17:11
|
On Oct 3, 2006, at 2:17 PM, Joe English wrote: > Jeff Hobbs wrote: > >> It is waiting for Ttk inclusion (which I have >> mostly sandboxed, but is totally lacking doc and needs more tests) > ^^^^^^^^^^^^^^^^^^^ > > People keep saying that. "Tile is totally undocumented!", > I keep hearing. I don't get it. Given that there is > documentation for every widget (including all options and Sorry for the late reply! Back from travel... At any rate, what happened to documentation for ttk::scale? It seems to be missing and has been for some time. It also isn't updated for the latest version since I notice ttk::paned and not panedwindow. BTW, thanks for the detailed analysis of that time dialog thing! I read it and not fully digested it yet, but I plan to soon. For the record, I didn't write that code! ;-) I just wanted to report a "bug/ feature" when we trying to convert some of our legacy stuff over to tile. Cheers, Joey |
|
From: Damon C. <da...@tc...> - 2006-10-03 16:56:36
|
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 |
