Hello Jochen Becher, > This has Pros and Cons. > Pro: input.device has to much to do. I would like to see many > different input.device tasks for different system tasks like on for > Mouse, one for gadgets etc. > Cons: If the application does not react very fast on Input Events the > GUI seems to hang. I have this problem now with MicroDot - it needs > too long to handle all that 6000 beta mailings. This is probably the favourite flame-war topic on csa.programming :-) Some time ago I had a very long discussion with Massimo Tantignone (author of VisualPrefs). It was about the possible alternatives to input.device-bound GUI handling and application-bound handling. For a project called OpenBoopsi, which was basically yet another class collection similar to ClassAct, we wanted to design the best possible event handling implementation. Eventually, we agreed that gadgets processing shouldn't be done on the input.device context because there are several limits to the complexity of the gadget dispatcher. A separate task would be required in many cases. Otherwise you can't do a gadget which draws the mandelbrot set without blocking input. Similarly you can't have a listview which reads its entries from a disk file because the input.device is just a task and not a process. Having boopsi gadgets on the input.device context is also a pain for debugging and makes the whole system hang immediately whenever a boopsi method makes some silly thing. But Application-bound input handling is not the way to go too. It makes the GUI less responsive, and the application developer must write everything to ensure that IDCMP event handling is always happening at short time intervals, otherwise the GUI will not respond at all and will not even refresh. Promiscuous solutions (some things done by the input.device and others done by the application) are very hard to implement because of race conditions. If you solve this problem by mutual exclusion, then you end up locking BOTH the input.device and the application whenever a boopsi method is running! Furthermore, deciding which methods are best executed by which task can't be done at compile time. One may assume that a listview gadget will render itself fast enough to do it on the input.device context, but an application might use a listview with 10,000 items or with complex vector images as labels. It seems none of the alternatives is good enough. Is there another solution? Yes, a very simple one indeed. I bet other developers already had the same idea, but I can't figure out why they didn't want to go for it. Perhaps too simple? A third task must be inserted between the application and the input.device. It's pourpose is to listen for at the window user port for low-level IDCMP events such as IDCMP_MOUSEMOVE and IDCMP_VANILLAKEY, convert them to boopsi messages (gpInput, gpRender etc.) and call the boopsi methods as if they were invoked by the input.device itself. The application will just receive "cooked" events such as IDCMP_GADGETUP, IDCMP_UPDATE, etc. Of course the gadgets must not be attached to the window gadget list: from the Intuition point of view, windows handled by the GUI task will look like they have no gadgets. Intuition will just send the mouse and keyboard IDCMP events and the GUI task will find which gadget should get the input by examining its own private data structures. This GUI task could be easily incapsulated in ClassAct's "window.class". The nice thing of this approch is that you don't have to change any of the existing boopsi gadget classes! The objects will just think they are being invoked by the Intuition input handler as usual. There can be a single GUI task for the whole system or one for each application or even one for each window. It does not matter, and it could even be made a configurable option. Of course the task may be given a high priority to ensure a responsive GUI even on a loaded system. Creating your own gpInput packets from IDCMP messages may seem both difficult and inefficient, but a second thought of the problem reveals that it's in fact very easy. It's very similar to what the groupgclass must do to forward input to its children. In my opinion this would be the ultimate solution for the boopsi GUI. It's efficient, flexible, easy to handle for the application programmer and it even makes debugging easy for the class implementor. > > Oliver Wagner told me this crash was caused by Exchange rendering graphics > > when it shouldnt do that --> ObtainGIRPort problem. Will go into an extra > > report form. > It's not so simple. It's typical saying "its an ObtainGIRPort problem" > but that's not true. All Reaction gadgets uses the same way to handle > to ObtainGIRPort problem (using a small function which first call > ObtainGIRPort, then DoMethod(GM_RENDER) on itself, then > ReleaseGIRPort) which is very stable. > I believe intuition has some bugs in its multitasking and semaphore > locking. The way intuition uses semaphores is sometimes very > "creative" and I already saw comments like "we should obtain this > semaphore here but this will lead to problems later on so we don't and > hope everything goes well". You understand... This reminds me of a book about multithreading. One sentence next to the end of the book said: "the best way to avoid problems related to semaphores (deadlocks, data corruption, etc.) is designing your program in a way which does not need semaphores at all". This suggestion seems very silly, but it's in fact true. Have you ever seen X11 deadlocking? (well, actually a few times :-). If it doesn't deadlock it's because all the data structures are accessed by the server task only, so there is no need for the applications (or for the Xlib) to lock any semaphores at all. Unfortunately, the design of Intuition (and layers) lets multiple tasks (applications and input.device) access the same structures at the same time, requiring careful locking. I read somewhere that Dale Luck wanted to turn Intuition into an Exec device, but he had no time to do it. This would have created a solid wall between applications and Intuition, solving many of today's issues. > > But I doubt its possible. At least not without an ROM update. :-( -- _ Bernardo Innocenti or _ // Amiga & UNIX developer - Sysop of SystemShock BBS \X/ WWW: http://www.worldlink.it/bernie - IRC: Bernie