From: Hans v. T. <hth...@zo...> - 2008-03-25 18:04:42
|
Hi, Is there a standard way to manage interdependent user actions? In my application a user has to open a file, then select an attribute based on the contents of the file, then select a value based on the selected attribute. I'm forcing this sequence by putting each user action inside the on signal event function needed earlier. This works fine if the user applies the sequence just once. But when a new file is opened, the old attribute selection interferes with the new one. Likewise, the old value selection interferes with a new value selection. Is there a better way to manage these user action dependencies? Any help, or pointers to any existing source code, appreciated.. Best Regards, Hans van Thiel |
From: Hans v. T. <hth...@zo...> - 2008-03-25 18:11:03
|
Hi, Is there a standard way to manage interdependent user actions? In my application a user has to open a file, then select an attribute based on the contents of the file, then select a value based on the selected attribute. I'm forcing this sequence by putting each user action inside the on signal event function needed earlier. This works fine if the user applies the sequence just once. But when a new file is opened, the old attribute selection interferes with the new one. Likewise, the old value selection interferes with a new value selection. Is there a better way to manage these user action dependencies? Any help, or pointers to any existing source code, appreciated.. Best Regards, Hans van Thiel |
From: Axel S. <Axe...@en...> - 2008-03-26 09:01:09
|
On Tue, 2008-03-25 at 19:00 +0100, Hans van Thiel wrote: > Hi, > > Is there a standard way to manage interdependent user actions? > > In my application a user has to open a file, then select an attribute > based on the contents of the file, then select a value based on the > selected attribute. I'm forcing this sequence by putting each user > action inside the on signal event function needed earlier. This works > fine if the user applies the sequence just once. But when a new file is > opened, the old attribute selection interferes with the new one. > Likewise, the old value selection interferes with a new value selection. I'm not quite sure I understand exactly how you nest the signal handlers. Also, I guess we need to understand how things 'interfere' when the user performs the sequence the second time. Can you boild it down to a small demo program? > Is there a better way to manage these user action dependencies? Otherwise, maybe you can create some sort of state machine, put its current state into an MVar and modify this MVar from within each signal handler. Then you don't have nested signals, which I suppose is the problem in your code. Cheers, Axel. |
From: Hans v. T. <hth...@zo...> - 2008-03-26 13:51:03
|
On Wed, 2008-03-26 at 10:01 +0100, Axel Simon wrote: > On Tue, 2008-03-25 at 19:00 +0100, Hans van Thiel wrote: > > Hi, > > > > Is there a standard way to manage interdependent user actions? > > > > In my application a user has to open a file, then select an attribute > > based on the contents of the file, then select a value based on the > > selected attribute. I'm forcing this sequence by putting each user > > action inside the on signal event function needed earlier. This works > > fine if the user applies the sequence just once. But when a new file is > > opened, the old attribute selection interferes with the new one. > > Likewise, the old value selection interferes with a new value selection. > > I'm not quite sure I understand exactly how you nest the signal > handlers. Also, I guess we need to understand how things 'interfere' > when the user performs the sequence the second time. Can you boild it > down to a small demo program? > Thanks very much for your reply! The program reads a .csv line, and then builds a pop up menu from that line. When a user selects an item, another popup menu is build, with another selection. So, the second menu is in the 'callback' from the first. The problem is when the first selection is done again, with a different result. Now a new (second) popup is built. But the first popup menu, from the first evocation of the primary callback, is still there. The second menu overlays the first. > > Is there a better way to manage these user action dependencies? > > Otherwise, maybe you can create some sort of state machine, put its > current state into an MVar and modify this MVar from within each signal > handler. Then you don't have nested signals, which I suppose is the > problem in your code. This crossed my mind, though I'm not sure I know how to do this. Another thing I thought of was using IORef's as sort of mutex flags, to lock and unlock access to events. but I've also noticed there are not only 'on' but also 'after' signals. It would be nice if you could do some cleanup and resets after a signal has been handled. Is this something you can do in GTK+ but not in Gtk2Hs? In Gtk2Hs they are essentially the same, right? It would be nice if you have a ready answer for me, but I wonder how other people have solved this. Anyone who has built a dynamic menu, which changes according to user actions, must have come up against this problem. Any examples, anyone, maybe with state, that I can have a look at? Best Regards, Hans > > Cheers, > Axel. > > |
From: Axel S. <Axe...@en...> - 2008-03-30 20:13:51
|
On Mar 26, 2008, at 14:50, Hans van Thiel wrote: > > On Wed, 2008-03-26 at 10:01 +0100, Axel Simon wrote: >> On Tue, 2008-03-25 at 19:00 +0100, Hans van Thiel wrote: >>> Hi, >>> >>> Is there a standard way to manage interdependent user actions? >>> >>> In my application a user has to open a file, then select an >>> attribute >>> based on the contents of the file, then select a value based on the >>> selected attribute. I'm forcing this sequence by putting each user >>> action inside the on signal event function needed earlier. This >>> works >>> fine if the user applies the sequence just once. But when a new >>> file is >>> opened, the old attribute selection interferes with the new one. >>> Likewise, the old value selection interferes with a new value >>> selection. >> >> I'm not quite sure I understand exactly how you nest the signal >> handlers. Also, I guess we need to understand how things 'interfere' >> when the user performs the sequence the second time. Can you boild it >> down to a small demo program? >> > Thanks very much for your reply! The program reads a .csv line, and > then > builds a pop up menu from that line. When a user selects an item, > another popup menu is build, with another selection. So, the second > menu > is in the 'callback' from the first. The problem is when the first > selection is done again, with a different result. Now a new (second) > popup is built. But the first popup menu, from the first evocation of > the primary callback, is still there. The second menu overlays the > first. There is an 'onDeselect' in MenuItem which you could use to close down your sub-menu. The next easiest way to reliably destroy all menus except for the one of the new selection is to add them all to a list store in an MVar (IORefs and MVars are basically the same, but MVar also work with several threads) and destroy and empty this list when you pop up a new menu. >>> Is there a better way to manage these user action dependencies? >> >> Otherwise, maybe you can create some sort of state machine, put its >> current state into an MVar and modify this MVar from within each >> signal >> handler. Then you don't have nested signals, which I suppose is the >> problem in your code. > This crossed my mind, though I'm not sure I know how to do this. > Another > thing I thought of was using IORef's as sort of mutex flags, to > lock and > unlock access to events. but I've also noticed there are not only 'on' > but also 'after' signals. It would be nice if you could do some > cleanup > and resets after a signal has been handled. Is this something you > can do > in GTK+ but not in Gtk2Hs? In Gtk2Hs they are essentially the same, > right? Yes, signals are Gtk+ concept, not something that we invented. 'on' and 'after' relate to when a signal handler is run for a given handler. It is rarely useful to connect to 'after' or to stop the delivery of a signal ('signalStopEmission') or to disable the emission of a signal ('signalBlock'), although all that is possible from Gtk2hs. I'm still not sure what you had in mind with the previous paragraph. Using IORef or MVars in Haskell land does not give you any control on how signals are emitted. And since all Gtk2Hs activity runs in a single thread, it is no good to try and block the execution of Haskell code using MVars or some other mutex mechanism. Axel. |