libera/#clim - IRC Chatlog
Search
10:53:46
jackdaniel
scymtym: thanks. I've got about right abstraction for layers (and below) abstractions in the grammar of graphics (that is ggplot2 underlying theory), what is left are scales and other refinements (and tidying up)
10:54:35
jackdaniel
after that will come interactivity: zooming, (optional) sensitive data points, perhaps continous in time data sources (like for monitoring)
12:40:13
admich
I'm amazed that there isn'a a standard function to know if an application frame is running. The only way seem the not exported climi::frame-process
12:51:21
admich
In demodemo all the launched demo share the same thread and event-queue. In this way we can launch more than one demo clicking on the buttons of demodemo app, but at the end only the last launched demo is running and the other hangs. The user feeling is weird.
12:53:02
admich
Possible solution: 1. launch the demo in its own thread 2. don't share the event-queu 3. Stop the running demo before start the nextone
12:54:16
jackdaniel
sharing the event queue shouldn't be much of a problem; because the event queue is shared multiple frames are capable of running despite having a single process underneath
12:56:56
jackdaniel
it is not that "previous frames" are inactive, it is that command loop is not correctly processed
12:57:11
jackdaniel
i.e start twice the graph toy demo that works solely based on events - both are "running"
12:58:20
jackdaniel
(of course starting frames "anew" in separate threads will make the issue go away, however I think that it would be just dodging the issue)
13:10:02
admich
All the events are handled but inside the top level lambda of the last launched application.
13:12:52
jackdaniel
btw that makes me think, that if we got this right, then there would be a lot more meaning to the macro with-application-frame (expected to be used by commands) than simply binding the variable to *application-frame*
13:14:51
jackdaniel
I think that from the ux perspective demodemo should start new ones in a separate thread (or we should get this multiplexing right)
13:16:15
jackdaniel
but picking up the "what if" topic, if we had multiplexing got 100% right, then all frames in a single port could run using a single thread, that would make cross-application-frame commands much easier
13:16:47
jackdaniel
the "activity frame" could steal other frame's events if they match its translator
13:17:21
jackdaniel
I think that this would be much harder had all frames been running in separate threads
13:19:10
admich
Returning to enable/disable from the spec seems that this states refers only to the visibility of the frame, not the running process. I can immagine some application that its not visible (disabled) but still listen fror some event. Anyway if we interpret disable as the app is not running we need to check it iin the code.
13:23:41
jackdaniel
in my understanding, enabled frame is well and running, shrunk frame is invisible and running (your imagined scenario), disabled is not running, and disowned is not present anywhere
13:24:20
jackdaniel
to highlight the difference (in my understanding) between disabled and disowned, say we have a frame that is also a frame manager (capable of adopting other frames as its panes)
13:24:35
jackdaniel
when the frame is disabled, you see an empty sheet in the place of the adopted frame
13:33:34
admich
the difference between disabled and disowned seems clear to me. When the frame is disowned it isn't in any frame-manager, and it hasn't the pane hierarchy that is generated with the help of the frame-manager. What is not clear to me is how much this concept are othogonal to the running of the top level. Now in mcclim I can have a running top level with the frame disabled and a frame enabled without runnign the top level.
13:35:39
jackdaniel
my impression of the spec is that: enabled/shrunk - the top level loop should be running, disabled/disowned - it shouldn't
13:36:18
jackdaniel
(unless explicitly started by the programmer, or explicitly left running by some exotic frame manager)
13:42:36
jackdaniel
sure (don't put too much weight on what I've said, I'm still trying to understand frame managers better myself) - see you