Menu
▾
▴
tcl-mac
|
From: Kevin W. <kw...@co...> - 2015-01-31 04:05:30
|
Hi all, Just a quick note to let you know I have committed the last of my HITheme work in Tk-Cocoa to trunk and core-8-5-branch; initial reports suggest that these changes address many of the serious bugs that folks have reported in recent months, especially since I removed the private Cocoa API's last summer. With these commits, this phase of major, active development on Tk/Cocoa is done. There have been enough changes over the past year that I don't feel unjustified in referring to this iteration as "Tk-Cocoa 2.0." I've posted a blog entry here that goes into more detail on the history, the technical issues, and what these changes mean: http://www.codebykevin.com/blosxom.cgi/2015/01/30#tk-cocoa-2.0 I think Tk-Cocoa is now improved. Thanks to all who have provided feedback, bug reports, patches, and encouragement. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com |
|
From: Will D. <wil...@gm...> - 2015-01-31 16:12:57
|
Thank you, Kevin! On Fri, Jan 30, 2015 at 8:06 PM Kevin Walzer <kw...@co...> wrote: > Hi all, > > Just a quick note to let you know I have committed the last of my > HITheme work in Tk-Cocoa to trunk and core-8-5-branch; initial reports > suggest that these changes address many of the serious bugs that folks > have reported in recent months, especially since I removed the private > Cocoa API's last summer. > > With these commits, this phase of major, active development on Tk/Cocoa > is done. There have been enough changes over the past year that I don't > feel unjustified in referring to this iteration as "Tk-Cocoa 2.0." I've > posted a blog entry here that goes into more detail on the history, the > technical issues, and what these changes mean: > > http://www.codebykevin.com/blosxom.cgi/2015/01/30#tk-cocoa-2.0 > > I think Tk-Cocoa is now improved. Thanks to all who have provided > feedback, bug reports, patches, and encouragement. > > --Kevin > > -- > Kevin Walzer > Code by Kevin/Mobile Code by Kevin > http://www.codebykevin.com > http://www.wtmobilesoftware.com > > > ------------------------------------------------------------ > ------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Tcl-mac mailing list > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac > |
|
From: Torsten B. <be...@ty...> - 2015-02-13 08:02:05
|
Dear Kevin,
this is really great and a big „thank you“ for these improvements! I didn’t work with the intermediate versions showing the flickering and ghost images, but with the current trunk all looks to me like it did before, so I cannot easily spot the subtle visual differences that would be there.
The only thing I do observe is a mysterious crash when resizing the main window of the application that I am currently developing. I cannot reproduce this with a blank wish window (without any widgets inside) or with just one widget, though.
When I resize the window slowly, even holding down the mouse button on a spot for a while, then moving on, everything is OK. After waiting for some fraction of a second, the window will even resize (while still holding the mouse button pressed) and resize more or less smoothly while dragging the mouse further across the screen. From your description, however, I would have expected it not to resize at all until the mouse button is released.
But when I do the resize very quickly, moving the mouse fast across the screen, the application will crash, leaving this behind:
(using a 32bit wish 8.6.3 embedded build on OS X 10.9.5)
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000010000020
VM Regions Near 0x10000020:
MALLOC_LARGE 00000000075bb000-000000000765c000 [ 644K] rw-/rwx SM=PRV
-->
__TEXT 000000008feee000-000000008ff21000 [ 204K] r-x/rwx SM=COW /usr/lib/dyld
Application Specific Information:
objc_msgSend() selector name: release
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x9915c4a7 objc_msgSend + 23
1 com.apple.AppKit 0x97a7336a -[NSBitmapGraphicsContext dealloc] + 38
2 libobjc.A.dylib 0x991725ef -[NSObject release] + 47
3 libobjc.A.dylib 0x9915e497 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 527
4 com.apple.CoreFoundation 0x9559991f _CFAutoreleasePoolPop + 47
5 com.apple.Foundation 0x98615c24 -[NSAutoreleasePool drain] + 122
6 com.apple.AppKit 0x9835438d -[NSWindow(NSWindowResizing) _resizeWithEvent:] + 668
7 com.apple.AppKit 0x98133112 -[NSTitledFrame resizeWithEvent:] + 43
8 com.apple.AppKit 0x97c70176 -[NSTitledFrame mouseDown:] + 217
9 com.apple.AppKit 0x97c6ff27 -[NSThemeFrame mouseDown:] + 212
10 com.apple.AppKit 0x97b80a9d -[NSWindow sendEvent:] + 11953
11 com.apple.AppKit 0x97b1c91d -[NSApplication sendEvent:] + 4034
12 Tk 0x000da148 0x8000 + 860488
13 Tk 0x000da555 0x8000 + 861525
14 Tcl 0x001fe99c Tcl_DoOneEvent + 308
15 Tk 0x0001ec0d Tk_MainLoop + 41
16 Tk 0x0002cba6 Tk_MainEx + 2038
17 wish-aqua8.6 0x000044c3 0x1000 + 13507
18 wish-aqua8.6 0x00004451 0x1000 + 13393
Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0 libsystem_kernel.dylib 0x93578992 kevent64 + 10
1 libdispatch.dylib 0x97172899 _dispatch_mgr_invoke + 238
2 libdispatch.dylib 0x97172532 _dispatch_mgr_thread + 52
Thread 2:
0 libsystem_kernel.dylib 0x93578046 __workq_kernreturn + 10
1 libsystem_pthread.dylib 0x93f33dcf _pthread_wqthread + 372
2 libsystem_pthread.dylib 0x93f37cce start_wqthread + 30
Thread 3:
0 libsystem_kernel.dylib 0x93578046 __workq_kernreturn + 10
1 libsystem_pthread.dylib 0x93f33dcf _pthread_wqthread + 372
2 libsystem_pthread.dylib 0x93f37cce start_wqthread + 30
Thread 4:
0 libsystem_kernel.dylib 0x93578046 __workq_kernreturn + 10
1 libsystem_pthread.dylib 0x93f33dcf _pthread_wqthread + 372
2 libsystem_pthread.dylib 0x93f37cce start_wqthread + 30
Thread 5:
0 libsystem_kernel.dylib 0x93577ace __select + 10
1 Tcl 0x0024d2e4 0x13d000 + 1114852
2 libsystem_pthread.dylib 0x93f325fb _pthread_body + 144
3 libsystem_pthread.dylib 0x93f32485 _pthread_start + 130
4 libsystem_pthread.dylib 0x93f37cf2 thread_start + 34
Thread 6:
0 libsystem_kernel.dylib 0x93572f7a mach_msg_trap + 10
1 libsystem_kernel.dylib 0x9357216c mach_msg + 68
2 com.apple.CoreFoundation 0x955d5bf9 __CFRunLoopServiceMachPort + 169
3 com.apple.CoreFoundation 0x955d51d1 __CFRunLoopRun + 1393
4 com.apple.CoreFoundation 0x955d49ea CFRunLoopRunSpecific + 394
5 com.apple.CoreFoundation 0x955d484b CFRunLoopRunInMode + 123
6 com.apple.AppKit 0x97b18b88 _NSEventThread + 283
7 libsystem_pthread.dylib 0x93f325fb _pthread_body + 144
8 libsystem_pthread.dylib 0x93f32485 _pthread_start + 130
9 libsystem_pthread.dylib 0x93f37cf2 thread_start + 34
Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x0213a1d0 ebx: 0x98615bb8 ecx: 0x99178167 edx: 0x10000000
edi: 0x0213aac0 esi: 0x97a73351 ebp: 0xbfffeee8 esp: 0xbfffeec8
ss: 0x00000023 efl: 0x00010202 eip: 0x9915c4a7 cs: 0x0000001b
ds: 0x00000023 es: 0x00000023 fs: 0x00000000 gs: 0x0000000f
cr2: 0x10000020
Logical CPU: 3
Error Code: 0x00000004
Trap Number: 14
It seems it could have something to do with timing. If the application has enough time to adjust, then OK, but if the change is „too radical“ or just too quick (too many events in a short time?), then the crash occurs. This is reproducible in 9 out of 10 times.
Another thing I noticed. The main window is having the rounded corners at the top side, but the bottom side has sharp corners, not looking like the typical Cocoa window (this is not new though, I observed this in older wish versions too). However, when doing the resizing of the main window, the corners turn into rounded ones and when the mouse button is released, the corners turn sharp again. Any idea what that may be caused by? It seems, Tk or the underlying Cocoa is drawing the window correctly, but then someone is drawing a sharp corner on top afterwards. Where could I look to find out how to remove this behavior?
Torsten
> Hi all,
>
> Just a quick note to let you know I have committed the last of my
> HITheme work in Tk-Cocoa to trunk and core-8-5-branch; initial reports
> suggest that these changes address many of the serious bugs that folks
> have reported in recent months, especially since I removed the private
> Cocoa API's last summer.
>
> With these commits, this phase of major, active development on Tk/Cocoa
> is done. There have been enough changes over the past year that I don't
> feel unjustified in referring to this iteration as "Tk-Cocoa 2.0." I've
> posted a blog entry here that goes into more detail on the history, the
> technical issues, and what these changes mean:
>
> http://www.codebykevin.com/blosxom.cgi/2015/01/30#tk-cocoa-2.0
>
> I think Tk-Cocoa is now improved. Thanks to all who have provided
> feedback, bug reports, patches, and encouragement.
>
> --Kevin
>
> --
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
|
|
From: Kevin W. <kw...@co...> - 2015-02-13 14:35:35
|
Hi Torsten, Thanks for the feedback. On 2/13/15 2:49 AM, Torsten Berg wrote: > > When I resize the window slowly, even holding down the mouse button on a spot for a while, then moving on, everything is OK. After waiting for some fraction of a second, the window will even resize (while still holding the mouse button pressed) and resize more or less smoothly while dragging the mouse further across the screen. From your description, however, I would have expected it not to resize at all until the mouse button is released. > > But when I do the resize very quickly, moving the mouse fast across the screen, the application will crash, leaving this behind: > (using a 32bit wish 8.6.3 embedded build on OS X 10.9.5) I've seen this in one or two instances; since you are reproducing it consistently it's obviously not just some random glitch. (I thought the problem was just on my system.) I suspect it's a result of the resize code I put in; I'll take a look and see if removing it solves the crash. > It seems it could have something to do with timing. If the application has enough time to adjust, then OK, but if the change is �too radical� or just too quick (too many events in a short time?), then the crash occurs. This is reproducible in 9 out of 10 times. It's setting window visibility to false and disabling screen updates, so it may not be able to keep up with a rapid stream of events. I may just have to take that out and leave a bit of flicker during resize--it will still be reduced because of the other changes I've made. I'll report back soon. > > Another thing I noticed. The main window is having the rounded corners at the top side, but the bottom side has sharp corners, not looking like the typical Cocoa window (this is not new though, I observed this in older wish versions too). However, when doing the resizing of the main window, the corners turn into rounded ones and when the mouse button is released, the corners turn sharp again. Any idea what that may be caused by? It seems, Tk or the underlying Cocoa is drawing the window correctly, but then someone is drawing a sharp corner on top afterwards. Where could I look to find out how to remove this behavior? No idea about this; I think I've seen it too, but IMO it is a minor visual artifact that I will probably not have time to address. I'll report back when I have something updated to test. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com |
|
From: Kevin W. <kw...@co...> - 2015-02-14 01:29:33
|
Hi Russell and Torsten, On 2/13/15 7:25 PM, Russell Owen wrote: > >>> It seems it could have something to do with timing. If the >>> application has enough time to adjust, then OK, but if the change is >>> �too radical� or just too quick (too many events in a short time?), >>> then the crash occurs. This is reproducible in 9 out of 10 times. >> It's setting window visibility to false and disabling screen updates, so >> it may not be able to keep up with a rapid stream of events. I may just >> have to take that out and leave a bit of flicker during resize--it will >> still be reduced because of the other changes I've made. I'll report >> back soon. > > I personally would rather have the flicker than the delay in the start > of resizing. But either way works and it is your call, since you are > doing the work! > > I realize a null result isn't much help but I tried rapidly resizing > some windows on my system (MacOS X 10.9.5 using the 8.5 branch of > tcl/tk checked out earlier today) and I have not been able to induce a > crash. That's with a plain wish window and with two applications I wrote. > I think I've fixed the issue: I was doing multiple calls to NSDisableScreenUpdates() and NSEnableScreenUpdates(), as well as setting the state of the main NSView to hidden, during resize events--once during the actual resize event, and also during the notification of the resize event. It was the NSNotification call that seemed to be clogging the event loop and causing the crash; removing those calls, but leaving them during the resize, preserves the smoothness I was striving for, but doesn't trigger any crashes in my testing. (I was testing this using the TkChat app I maintain, which I was able to crash consistently when resizing it quickly.) See if the new commits help the issue on your end. Thanks, Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com |
|
From: Russell O. <ro...@uw...> - 2015-02-14 23:50:30
|
I’m not seeing any hangs in this version (but I didn’t in the previous version, either). — Russell On Feb 13, 2015, at 5:29 PM, Kevin Walzer <kw...@co...> wrote: > Hi Russell and Torsten, > > On 2/13/15 7:25 PM, Russell Owen wrote: >> >>>> It seems it could have something to do with timing. If the application has enough time to adjust, then OK, but if the change is �too radical� or just too quick (too many events in a short time?), then the crash occurs. This is reproducible in 9 out of 10 times. >>> It's setting window visibility to false and disabling screen updates, so >>> it may not be able to keep up with a rapid stream of events. I may just >>> have to take that out and leave a bit of flicker during resize--it will >>> still be reduced because of the other changes I've made. I'll report >>> back soon. >> >> I personally would rather have the flicker than the delay in the start of resizing. But either way works and it is your call, since you are doing the work! >> >> I realize a null result isn't much help but I tried rapidly resizing some windows on my system (MacOS X 10.9.5 using the 8.5 branch of tcl/tk checked out earlier today) and I have not been able to induce a crash. That's with a plain wish window and with two applications I wrote. >> > > I think I've fixed the issue: I was doing multiple calls to NSDisableScreenUpdates() and NSEnableScreenUpdates(), as well as setting the state of the main NSView to hidden, during resize events--once during the actual resize event, and also during the notification of the resize event. It was the NSNotification call that seemed to be clogging the event loop and causing the crash; removing those calls, but leaving them during the resize, preserves the smoothness I was striving for, but doesn't trigger any crashes in my testing. (I was testing this using the TkChat app I maintain, which I was able to crash consistently when resizing it quickly.) > > See if the new commits help the issue on your end. > > Thanks, > Kevin > > -- > Kevin Walzer > Code by Kevin/Mobile Code by Kevin > http://www.codebykevin.com > http://www.wtmobilesoftware.com > |
|
From: Torsten B. <be...@ty...> - 2015-02-15 23:06:28
|
Dear Kevin,
thanks, yes this fixes the issue. I cannot crash the application any longer. That’s good! Now, I just see some visual artifacts when making a window larger. Some kind of black marks that are left behind from the lower right corner of the window when I slowly make the window larger and wait for the window to resize and then continue dragging. But that is OK as long as the app does not crash!
But there is another thing. When the vertical scrollbar is in the „empty“ state, i.e. the content is not so large that scrolling is enabled and the gray bar is not shown, then it seems the widget collapses into a small quadrate as if ignoring any -sticky or -fill options. Try to run this script displaying a listbox with vertical and horizontal scrollbar attached:
set parent .f
frame $parent -relief flat -borderwidth 1 -background #a8a8a8
# upper left:
set win $parent.ctrl
listbox $win -relief flat -borderwidth 0
# lower left:
ttk::scrollbar $parent.sx -orient horizontal -command [list $win xview]
grid $parent.sx -column 0 -row 1 -sticky ew
$win configure -xscrollcommand [list $parent.sx set]
# upper right:
ttk::scrollbar $parent.sy -orient vertical -command [list $win yview]
grid $parent.sy -column 1 -row 0 -sticky ns
$win configure -yscrollcommand [list $parent.sy set]
# lower right:
frame $parent.lr -background #fafafa
grid $parent.lr -column 1 -row 1 -sticky news
# Arrange child widget in the parent frame:
grid $win -column 0 -row 0 -sticky nsew
grid columnconfigure $parent 0 -weight 1
grid rowconfigure $parent 0 -weight 1
pack $parent -fill both -expand yes
# insert some data:
for {set i 0} {$i < 20} {incr i} {$win insert end $i}
Initially, everything seems ok, the vertical scrollbar is there and is functional. But when making the window longer than the content of the twenty rows, the vertical scrollbar area changes its appearance and the scrollbar trough collapses to a small area in the middle of the vertical scrollbar. Is that reproducible at your end?
As for the sharp corners of the main window, you are right, this is nothing major and I didn’t intend to make you „fix“ this. I just thought you might know where to look for such a thing and I could try myself with my limited knowledge to the complex structure of the Tk code.
Torsten
> I think I've fixed the issue: I was doing multiple calls to
> NSDisableScreenUpdates() and NSEnableScreenUpdates(), as well as setting
> the state of the main NSView to hidden, during resize events--once
> during the actual resize event, and also during the notification of the
> resize event. It was the NSNotification call that seemed to be clogging
> the event loop and causing the crash; removing those calls, but leaving
> them during the resize, preserves the smoothness I was striving for, but
> doesn't trigger any crashes in my testing. (I was testing this using the
> TkChat app I maintain, which I was able to crash consistently when
> resizing it quickly.)
>
> See if the new commits help the issue on your end.
|
|
From: Kevin W. <kw...@co...> - 2015-02-16 03:14:06
|
Hi Torsten,
Glad resizing no longer crashes your app. :-)
On 2/15/15 6:06 PM, Torsten Berg wrote:
> But there is another thing. When the vertical scrollbar is in the �empty� state, i.e. the content is not so large that scrolling is enabled and the gray bar is not shown, then it seems the widget collapses into a small quadrate as if ignoring any -sticky or -fill options. Try to run this script displaying a listbox with vertical and horizontal scrollbar attached:
I saw what you have described during the development of the new scroll
implementation. During those times it seemed that the system couldn't
correctly calculate the bounds of the scrollbar and so shrank to that
minimal rect.
I'm a bit surprised to see it now. I can certainly say that it does not
show up in other cases where the entire view is visibile, thus not
requiring a scrollbar; the scroll trough is drawn correctly, without
scrollbar. For instance, if I rewrite the code you presented as a simple
UI with a listbox and a scrollbar packed in a frame, the scrollbar
renders as expected. The example you presented, with all of its gridding
and vars and child widgets, was so complicated that I didn't understand
what it was, originally.
I can't say exactly what it causing the issue in your example; the
HITheme scrollbar was so difficult to implement that I am not likely to
dig into what is, essentially, a cosmetic issue. Even in your example,
the scrollbar comes back as required if the window is resized. And the
issue is not evident at all if you use a simpler layout.
My own example is below for your reference. --Kevin
frame .f
pack .f -fill both -expand yes
listbox .f.list
pack .f.list -fill both -expand yes -side left
ttk::scrollbar .f.scroll -command [list .f.list yview]
pack .f.scroll -side right -fill y -expand no
.f.list configure -yscrollcommand [list .f.scroll set]
# insert some data:
for {set i 0} {$i < 20} {incr i} {.f.list insert end $i}
--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com
|
|
From: Torsten B. <be...@ty...> - 2015-02-16 07:34:05
|
Hi Kevin,
I can reproduce that your example works. We do not need the vars and grid ding at all, you are right. I just more or less copied the relevant part of the code from my application. Now, just add these 3 lines to sour example:
ttk::scrollbar .f.scrollx -orient horizontal -command [list .f.list xview]
pack .f.scrollx -side bottom -fill x
.f.list configure -xscrollcommand [list .f.scrollx set]
Then, the bug occurs again (you do not even need the 3rd line). So, only when both vertical AND horizontal scrollbars are present, it is exposed. It does also NOT show up when just resizing (= enlarging) the window and keeping the mouse pointer outside the vertical scrollbar area. But as soon as you move the pointer into the vertical scrollbar area, the trough collapses (but of course only when you have a horizontal scrollbar at the same time. E.g. having two vertical scrollbars does not show the bug). I hope this helps to track the problem down …
Regards, Torsten
Am 16.02.2015 um 04:13 schrieb Kevin Walzer <kw...@co...>:
> Hi Torsten,
>
> Glad resizing no longer crashes your app. :-)
>
> On 2/15/15 6:06 PM, Torsten Berg wrote:
>> But there is another thing. When the vertical scrollbar is in the �empty� state, i.e. the content is not so large that scrolling is enabled and the gray bar is not shown, then it seems the widget collapses into a small quadrate as if ignoring any -sticky or -fill options. Try to run this script displaying a listbox with vertical and horizontal scrollbar attached:
> I saw what you have described during the development of the new scroll
> implementation. During those times it seemed that the system couldn't
> correctly calculate the bounds of the scrollbar and so shrank to that
> minimal rect.
>
> I'm a bit surprised to see it now. I can certainly say that it does not
> show up in other cases where the entire view is visibile, thus not
> requiring a scrollbar; the scroll trough is drawn correctly, without
> scrollbar. For instance, if I rewrite the code you presented as a simple
> UI with a listbox and a scrollbar packed in a frame, the scrollbar
> renders as expected. The example you presented, with all of its gridding
> and vars and child widgets, was so complicated that I didn't understand
> what it was, originally.
>
> I can't say exactly what it causing the issue in your example; the
> HITheme scrollbar was so difficult to implement that I am not likely to
> dig into what is, essentially, a cosmetic issue. Even in your example,
> the scrollbar comes back as required if the window is resized. And the
> issue is not evident at all if you use a simpler layout.
>
> My own example is below for your reference. --Kevin
>
> frame .f
> pack .f -fill both -expand yes
>
> listbox .f.list
> pack .f.list -fill both -expand yes -side left
>
>
> ttk::scrollbar .f.scroll -command [list .f.list yview]
> pack .f.scroll -side right -fill y -expand no
>
> .f.list configure -yscrollcommand [list .f.scroll set]
>
> # insert some data:
> for {set i 0} {$i < 20} {incr i} {.f.list insert end $i}
>
> --
> Kevin Walzer
> Code by Kevin/Mobile Code by Kevin
> http://www.codebykevin.com
> http://www.wtmobilesoftware.com
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
|
|
From: Kevin W. <kw...@co...> - 2015-02-16 15:58:23
|
Torsten, On 2/16/15 2:33 AM, Torsten Berg wrote: > Then, the bug occurs again (you do not even need the 3rd line). So, only when both vertical AND horizontal scrollbars are present, it is exposed. It does also NOT show up when just resizing (= enlarging) the window and keeping the mouse pointer outside the vertical scrollbar area. But as soon as you move the pointer into the vertical scrollbar area, the trough collapses (but of course only when you have a horizontal scrollbar at the same time. E.g. having two vertical scrollbars does not show the bug). I hope this helps to track the problem down … OK, I see the issue when the horizontal scrollbar is added. However, we still haven't addressed the core part of my question to you: Is this a cosmetic or functional bug? Is scrolling hindered in some way because of this issue, or is it just a visual glitch? All of my testing indicates that it is visual: yes, it looks a little funny, but the scrollbar appears when required and scrolling is not hindered, nor is the overall layout of a window hindered. I have less time at present to work on Tk, so I am prioritizing functional bugs: If this issue messes up layout somehow (as radio and checkbutton metrics still do), or if it causes a consistent crash, as the resizing did, then that gets focus. Cosmetic bugs are much lower priority. The scrollbar does not get darker when it is pressed; that's possible to implement in HITheme, but figuring out the right place to toggle the pressed/not-pressed state is tricky, and I decided not to spend further time on it. What we have is good enough. Similarly, checkbuttons with an "indiatoron" state look very different than standard checkbuttons; they are rendered using a Unix-style layout. It's ugly, but there's no easy way to show that natively, so I left it as is. It's good enough. This bug is falling into the cosmetic category for me, and as such, I am not likely to spend much time on it unless my reading of the situation is wrong. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com |
|
From: Torsten B. <be...@ty...> - 2015-02-17 07:03:05
|
Dear Kevin, no, it is not a functional bug. Everything is working as far as I can tell, and I can surely understand that you do not want to spend time on a visual „glitch“. I am always inclined to try and make it perfect ;-) Torsten > Torsten, > > On 2/16/15 2:33 AM, Torsten Berg wrote: >> Then, the bug occurs again (you do not even need the 3rd line). So, only when both vertical AND horizontal scrollbars are present, it is exposed. It does also NOT show up when just resizing (= enlarging) the window and keeping the mouse pointer outside the vertical scrollbar area. But as soon as you move the pointer into the vertical scrollbar area, the trough collapses (but of course only when you have a horizontal scrollbar at the same time. E.g. having two vertical scrollbars does not show the bug). I hope this helps to track the problem down … > OK, I see the issue when the horizontal scrollbar is added. > > However, we still haven't addressed the core part of my question to you: > Is this a cosmetic or functional bug? > > Is scrolling hindered in some way because of this issue, or is it just a > visual glitch? All of my testing indicates that it is visual: yes, it > looks a little funny, but the scrollbar appears when required and > scrolling is not hindered, nor is the overall layout of a window hindered. > > I have less time at present to work on Tk, so I am prioritizing > functional bugs: If this issue messes up layout somehow (as radio and > checkbutton metrics still do), or if it causes a consistent crash, as > the resizing did, then that gets focus. > > Cosmetic bugs are much lower priority. The scrollbar does not get darker > when it is pressed; that's possible to implement in HITheme, but > figuring out the right place to toggle the pressed/not-pressed state is > tricky, and I decided not to spend further time on it. What we have is > good enough. Similarly, checkbuttons with an "indiatoron" state look > very different than standard checkbuttons; they are rendered using a > Unix-style layout. It's ugly, but there's no easy way to show that > natively, so I left it as is. It's good enough. > > This bug is falling into the cosmetic category for me, and as such, I am > not likely to spend much time on it unless my reading of the situation > is wrong. > > --Kevin > > -- > Kevin Walzer > Code by Kevin/Mobile Code by Kevin > http://www.codebykevin.com > http://www.wtmobilesoftware.com > |
×
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