Menu
▾
▴
tcl-mac
|
From: Russell O. <ro...@uw...> - 2014-12-06 00:55:02
|
I have a log window consisting of a Text widget, scroll bar, and various widgets to control the display. Some of of the control widgets are usually hidden, using grid.remove() to remove the parent frame of the widgets. With Tcl/Tk 8.5.17 on MacOS we see the hidden widgets briefly appear whenever the main frame for this window receives an <Expose> event. Unfortunately such an event occurs whenever a new item is appended to the log (I'm not sure why). New lines can come in quite often, leading to an annoying flicker of the hidden widgets. Clearly this is merely a cosmetic annoyance. Nonetheless, I'm reporting it and asking if anyone can suggest a reasonable workaround. The only one I've thought of, so far, is to hide widgets using grid.forget instead of grid.remove (I have not verified that works, but I'd be amazed if it didn't). That's a bit of a nuisance because I'll have to record the grid parameters, but it's certainly doable. If anyone has a better idea I'd love to hear it. -- Russell |
|
From: Russell O. <ro...@uw...> - 2014-12-06 01:20:54
|
On 12/5/14 4:54 PM, Russell Owen wrote:> I have a log window consisting of a Text widget, scroll bar, and various > widgets to control the display. Some of of the control widgets are > usually hidden, using grid.remove() to remove the parent frame of the > widgets. > > With Tcl/Tk 8.5.17 on MacOS we see the hidden widgets briefly appear > whenever the main frame for this window receives an <Expose> event. > Unfortunately such an event occurs whenever a new item is appended to > the log (I'm not sure why). New lines can come in quite often, leading > to an annoying flicker of the hidden widgets. > > Clearly this is merely a cosmetic annoyance. Nonetheless, I'm reporting > it and asking if anyone can suggest a reasonable workaround. The only > one I've thought of, so far, is to hide widgets using grid.forget > instead of grid.remove (I have not verified that works, but I'd be > amazed if it didn't). For the record: using grid_forget() on the frame does not prevent the flicker nor does using grid_forget() on the widgets contained in the hidden frame. Perhaps destroying the widgets when not in use would work, but that's getting drastic. -- Russell |
|
From: Kevin W. <kw...@co...> - 2014-12-06 02:54:21
|
On 12/5/14, 7:54 PM, Russell Owen wrote: > Clearly this is merely a cosmetic annoyance. Nonetheless, I'm reporting > it and asking if anyone can suggest a reasonable workaround. The only > one I've thought of, so far, is to hide widgets using grid.forget > instead of grid.remove (I have not verified that works, but I'd be > amazed if it didn't). That's a bit of a nuisance because I'll have to > record the grid parameters, but it's certainly doable. If anyone has a > better idea I'd love to hear it. I'm aware of issues like this; they are likely a side effect of my removing the private Cocoa API calls from Tk that are a big no-no under Apple's guidelines but which undeniably improved the drawing performance. In other words, removing them has resulted in degraded drawing performance, which is why they were put there in the first place. It's a tough call, but as I discussed on the list a few months ago, I think keeping them in there was simply a bad idea because Apple's distribution channels so strongly discourage them. The Mac App Store rejects any apps making use of private API calls, for instance. I don't know of a way to substantially improve drawing performance; I (and other contributors) have spent a lot of time tweaking things and fixing the worst of the bugs, but that won't change the fundamental issue. I'm sorry about that. It's a lousy situation, and I wish Apple's guidelines did not put us in this position. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com |
|
From: Kevin W. <kw...@co...> - 2014-12-06 03:00:47
|
On 12/5/14, 7:54 PM, Russell Owen wrote: > Clearly this is merely a cosmetic annoyance. Nonetheless, I'm reporting > it and asking if anyone can suggest a reasonable workaround. The only > one I've thought of, so far, is to hide widgets using grid.forget > instead of grid.remove (I have not verified that works, but I'd be > amazed if it didn't). That's a bit of a nuisance because I'll have to > record the grid parameters, but it's certainly doable. If anyone has a > better idea I'd love to hear it. I'm aware of issues like this; they are likely a side effect of my removing the private Cocoa API calls from Tk that are a big no-no under Apple's guidelines but which undeniably improved the drawing performance. In other words, removing them has resulted in degraded drawing performance, which is why they were put there in the first place. It's a tough call, but as I discussed on the list a few months ago, I think keeping them in there was simply a bad idea because Apple's distribution channels so strongly discourage them. The Mac App Store rejects any apps making use of private API calls, for instance. I don't know of a way to substantially improve drawing performance; I (and other contributors) have spent a lot of time tweaking things and fixing the worst of the bugs, but that won't change the fundamental issue. I'm sorry about that. It's a lousy situation, and I wish Apple's guidelines did not put us in this position. --Kevin -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com |
|
From: Russell O. <ro...@uw...> - 2014-12-08 21:28:48
|
On 12/5/14 6:40 PM, Kevin Walzer wrote: > On 12/5/14, 7:54 PM, Russell Owen wrote: >> Clearly this is merely a cosmetic annoyance. Nonetheless, I'm reporting >> it and asking if anyone can suggest a reasonable workaround. The only >> one I've thought of, so far, is to hide widgets using grid.forget >> instead of grid.remove (I have not verified that works, but I'd be >> amazed if it didn't). That's a bit of a nuisance because I'll have to >> record the grid parameters, but it's certainly doable. If anyone has a >> better idea I'd love to hear it. > > I'm aware of issues like this; they are likely a side effect of my > removing the private Cocoa API calls from Tk that are a big no-no under > Apple's guidelines but which undeniably improved the drawing > performance. In other words, removing them has resulted in degraded > drawing performance, which is why they were put there in the first place. > > It's a tough call, but as I discussed on the list a few months ago, I > think keeping them in there was simply a bad idea because Apple's > distribution channels so strongly discourage them. The Mac App Store > rejects any apps making use of private API calls, for instance. > > I don't know of a way to substantially improve drawing performance; I > (and other contributors) have spent a lot of time tweaking things and > fixing the worst of the bugs, but that won't change the fundamental > issue. I'm sorry about that. It's a lousy situation, and I wish Apple's > guidelines did not put us in this position. I appreciate all the work you have put into Aqua Tk and we can certainly live with the flicker. -- Russell |
|
From: Michiel de H. <mjl...@ya...> - 2014-12-16 04:13:06
|
Hi Russell, Can you provide a test script that demonstrates the flickering of hidden widgets? This would help to establish what the exact cause of this behavior is. Thanks, -Michiel. > I have a log window consisting of a Text widget, scroll bar, and various > widgets to control the display. Some of of the control widgets are > usually hidden, using grid.remove() to remove the parent frame of the > widgets. > > With Tcl/Tk 8.5.17 on MacOS we see the hidden widgets briefly appear > whenever the main frame for this window receives an <Expose> event. > Unfortunately such an event occurs whenever a new item is appended to > the log (I'm not sure why). New lines can come in quite often, leading > to an annoying flicker of the hidden widgets. > > Clearly this is merely a cosmetic annoyance. Nonetheless, I'm reporting > it and asking if anyone can suggest a reasonable workaround. The only > one I've thought of, so far, is to hide widgets using grid.forget > instead of grid.remove (I have not verified that works, but I'd be > amazed if it didn't). That's a bit of a nuisance because I'll have to > record the grid parameters, but it's certainly doable. If anyone has a > better idea I'd love to hear it. |
|
From: Russell O. <ro...@uw...> - 2014-12-16 17:40:54
|
On 12/15/14 8:12 PM, Michiel de Hoon wrote: > Hi Russell, > > Can you provide a test script that demonstrates the flickering of hidden widgets? > This would help to establish what the exact cause of this behavior is. > > Thanks, > -Michiel. > >> I have a log window consisting of a Text widget, scroll bar, and various >> widgets to control the display. Some of of the control widgets are >> usually hidden, using grid.remove() to remove the parent frame of the >> widgets. >> >> With Tcl/Tk 8.5.17 on MacOS we see the hidden widgets briefly appear >> whenever the main frame for this window receives an <Expose> event. >> Unfortunately such an event occurs whenever a new item is appended to >> the log (I'm not sure why). New lines can come in quite often, leading >> to an annoying flicker of the hidden widgets. >> >> Clearly this is merely a cosmetic annoyance. Nonetheless, I'm reporting >> it and asking if anyone can suggest a reasonable workaround. The only >> one I've thought of, so far, is to hide widgets using grid.forget >> instead of grid.remove (I have not verified that works, but I'd be >> amazed if it didn't). That's a bit of a nuisance because I'll have to >> record the grid parameters, but it's certainly doable. If anyone has a >> better idea I'd love to hear it. I'll have a go when I get some free time, but I suspect we'll have to live with it in any case. It sounds like a side effect of cleaning out the reliance on undocumented Apple calls. -- Russell |
|
From: Russell O. <ro...@uw...> - 2014-12-17 17:33:03
|
On 12/5/14 4:54 PM, Russell Owen wrote: > I have a log window consisting of a Text widget, scroll bar, and various > widgets to control the display. Some of of the control widgets are > usually hidden, using grid.remove() to remove the parent frame of the > widgets. > > With Tcl/Tk 8.5.17 on MacOS we see the hidden widgets briefly appear > whenever the main frame for this window receives an <Expose> event. > Unfortunately such an event occurs whenever a new item is appended to > the log (I'm not sure why). New lines can come in quite often, leading > to an annoying flicker of the hidden widgets.... I was able to generate a simple demo script (below) and have posted a bug report <http://core.tcl.tk/tk/tktview/7a325ad72cbb6e331fbae3f4116fe112bda698f4>. My description was a bit wrong: it's not <Expose> events that cause the flicker, but something else that occurs at the same time as the <Expose> event (I have not figured out what). Also, menubuttons flicker but a few other widgets I've tried do not. Michiel de Hoon reports seeing the problem in Tcl/Tk 8.6.3. I would really appreciate it if somebody could try this on linux (I don't have access to a linux with a new enough Tcl/Tk). That would support or disprove Kevin Walzer's theory that this is caused by removing the private Cocoa API calls from Tk. If Keven is right then we'll likely have to live with it. If it shows up on linux as well then it's more likely worth trying to fix. Regards, -- Russell #!/usr/bin/env wish # A simple test case to show flicker of a hidden widget. # # I see the flicker on MacOS 10.9 using Tcl/Tk 8.5.17, but not some older versions of Tcl/Tk I have tried. # # To see the flicker: # - Run the script # - Push the "Hide Wdg" button # - Resize the widget, preferably in width; the hidden widget will be shown while resizing # # Variations: # - I first saw the problem with a window that contained a scrolled Text widget (a log window). Every time text was added to the Text widget the hidden widget flickered. # - I've used grid_forget and still see the flicker. # - I've tried making hidden widget a Label or an Entry instead of a MenuButton and I do NOT see the flicker. wm geometry . "200x50" menubutton .wdg -text "Wdg" grid .wdg -row 0 -column 1 button .btn -text "Hide Wdg" -command {grid remove .wdg} grid .btn -row 0 -column 0 |
|
From: Linus N. <li...@fa...> - 2014-12-18 00:04:08
|
Hi,
That is a very nice and short test script, Russel.
I don’t know if it’s the same root cause, but with the latest Tk code our application suffers badly from similar flickering problems. We have it going on in multiple places. Could be multiple separate causes, or it could be the same cause as Russel’s script. But they’re all new since the removing of the internal Cocoa API calls.
One problem is that we often create windows (tk frames) with scrollbars in them, and after destroying those windows the scrollbars inside them linger, flickering, whenever you config some other tk widget.
To replicate, run the script below and then move the mouse inside the window. Then the flicking appears. The (destroyed) scrollbar keeps appearing and disappearing. It seems that the configuring of the button triggers it somehow. Re-sizing the whole window also causes the destroyed scrollbars to appear.
#################
proc main {} {
console show
wm geometry . 800x600
frame .f -width 750 -height 550 -bg grey75
place .f -x 50 -y 50 -anchor nw
button .f.b -text hello
place .f.b -x 100 -y 100 -anchor nw
set w [create_window .f 10 10 300 300]
update
destroy $w
bind all <Motion> {
.f.b configure -text [clock seconds]
}
}
proc create_window {parent_w x y width height} {
set w $parent_w.c_container
frame $w -bg grey75 -bd 0 -width $width -height $width
scrollbar $w.vscroll -command "$w.c yview"
canvas $w.c -highlightthickness 0 -width [expr {$width - 15}] -height [expr {$width}] -relief sunken -bg grey85 -bd 0 -yscrollcommand "$w.vscroll set"
grid $w.c -padx 1 -pady 1 -row 0 -column 0 -rowspan 1 -columnspan 1 -sticky news
grid $w.vscroll -padx 1 -pady 1 -row 0 -column 1 -rowspan 1 -columnspan 1 -sticky news
place $w -x $x -y $y -anchor nw
return $w
}
after 10 main
#################
Linus
> 17 dec 2014 kl. 18:32 skrev Russell Owen <ro...@uw...>:
>
> On 12/5/14 4:54 PM, Russell Owen wrote:
>> I have a log window consisting of a Text widget, scroll bar, and various
>> widgets to control the display. Some of of the control widgets are
>> usually hidden, using grid.remove() to remove the parent frame of the
>> widgets.
>>
>> With Tcl/Tk 8.5.17 on MacOS we see the hidden widgets briefly appear
>> whenever the main frame for this window receives an <Expose> event.
>> Unfortunately such an event occurs whenever a new item is appended to
>> the log (I'm not sure why). New lines can come in quite often, leading
>> to an annoying flicker of the hidden widgets....
>
> I was able to generate a simple demo script (below) and have posted a
> bug report
> <http://core.tcl.tk/tk/tktview/7a325ad72cbb6e331fbae3f4116fe112bda698f4>. My
> description was a bit wrong: it's not <Expose> events that cause the
> flicker, but something else that occurs at the same time as the <Expose>
> event (I have not figured out what). Also, menubuttons flicker but a few
> other widgets I've tried do not.
>
> Michiel de Hoon reports seeing the problem in Tcl/Tk 8.6.3.
>
> I would really appreciate it if somebody could try this on linux (I
> don't have access to a linux with a new enough Tcl/Tk). That would
> support or disprove Kevin Walzer's theory that this is caused by
> removing the private Cocoa API calls from Tk. If Keven is right then
> we'll likely have to live with it. If it shows up on linux as well then
> it's more likely worth trying to fix.
>
> Regards,
>
> -- Russell
>
> #!/usr/bin/env wish
> # A simple test case to show flicker of a hidden widget.
> #
> # I see the flicker on MacOS 10.9 using Tcl/Tk 8.5.17, but not some
> older versions of Tcl/Tk I have tried.
> #
> # To see the flicker:
> # - Run the script
> # - Push the "Hide Wdg" button
> # - Resize the widget, preferably in width; the hidden widget will be
> shown while resizing
> #
> # Variations:
> # - I first saw the problem with a window that contained a scrolled Text
> widget (a log window). Every time text was added to the Text widget the
> hidden widget flickered.
> # - I've used grid_forget and still see the flicker.
> # - I've tried making hidden widget a Label or an Entry instead of a
> MenuButton and I do NOT see the flicker.
>
> wm geometry . "200x50"
> menubutton .wdg -text "Wdg"
> grid .wdg -row 0 -column 1
> button .btn -text "Hide Wdg" -command {grid remove .wdg}
> grid .btn -row 0 -column 0
>
>
>
> ------------------------------------------------------------------------------
> 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=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Tcl-mac mailing list
> tc...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-mac
|
|
From: Kevin W. <kw...@co...> - 2014-12-18 15:54:45
|
On 12/17/14, 6:43 PM, Linus Nyberg wrote: > I don’t know if it’s the same root cause, but with the latest Tk code our application suffers badly from similar flickering problems. We have it going on in multiple places. Could be multiple separate causes, or it could be the same cause as Russel’s script. But they’re all new since the removing of the internal Cocoa API calls. > One problem is that we often create windows (tk frames) with scrollbars in them, and after destroying those windows the scrollbars inside them linger, flickering, whenever you config some other tk widget. > To replicate, run the script below and then move the mouse inside the window. Then the flicking appears. The (destroyed) scrollbar keeps appearing and disappearing. It seems that the configuring of the button triggers it somehow. Re-sizing the whole window also causes the destroyed scrollbars to appear. I had seen an error like this in some other contexts, and had committed a fix to the scrollbar code which I had thought fixed the issue. I'm dismayed these are still cropping up, and am not sure where to look. It is very frustrating that repeated, ad-hoc fixes are necessary to the drawing code. --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