Menu
▾
▴
tcl-core
|
From: Donald G P. <dg...@em...> - 2002-08-29 17:20:41
|
Michael J McLennan wrote: > > TIP #107: FIX THE 2-SECOND "RAISE DELAY" IN TK > This is one of the the most important TIPs I've seen. This is one "yes" > for our TYANNOTT. If we get another and no one else objects, just go > ahead and make the change. Looks like a vote sponsorship to me. For sake of a definite end, lets say votes should be cast (to Michael) by [clock format 1031068800]. My vote: TIP 107: PRESENT | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: George H. <ga...@si...> - 2002-08-29 18:00:03
|
In message <200...@po...>, Donald G Porter wri tes: : : Michael J McLennan wrote: : > > TIP #107: FIX THE 2-SECOND "RAISE DELAY" IN TK : : > This is one of the the most important TIPs I've seen. This is one "yes" : > for our TYANNOTT. If we get another and no one else objects, just go : > ahead and make the change. : : Looks like a vote sponsorship to me. For sake of a definite end, lets : say votes should be cast (to Michael) by [clock format 1031068800]. : I also vote yes (that's TYANNOTT). So if there are any NOs, let's here them. --gah |
|
From: <ke...@cr...> - 2002-09-03 15:00:56
|
TIP #107: PRESENT
I've never seen the problem - perhaps none of my WMs exhibit it -
and I don't feel qualified to express a strong opinion.
--
73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development
ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A
Schenectady, New York 12301-0008 USA
|
|
From: <ke...@cr...> - 2003-09-16 15:09:12
|
> In addition to the shortcoming that I mentioned earlier, the "right"
> ensemble mechanism should be good enough for Tcl to use at its very
> core. Commands such as "info" and "winfo" should be implemented as
> ensembles. I just don't see that in TIP #112.
I think you're putting the cart before the horse here.
The reason that I want to see TIP #112 passed and implemented is
precisely that I want to begin refactoring the core ensembles to use
it. Does every proposal have to have a complete release roadmap for
its proposed use before it can be approved?
Refactoring Tcl's own ensembles to use this mechanism is the
proper subject for other TIPs once we're agreed on the fundamental
infrastructure.
--
73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development
ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A
Schenectady, New York 12301-0008 USA
|
|
From: Michael M. <mm...@ca...> - 2003-09-16 15:20:56
|
Did I miss something? TIP #112 doesn't describe any C language bindings for ensembles, so it is not clear to me how you would refactor the core (specifically, "info", widget subcommands, etc.) to use it. It seems to me to be a Tcl-only solution, and an overly complicated one at that. I'm not asking for a "complete roadmap," but I don't think this TIP describes enough of the "fundamental infrastructure" to make a suitable basis for other parts of the core. Maybe the right solution is to stop the vote and let this one cook a little longer. --Michael On 16 Sep, Kevin Kenny wrote: >> In addition to the shortcoming that I mentioned earlier, the "right" >> ensemble mechanism should be good enough for Tcl to use at its very >> core. Commands such as "info" and "winfo" should be implemented as >> ensembles. I just don't see that in TIP #112. > > I think you're putting the cart before the horse here. > > The reason that I want to see TIP #112 passed and implemented is > precisely that I want to begin refactoring the core ensembles to use > it. Does every proposal have to have a complete release roadmap for > its proposed use before it can be approved? > > Refactoring Tcl's own ensembles to use this mechanism is the > proper subject for other TIPs once we're agreed on the fundamental > infrastructure. > > -- > 73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development > ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A > Schenectady, New York 12301-0008 USA > |
|
From: Donal K. F. <don...@ma...> - 2003-09-17 10:35:08
|
Michael McLennan wrote: > Did I miss something? TIP #112 doesn't describe any C language > bindings for ensembles, so it is not clear to me how you would > refactor the core (specifically, "info", widget subcommands, etc.) > to use it. It seems to me to be a Tcl-only solution, and an > overly complicated one at that. Every feature of #112 is there because someone wanted it. Sure -map is a subtle feature, but it is also one that feedback from other people indicates is very valuable. It's also a major distinguishing feature when compared with Itcl ensembles (if I've not grabbed the wrong end of the stick.) If 112 passes, I'll have to make a C API to its facilities the subject of a future followup TIP. This is not a problem. Rome wasn't built in a day. > I'm not asking for a "complete roadmap," but I don't think this > TIP describes enough of the "fundamental infrastructure" to make > a suitable basis for other parts of the core. Good thing that 112 doesn't make such a proposal. :^) > Maybe the right solution is to stop the vote and let this one > cook a little longer. I disagree. :^) Donal. -- Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ don...@ma... -- I'm curious; where does this statistic come from? Does its home, perchance, ever see sunlight? -- Jason A Williams <jas...@co...> |
|
From: Donal K. F. <don...@ma...> - 2003-09-17 10:09:00
|
Kevin Kenny wrote: > The reason that I want to see TIP #112 passed and implemented is > precisely that I want to begin refactoring the core ensembles to use > it. Does every proposal have to have a complete release roadmap for > its proposed use before it can be approved? > > Refactoring Tcl's own ensembles to use this mechanism is the > proper subject for other TIPs once we're agreed on the fundamental > infrastructure. This is something that I am in complete agreement with. Such a refactoring, though a matter that I hope to pursue in the future, is outside the scope of TIP#112 and *deliberately* so. It requires as a prerequisite a satisfactory way of bytecode compiling such things, and possibly a performance study as well. In neither case is a TIP required (the compiler API is internal, and performance studies are not specifications by any stretch of the imagination.) If/when I can figure out that making much of the core into an ensemble will improve things, I'll put forward a separate proposal on the matter which will also outline a protocol for non-core code to extend those ensembles (or perhaps a mechanism for preventing it; there are details here that I do not see all the way through yet.) OTOH, experiments with the sample implementation (by Joe English) indicate that what exists is already valuable for user code purely by virtue of it making it easier for that code to present compound-command-type APIs (and faster too.) As such, even if the current TIP presented the entirety of the ensemble API that got implemented in Tcl 8.5, it would still be a clear step forward. Donal. -- Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ don...@ma... -- I'm curious; where does this statistic come from? Does its home, perchance, ever see sunlight? -- Jason A Williams <jas...@co...> |
|
From: <ke...@cr...> - 2003-10-01 18:50:07
|
mm...@ca... said:
> If colors are a elevated to the level of an object, wouldn't that
> encourage people to use color objects for animation? For example,
> they might create a color called "shimmer", use that color to draw
> lots of items on a canvas, and then set up an "after" script to change
> "shimmer" to various colors of the rainbow at 100ms intervals.
> I think George has a good point. If colors are objects, they must
> notify widgets to do redraws without forcing layout changes.
Can't we defer that, though, since we have trouble with binary
compatibility and Tk_ClassProcs? Getting notification when the
desktop theme changes is useful in itself; can't we worry about
animation-by-shimmering-color-palette in the Tcl 9 time frame (where
it has to be, anyway) and still have the other uses for named colors
in 8.5?
(I really dislike the practice of turning down otherwise sound
proposals because their scope is insufficiently broad. It discourages
developers from getting *anything* done if they think they have to
solve all the world's problems before any change is acceptable.)
--
73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development
ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A
Schenectady, New York 12301-0008 USA
|
|
From: Damon C. <da...@yo...> - 2003-10-01 18:59:31
|
> mm...@ca... said:
> > If colors are a elevated to the level of an object, wouldn't that
> > encourage people to use color objects for animation? For example,
> > they might create a color called "shimmer", use that color to draw
> > lots of items on a canvas, and then set up an "after" script to change
> > "shimmer" to various colors of the rainbow at 100ms intervals.
>
> > I think George has a good point. If colors are objects, they must
> > notify widgets to do redraws without forcing layout changes.
>
> Can't we defer that, though, since we have trouble with binary
> compatibility and Tk_ClassProcs? Getting notification when the
> desktop theme changes is useful in itself; can't we worry about
> animation-by-shimmering-color-palette in the Tcl 9 time frame (where
> it has to be, anyway) and still have the other uses for named colors
> in 8.5?
>
> (I really dislike the practice of turning down otherwise sound
> proposals because their scope is insufficiently broad. It discourages
> developers from getting *anything* done if they think they have to
> solve all the world's problems before any change is acceptable.)
There are always lots of ways to do things. Some are efficient.
Others are not. If changing a color forces a reconfiguration on the
global level, doing this on a canvas would be really inefficient.
You would then just do it another way. I would probably tag the items
and then just itemconfigure the tags. *shrug*
I see where Michael is coming from, I just think that making color
changes work a certain way won't limit their ability, just force someone
to make a better decision based on what's available.
D
|
|
From: Michael M. <mm...@ca...> - 2003-10-01 19:23:18
|
On 1 Oct, Kevin Kenny wrote: > Can't we defer that, though, since we have trouble with binary > compatibility and Tk_ClassProcs? Getting notification when the > desktop theme changes is useful in itself; can't we worry about > animation-by-shimmering-color-palette in the Tcl 9 time frame (where > it has to be, anyway) and still have the other uses for named colors > in 8.5? > > (I really dislike the practice of turning down otherwise sound > proposals because their scope is insufficiently broad. It discourages > developers from getting *anything* done if they think they have to > solve all the world's problems before any change is acceptable.) I don't think we should introduce an API for something like this, and then change the API at a later point because the original was botched. People will start updating their widgets to support the new color objects, only to have to change the code again later. I'm not saying that we need a "complete solution" for everything, but we should at least have a plan that takes into account future development. We should at least figure out how the notifications should work for redraw only, then figure out how to make that compatible with the 1.0 release, which will be much simpler. --Michael |
|
From: Donal K. F. <don...@ma...> - 2003-10-02 13:38:39
|
Michael McLennan wrote: > I don't think we should introduce an API for something like this, > and then change the API at a later point because the original was > botched. People will start updating their widgets to support the > new color objects, only to have to change the code again later. While I understand and appreciate that PoV, I worry that it makes it so hard to take the first step and get a feature at all that we end up never getting the feature in the first place. > I'm not saying that we need a "complete solution" for everything, > but we should at least have a plan that takes into account future > development. We should at least figure out how the notifications > should work for redraw only, then figure out how to make that > compatible with the 1.0 release, which will be much simpler. There's a 9.0 possibility beginning to appear on the horizon for deliverables (after 8.5 reaches feature-freeze I'd say), and people using whatever API we make can be expected to have to alter things a bit at that point. I suppose we could have widgets be updated with the WorldChanged unless they've defined a handler for doing it more neatly. That'd allow for graceful support of existing widgets, while allowing new (and core) widgets to be updated to use a more efficient interface (which could be whatever makes sense...) Donal. -- Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ don...@ma... -- Name me one elf who wants to go to Blackpool after he dies. -- Raymond E. Feist on fei...@co... |
|
From: <ke...@cr...> - 2004-03-23 18:37:51
|
mm...@ca... said:
> I have been trying for years to get [incr Tk] adopted as a mega-widget
> standard in the Tcl/Tk core. It is widely used, well-documented, and
> a defacto standard for mega-widget development.
I would be happy to entertain a TIP to that effect.
I do not recall any being offered for consideration.
--
73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development
ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A
Schenectady, New York 12301-0008 USA
|
|
From: Michael M. <mm...@ca...> - 2004-03-23 21:58:04
|
On 23 Mar, Kevin Kenny wrote: > mm...@ca... said: >> I have been trying for years to get [incr Tk] adopted as a mega-widget >> standard in the Tcl/Tk core. It is widely used, well-documented, and >> a defacto standard for mega-widget development. > > I would be happy to entertain a TIP to that effect. > I do not recall any being offered for consideration. I'm surprised to hear you say that, Kevin. TIP #6 clearly proposed bundling all of [incr Tcl/Tk] into the core, and it was rejected. We all met together at the 2001 O'Reilly OpenSource Conference, and the idea came up again. After much debate, we finally reached a compromise: We could include [incr Tcl] in the core, but only if we left out [incr Tk], and TIP #50 was born. TIP #50 was voted on and accepted, and it clearly states that Jeff Hobbs would lead the effort. Many messages on this list have lamented the fact that the TIP was never realized, and they usually imply that this was some fault of mine or someone else on the [incr Tcl] team. I'll take blame for my own inaction, but everyone on the TCT shares that same blame. Any one of us could have integrated [incr Tcl] at any point. How hard is it to copy a directory and edit a few Makefiles? To me, TIP #50 was always a half-a-loaf solution. It included [incr Tcl] but removed its killer app, [incr Tk]. So personally, I find very little incentive to push this castrated version of [incr Tcl] forward. I have my own copy of Tcl/Tk and [incr Tcl/Tk] and it works just fine for me. I'm sorry that others don't get that for free, but frankly, after having developed itcl1.0, 2.0, 3,0 and the namespaces implementation for tcl8.0, I'm tired of fighting for [incr Tcl]. John always said that people would vote with their feet. Well, they have voted, [incr Tcl] is widely used, and yet it's still not part of the core. As far as I'm concerned, that's not (completely) my fault, and it's not really my problem. The point in my original message is that if [incr Tk], with its widespread use and large following, is relegated to the land of extensions, then other mega-widget packages should be treated on the same footing. Our policy has always been for a package to prove itself in the real world before being considered for integration into the core. --Michael |
|
From: Jeff H. <je...@Ac...> - 2004-03-23 22:39:07
|
Michael McLennan wrote: > TIP #50 was voted on and accepted, and it clearly states that > Jeff Hobbs would lead the effort. Many messages on this list To clarify, those were DGP's words on the TIP that said I would lead the effort. I was clear on willing to assist, and I was hoping to make a general mechanism for the core to have modules (packages, extensions, whatever) that could be dropped into a directory and would compile with the core. That part I actually have somewhat done (I haven't quite perfected selective inclusion/exclusion, it's all or nothing for what's in the dir now). I think I even tested itcl in doing this (it was many months ago). > To me, TIP #50 was always a half-a-loaf solution. It > included [incr Tcl] but removed its killer app, [incr Tk]. FWIW, even as an itcl user, I was never hot on itk. It took a lot of memory and wasn't the design I would choose to make megawidgets. We've had this discussion before though, many years ago in fact. I haven't explored Damon's APIs enough to comment there yet, but the whole idea needs to be revisited. I think that iwidgets and itk have moved to secondary status on the widget set usage preferences as numerous other widget sets have been developed. They are "easier" to develop for and/or have different design considerations that users prefer. I don't know if one exists that is the "killer" megawidget implementation, but I do think that there are some things that can be better exposed to the user that would assist any megwidget package author, like option management. I see that Damon addresses this in part, but I'm not sure about all the other bits that go around it. Jeff |
|
From: Michael M. <mm...@ca...> - 2004-03-23 23:11:20
|
Thanks, Jeff. Now I remember the real reasons behind all of this quite clearly. --Michael On 23 Mar, Jeff Hobbs wrote: > Michael McLennan wrote: >> TIP #50 was voted on and accepted, and it clearly states that >> Jeff Hobbs would lead the effort. Many messages on this list > > To clarify, those were DGP's words on the TIP that said I > would lead the effort. I was clear on willing to assist, > and I was hoping to make a general mechanism for the core > to have modules (packages, extensions, whatever) that could > be dropped into a directory and would compile with the core. > > That part I actually have somewhat done (I haven't quite > perfected selective inclusion/exclusion, it's all or nothing > for what's in the dir now). I think I even tested itcl in > doing this (it was many months ago). > >> To me, TIP #50 was always a half-a-loaf solution. It >> included [incr Tcl] but removed its killer app, [incr Tk]. > > FWIW, even as an itcl user, I was never hot on itk. It took > a lot of memory and wasn't the design I would choose to make > megawidgets. We've had this discussion before though, many > years ago in fact. > > I haven't explored Damon's APIs enough to comment there yet, > but the whole idea needs to be revisited. I think that > iwidgets and itk have moved to secondary status on the widget > set usage preferences as numerous other widget sets have been > developed. They are "easier" to develop for and/or have > different design considerations that users prefer. > > I don't know if one exists that is the "killer" megawidget > implementation, but I do think that there are some things that > can be better exposed to the user that would assist any > megwidget package author, like option management. I see that > Damon addresses this in part, but I'm not sure about all the > other bits that go around it. > > Jeff > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Donal K. F. <don...@ma...> - 2004-03-24 14:42:13
|
Michael McLennan wrote: > I'm surprised to hear you say that, Kevin. TIP #6 clearly proposed > bundling all of [incr Tcl/Tk] into the core, and it was rejected. We > all met together at the 2001 O'Reilly OpenSource Conference, and the > idea came up again. After much debate, we finally reached a > compromise: We could include [incr Tcl] in the core, but only if we > left out [incr Tk], and TIP #50 was born. If nothing else, [incr Tk] can't go in the Tcl core because it requires Tk which is not in the Tcl core either. If, once we've got TIP#50 done (all it requires is effort, but unfortunately much of that since the build system has to be altered so it works standalone) people wish to propose a separate TIP to put [incr Tk] into Tk in the same sense, well that's just fine. But it's a separate issue. > TIP #50 was voted on and accepted, and it clearly states that Jeff > Hobbs would lead the effort. Many messages on this list have > lamented the fact that the TIP was never realized, and they usually > imply that this was some fault of mine or someone else on the [incr > Tcl] team. I'll take blame for my own inaction, but everyone on the > TCT shares that same blame. Any one of us could have integrated > [incr Tcl] at any point. How hard is it to copy a directory and edit > a few Makefiles? And rewrite the test suite? Err, quite hard actually (apparently)... I believe Don Porter's looking into doing this so that itcl matches the core build and test mechanisms. There are separate questions though on how to integrate itcl with tcl as it is today. When I last looked at the itcl source tree, there were a number of things that were listed as obsolete or deprecated (I forget which, sorry); should they be excised as part of this process? I'm happy to de-defer #50 once I'm sure there is sufficient effort committed to make it happen in time for 8.5b1. I don't want to move it out of Deferred only to have it go back there again with no further progress when we feature-freeze 8.5. I hope the rest of the TCT agree with that. Quick question: Is making itcl a sibling package to the thread extension acceptable as an initial stage to achieving the goals of TIP#50? (FWIW, the thing about #50 that annoyed me most was that I didn't get a chance to raise issues about it before it was voted on because I was on vacation for a few weeks. There was a clear majority for it AIUI, but that doesn't mean that it couldn't have stood a quick technical review first. But this is all water under the bridge...) Donal. |
|
From: <ke...@cr...> - 2004-03-24 15:09:12
|
Me:
> I would be happy to entertain a TIP to that effect.
> I do not recall any being offered for consideration.
Michael:
> I'm surprised to hear you say that, Kevin. TIP #6 clearly proposed
> bundling all of [incr Tcl/Tk] into the core, and it was rejected.
Temper your surprise with remembering that I wasn't on the TCT
when TIP #6 was proposed.
> We all met together at the 2001 O'Reilly OpenSource Conference, and the
> idea came up again. After much debate, we finally reached a
> compromise: We could include [incr Tcl] in the core, but only if we
> left out [incr Tk], and TIP #50 was born.
As far as I remember, I served as secretary to that discussion,
which Melissa Hirschl Chawla moderated. My opinion, then as now,
was neutral: I will be happy to consider the proposal.
Aside from contributing my YES on TIP #50, I have been careful
to have no official opinion on the merits of any [incr Tcl]-related
proposal. I haven't ever been an [incr Tcl] implementor, and I
haven't used it (for reasons I refuse to discuss in this forum)
in some years.
I voted on TIP #50 presuming that its vocal proponents
would carry it forward (with Jeff as release manager, as he has
been for a number of Tcl/Tk releases). I didn't understand a YES
vote as a promise to undertake the work!
My advice to anyone who wants to see TIP #50 move forward is to
review TIP #81, make necessary changes, propose it for vote, and
compose an analogous TIP to TIPs #24 and #30 describing who is
responsible for making it happen.
--
73 de ke9tv/2, Kevin KENNY GE Corporate Research & Development
ke...@cr... P. O. Box 8, Bldg. K-1, Rm. 5B36A
Schenectady, New York 12301-0008 USA
|
|
From: Mark H. <mh...@pi...> - 2002-08-29 17:29:38
|
TIP #107: YES |
|
From: D. R. H. <dr...@hw...> - 2002-08-29 17:40:10
|
TIP #107: Yes -- D. Richard Hipp -- dr...@hw... -- http://www.hwaci.com/drh/ |
|
From: Donal K. F. <don...@ma...> - 2002-08-30 08:40:49
|
Donald G Porter wrote: > > Michael J McLennan wrote: > > > TIP #107: FIX THE 2-SECOND "RAISE DELAY" IN TK > > > This is one of the the most important TIPs I've seen. This is one "yes" > > for our TYANNOTT. If we get another and no one else objects, just go > > ahead and make the change. > > Looks like a vote sponsorship to me. For sake of a definite end, lets > say votes should be cast (to Michael) by [clock format 1031068800]. That's strange; I've not seen the message that you are replying to. TIP#107: YES (Why does [raise] wait anyway? Most of the rest of Tk is async...) Donal. -- Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ don...@ma... -- I'm curious; where does this statistic come from? Does its home, perchance, ever see sunlight? -- Jason A Williams <jas...@co...> |
|
From: Andreas K. <and...@Ac...> - 2002-08-30 15:37:24
|
TIP #107: PRESENT Not enough knowledge 'bout Tk. -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com Join Tcl'2002 in Vancouver http://www.tcl.tk/community/tcl2002/ ** Registration is open ** |
|
From: Brent W. <we...@pa...> - 2002-08-30 21:36:24
|
TIP #107: YES [raise] waits so that the [wm stackorder] command returns accurate results. noone but the test suite seems to care much. >>>"Donal K. Fellows" said: > Donald G Porter wrote: > > > > Michael J McLennan wrote: > > > > TIP #107: FIX THE 2-SECOND "RAISE DELAY" IN TK > > > > > This is one of the the most important TIPs I've seen. This is one "yes" > > > for our TYANNOTT. If we get another and no one else objects, just go > > > ahead and make the change. > > > > Looks like a vote sponsorship to me. For sake of a definite end, lets > > say votes should be cast (to Michael) by [clock format 1031068800]. > > That's strange; I've not seen the message that you are replying to. > > TIP#107: YES > > (Why does [raise] wait anyway? Most of the rest of Tk is async...) > > Donal. > -- > Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ don...@ma... .uk > -- I'm curious; where does this statistic come from? Does its home, perchanc e, > ever see sunlight? -- Jason A Williams <jas...@co...n.a c.u k> > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core -- Brent Welch Software Architect, Panasas Inc Pioneering the World's Most Scalable and Agile Storage Network www.panasas.com we...@pa... |
|
From: Mo D. <su...@ba...> - 2002-09-04 18:58:23
|
On Fri, 30 Aug 2002 14:36:12 -0700 Brent Welch <we...@pa...> wrote: > TIP #107: YES > > [raise] waits so that the [wm stackorder] command returns accurate > results. noone but the test suite seems to care much. I have to admit that I am a little concerned about that. How can we ever check to see if the raise, lower, or wm stackorder commands are working properly if we just remove the test cases? If this is only a problem with some window managers then why not just return right away on these buggy systems? Mo |
|
From: Jeff H. <Je...@Ac...> - 2002-09-04 19:08:46
|
> > TIP #107: YES > > > > [raise] waits so that the [wm stackorder] command returns accurate > > results. noone but the test suite seems to care much. > > I have to admit that I am a little concerned about that. How can > we ever check to see if the raise, lower, or wm stackorder commands > are working properly if we just remove the test cases? If this is only > a problem with some window managers then why not just return > right away on these buggy systems? Knowing which systems are buggy is hard to the point of futile to check for. The tests weren't removed, a small delay was added (100msecs with update) to allow even a slow X connection to do it's work, and then the result is checked. I think this is a good compromise. Jeff |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X