so, this is annoying and old (present in 0.46), and this is how it goes...
if you open a patch that has an open subpatch, even though that suboatch is in the background and you are looking and clicking on the parent patch, you won't be able to get into the edit mode!
you can only get into the edit mode after you click in the subpatch canvas and come back, or reopen the subpatch.
By the way, pd actually turns to edit mode (as you can check in the edit mode), but this doesn't really happen for real.
check attachment.
i'm on a mac (latest os) btw.
cheers
Anonymous
unable to reproduce (Pd-0.47.0-1 as packaged in Debian/sid)
note, that when i open your test-patch, the subpatch window opens in the front (and has focus), so i need to switch to the parent window...which might trigger all the things necessary to hide the bug.
in any case: what does "not being in the edit mode" involve?
OSX has this long lasting minor issue that the cursor won't update when switching to edit-mode via Cmd-E - even though you actually are in edit-mode.
i expect that the problem here is more serious, but it would be interesting to enumerate all signs of (not) being in edit-mode (e.g. do the comments get their resize hooks?)
2016-05-18 4:57 GMT-03:00 "IOhannes m zmölnig" zmoelnig@users.sf.net:
it means I'm not in edit mode at all indeed on the parent patch, but I
realize now that the subpatch goes into edit mode! See attachment
cheers
and a minor nitpicks:
- what's the latest os on mac?
2016-05-18 4:58 GMT-03:00 "IOhannes m zmölnig" zmoelnig@users.sf.net:
https://en.wikipedia.org/wiki/OS_X_El_Capitan
just keep in mind that this bug-report might stay open for years (it wouldn't have been the first) and then "latest" will have a completely different meaning...
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
I'm not seeing this with Pd 0.46-7 on OSX 10.11.
Maybe you're referring to the fact that using the Cmd+E key binding toggles edit mode but the cursor doesn't change until you move the mouse...
Nevermind, I'm definitely see it in the test-bug.pd patch.
I'm seeing this too (was assuming it was just modern linux window managers
but I see it malfunctions in (yet a different way on) Mac as well. I can't
figure out how to get Tk to get the most-recently-created window in front;
but will keep looking.
Miller
On Wed, May 18, 2016 at 07:33:40PM +0000, danomatika wrote:
Related
Bugs: #1249
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
I see it on 10.9.5 both in 0.46 and 0.47.