NSMenu patch

Hi, The following NSMenu patch adds checking if menu item enabled before [_view performActionWithHighlightingForItemAtIndex: i] method performed in performKeyEquivalent: method. NSMenu.m.patch Description: Binary data ___ Bug-gnustep mailing list

Re: NSMenu

Quentin Mathé wrote: NSMenuItem autoenabling doesn't work with NSPopUpButton... is it an unimplemented feature ? other problem... with the code below : NSMenu *menu = [[NSMenu alloc] initWithTitle:@""]; [NSMenu popUpContextMenu:menu withEvent:myEvent forView:myView]; RELEASE(

Re: NSMenu

Le 4 févr. 04, à 23:17, Fred Kiefer a écrit : Quentin Mathé wrote: NSMenuItem autoenabling doesn't work with NSPopUpButton... is it an unimplemented feature ? other problem... with the code below : NSMenu *menu = [[NSMenu alloc] initWithTitle:@""]; [NSMenu popUpC

bug in NSMenu

g the notification that the same item has been inserted. [NSMenu insertItem:atIndex:] calls [NSMenuItem setMenu:] and only after that it sends NSMenuDidAddItemNotification. The problem is that [NSMenuItem setMenu:] calls [NSMenu itemChanged:], which sends NSMenuDidChangeItemNotification. Sorry, didn't

NSMenu and AppIcons

It seems that an AppIcon won't display if it is set after the menu has been created and displayed. for example: I have an app in which the menu was created in a createmenu() function, that was called from main(). and the appicon was set in the applicationDidFinishLaunching method of the delega

NSMenu, NSPopupButton fidget.

Hi, So you know where I'm coming from: I'm using GNUstep on a 200MHz Apple PowerBook (3400c for the curious). Anyhow, GNUstep is quite slow on this particular platform (and I expected as much.) However, a side benefit of this is I can see subtle problems in NSPopUp and NSMenu bec

NSPopUpButton*, NSMenu* patch.

Hi, Here is a rather large patch that makes some changes to NSMenu* and NSPopUpButton*. Basically it allows one to use images in popupbuttons once again and it removes many redisplays which were causing the menus and popups to be quite painful on slow machines (bonus: the windows menu should

Re: NSMenu patch

> Hi, > > The following NSMenu patch adds checking if menu item enabled before > [_view performActionWithHighlightingForItemAtIndex: i] method performed in > performKeyEquivalent: method. Thanks Serg - I applied your patch to CVS. :-)

Fix: NSMenuItem, NSMenu (GMArchiverMethods)

econd time (raises), by just setting the menu of the item. 2000-09-10 Georg Fleischmann * gui/Source/NSMenuItem.m ([NSMenuItem setSubmenu:]): set target only if mi_menu != nil * gui/Model/GMAppKit.m ([NSMenu(GMArchiverMethods) initWithModelUnarchiver:]):

Re: bug in NSMenu

Hi Benhur, tahnk you for this bug report. I tried to fix it with two changes to NSMenu. For one now the initWithCoder will send all notifications at the end and when inserting an item the notification is send before the menu of the item is set. Please check if this changes remove all your

Re: NSMenu and AppIcons

Rob Burns wrote: > It seems that an AppIcon won't display if it is set after the menu has been created >and displayed. for example: > > I have an app in which the menu was created in a createmenu() function, that was >called from main(). and the appicon was set in the applicationDidFinishLaunc

Re: NSMenu, NSPopupButton fidget.

Michael Hanni wrote: > > General question: I have never been able to build and use profile builds. Any > hints? Also, is there a way to get the runtime to spew out all the message > passing? I mean, I want to actually watch the event and display loop in action > for NSMenuView. Is this feasible?

Re: NSPopUpButton*, NSMenu* patch.

hange? As for the rest of your patch I would like to analyse it a bit more before committing it. It is a rather huge patch and there is some code that looks strange. (E.g. why is the setNeedsDisplayForItemAtIndex method called in the NSMenu implementation of itemChanged and not in that of NSMen

Re: NSPopUpButton*, NSMenu* patch.

s executed other times - perhaps too many :-) - but it never sets a different size, always the same one - always _cellSize.width + 1, so I can't understand why you see a resizing at the end. When do you see a resizing ? > [changes to NSTabView.m] Applied. I'll look at the other NSMen

Re: NSPopUpButton*, NSMenu* patch.

prove on the existing code. We need to try raise the quality level of the changes we do to NSMenu*. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep

NSMenu* and NSPopuUp* issues

Hi everybody, Currently I'm working on fixing as much as possible NSMenu* and NSPopUp* related problems and bugs. I've found semi-working horizontal menus code. I've search through mail list archive and found discussions about horizontal menus. As a result of this discussion was:

Re: Fix: NSMenuItem, NSMenu (GMArchiverMethods)

Hi Georg, thanks for reporting problems with the GModel code - I looked at the recent changes to the NSMenuItem and I am still puzzled by the fact that (AFAIK) in OPENSTEP the target of the submenuAction: is the submenu to be detached, while in GNUstep it seems we are using the menu itself (=

Re: Fix: NSMenuItem, NSMenu (GMArchiverMethods)

Hi Nicola, >I am still puzzled >by the fact that (AFAIK) in OPENSTEP the target of the submenuAction: >is the submenu to be detached, while in GNUstep it seems we are >using the menu itselfI checked it: In OpenStep the target of the submenuAction: is the menu itself (no difference to GNustep).

Re: Fix: NSMenuItem, NSMenu (GMArchiverMethods)

> Hi Nicola, > > >I am still puzzled > >by the fact that (AFAIK) in OPENSTEP the target of the submenuAction: > >is the submenu to be detached, while in GNUstep it seems we are > >using the menu itselfI checked it: > > In OpenStep the target of the submenuAction: is the menu itself > (no differ

Re: Fix: NSMenuItem, NSMenu (GMArchiverMethods)

Hi Nicola, >Ahm - my assertion is mainly based on the fact that in all gmodels >I saw, the target is the submenu. Actually, that is the way the You're right. I missdescribed my observations... The target of the NSMenuItem on OpenStep points to the submenu. Just like it is in the gmodel files yo

Re: Fix: NSMenuItem, NSMenu (GMArchiverMethods)

Hi Georg, > So of course it's clear why MacOSX needs the submenu ivar. Ahm - you mean because targets should not be retained while of course you need to retain the submenu somewhere ? > Are you going to implement it like OpenStep or like MacOSX ? Well - if you are asking to me - I am going

Re: Fix: NSMenuItem, NSMenu (GMArchiverMethods)

Hi Nicola, >Ahm - you mean because targets should not be retained while of course >you need to retain the submenu somewhere ? I meant that if the target would point to the super menu, you need the extra submenu entry. I don't know where the target points on MacOSX, though. >unfortunately I do

Re: Fix: NSMenuItem, NSMenu (GMArchiverMethods)

Hi Georg, > >unfortunately I don't rememeber > >which gmodels come from OPENSTEP - and which versions - and which from > >macosx. > > gmodel files generated on OpenStep 4.2 don't contain a submenu entry at all > (only target). Thanks ! I suspect the gmodels containing a submenu were genera

[PATCH] NSMenu patch version 2.

This is the rewritten NSMenu patch. It fixes #100248 - Ghost menu #101875 - Menu flickering #101877 - Menu does not move down #101880 - popupbutton does not scroll It should also behave correctly with respect to highlighting and opening closing menus. (Correct means, as I understood it is

Re: NSMenu* and NSPopuUp* issues

> So, finally, we have to decide: Do we need horizontal menus in GNUstep > library or not? There is 2 ways: How does removing the code affect, for example, menus on a Windows system ? I havent yet persuaded GNUstep to run under Windows I have to admit (will give it yet another bash in the near fut

Re: NSMenu* and NSPopuUp* issues

On 2003-03-21 09:18:31 +0100 Serg Stoyan <[EMAIL PROTECTED]> wrote: Hi everybody, Currently I'm working on fixing as much as possible NSMenu* and NSPopUp* related problems and bugs. I've found semi-working horizontal menus code. I've search through mail list archive and fo

Re: NSMenu* and NSPopuUp* issues

Hello Stefan, > On 2003-03-21 09:18:31 +0100 Serg Stoyan <[EMAIL PROTECTED]> wrote: > > > Hi everybody, > > > > Currently I'm working on fixing as much as possible NSMenu* and > > NSPopUp* related problems and bugs. I've found semi-working horiz

Re: NSMenu* and NSPopuUp* issues

Citando Serg Stoyan <[EMAIL PROTECTED]>: > Hi everybody, > > Currently I'm working on fixing as much as possible NSMenu* and > NSPopUp* related problems and bugs. Well, there is one bug I see in menus that I don't know if is corrected by recent patches. It is easy

Re: NSMenu* and NSPopuUp* issues

On Fri, 21 Mar 2003 10:18:31 +0200, "Serg Stoyan" <[EMAIL PROTECTED]> said: > So, finally, we have to decide: Do we need horizontal menus in GNUstep > library or not? There is 2 ways: > > 1. We decide to leave horizontal menus -- I'll finish implementation. > 2. We decide to remove -- I'll remove

Re: NSMenu* and NSPopuUp* issues

Benhur Stein <[EMAIL PROTECTED]> writes: > Citando Serg Stoyan <[EMAIL PROTECTED]>: > > Well, there is one bug I see in menus that I don't know if is corrected > by recent patches. It is easy to see it using Terminal.app. > > I use bash and a prompt command that changes the title of the window >

Re: NSMenu* and NSPopuUp* issues

I second Josh's opinion. Horizontal Menus are something I'd personally use. Alex Perez On Fri, 21 Mar 2003, Josh Rendlesham wrote: > On Fri, 21 Mar 2003 10:18:31 +0200, "Serg Stoyan" <[EMAIL PROTECTED]> > said: > > So, finally, we have to decide: Do we need horizontal menus in GNUstep > > libra

Re: NSMenu* and NSPopuUp* issues

Hello Benhur, > Citando Serg Stoyan <[EMAIL PROTECTED]>: > > > Hi everybody, > > > > Currently I'm working on fixing as much as possible NSMenu* and > > NSPopUp* related problems and bugs. > > Well, there is one bug I see in menus that I don&#x

[PATCH] Fix NSMenu retainCount problem

to have no reason to be there and caused a retain on NSMenu. Must be confirmed. NSMenu patch has fixed the code below : NSMenu *menu = [[NSMenu alloc] initWithTitle:@"boum"]; [menu addItem:menuItem]; // now the menu retain count is still 1 and not higher NSMenuView patch has fixed the code b

NSMenu* drawing efficency patch (try 1)

Howdy, This small patch makes NSMenu* much more snappy on my PowerBook 3400c. It fixes a FIXME that has existed in the code for awhile and also saves the two most used drawing selectors in the menu code. ChangeLog: 2002-02-10 Michael Hanni <[EMAIL PROTECTED]> *

Re: [PATCH] NSMenu patch version 2.

Hello Willem, I tried this patch and it does some nice stuff, though my biggest pet peeve with the menus still exists. That is, if you click on a menu item and drag up and down the menu after a few passes you start getting menu windows showing up at (0,0). Are you seeing this as well? I looked i

Re: [PATCH] NSMenu patch version 2.

On Thursday, March 6, 2003, at 03:29 pm, Willem Rein Oudshoorn wrote: This is the rewritten NSMenu patch. It fixes #100248 - Ghost menu #101875 - Menu flickering #101877 - Menu does not move down #101880 - popupbutton does not scroll Thanks ... Seems to work nicely, so I committed your patch

Re: [PATCH] NSMenu patch version 2.

xed. I have strong suspicion that the bug is not in the NSMenu code, but that the frequently mapping/unmapping windows bring to light a bug in the x11 part of back. Also, running GNUstep applications insided Xnest and WindowMaker with sloppy focuse will make it much easier to reproduce thi

Re: [PATCH] NSMenu patch version 2.

little this afternoon, but I didn't see anything that jumped out at me. Yes, I have seen this as well. I think this bug is related to #101876 - Menus do not dissappear. Which is not fixed. I have strong suspicion that the bug is not in the NSMenu code, but that the frequently mapping/unmapp

Re: [PATCH] NSMenu patch version 2.

should be allowed to put any object as a menurepresentation. That is why I like informal protocols better than requiring a subclass. * [PERSONAL] The coupling between NSMenu and NSMenuView is tight and for me was a little hard to understand. By trying to make explicit what the expected

Recent changed in NSMenu and friends

Some changes are done to the NSMenu and friends I am not really sure about. Especially the changes relating to when to call update/sizeToFit. As it is now it does not work correctly, transient windows have close buttons etcetera. In my opinion the methods "update" and "size

NSMenu menu position saving bug (PATCH)

Hi there, The menu position saving code has not worked for me for quite awhile. After being prodded by Alex I chased this bug down. Attached is a patch. Basically the problem is with this code: return [NSString stringWithFormat: @"\033%@", [self title]]; //NSMenu.m ~155 On my machine this wou

Re: [PATCH] Fix NSMenu retainCount problem

nes which seems to have no reason to be there and caused a retain on NSMenu. Must be confirmed. NSMenu patch has fixed the code below : NSMenu *menu = [[NSMenu alloc] initWithTitle:@"boum"]; [menu addItem:menuItem]; // now the menu retain count is still 1 and not higher NSMenuView patc

Re: [PATCH] Fix NSMenu retainCount problem

(the count is wrong at the highest level, here NSMenu) or I'm not understanding what you have said. So if you agree, I will apply the second patch and also some of the more verbose error messages you did add to NSMenu. The other changes would only make the code in NSMenu harder to read a

Re: [PATCH] Fix NSMenu retainCount problem

think it's the case (the count is wrong at the highest level, here NSMenu) or I'm not understanding what you have said. Ok, so I did not make myself clear. Look at the example below. Here is an example : with Cocoa, the code below release and dealloc the menu variable. NSMenu *menu

Re: [PATCH] Fix NSMenu retainCount problem

Le 6 févr. 04, à 01:25, Fred Kiefer a écrit : menu = [[NSMenu alloc] initWithTitle: @"boum"]; NSLog(@"menu retain count before = %d", [menu retainCount]); { CREATE_AUTORELEASE_POOL(pool2); menuItem = [[NSMenuItem alloc] init]; [menu addItem: menu

Re: [PATCH] Fix NSMenu retainCount problem

Le 6 févr. 04, à 02:43, Quentin Mathé a écrit : Le 6 févr. 04, à 01:25, Fred Kiefer a écrit : menu = [[NSMenu alloc] initWithTitle: @"boum"]; NSLog(@"menu retain count before = %d", [menu retainCount]); { CREATE_AUTORELEASE_POOL(pool2); menuItem = [[NS

Re: [PATCH] Fix NSMenu retainCount problem

Quentin Mathé wrote: Le 6 févr. 04, à 02:43, Quentin Mathé a écrit : Le 6 févr. 04, à 01:25, Fred Kiefer a écrit : menu = [[NSMenu alloc] initWithTitle: @"boum"]; NSLog(@"menu retain count before = %d", [menu retainCount]); { CREATE_AUTORELEASE_POOL(po

Re: [PATCH] Fix NSMenu retainCount problem

Le 7 févr. 04, à 00:30, Fred Kiefer a écrit : if what you want is the actuall behaviour on MacOSX, than we really need your full patch to get it. Yes, it's the Mac OS X behavior I want because it seems natural to me. I my opinion, correct objective-c memory management should be to dealloc the ma

Re: [PATCH] Fix NSMenu retainCount problem

Quentin Mathé wrote: > the user shouldn't have to know the framework implementation. In other > terms, correct objective-c memory management needs to support this rule > : sending a message to an object should never induce increased retain > count for this object. I don't think this rule should be

Re: [PATCH] Fix NSMenu retainCount problem

On 7 Feb 2004, at 14:47, Alexander Malmberg wrote: Quentin Mathé wrote: the user shouldn't have to know the framework implementation. In other terms, correct objective-c memory management needs to support this rule : sending a message to an object should never induce increased retain count for th

Re: [PATCH] Fix NSMenu retainCount problem

the necessary "invalidation" from the -dealloc (like eg. -base's NSConnection). Well I see your point... but for NSMenu, with this approach, I must write : - (void)methodForContextMenuExample { NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; NSMenu *menu = [[N

Re: [PATCH] Fix NSMenu retainCount problem

e autorelease pools to ensure that there are no pending autoreleases. Alternatively, you can split out the necessary "invalidation" from the -dealloc (like eg. -base's NSConnection). Well I see your point... but for NSMenu, with this approach, I must write : - (void)methodForContextMen

Re: [PATCH] Fix NSMenu retainCount problem

Le 7 févr. 04, à 17:55, Richard Frith-Macdonald a écrit : But depending on an undocumented feature of the MacOS-X implementation of NSMenu ... you are expecting the menu to be destroyed when you release it, and that might not be so. The code may not work in the next release... it may even

Re: Recent changed in NSMenu and friends

Hello Willem, > Some changes are done to the NSMenu and friends I am not really > sure about. Especially the changes relating to when > to call update/sizeToFit. > > As it is now it does not work correctly, transient windows > have close buttons etcetera. In my opinion the

Re: Recent changed in NSMenu and friends

t 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 displa

Re: Recent changed in NSMenu and friends

Serg Stoyan <[EMAIL PROTECTED]> writes: > Hello Willem, > > > Some changes are done to the NSMenu and friends I am not really > > sure about. Especially the changes relating to when > > to call update/sizeToFit. > > > > As it is now it does not work c

Re: Recent changed in NSMenu and friends

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 nee

Re: Recent changed in NSMenu and friends

Hello Willem, > Serg Stoyan <[EMAIL PROTECTED]> writes: > > > Hello Willem, > > > > > Some changes are done to the NSMenu and friends I am not really > > > sure about. Especially the changes relating to when > > > to call update/sizeToFit. &

Re: NSMenu menu position saving bug (PATCH)

On 10 Jan 2004, at 15:13, Michael Hanni wrote: Hi there, The menu position saving code has not worked for me for quite awhile. After being prodded by Alex I chased this bug down. Attached is a patch. Basically the problem is with this code: return [NSString stringWithFormat: @"\033%@", [self t

Re: NSMenu menu position saving bug (PATCH)

Hi, On 2004-01-10 01:59:05 -0700 Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: On 10 Jan 2004, at 15:13, Michael Hanni wrote: so the key was always nil (interestingly enough, if I manually edited the key in the defaults to be \033Info it worked properly). I changed this to: So it sounds

Re: NSMenu menu position saving bug (PATCH)

On 10 Jan 2004, at 16:23, Michael Hanni wrote: Hi, On 2004-01-10 01:59:05 -0700 Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: On 10 Jan 2004, at 15:13, Michael Hanni wrote: so the key was always nil (interestingly enough, if I manually edited the key in the defaults to be \033Info it work

Re: NSMenu menu position saving bug (PATCH)

On 10 Jan 2004, at 09:52, Richard Frith-Macdonald wrote: This is on a powerpc machine, debian linux, gcc 3.3.3-0pre1, and libc6 2.3.2.ds1-10. Any ideas? Just one ... I think powerpc systems use a different byte order from intel systems ... maybe there is some problem with accessing the wrong by

Re: NSMenu menu position saving bug (PATCH)

Hi Richard, On 2004-01-10 03:01:44 -0700 Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: I think I have found the problem. I've committed a fix for the base library to cvs. Please could you update and see if it works for you. Excellent! This does indeed fix the bug. The string is being sav

[bugs #11777] intermittent crash when bringing NSMenu in the foreground

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=11777> Summary: intermittent crash when bringing NSMenu in the foreground Project: GNUstep Submitted by: rmottola Submitted on: Sat 01/29/2005 at 11:43

[bugs #11777] intermittent crash when bringing NSMenu in the foreground

Update of bugs #11777 (project gnustep): Status:None => Fixed Assigned to:None => gcasa Open/Closed:Open => In Test

[bug #14251] NSMenu is displaying with window border on Xorg

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=14251> Summary: NSMenu is displaying with window border on Xorg Project: GNUstep Submitted by: gcasa Submitted on: Mon 08/22/05 at 01:10 Category:

[bug #14251] NSMenu is displaying with window border on Xorg

Follow-up Comment #1, bug #14251 (project gnustep): Which window manager are you using? The window decoration is most likely not added by the X server itself, but by the window manager. We need to convince each single window manager not do it an perhaps this one we ignored up to now. ___

[bug #14251] NSMenu is displaying with window border on Xorg

Follow-up Comment #2, bug #14251 (project gnustep): I use Xorg on linux/x86 with windowmaker and don't have this problem. Also on x86 on debian I recently switched from xfree to xorg and apart form a huge speed decrease I can't notice this bug. ___

[bug #14251] NSMenu is displaying with window border on Xorg

Update of bug #14251 (project gnustep): Status:None => Invalid Assigned to:None => gcasa Open/Closed:Open => Closed _

[bug #11777] intermittent crash when bringing NSMenu in the foreground

Update of bug #11777 (project gnustep): Open/Closed: In Test => Closed ___ Follow-up Comment #2: closing as fixed years ago ___ Reply

[bug #30025] NSMenu does not behave like on OS X

URL: <http://savannah.gnu.org/bugs/?30025> Summary: NSMenu does not behave like on OS X Project: GNUstep Submitted by: dwetzel Submitted on: Di 01 Jun 2010 19:29:03 CEST Category: Gui/AppKit Sever

[bug #30025] NSMenu does not behave like on OS X

Update of bug #30025 (project gnustep): Status:None => In Progress ___ Follow-up Comment #1: I fixed the first issue in SVN, please have a look whether this works for you. As for the seco

[bug #30025] NSMenu does not behave like on OS X

Additional Item Attachment, bug #30025 (project gnustep): File name: macmenu.pngSize:73 KB ___ Reply to this item at: ___ Nachrich

[bug #30025] NSMenu does not behave like on OS X

Update of bug #30025 (project gnustep): Status: In Progress => Ready For Test Assigned to:None => FredKiefer Open/Closed:Open => In Test _

[bug #30025] NSMenu does not behave like on OS X

in -[NSMenuItem _corePerformAction] () #28 0x7fff847fa428 in -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] () #29 0x7fff84a7e41d in -[NSMenu _internalPerformActionForItemAtIndex:] () #30 0x7fff84930217 in -[NSCarbonMenuImpl _carbonCommandProcessEvent:handlerCallRef:] ()

[bug #30025] NSMenu does not behave like on OS X

Update of bug #30025 (project gnustep): Open/Closed:Open => In Test ___ Follow-up Comment #4: I added calls to synchronizeTitleAndSelectedItem in a few more places. This should fix the wron

[bug #30025] NSMenu does not behave like on OS X

Update of bug #30025 (project gnustep): Status: Ready For Test => Fixed ___ Follow-up Comment #5: works for me now. thanks Fred! ___ R

[bug #30025] NSMenu does not behave like on OS X

Update of bug #30025 (project gnustep): Open/Closed: In Test => Closed ___ Reply to this item at: ___ Nac

[bug #15631] NSMenu not resizing properly to accommodate main menu title

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=15631> Summary: NSMenu not resizing properly to accommodate main menu title Project: GNUstep Submitted by: gcasa Submitted on: Sun 02/05/06 at 21:37

[bug #15631] NSMenu not resizing properly to accommodate main menu title

Follow-up Comment #1, bug #15631 (project gnustep): I should mention that with SVN r22420 of gui this problem is not present. ___ Reply to this item at:

[bug #15631] NSMenu not resizing properly to accommodate main menu title

Update of bug #15631 (project gnustep): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #2: Thanks .. glitch i

[bug #18646] NSMenu and NSPopup selected cell displaced by kde taskbar

URL: <http://savannah.gnu.org/bugs/?18646> Summary: NSMenu and NSPopup selected cell displaced by kde taskbar Project: GNUstep Submitted by: padski Submitted on: Saturday 12/30/2006 at 19:46 Category: Appli

[bug #18646] NSMenu and NSPopup selected cell displaced by kde taskbar

Follow-up Comment #1, bug #18646 (project gnustep): It depends on how window manager place a newly mapped window. Most window managers won't allow a newly mapped window outside the screen, therefore, the menu/popup is shifted by window manager. I have no fix for that, just know the reason.

[bug #18646] NSMenu and NSPopup selected cell displaced by kde taskbar

Follow-up Comment #2, bug #18646 (project gnustep): what surprises me is that the mechanism that seems to work at the edge of the screen, doesn't work here. ___ Reply to this item at:

[bug #18646] NSMenu and NSPopup selected cell displaced by kde taskbar

Follow-up Comment #3, bug #18646 (project gnustep): Not only some window managers try to put a newly mapped window inside the screen, GNUstep also tries to do the same thing if menu is partially outside the screen. But when a taskbar exists, there is a XWindow hints to tell window manager not to

[bug #18646] NSMenu and NSPopup selected cell displaced by kde taskbar

Update of bug #18646 (project gnustep): Category: Application => Backend ___ Reply to this item at: ___ Na

Menus in lower left corner WAS: Re: [PATCH] NSMenu patch version 2.

Fred Kiefer <[EMAIL PROTECTED]> writes: > Hi Wim, > > menus kep on appearing in the lower left corner for me as well. It > would be great if you could resolve this problem quickly. I think I know what the problem is and I don't like it. After tracing x11 section in Back I discovered that: * T

Re: Menus in lower left corner WAS: Re: [PATCH] NSMenu patch version2.

Pete French <[EMAIL PROTECTED]> writes: > > Sequence that will lead to NOT unmapping window (theory) > > > > > > A - XMapWindow (..., WINDOW) > > B - WINDOW is toplevel window, now this request is redirected > > to the window manager.

Re: Menus in lower left corner WAS: Re: [PATCH] NSMenu patch version2.

Hi Willem, Thanks for your work on this... Menu problems in my mind have a huge impact on usability. --- Willem Rein Oudshoorn <[EMAIL PROTECTED]> wrote: > > Yes, it could happen to any X app. But it is very very unlikely. > How many applications do map/unmap windows in quick succession? > Of co