* emblem drawing glitches on linux @ 2003-06-26 0:58 Tom Lowshang 2003-06-26 0:59 ` Eric McDonald 2003-06-26 4:35 ` Hans Ronne 0 siblings, 2 replies; 24+ messages in thread From: Tom Lowshang @ 2003-06-26 0:58 UTC (permalink / raw) To: xconq7 Hi all, my first post to this list. With so few posters here, how could anyone _not_ notice a first post? :-) When moving a unit, I can see emblems being drawn and erased in adjacent cells if at least one of those cells has not been seen before. If another unit becomes active, then the emblems around first unit remain on the map. There are other cases where the emblems remain, but I can't quite figured the pattern out. I can erase the extra emblems by redrawing the map, so they are really just a visual nuisance. Everything works fine otherwise. I use xconq under linux (debian sid) and tck/tk 8.4.3. No difference with tcl/tk 8.3.5. I also did a fresh CVS check out, since I have been messing with the code a bit, but no luck. Since no one else has reported this problem under linux, I do wonder whether it is a something peculiar on my system or perhaps debian, but I am not yet convinced. Tom ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: emblem drawing glitches on linux 2003-06-26 0:58 emblem drawing glitches on linux Tom Lowshang @ 2003-06-26 0:59 ` Eric McDonald 2003-06-26 4:41 ` Tom Lowshang 2003-06-26 4:35 ` Hans Ronne 1 sibling, 1 reply; 24+ messages in thread From: Eric McDonald @ 2003-06-26 0:59 UTC (permalink / raw) To: Tom Lowshang; +Cc: xconq7 On Wed, 25 Jun 2003, Tom Lowshang wrote: > When moving a unit, I can see emblems being drawn and erased in > adjacent cells if at least one of those cells has not been seen > before. If another unit becomes active, then the emblems around > first unit remain on the map. There are other cases where the > emblems remain, but I can't quite figured the pattern out. I > can erase the extra emblems by redrawing the map, so they are > really just a visual nuisance. Everything works fine otherwise. Hi Tom, I don't think I have seen your problem on my Linux/X11 system. I doubt this is the case, but: If you have the People view option turned on, then emblems will be drawn demarcating your country's border. Furthermore, your emblem will also be placed on cells in which you have intruded into an enemy's country. Does this perhaps fit the behavior you are seeing? Eric ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: emblem drawing glitches on linux 2003-06-26 0:59 ` Eric McDonald @ 2003-06-26 4:41 ` Tom Lowshang 2003-06-26 5:49 ` Eric McDonald 2003-06-26 16:00 ` emblem drawing glitches on linux Hans Ronne 0 siblings, 2 replies; 24+ messages in thread From: Tom Lowshang @ 2003-06-26 4:41 UTC (permalink / raw) To: xconq7 On Wed, Jun 25, 2003 at 06:28:35PM -0400, Eric McDonald wrote: > On Wed, 25 Jun 2003, Tom Lowshang wrote: > > > When moving a unit, I can see emblems being drawn and erased > > in adjacent cells if at least one of those cells has not > > been seen before. If another unit becomes active, then the > > emblems around first unit remain on the map. There are > > other cases where the emblems remain, but I can't quite > > figured the pattern out. I can erase the extra emblems by > > redrawing the map, so they are really just a visual > > nuisance. Everything works fine otherwise. > > Hi Tom, > > I don't think I have seen your problem on my Linux/X11 > system. > > I doubt this is the case, but: If you have the People view > option turned on, then emblems will be drawn demarcating > your country's border. Furthermore, your emblem will also be > placed on cells in which you have intruded into an enemy's > country. Does this perhaps fit the behavior you are seeing? > > Eric People view is off but the behaviour is similar in that the emblems usually never appear in cells your have seen before. Are you using x11 or tcl/tk interface? A screenshot would be great right now, but changing focus on the xconq window redraws the map and clears the errant emblems :-( so let me try a more detailed description. I am in the introductory game, turn 4. I move the unit 1 cell NE, everything is ok. Turn 5, I move NE again, but now 5 emblems appear briefly in the adjacent cells to the W, NW, NE, E, and SE of the unit. The emblems remain long enough to be visible, then they are erased. I move NE until turn 8 and the above effect repeats each turn. But in turn 8 the next unit is completed, so now when I move the first unit NE again, the second unit becomes active, and the 5 emblems remain visible around the first unit. I move second unit NE. Turn 9, move second unit NE again, but no emblems appear in adjacent cells, like they did for first the unit. Move first unit NE, the emblems quickly appear and disappear again. Turn 10, unit 1 is still active so I move it NE. When the second unit becomes active, the 5 emblems around the first unit are again left on the map. Phew, that's enough I hope. Note that was the simplest possible example could come up with. I played a complete introductory game and I could tell there were more complicated patterns occurring, so I hope the simple case is helpful. Tom ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: emblem drawing glitches on linux 2003-06-26 4:41 ` Tom Lowshang @ 2003-06-26 5:49 ` Eric McDonald 2003-06-26 16:00 ` Tom Lowshang 2003-06-26 16:00 ` emblem drawing glitches on linux Hans Ronne 1 sibling, 1 reply; 24+ messages in thread From: Eric McDonald @ 2003-06-26 5:49 UTC (permalink / raw) To: Tom Lowshang; +Cc: xconq7 On Wed, 25 Jun 2003, Tom Lowshang wrote: > People view is off but the behaviour is similar in that the > emblems usually never appear in cells your have seen before. > Are you using x11 or tcl/tk interface? I am using the Tcl/Tk interface on X11. Are you using the Xt/Xaw interface? > A screenshot would be great right now, but changing focus on the > xconq window redraws the map and clears the errant emblems :-( IIRC, xv had a time-delayed screen capture option (so a user could get shots of selected menu items, etc...). That would give you time to move a unit and then tell the wayward emblems to say cheese. Eric ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: emblem drawing glitches on linux 2003-06-26 5:49 ` Eric McDonald @ 2003-06-26 16:00 ` Tom Lowshang 2003-06-26 22:55 ` Eric McDonald 0 siblings, 1 reply; 24+ messages in thread From: Tom Lowshang @ 2003-06-26 16:00 UTC (permalink / raw) To: xconq7 On Thu, Jun 26, 2003 at 01:19:53AM -0400, Eric McDonald wrote: > On Wed, 25 Jun 2003, Tom Lowshang wrote: > > > Are you using x11 or tcl/tk interface? > > I am using the Tcl/Tk interface on X11. Are you using the > Xt/Xaw interface? No, I am using tcl/tk interface, with tcl/tk 8.4.3. Which version of tcl/tk are you using? However, I don't think the problem relates to tcl/tk version since I tried 8.3.5 and the same thing occured. > > > A screenshot would be great right now, but changing focus on > > the xconq window redraws the map and clears the errant > > emblems :-( > > IIRC, xv had a time-delayed screen capture option Good idea! I will check into this. Tom ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: emblem drawing glitches on linux 2003-06-26 16:00 ` Tom Lowshang @ 2003-06-26 22:55 ` Eric McDonald 2003-06-26 23:04 ` (linux) xconq errors at exit Tom Lowshang 0 siblings, 1 reply; 24+ messages in thread From: Eric McDonald @ 2003-06-26 22:55 UTC (permalink / raw) To: Tom Lowshang; +Cc: xconq7 On Thu, 26 Jun 2003, Tom Lowshang wrote: > No, I am using tcl/tk interface, with tcl/tk 8.4.3. Which > version of tcl/tk are you using? However, I don't think the > problem relates to tcl/tk version since I tried 8.3.5 and the > same thing occured. I am using Tcl/Tk 8.3.3. I agree that the Tcl version is probably not the issue. On a somewhat unrelated note, could you tell me if you get BadWindow and BadDrawable messages on your console from games that are started from the setup dialogs (as opposed to starting them with -g from the command line)? Of some interest is whether these are occuring with Tk 8.4 and higher.... Thanks, Eric ^ permalink raw reply [flat|nested] 24+ messages in thread
* (linux) xconq errors at exit 2003-06-26 22:55 ` Eric McDonald @ 2003-06-26 23:04 ` Tom Lowshang 2003-06-27 1:02 ` Hans Ronne 2003-06-27 1:33 ` Eric McDonald 0 siblings, 2 replies; 24+ messages in thread From: Tom Lowshang @ 2003-06-26 23:04 UTC (permalink / raw) To: xconq7 On Thu, Jun 26, 2003 at 05:49:23PM -0400, Eric McDonald wrote: > > On a somewhat unrelated note, could you tell me if you get > BadWindow and BadDrawable messages on your console from games > that are started from the setup dialogs (as opposed to > starting them with -g from the command line)? Of some interest > is whether these are occuring with Tk 8.4 and higher.... > If I start xconq on console, I get "X error on display :0.0: BadWindow (invalid Window parameter)" when xconq exits only. The message repeat several time. This happens whether I use -g or setup dialogs. I also just discovered that that xconq does not handle the window closing well, either. If I close a setup dialog, xconq does not exit until I interrupt it with control-c. If I close the map window, I see the above message, followed by: Fatal error encountered. Signal 11 Error: invalid command name ".m1.leftside.topside.notices.t" Error: while evaluating `low_notify {Game was saved to "/home/tlow/.xconq/ERRsave.xcq". }' Aborted I usually do not run xconq from a console, so I have not seen these messages before. Tom ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: (linux) xconq errors at exit 2003-06-26 23:04 ` (linux) xconq errors at exit Tom Lowshang @ 2003-06-27 1:02 ` Hans Ronne 2003-06-27 1:33 ` Eric McDonald 1 sibling, 0 replies; 24+ messages in thread From: Hans Ronne @ 2003-06-27 1:02 UTC (permalink / raw) To: Tom Lowshang; +Cc: xconq7 >On Thu, Jun 26, 2003 at 05:49:23PM -0400, Eric McDonald wrote: >> >> On a somewhat unrelated note, could you tell me if you get >> BadWindow and BadDrawable messages on your console from games >> that are started from the setup dialogs (as opposed to >> starting them with -g from the command line)? Of some interest >> is whether these are occuring with Tk 8.4 and higher.... >> > >If I start xconq on console, I get "X error on display :0.0: >BadWindow (invalid Window parameter)" when xconq exits only. The >message repeat several time. This happens whether I use -g or >setup dialogs. The BadWindow/BadDrawable message is triggered by using the "wm withdraw" command within the tcl script, and this always happens at the end of the setup dialog (when the dialog is withdrawn). If you look at the error messages you will find that there is one pair less if you use -g since one tcl window less (the setup dialog) is withdrawn in that case. This is what Eric meant. The other error messages come from other dialogs that you close during the game or during exit. >I also just discovered that that xconq does not handle the >window closing well, either. If I close a setup dialog, xconq >does not exit until I interrupt it with control-c. If I close >the map window, I see the above message, followed by: > >Fatal error encountered. Signal 11 This is a known problem. I don't think it's related to the BadDrawable messages. Hans ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: (linux) xconq errors at exit 2003-06-26 23:04 ` (linux) xconq errors at exit Tom Lowshang 2003-06-27 1:02 ` Hans Ronne @ 2003-06-27 1:33 ` Eric McDonald 2003-06-27 3:51 ` Tom Lowshang 1 sibling, 1 reply; 24+ messages in thread From: Eric McDonald @ 2003-06-27 1:33 UTC (permalink / raw) To: Tom Lowshang; +Cc: xconq7 On Thu, 26 Jun 2003, Tom Lowshang wrote: > If I start xconq on console, I get "X error on display :0.0: > BadWindow (invalid Window parameter)" when xconq exits only. The > message repeat several time. This happens whether I use -g or > setup dialogs. Which Tk is this with? (Not that it probably matters; I am simply looking for data points...) Also, when you say "when xconq exits only", do you mean you watch these messages only appear on your console while Xconq is exiting and not before? And, if so, were any other Xconq windows, besides the one that contains the map displays, open? > Fatal error encountered. Signal 11 That's a segmentation fault. There is deeply entwined interaction between the Tcl/Tk part of the interface and the C part of the interface, and if something goes away in one (and its memory gets deallocated) then the other might very well get a little bit upset. Probably more safeguards could be put in place.... It's something I might investigate once I find a way to appropriately deal with the BadWindow/BadDrawable stuff. Thanks for the data, Eric ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: (linux) xconq errors at exit 2003-06-27 1:33 ` Eric McDonald @ 2003-06-27 3:51 ` Tom Lowshang 2003-06-27 14:47 ` [RFC] Possible BadWindow/BadDrawable Fix Eric McDonald 0 siblings, 1 reply; 24+ messages in thread From: Tom Lowshang @ 2003-06-27 3:51 UTC (permalink / raw) To: xconq7 On Thu, Jun 26, 2003 at 09:02:51PM -0400, Eric McDonald wrote: > > Which Tk is this with? (Not that it probably matters; I am > simply looking for data points...) 8.4.3 > > Also, when you say "when xconq exits only", do you mean you > watch these messages only appear on your console while Xconq > is exiting and not before? And, if so, were any other Xconq > windows, besides the one that contains the map displays, open? Yes, that is what I meant, but I was bit hasty in that conclusion. After pressing Q, the messages actually appear whenever one of the exit dialogs opens and/or closes. The specific exit dialogs that I am refering to are "Do you want to save game before quitting", "You cannot quit without resigning", and "You lost!". Hope this helps. Tom ^ permalink raw reply [flat|nested] 24+ messages in thread
* [RFC] Possible BadWindow/BadDrawable Fix 2003-06-27 3:51 ` Tom Lowshang @ 2003-06-27 14:47 ` Eric McDonald 2003-06-27 19:45 ` Hans Ronne 0 siblings, 1 reply; 24+ messages in thread From: Eric McDonald @ 2003-06-27 14:47 UTC (permalink / raw) To: xconq7 So far the only way I have been able to get rid of the BadWindow errors in the Tcl/Tk interface on X is to destroy a window after it is withdrawn. This can be done in tkconq.tcl with: wm withdraw .windowpath destroy .windowpath Perhaps the "destroy" part could be wrapped in: if { "$tcl_platform(platform)" == "unix" } { } Or it can be done in tkmain.c with: tkwin = Tk_NameToWindow(interp, ".windowpath", Tk_MainWindow(interp)); if (NULL == tkwin){ /* Appropriate error message here. */ } else{ Tk_UnmapWindow(tkwin); Tk_DestroyWindow(tkwin); } And perhaps this could be wrapped in an appropriate #ifdef. This has implications for window reuse. In the case of the .newgame window, it doesn't really matter, but means that other windows will need to be recreated from scratch each time they show up in the game. My personal opinion is that new users are more likely to be scared off by the X messages than by a slightly longer delay due to window recreation. This delay is probably negligible on most modern machines, _not that I am advocating the neglect of older machines.... I will make up the necessary patches tomorrow, if I see no serious objections to this proposal. Thanks, Eric ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] Possible BadWindow/BadDrawable Fix 2003-06-27 14:47 ` [RFC] Possible BadWindow/BadDrawable Fix Eric McDonald @ 2003-06-27 19:45 ` Hans Ronne 2003-06-28 17:51 ` [Patch] " Eric McDonald 0 siblings, 1 reply; 24+ messages in thread From: Hans Ronne @ 2003-06-27 19:45 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 > So far the only way I have been able to get rid of the BadWindow errors in >the Tcl/Tk interface on X is to destroy a window after it is withdrawn. > >This can be done in tkconq.tcl with: >Or it can be done in tkmain.c with: The second solution seems to be the best way if it works. >And perhaps this could be wrapped in an appropriate #ifdef. > > This has implications for window reuse. In the case of the .newgame window, >it doesn't really matter, but means that other windows will need to be >recreated from scratch each time they show up in the game. > > My personal opinion is that new users are more likely to be scared off >by the >X messages than by a slightly longer delay due to window recreation. This >delay >is probably negligible on most modern machines, _not that I am advocating the >neglect of older machines.... I don't think it matters under linux, either. But in MacTCL and WinTCL, performance would suffer. However, if you use #ifdef UNIX things should be OK. Hans ^ permalink raw reply [flat|nested] 24+ messages in thread
* [Patch] BadWindow/BadDrawable Fix 2003-06-27 19:45 ` Hans Ronne @ 2003-06-28 17:51 ` Eric McDonald 0 siblings, 0 replies; 24+ messages in thread From: Eric McDonald @ 2003-06-28 17:51 UTC (permalink / raw) To: xconq7 On Fri, 27 Jun 2003, Hans Ronne wrote: > >Or it can be done in tkmain.c with: > > The second solution seems to be the best way if it works. OK, here is pretty much everything. I still need to think about dealing with the error and warning dialogs because they use tk_messageBox, but this should fix (at least it does on my machine) the BadWindow/BadDrawable errors for: .newgame, .prefs, .find, .contour, .research, .gameover, .meridian, .help, .scores, .design, and .agreements (even though I know this last window is currently unused). I also did a few cosmetic brushups to the Tcl code for the research dialog since it appeared to be overindented in my editor. And included is the small patch to tkmap.c that I sent to the list a few days ago. It never made it into CVS. All it does is remove a compile-time warning. --- orig-tkconq.h Fri Jun 27 21:44:21 2003 +++ tkconq.h Fri Jun 27 21:47:32 2003 @@ -315,6 +315,8 @@ extern void init_x_signal_handlers(void); /* Lives in xconq.c. */ +extern int withdraw_window (const char *, Tcl_Interp *); + extern void initial_ui_init(void); extern void init_display(void); extern void init_redraws(void); --- orig-tkmain.c Fri Jun 27 20:22:38 2003 +++ tkmain.c Fri Jun 27 23:09:09 2003 @@ -195,6 +195,8 @@ TclCmdFn mapw_cmd; TclCmdFn imfsample_cmd; +TclCmdFn tk_withdraw_window; + void update_mouseover(Map *map, int rawx, int rawy); /* Declarations of local functions. */ @@ -346,6 +348,7 @@ tcl_cmd("get_scores", tk_get_scores); tcl_cmd("reset_popup_flag", tk_reset_popup_flag); tcl_cmd("exit_xconq", tk_exit_xconq); + tcl_cmd("withdraw_window", tk_withdraw_window); tkwin = Tk_MainWindow(interp); @@ -4255,4 +4258,52 @@ void end_printing_forms(void) { +} + +int +tk_withdraw_window( \ + ClientData cldata, Tcl_Interp *interp, int argc, char *argv[]) +{ + if (2 > argc){ + /* TODO: How should we report the error? */ + return TCL_ERROR; + } + return withdraw_window(argv[1], interp); +} + +/* + * Does the equivalent of "wm withdraw" in Tcl/Tk with the additional + * step of destroying the window on X11 to get rid of the BadWindow messages. + */ +int +withdraw_window (const char * windowpath, Tcl_Interp * interp) +{ + + Tk_Window tkwin = NULL; +#ifdef UNIX + Window xid = 0; +#endif + + tkwin = Tk_NameToWindow(interp, (char *)windowpath, Tk_MainWindow(interp)); + if (NULL == tkwin){ + /* Assume that the user may have closed the window. + ...for now, anyway... + We may get smarter about this someday. + */ + Dprintf("Could not find window %s.\n", windowpath); + } + else{ +#ifdef UNIX + xid = Tk_WindowId(tkwin); +#endif + Tk_UnmapWindow(tkwin); +#ifdef UNIX + Tk_DestroyWindow(tkwin); + Dprintf("Unmapped window %s with XID %x.\n", windowpath, (unsigned)xid); +#else + Dprintf("Unmapped window %s.\n", windowpath); +#endif + } + return TCL_OK; + } --- orig-tkconq.tcl Fri Jun 27 21:48:30 2003 +++ tkconq.tcl Fri Jun 27 23:41:09 2003 @@ -1424,7 +1424,7 @@ } launch_game # Once the game is underway, we can make this dialog go away. - wm withdraw .newgame + withdraw_window ".newgame" } set indepside_up 0 @@ -2928,7 +2928,7 @@ -bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \ -fg $fgcolor -activeforeground $afcolor -width 8 button .contour.bottom.cancel -text "Cancel" \ - -command { wm withdraw .contour } \ + -command { withdraw_window ".contour" } \ -bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \ -fg $fgcolor -activeforeground $afcolor -width 8 grid .contour.bottom.cancel .contour.bottom.ok -sticky ew -padx 8 -pady 4 @@ -2936,7 +2936,7 @@ bind .contour <Key> { if {"%K" == "Escape"} { .contour.bottom.cancel flash - wm withdraw .contour + withdraw_window ".contour" } elseif {"%K" == "Return"} { .contour.bottom.ok flash ok_contour_interval @@ -2952,7 +2952,7 @@ execute_long_command $map_number($contour_interval_map) \ "map contour-interval=$contour_interval" - wm withdraw .contour + withdraw_window ".contour" } set new_meridian_interval 0 @@ -2994,7 +2994,7 @@ -bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \ -fg $fgcolor -activeforeground $afcolor -width 8 button .meridian.bottom.cancel -text "Cancel" \ - -command { wm withdraw .meridian } \ + -command { withdraw_window ".meridian" } \ -bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \ -fg $fgcolor -activeforeground $afcolor -width 8 grid .meridian.bottom.cancel .meridian.bottom.ok -sticky ew -padx 8 -pady 4 @@ -3002,7 +3002,7 @@ bind .meridian <Key> { if {"%K" == "Escape"} { .meridian.bottom.cancel flash - wm withdraw .meridian + withdraw_window ".meridian" } elseif {"%K" == "Return"} { .meridian.bottom.ok flash ok_meridian_interval @@ -3018,7 +3018,7 @@ set default_map_options(meridian_interval) $new_meridian_interval set_map_view_option .m1 meridian_interval - wm withdraw .meridian + withdraw_window ".meridian" } # Given a map window, set up all of its standard event bindings. @@ -3690,7 +3690,7 @@ } proc ask_bool_done { mapn } { - wm withdraw .bool + wm withdraw .bool destroy .bool } @@ -3877,7 +3877,8 @@ button .find.bottom.find -text "Find" -command ok_find -default active \ -bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \ -fg $fgcolor -activeforeground $afcolor -width 8 - button .find.bottom.cancel -text "Cancel" -command { wm withdraw .find } \ + button .find.bottom.cancel -text "Cancel" \ + -command { withdraw_window ".find" } \ -bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \ -fg $fgcolor -activeforeground $afcolor -width 8 grid .find.bottom.cancel .find.bottom.find -sticky ew -padx 8 -pady 4 @@ -3885,7 +3886,7 @@ bind .find <Key> { if {"%K" == "Escape"} { .find.bottom.cancel flash - wm withdraw .find + withdraw_window ".find" } elseif {"%K" == "Return"} { .find.bottom.find flash ok_find @@ -3907,7 +3908,7 @@ if { $rslt == 0 } { bell } else { - wm withdraw .find + withdraw_window ".find" } } @@ -3946,16 +3947,17 @@ frame .research.bottom -bg $bgcolor pack .research.bottom -side bottom -fill x button .research.bottom.ok -text "Research" -command ok_research \ - -bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \ - -fg $fgcolor -activeforeground $afcolor + -bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \ + -fg $fgcolor -activeforeground $afcolor pack .research.bottom.ok -side left -padx 5 -pady 5 button .research.bottom.rest -text "Rest" -command rest_research \ - -bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \ - -fg $fgcolor -activeforeground $afcolor + -bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \ + -fg $fgcolor -activeforeground $afcolor pack .research.bottom.rest -side left -padx 5 -pady 5 - button .research.bottom.cancel -text "Close" -command { wm withdraw .research } \ - -bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \ - -fg $fgcolor -activeforeground $afcolor + button .research.bottom.cancel -text "Close" \ + -command { withdraw_window ".research" } \ + -bg $bgcolor -highlightbackground $hbcolor -activebackground $abcolor \ + -fg $fgcolor -activeforeground $afcolor pack .research.bottom.cancel -side left -padx 5 -pady 5 listbox .research.topics -selectmode browse -width 25 \ @@ -4005,12 +4007,12 @@ return } set_side_research $i - wm withdraw .research + withdraw_window ".research" } proc rest_research {} { set_side_research nothing - wm withdraw .research + withdraw_window ".research" } # Create and popup an agreement editing window. @@ -4131,7 +4133,7 @@ } proc close_agreements_window {} { - wm withdraw .agreements + withdraw_window ".agreements" } proc update_agreement_display {} { @@ -4205,7 +4207,7 @@ } proc dismiss_scores {} { - wm withdraw .scores + withdraw_window ".scores" } # Create and popup the preferences dialog. @@ -4275,7 +4277,7 @@ bind .prefs <Key> { if {"%K" == "Escape"} { .prefs.bot.cancel flash - wm withdraw .prefs + withdraw_window ".prefs" } elseif {"%K" == "Return"} { .prefs.bot.ok flash ok_preferences @@ -4728,7 +4730,7 @@ # Make the dialog go away, without altering any preferences. proc dismiss_preferences_dialog {} { - wm withdraw .prefs + withdraw_window ".prefs" } # Create and popup the help window. @@ -4994,7 +4996,7 @@ # Make the dialog go away. proc dismiss_help_dialog {} { - wm withdraw .help + withdraw_window ".help" } # Game save dialog. @@ -5108,7 +5110,7 @@ } proc dismiss_game_over_dialog {} { - wm withdraw .gameover + withdraw_window ".gameover" } proc disable_move_mode {} { @@ -5980,7 +5982,7 @@ proc dismiss_design_palette {} { if { "[ winfo exists .design ]" } { - wm withdraw .design + withdraw_window ".design" } } --- orig-tkmap.c Fri Jun 27 23:48:29 2003 +++ tkmap.c Fri Jun 27 23:49:29 2003 @@ -4230,7 +4230,7 @@ the interface freeze. */ XDrawLines(dpy, d, gc, points, 5, CoordModeOrigin); } -#endif MAC +#endif /* MAC */ XFlush(dpy); XSetFunction(dpy, gc, GXcopy); ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: emblem drawing glitches on linux 2003-06-26 4:41 ` Tom Lowshang 2003-06-26 5:49 ` Eric McDonald @ 2003-06-26 16:00 ` Hans Ronne 2003-06-26 16:15 ` Tom Lowshang 1 sibling, 1 reply; 24+ messages in thread From: Hans Ronne @ 2003-06-26 16:00 UTC (permalink / raw) To: Tom Lowshang; +Cc: xconq7 >I am in the introductory game, turn 4. I move the unit 1 cell >NE, everything is ok. Turn 5, I move NE again, but now 5 emblems >appear briefly in the adjacent cells to the W, NW, NE, E, and SE >of the unit. The emblems remain long enough to be visible, then >they are erased. I move NE until turn 8 and the above effect >repeats each turn. But in turn 8 the next unit is completed, so >now when I move the first unit NE again, the second unit becomes >active, and the 5 emblems remain visible around the first unit. >I move second unit NE. Turn 9, move second unit NE again, but >no emblems appear in adjacent cells, like they did for first the >unit. Move first unit NE, the emblems quickly appear and >disappear again. Turn 10, unit 1 is still active so I move it >NE. When the second unit becomes active, the 5 emblems around >the first unit are again left on the map. This is something I have never seen, either on Linux, Mac or Windows. We did have certain redraw problems before I rewrote the unit view code, but they were of a different kind. And these problems are gone now. Are the emblems you are seeing that of your own side? Hans ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: emblem drawing glitches on linux 2003-06-26 16:00 ` emblem drawing glitches on linux Hans Ronne @ 2003-06-26 16:15 ` Tom Lowshang 2003-06-26 21:49 ` Hans Ronne 0 siblings, 1 reply; 24+ messages in thread From: Tom Lowshang @ 2003-06-26 16:15 UTC (permalink / raw) To: xconq7 On Thu, Jun 26, 2003 at 07:34:43AM +0200, Hans Ronne wrote: > > This is something I have never seen, either on Linux, Mac or > Windows. We did have certain redraw problems before I rewrote > the unit view code, but they were of a different kind. And > these problems are gone now. Unfortunately I have not run cvs update in some months, so I cannot say if the problem relates to any recent changes. > > Are the emblems you are seeing that of your own side? Yes, they are. Sorry I forgot to mention that before. The discussion so far suggests that the problem is specific to my system (or debian). Does anyone else think this is likely? Tom ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: emblem drawing glitches on linux 2003-06-26 16:15 ` Tom Lowshang @ 2003-06-26 21:49 ` Hans Ronne 2003-07-05 0:36 ` Tom Lowshang 0 siblings, 1 reply; 24+ messages in thread From: Hans Ronne @ 2003-06-26 21:49 UTC (permalink / raw) To: Tom Lowshang; +Cc: xconq7 >On Thu, Jun 26, 2003 at 07:34:43AM +0200, Hans Ronne wrote: >> >> This is something I have never seen, either on Linux, Mac or >> Windows. We did have certain redraw problems before I rewrote >> the unit view code, but they were of a different kind. And >> these problems are gone now. > >Unfortunately I have not run cvs update in some months, so I >cannot say if the problem relates to any recent changes. That's the first thing to test, then. It is also good to do this is if you are using TclTk 8.4. Full source compatibility with 8.4 was added just a few weeks ago. But I agree that it is most likely a specific issue with your system, since I never heard of this problem even before the unit view changes. Hans ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: emblem drawing glitches on linux 2003-06-26 21:49 ` Hans Ronne @ 2003-07-05 0:36 ` Tom Lowshang 2003-07-05 4:39 ` Hans Ronne 0 siblings, 1 reply; 24+ messages in thread From: Tom Lowshang @ 2003-07-05 0:36 UTC (permalink / raw) To: xconq7 The glitches were introduced by the checkin on 2003-05-01, which is mostly to do with unit views. This checkin still covers a lot of code though, so is there anything I can do to narrow it down further? Tom ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: emblem drawing glitches on linux 2003-07-05 0:36 ` Tom Lowshang @ 2003-07-05 4:39 ` Hans Ronne 2003-07-05 8:28 ` Tom Low-Shang 0 siblings, 1 reply; 24+ messages in thread From: Hans Ronne @ 2003-07-05 4:39 UTC (permalink / raw) To: Tom Lowshang; +Cc: xconq7 >The glitches were introduced by the checkin on 2003-05-01, which >is mostly to do with unit views. This checkin still covers a lot >of code though, so is there anything I can do to narrow it down >further? Thanks, that was very useful information. Unfortunately, the new unit view code was a major change all over the kernel and the interfaces, so it is difficult to take it apart. However, for technical reasons I doubt that the problem is with the unit view code itself. Rather, I suspect some other changes thst were made at the same time. Two things come to mind: 1. There was a change in update_cell (end of tkmap.c) where an "erasing row" now always is drawn if we see unit views instead of units and unit names are shown on the map. What happens if you turn off unit names? Do you still see the glitches? And what happens if you start the game with see-all? Do they disappear then? 2. There weer also some changes to draw_current which draws the current unit. What happens if you back out of these changes (if possible) so that the unit view-specific code is bypassed? One way to achieve thtis is to change line 3246 in tkmap.c from: if (vp->show_all) { to: if (1) { Hans ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: emblem drawing glitches on linux 2003-07-05 4:39 ` Hans Ronne @ 2003-07-05 8:28 ` Tom Low-Shang 2003-07-05 16:11 ` Hans Ronne 0 siblings, 1 reply; 24+ messages in thread From: Tom Low-Shang @ 2003-07-05 8:28 UTC (permalink / raw) To: xconq7 On Sat, Jul 05, 2003 at 02:32:56AM +0200, Hans Ronne wrote: > > 1. There was a change in update_cell (end of tkmap.c) where an > "erasing row" now always is drawn if we see unit views instead > of units and unit names are shown on the map. What happens if > you turn off unit names? Do you still see the glitches? Unit names were already off so I tried with unit names on. There is a small change but the glitches are still there. The difference is that the glitch emblems only appear in the W and NW cells, instead of W, NW, NE, E, and SE cells as they did in my long turn-by-turn description of the problem. > And what happens if you start the game with see-all? Do they > disappear then? Yes! The problem goes away completely. > > 2. There weer also some changes to draw_current which draws > the current unit. What happens if you back out of these > changes (if possible) so that the unit view-specific code is > bypassed? No glitch emblems! This looks promising. Let me know if there is anything else you would like me to try. Tom ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: emblem drawing glitches on linux 2003-07-05 8:28 ` Tom Low-Shang @ 2003-07-05 16:11 ` Hans Ronne 2003-07-05 16:20 ` Tom Low-Shang 0 siblings, 1 reply; 24+ messages in thread From: Hans Ronne @ 2003-07-05 16:11 UTC (permalink / raw) To: Tom Low-Shang; +Cc: xconq7 >Unit names were already off so I tried with unit names on. >There is a small change but the glitches are still there. The >difference is that the glitch emblems only appear in the W and >NW cells, instead of W, NW, NE, E, and SE cells as they did in >my long turn-by-turn description of the problem. OK. That's because the name erasing code in part erases your glitch. >> And what happens if you start the game with see-all? Do they >> disappear then? > >Yes! The problem goes away completely. > >> >> 2. There weer also some changes to draw_current which draws >> the current unit. What happens if you back out of these >> changes (if possible) so that the unit view-specific code is >> bypassed? > >No glitch emblems! This looks promising. Let me know if there >is anything else you would like me to try. I'm not 100% sure whay the problem is yet, but perhaps you could try this patch in draw_current: if (vp->show_all) { x_xform_unit_self(mapw, unit, &sx, &sy, &sw, &sh); } else if (uview) { rslt = x_xform_unit_self_view(mapw, uview, &sx, &sy, &sw, &sh); /* This may be called while there is no view object for the current unit, such as while updating the display when the unit moves and is "between" cells. */ if (!rslt) return; + } else { + return; } Hans ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: emblem drawing glitches on linux 2003-07-05 16:11 ` Hans Ronne @ 2003-07-05 16:20 ` Tom Low-Shang 2003-07-07 18:17 ` Hans Ronne 0 siblings, 1 reply; 24+ messages in thread From: Tom Low-Shang @ 2003-07-05 16:20 UTC (permalink / raw) To: xconq7 On Sat, Jul 05, 2003 at 10:25:51AM +0200, Hans Ronne wrote: > I'm not 100% sure whay the problem is yet, but perhaps you could try this > patch in draw_current: > > if (vp->show_all) { > x_xform_unit_self(mapw, unit, &sx, &sy, &sw, &sh); > } else if (uview) { > rslt = x_xform_unit_self_view(mapw, uview, &sx, &sy, &sw, &sh); > /* This may be called while there is no view object for > the current unit, such as while updating the display > when the unit moves and is "between" cells. */ > if (!rslt) > return; > + } else { > + return; > } The glitch emblems do not appear when I make the above changes. Tom ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: emblem drawing glitches on linux 2003-07-05 16:20 ` Tom Low-Shang @ 2003-07-07 18:17 ` Hans Ronne 0 siblings, 0 replies; 24+ messages in thread From: Hans Ronne @ 2003-07-07 18:17 UTC (permalink / raw) To: Tom Low-Shang; +Cc: xconq7 >The glitch emblems do not appear when I make the above changes. Excellent. This was clearly a bug, even if it had no effects for most people. I will check in the fix. Thanks for your help in debugging it. Hans ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: emblem drawing glitches on linux 2003-06-26 0:58 emblem drawing glitches on linux Tom Lowshang 2003-06-26 0:59 ` Eric McDonald @ 2003-06-26 4:35 ` Hans Ronne 2003-06-26 5:46 ` Tom Lowshang 1 sibling, 1 reply; 24+ messages in thread From: Hans Ronne @ 2003-06-26 4:35 UTC (permalink / raw) To: Tom Lowshang; +Cc: xconq7 >Hi all, my first post to this list. With so few posters here, >how could anyone _not_ notice a first post? :-) > >When moving a unit, I can see emblems being drawn and erased in >adjacent cells if at least one of those cells has not been seen >before. If another unit becomes active, then the emblems around >first unit remain on the map. There are other cases where the >emblems remain, but I can't quite figured the pattern out. I >can erase the extra emblems by redrawing the map, so they are >really just a visual nuisance. Everything works fine otherwise. Welcome to the list! It's always nice to get user feedback. I'm not sure I understand the problem you describe, though. Do you mean that you see emblems without units being drawn? That would be strange indeed, unless you have turned on "View People" or "View Control", both of which use emblems without units to denote borders. OTOH, if you are talking about unit-associated emblems, they should always be drawn, whether the unit is active or not. A possible complication if you are using linux is that you have two versions of xconq: an obsolete installed version and a current CVS version. Even if you build and run the CVS version, it may still use the installed libraries and tcl scripts if that is where XCONQLIB points on your system. This is a frequent source of problems since the tcl scripts of one version of xconq seldom are completely compatible with another version. Hans ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: emblem drawing glitches on linux 2003-06-26 4:35 ` Hans Ronne @ 2003-06-26 5:46 ` Tom Lowshang 0 siblings, 0 replies; 24+ messages in thread From: Tom Lowshang @ 2003-06-26 5:46 UTC (permalink / raw) To: xconq7 On Thu, Jun 26, 2003 at 12:42:45AM +0200, Hans Ronne wrote: > > I'm not sure I understand the problem you describe, though. Do > you mean that you see emblems without units being drawn? That > would be strange indeed, unless you have turned on "View > People" or "View Control", both of which use emblems without > units to denote borders. OTOH, if you are talking Yes the emblems appear without units. View People and View Control are both off, but the extra emblems are appearing in border cells. See my long turn by turn description in another mail. > about unit-associated emblems, they should always be drawn, > whether the unit is active or not. Unit enblems are ok. > > A possible complication if you are using linux is that you > have two versions of xconq: an obsolete installed version and > a current CVS version. Even if you build and run the CVS > version, it may still use the installed libraries and tcl > scripts if that is where XCONQLIB points on your system. This > is a frequent source of problems since the tcl scripts of one > version of xconq seldom are completely compatible with another > version. Only the CVS version is installed. Just to be safe, I removed the install directory to ensure no stale files existed, and ran make install again, but it did not help. Tom ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2003-07-05 16:20 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-06-26 0:58 emblem drawing glitches on linux Tom Lowshang 2003-06-26 0:59 ` Eric McDonald 2003-06-26 4:41 ` Tom Lowshang 2003-06-26 5:49 ` Eric McDonald 2003-06-26 16:00 ` Tom Lowshang 2003-06-26 22:55 ` Eric McDonald 2003-06-26 23:04 ` (linux) xconq errors at exit Tom Lowshang 2003-06-27 1:02 ` Hans Ronne 2003-06-27 1:33 ` Eric McDonald 2003-06-27 3:51 ` Tom Lowshang 2003-06-27 14:47 ` [RFC] Possible BadWindow/BadDrawable Fix Eric McDonald 2003-06-27 19:45 ` Hans Ronne 2003-06-28 17:51 ` [Patch] " Eric McDonald 2003-06-26 16:00 ` emblem drawing glitches on linux Hans Ronne 2003-06-26 16:15 ` Tom Lowshang 2003-06-26 21:49 ` Hans Ronne 2003-07-05 0:36 ` Tom Lowshang 2003-07-05 4:39 ` Hans Ronne 2003-07-05 8:28 ` Tom Low-Shang 2003-07-05 16:11 ` Hans Ronne 2003-07-05 16:20 ` Tom Low-Shang 2003-07-07 18:17 ` Hans Ronne 2003-06-26 4:35 ` Hans Ronne 2003-06-26 5:46 ` Tom Lowshang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).