TkTests

(i) scrollbar.test scrollbar-3.42

2008-07-04

Problem: test scrollbar-3.42 fails under windows. Idea: test scrollbar-3.42 # line 288 place configure .t.s -width [expr [winfo reqwidth .t.s] - 4] place configure .t.s -width [expr {([winfo reqwidth .t.s] - 4) / 2}] Explenation test: #line 281 toplevel .t -width 250 -height 100 wm geom .t +0+0 scrollbar .t.s -orient horizontal -borderwidth 2 place .t.s -width 201 update if {[testConstraint testmetrics]} { place configure .t.s -width [expr 2*[testmetrics cxhscroll .t.s]+1] } else { puts [winfo reqwidth .t.s] place configure .t.s -width [expr {([winfo reqwidth .t.s] - 4)/2}] } update test scrollbar-3.42 {ScrollbarWidgetCmd procedure, "fraction" option} { .t.s fraction 100 0 } {0} Although, according to man page the result of a test should be 1, pathName fraction x y Returns a real number between 0 and 1 indicating where the point given by x and y lies in the trough area of the scrollbar. The value 0 corresponds to the top or left of the trough, the value 1 corresponds to the bottom or right, 0.5 corresponds to the middle, and so on. X and y must be pixel coordinates relative to the scrollbar widget. If x and y refer to a point outside the trough, the closest point in the trough is used. ) nevertheless, according to tkScrollbar.c that differs: /* tkScrollbar.c*/ // line 329 } else if ((c == 'f') && (strncmp(argv[1], "fraction", length) == 0)) { int x, y, pos, length; [...] if (scrollPtr->vertical) { pos = y - (scrollPtr->arrowLength + scrollPtr->inset); length = Tk_Height(scrollPtr->tkwin) - 1 - 2*(scrollPtr->arrowLength + scrollPtr->inset); } else { pos = x - (scrollPtr->arrowLength + scrollPtr->inset); length = Tk_Width(scrollPtr->tkwin) - 1- 2*(scrollPtr->arrowLength + scrollPtr->inset); } if (length == 0) { fraction = 0.0; } else { fraction = ((double) pos / (double) length); } if (fraction < 0) { fraction = 0; } else if (fraction > 1.0) { fraction = 1.0; } The goal of the test case is following situation: pos >= 0; length <= 0 (as place configure .t.s -width [expr [winfo reqwidth .t.s] - 4] aims at creating the widget which length is smaller than requested by window's geometry manager). However, It's not considered that the [expr [winfo reqwidth .t.s] - 4] (where 4 is for scrollbar .t.s -borderwidth 2) value is greater than 1+ 2*(scrollPtr->arrowLength + scrollPtr->inset); (in contrary to Unix) /* tkUnixScrlbr.c */ // line 339 if (scrollPtr->vertical) { Tk_GeometryRequest(scrollPtr->tkwin, scrollPtr->width + 2*scrollPtr->inset, 2*(scrollPtr->arrowLength + scrollPtr->borderWidth + scrollPtr->inset)); } else { Tk_GeometryRequest(scrollPtr->tkwin, 2*(scrollPtr->arrowLength + scrollPtr->borderWidth+ scrollPtr->inset), scrollPtr->width + 2*scrollPtr->inset); } Tk_SetInternalBorder(scrollPtr->tkwin, scrollPtr->inset); /* tkWinScrlbr.c */ // line 464 if (scrollPtr->vertical) { Tk_GeometryRequest(scrollPtr->tkwin, scrollPtr->width, 2*scrollPtr->arrowLength + minThumbSize); } else { Tk_GeometryRequest(scrollPtr->tkwin, 2*scrollPtr->arrowLength + minThumbSize, scrollPtr->width); } Tk_SetInternalBorder(scrollPtr->tkwin, 0); minThumbSize = hThumb; hThumb = GetSystemMetrics(SM_CXHTHUMB); GetSystemMetrics - This function retrieves the dimensions of Windows display elements and system configuration settings. SM_CXHTHUMB - For retrieving the width of the thumb box in a horizontal scroll bar, in pixels. In a result even if we set place configure .t.s -width [expr [winfo reqwidth .t.s] - 4] tkScrollbar.c's variable length may still be > 0 under Windows I suggest p.e. dividing place configure .t.s -width [expr {([winfo reqwidth .t.s] - 4) / 2}]

(.) frame.test frame-2.5

2008-07-03

Problem: test scrollbar-3.42 fails under windows. Questions How to figure out in tcl if a definition was made during the compilation? Add another constraint? Explenation This frame.test is only analyzing the platform if {$tcl_platform(platform) == "windows"} { test frame-2.5 {toplevel configuration options} { catch {destroy .t} toplevel .t -width 200 -height 100 wm geometry .t +0+0 list [catch {.t configure -use 0x44022} msg] $msg [.t configure -use] } {1 {window "0x44022" doesn't exist} {-use use Use {} {}}} } else { test frame-2.5 {toplevel configuration options} { catch {destroy .t} toplevel .t -width 200 -height 100 wm geometry .t +0+0 list [catch {.t configure -use 0x44022} msg] $msg [.t configure -use] } {1 {can't modify -use option after widget is created} {-use use Use {} {}}} } while in tkFrame.c there is only definition checked /* * Don't allow the options -class, -colormap, -container, -screen, * -use, or -visual to be changed. */ // line 775 #ifdef SUPPORT_CONFIG_EMBEDDED if (c == 'u') { //this checks if -use is changed const char *string = Tcl_GetString(objv[i+1]); if (TkpUseWindow(interp, framePtr->tkwin, string) != TCL_OK) { result = TCL_ERROR; goto done; } } else { Tcl_AppendResult(interp, "can't modify ", arg, " option after widget is created", NULL); result = TCL_ERROR; goto done; } #else Tcl_AppendResult(interp, "can't modify ", arg, " option after widget is created", NULL); result = TCL_ERROR; goto done; #endif When compiling Tcl under Windows by Msys + Mingw, there's created Makefile that doesn't contain SUPPORT_CONFIG_EMBEDDED definition (in contrary to Makefile.vc and Makefile.bc). I didn't manage to find how to figure out if a definition was made during the compilation. Moreover, as those compilations differ, should detecting the way of windows compilation be add as another constraint?

(?) wm.test - wm-geometry-2.1 in Ubuntu

2008-07-03

Problem: wm.test - wm-geometry-2.1 fails under Ubuntu Question: How to obtain Ubuntu's left top edge of the screen? Explenation: I've encountered strange behavior of wm geometry x and x coordination in Ubuntu (8.04 Gnome) ==== wm-geometry-2.1 setting values FAILED ==== Contents of test case: wm geometry .t 150x150+50+50 update lappend result [wm geometry .t] wm geometry .t {} update lappend result [string equal [wm geometry .t] "150x150+50+50"] ---- Result was: 150x150+55+74 0 ---- Result should have been (exact matching): 150x150+50+50 0 As test wm-geometry-2.1 (wm.test) fails in this environment, I checked and for following code >toplevel .t >wm geometry .t 200x200+0+0 >wm geometry .t it returns 200x200+5+24 In Ubuntu's default settings GNOME Panel consists of 2 panels: top one and bottom one. Both height is 24 pixels and this is where 24 px come from, but those 5 of height are inexplicable. -If I move panel to the left it sometimes reacts 200x200+5+24 (even after rebooting) and sometimes returns 200x200+30+24 -If I move the top panel on the right, wm geometry .t still shows the same results, but the widget itself moves up those 24px that panel took screenshot: http://www.assembla.com/spaces/TkTests/documents/dFjqsKsoKr3Bdjab7jnrAJ/download/wmGeometryScreen1 -If I get back, the results now increase to 200x200+5+49 screenshot: http://www.assembla.com/spaces/TkTests/documents/a7tbJ4soOr3yHuab7jnrAJ/download/wmGeometryScreen2 To make it worse, it always (no matter what I do) > wm geometry .t 150x150-0-0 > wm geometry .t >150x150--5--24 On the live CD with default settings >toplevel .t >wm geometry .t 200x200+0+0 >wm geometry .t it returns 200x200+5+49 As this happens only on Ubuntu, should this be taken care in the test? I tried to find out if any parameter corresponds somehow with the results (so that I could count the tktest result), but with no effect.

(?i) constraints.tcl - testConstraint fonts

2008-07-02

Problems: Often failing testConstraint fonts Different font metrics. Suggestion: adding -highlightthickness configuration of entry Question: Try to make the constraints in a way that they'd be more likely to pass? Explenation: I've encountered strange behavior of wm geometry x and x coordination in Ubuntu (8.04 Gnome) TestConstraint fonts is often used in tktests. Should I try to make the constraints in a way that they'd be more likely to pass (and then, according to that, also update tests)? # line 184 entry .e -width 0 -font {Helvetica -12} -bd 1 .e insert end a.bcd winfo reqwidth .e if {([winfo reqwidth .e] != 37) || ([winfo reqheight .e] != 20)} { testConstraint fonts 0 } -> XP - 34 -> Slackware - 36 -> Ubuntu -37 (correct according to the constraint) I've noticed, that there should be the -highlightthickness 1 option in entry .e as Windows' default value is 0 in contrary to Slack's and Ubuntu's. This changed the value reqwidth to 36, which still doesn't meet the expectiations... The problem of reqwidth lies in the font measure; % font measure {Helvetica -12} -displayof .e "a.bcd" >> winXP: 30 >> Ubuntu: 31 (they differ in the c letter) I was wondering if not conduct tests on a popular font with fixed-width font, where each normal character is the same width as all the other characters, p.e. Courier, Verdana (% font metrics Courier -fixed ). This, I suppose, would substatntially influence on similar reqwidth values. However, there's still the same value of reqheight needed for font constraint passing. This requires the same font metrics values which I couldn't achieve in my environments. To sum up - I wonder whether try to make the constraints in a way that they'd be more likely to pass.