Some questions to clarify my thoughts on this, and a possible idea: The MapRequest event is the event that assigns a workspace value to the application? This event occurs just before the application is displayed?
There is some sort of time mapping with each process when it is started, right? (This is how things like top keep track of how long a process has been running?) From my investigation, this time mapping is made as soon as an application is called, regardless of how long it takes to start up, so it appears to be triggered by the creation of the process. So my idea would be to build a small running table of what workspace was displayed at what time (3:02:01 workspace 1, 3:02:02 workspace 2, etc). If a MapRequest event occurs, check the start time on the process, then match the start time to the workspace active at that time. Map the window to that workspace. Each Unix timestamp would be 32 bits or four bytes of memory, and the workspace integer would be another four bytes, more or less (unsigned int, you might be able to get away with a short but I'm not sure how that would work out across platforms - probably not worth it). If the "image" went back say, a minute in one-second intervals, that would be 480 bytes of storage required, plus whatever overhead is required for something like this. Apps that don't load don't cause MapRequest events (do they?) so they aren't an issue. Only apps that cause MapRequest events are handled, so only apps that we care about are actually looked up. Storage requirements grow linearly as you enlarge the "visibility window". I would suggest a minute, as I don't know any programs that take that long to load even on an old machine with 32MB. You're not forced to store arbitrarily large numbers of strings (exec calls), so it can't grow out of control and doesn't pose a security or performance problem. The worst failure that can happen is that the program is started in the wrong workspace (its start time matches a workspace that is too new), which is kind of what happens now. This could be fixed by increasing the time resolution (down to .5 seconds or even .1 seconds, if possible) of the "visibility window", which would mean more memory and processor usage. I'm sure there is something catastrophically wrong with this. :) It wouldn't be perfect, but I can't see any way for it to really be a problem, either. The only real concern I can see is, of course, the memory and code required to implement this, which would make things bigger, as it always does -- not sure if it is worth the bloat or the additional processor time. Matt Sean 'Shaleh' Perry wrote: >>Thats it. Would be most obliged if you could work that in somehow .. >> Having apps open where you issue the command not where you actually >> *are* when it finally decides to open. >> > > > this is really, really, really not easy. otherwise I would have done it long > ago (-: > > as a rehash, the issue is this: > > the menu code calls fork()->exec() to start a new application. At this point > blackbox goes off and does its own thing. > > moments later an event "MapRequest" occurs. This is the new application trying > to display itself. There is *zero* connection between this event occuring and > the earlier menu request. Blackbox has no way of knowing this application was > actually started by it. You see there is no mapping between X Windows and > their pids. So while we are in name the parent we do not know this window is > "ours". It might as well have been started from a term, the console or even > remotely from another machine. It is this transparency that is there to bite > us in the ass. > > The *BEST* thing we could do would be to store the string we exec() 'mozilla > http://www.pornpornporn.com' and when the window launches we could check if the > command stored in WM_COMMAND matched any of the commands in our wait queue. > Which means we also have to support apps that never actually load, apps like > 'rxvt' which there are a billion of at once, etc. It just gets messy. > > Any of you out there have a way to do this please let me know. I have not > found a clean solution yet. >
