Thus spake Kim Woelders: > [EMAIL PROTECTED] wrote: > >Yes, I had exactly the same problem (and the problem hasn't change > >with E16.7). When Scribus starts, some dialogs window appears, but > >they shouldn't exist for scribus (i.e. in "Tools" menu, they are all > >unchecked) nor for E (they don't appear in the 'wl' command of eesh). > >These windows are thus unmanaged by E. If you check these windows in > >the 'Tools" menu, nothing happens. If you uncheck them, they > >disappear. Then, all is OK. If you check again these windows, they > >appear, managed with menuborder. A quick "hack" is that when you > >close scribus, all tools windows must be open, so that the next time > >you start scribus, they are marked as opened, and appear managed. If > >you closed them, the next time, they are marked as closed, but are > >still opened, unmanaged. > > > >I don't know what happen, but it looks like these windows shouldn't > >appear... but does. > > > There seem to be a few apps that have windows which escape management > by E, MonoDevelop being the only other one I know of. > > I think it is a bug in scribus. It sends a bogus Unmap event after a > dialog window is (requested to be) mapped but before it has actually > been mapped. The attached patch seems to make scribus behave, although > I think there are some other program logic bugs (why try to hide the > window immediately after it is mapped?). > > However, I think E probably should be fixed to ignore these bogus > events.
I've passed this information (and the patch) along to the scribus people. Al ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ enlightenment-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
