Ok,
I found the CMPluginContext bug, and a way to reproduce it.
in your project, have a few items already added, and ready to be commited. Have a new item in your tree. Bring up the commit window. Click add next to that file, and click the checkbox, type your message in and hit enter. The commit will fail.
- Eric
On 7. Mar 2007, at 22:44, Eric Coleman wrote:
I found the CMPluginContext bug, and a way to reproduce it.
Why do you call it a CMPluginContext bug? I.e. what does CMPluginContext has to do with this?
in your project, have a few items already added, and ready to be commited. Have a new item in your tree. Bring up the commit window. Click add next to that file, and click the checkbox, type your message in and hit enter. The commit will fail.
I’ll try it the next time I get the chance (I ought to have a test svn repository ;) )
On Mar 11, 2007, at 9:54 AM, Allan Odgaard wrote:
On 7. Mar 2007, at 22:44, Eric Coleman wrote:
I found the CMPluginContext bug, and a way to reproduce it.
Why do you call it a CMPluginContext bug? I.e. what does CMPluginContext has to do with this?
http://article.gmane.org/gmane.editors.textmate.general/17197/match=cmplugin...
in your project, have a few items already added, and ready to be commited. Have a new item in your tree. Bring up the commit window. Click add next to that file, and click the checkbox, type your message in and hit enter. The commit will fail.
I’ll try it the next time I get the chance (I ought to have a test svn repository ;) )
It does not reproduce for me. It must be that something is writing the text "CMPluginExamineContext" to stdout when you invoke the popup menu, even though the menu has no intentional relationship to context menu plugins. I'm wondering if there's a third-party contextual menu plugin involved?
Chris
On 12. Mar 2007, at 01:07, Chris Thomas wrote:
On Mar 11, 2007, at 9:54 AM, Allan Odgaard wrote:
On 7. Mar 2007, at 22:44, Eric Coleman wrote:
I found the CMPluginContext bug, and a way to reproduce it.
Why do you call it a CMPluginContext bug? I.e. what does CMPluginContext has to do with this?
http://article.gmane.org/gmane.editors.textmate.general/17197/ match=cmpluginexaminecontext
Ah, I sort of missed that one.
in your project, have a few items already added, and ready to be commited. Have a new item in your tree. Bring up the commit window. Click add next to that file, and click the checkbox, type your message in and hit enter. The commit will fail.
I’ll try it the next time I get the chance (I ought to have a test svn repository ;) )
It does not reproduce for me. It must be that something is writing the text "CMPluginExamineContext" to stdout when you invoke the popup menu,
But weird that someone writing to stdout, fools the process, no?!?
even though the menu has no intentional relationship to context menu plugins. I'm wondering if there's a third-party contextual menu plugin involved?
Yeah, sadly popUpContextMenu:withEvent:forView: is really all we have in Cocoa, for opening a pop-up menu, but that one is a “real” context menu, which has context menu plug-ins show in the menu.
An alternative is either using an NSPopUpButtonCell or so, but I ran into problems with that approach (it is sort of hacky, because you’d use a cell without a view, or a view outside a view hierarchy), so I use the Carbon Menu Manager for custom pop-ups, there is some code for this in the Dialog plug-in (if you wish to switch the current code, or I could do it ;) ) -- the only tricky part with Menu Manager is, that it uses global coordinates relative to the main screen, where I found, by experimentation, that the main screen is the one with its origin in (0, 0), not feeling overly confident though, that this is really how it is defined. But [NSMenu mainScreen] was not (always) the right one…
On Mar 12, 2007, at 3:10 AM, Allan Odgaard wrote:
On 12. Mar 2007, at 01:07, Chris Thomas wrote:
It does not reproduce for me. It must be that something is writing the text "CMPluginExamineContext" to stdout when you invoke the popup menu,
But weird that someone writing to stdout, fools the process, no?!?
I frequently see "CMPluginExamineContext" in the Console.
That was bugging me, so I looked around. Turns out the culprit is Path Finder, more specifically
~/Library/Contextual Menu Items/Path Finder CM.plugin
I just emailed the CocoaTech folks, hopefully they'll fix that soon.
I guess if you are not using PathFinder, moving that plugin to the trash and loggin out/in should fix that problem.
Gerd
On Mar 12, 2007, at 4:10 AM, Allan Odgaard wrote:
in your project, have a few items already added, and ready to be commited. Have a new item in your tree. Bring up the commit window. Click add next to that file, and click the checkbox, type your message in and hit enter. The commit will fail.
I’ll try it the next time I get the chance (I ought to have a test svn repository ;) )
It does not reproduce for me. It must be that something is writing the text "CMPluginExamineContext" to stdout when you invoke the popup menu,
But weird that someone writing to stdout, fools the process, no?!?
No, CommitWindow returns data via stdout, because it's called from the commit script like a normal tool. Things like NSLog write to stderr, which is why this is not usually a problem. Ultimately, probably, some small bits of CommitWindow should be added to a plugin and the main logic should be implemented through tm_dialog, which will eliminate the possibility of this sort of problem.
An alternative is either using an NSPopUpButtonCell or so, but I ran into problems with that approach (it is sort of hacky, because you’d use a cell without a view, or a view outside a view hierarchy), so I use the Carbon Menu Manager for custom pop-ups, there is some code for this in the Dialog plug-in (if you wish to switch the current code, or I could do it ;) ) -- the only tricky part with Menu Manager is, that it uses global coordinates relative to the main screen, where I found, by experimentation, that the main screen is the one with its origin in (0, 0), not feeling overly confident though, that this is really how it is defined. But [NSMenu mainScreen] was not (always) the right one…
In Carbon, IIRC, the screen at topleft (0,0) is always the screen containing the menubar. This would have been necessary for compatibility with apps written before multiple monitor support (which arrived in 1987). According to the docs, [NSScreen mainScreen] returns the screen containing the key window, which probably made sense in menubarless NeXTstep... although, even then, why not just get the key window and ask for its screen?
Chris