Hello Michael, > Aloha, > > --- Serg Stoyan <[EMAIL PROTECTED]> wrote: > > > > Give me example, please, of such miswork. I have latest CVS and > > everything works correct for me. > > I emailed a few days ago about how this is broken... Load up an > application, tear off a window -- so far so good -- now go back to the > main menu and redisplay the menu you tore off: close button on a > transient window. This is a big usability issue, not to mention a visual > regression from previous versions.
You are right. Sorry for last misunderstanding. > I just updated from CVS and this problem is still there. Not to mention > that with some small effort you can confuse the hell out of the transient > menu's display. Open up a bunch of windows in GSTest, close a couple, > reopen some, and in that melee there will be a double-draw which looks > okay on the Torn-off Windows menu but when you call up the transient it > is completely hosed. (It almost looks like there are two competing > titleViews and that is what is displacing the menu view... hmmm.) I can't still reproduce it, but I hope Willem's patch fix it. > [It is worth noting that GSTest is not really a fair test of the Windows > menu. There is some black magic in place within those tests which makes > each window update itself twice in the windows menu. Look at the restart > method in the test bundles.] > > One other small thing, our NSMenuView is -- for all intents and purposes > -- opaque so in closeTransient in NSMenu I don't think we need to set the > contentView as needing display: the addSubview for the menuview already > sets the menuview as needing display, which should be enough (?). Hmm... You are right. Maybe Willem add this to his patch? -- Serg Stoyan _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
