> - there is no indication which window is active, I suggest you add different > window title background color for inactive window
I agree it would be more intuitive. Week ago, I actually considered implementing it, but in the end there was no time left to do it. Because of my other commitments, I will not be able to work on graphics stack for at least next two months. I might add this feature after this period, but the stack will be probably merged into mainline by that time and I am not sure what changes or improvements will be done during that process. But I am definitely adding your suggestion to my TODO list. > - when trying to drag an inactive window (title) using mouse, it does not > work Basically the same as above goes also for this suggestion. The complexity and robustness of currently fairly simple mouse clicking handler (as well as button widget clicking handler) could be significantly improved to handle all the possible corner cases to behave more similarly as in GUIs of established operating systems. > - when in kernel console (i.e. after pressing Alt+M), moving the mouse > reveals As strangely as it might seem, this is actually very useful "feature" when debugging the graphics stack. Because both compositor and kernel console are doing damage to the framebuffer, you can reproduce bugs while being able to see debug printouts in the kernel console. As far as my memory goes, this "cooperative" sharing of framebuffer is actually happening also in the original console server, which is currently in mainline (i.e. that even when in kernel console, console server is still being able to do damage to framebuffer if instructed to do so). It was only much more subtle (i.e. at some occasion, the bdsh command prompt popped out in the kernel console), because the mouse pointer was handled by first tier of the stack (fb server). _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
