On Sun, Feb 23, 2014 at 7:46 AM, Axel Simon <axel.si...@in.tum.de> wrote:
> Dear Don,
>
> I haven't tracked the developments of ghc's concurrency recently so I don't 
> know if there is still this -threaded option or if everything is nowadays 
> multithreaded. There used to be the necessity to install this call-back that 
> would run the main loop of Gtk+ while the Haskell program has got nothing to 
> do. If there is some sort of stall/backlag/timeout in connection with 
> messages that make the popup disappear when it does not disappear in C then 
> it might be related to this. Maybe you try to connect to unrealize/hide 
> messages of the popup window and at least try to find out if it is hidden or 
> destroyed?

I have another data point, discovered this morning on a hunch. First
of all, my setup is up-to-date 64-bit Arch Linux. I do not run a
desktop system, just a window manager, xmonad. When testing my
application, I start it from an xterm (as opposed, say, to dmenu).
Main window comes up, displaying the tree of accounts. I then
double-click an account to display its transactions in a register. The
register is the problem window. With all three windows on the screen,
I reliably get the bad behavior I've reported. This morning, I tried
minimizing (I import XMonad.Layout.Minimize) both the xterm and
account-tree windows, so that the register window was now the only
window on the screen. Right-clicked to get the popup and -- voila --
rock-solid. I repeated the experiment several times and the popup
behaves correctly.

Next, I tried shutting down xmonad and running fvwm instead. With all
three windows on the screen, I got the incorrect behavior. I then
iconified the xterm and account-tree window, leaving only the register
window. Just to further confuse us, the incorrect behavior occurred
persistently!

I think you are on to something in what you say in your message. The
behavior certainly smacks of some sort of a timeout occurring. The
first time you try to bring up a popup with all three windows on the
screen, it will remain on-screen for about 10 seconds, consistently.
I'll bet there is a 10 second timeout buried somewhere in the code.
I'll try to pursue your suggestion.

/Don

>
> Cheers,
> Axel
>
> On 21.02.2014, at 14:00, Donald Allen <donaldcal...@gmail.com> wrote:
>
>>
>>
>>
>> On Thu, Feb 20, 2014 at 2:55 PM, Daniel Wagner <dan...@wagner-home.com> 
>> wrote:
>> Man, you have *got* to get into the habit of creating a minimal working
>> example. =)
>>
>> Yeah, I know. I only had a 45 year career in computer science, running 
>> software projects large and small (including the Tenex project at BBN when 
>> Tenex was the predominant host OS on the ArpaNet), wrote my first computer 
>> program in 1960 (IBM 1620 assembly code), so I'm still a newbie, still 
>> learning, but I'm trying.
>>
>> Seriously, I did attempt to reproduce the problem with a small example and 
>> got the same result you did -- the popup menu works correctly (our examples 
>> were almost identical, but I did try yours to be sure and it works correctly 
>> as it did for you). I have not been able to devote time to this since I sent 
>> my message, but returned to it yesterday, trying to find the difference 
>> between what my application is doing and both our small examples. This 
>> resulted in a useful bit of information: my application has another window, 
>> call it Window B, that also needs a popup, which I hadn't gotten to. I 
>> adapted the little snippet of code from the failing window (Window A) to 
>> produce a right-button popup in Window B. This one works correctly.
>>
>> Window A: a window containing a scrolled window containing a treeview. The 
>> treeview's model is a TreeModelSort whose child model is a ListStore. The 
>> popup fails in this window as described.
>> Window B: a window containing a scrolled window containing a treeview. The 
>> treeview's model is a TreeStore. The popup works correctly with this window.
>>
>> So I'm a bit closer to isolating what's going on here, but I'm not there yet.
>>
>> The minimal framework I could put around your code to make it run is
>> included below. It does not have the problem you describe. Does the code
>> below show the bad behavior you describe when you try it? If not, could
>> you please try to cook up the smallest piece of code that *does*
>> reproduce your problem?
>>
>> ~d
>>
>> import Control.Monad.IO.Class
>> import Graphics.UI.Gtk
>>
>> main = do
>>         initGUI
>>         w <- windowNew
>>         b <- buttonNewWithLabel "foo"
>>         on b buttonPressEvent (tryEvent (do button <- eventButton
>>                                             theTime <- eventTime
>>                                             case button of
>>                                                 RightButton -> liftIO
>> (mouseButtonPressed theTime)
>>                                                 _ -> stopEvent))
>>         containerAdd w b
>>         widgetShowAll w
>>         mainGUI
>>
>> mouseButtonPressed :: TimeStamp -> IO ()
>> mouseButtonPressed theTime
>>     = do menu <- menuNew
>>          print "mouseButtonPressed called"
>>          print ("time", theTime)
>>          menuItem <- menuItemNewWithLabel "New transaction (ctrl-n)"
>>          on menuItem menuItemActivated (putStrLn "activated, lol")
>>          menuShellAppend menu menuItem
>>          menuItem <- menuItemNewWithLabel "Duplicate selected transaction
>> (ctrl-d)"
>>          menuShellAppend menu menuItem
>>          widgetShowAll menu
>>          print "about to call menuPopup"
>>          menuPopup menu (Just (RightButton, theTime))
>>
>> On 2014-02-18 20:17, Donald Allen wrote:
>>
>> > I am trying to pop up a menu when the right button is pressed with the
>> > cursor in a particular treeview. I set up the event handler as follows:
>> >
>> > -- Handle buttonPressEvent within the view
>> > on view buttonPressEvent (tryEvent (do button <- eventButton
>> > theTime <- eventTime
>> > case button of
>> > RightButton -> liftIO (mouseButtonPressed theTime accountRegister
>> > globals)
>> > _ -> stopEvent))
>> >
>> > and
>> >
>> > mouseButtonPressed :: TimeStamp -> AccountRegister -> Globals -> IO ()
>> > mouseButtonPressed theTime accountRegister globals
>> > = do menu <- menuNew
>> > print "mouseButtonPressed called"
>> > print ("time", theTime)
>> > menuItem <- menuItemNewWithLabel "New transaction (ctrl-n)"
>> > on menuItem menuItemActivated (newTransaction accountRegister globals)
>> > menuShellAppend menu menuItem
>> > menuItem <- menuItemNewWithLabel "Duplicate selected transaction
>> > (ctrl-d)"
>> > menuShellAppend menu menuItem
>> > widgetShowAll menu
>> > print "about to call menuPopup"
>> > menuPopup menu (Just (RightButton, theTime))
>> >
>> > The first time I press the right button, the menu appears for perhaps
>> > 10 seconds and then disappears. During that time, I can click 'New
>> > transaction' and the right thing happens. The second time I press the
>> > right button, the menu appears very briefly, less than a second and
>> > then disappears. Subsequent right clicks behave the same. In other
>> > words, useless.
>> >
>> > The debugging prints in mouseButtonPressed all appear in response to
>> > the right clicks. The event time advances, as you would expect.
>> >
>> > I'm at a complete loss as to what might be causing this and can't
>> > continue with my project if this is not solved. Any suggestions would
>> > be appreciated.
>> >
>> > ------------------------------------------------------------------------------
>> > Managing the Performance of Cloud-Based Applications
>> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> > Read the Whitepaper.
>> > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>> > [1]
>> >
>> > _______________________________________________
>> > Gtk2hs-devel mailing list
>> > Gtk2hs-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel [2]
>>
>>
>>
>> Links:
>> ------
>> [1]
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&amp;iu=/4140/ostg.clktrk
>> [2] https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
>>
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Gtk2hs-devel mailing list
>> Gtk2hs-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
>>
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
>> Gtk2hs-devel mailing list
>> Gtk2hs-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
>

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Gtk2hs-devel mailing list
Gtk2hs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel

Reply via email to