[active] reports 0 with a right click to the canvas (Ubuntu)

[LGoodacre]

The [active] object send me a 0 whenever I right click on the canvas. This is immediately testable from the active-help.pd patch. It sounds like it's platform specific; I'm on Ubuntu 17.04.

I've also noticed that [active] seems to misbehave when I press the F-keys as well. It's sporadic, but I definitely get "0" messages when the window is still active.

[porres]

It sounds like it's platform specific

Yeah, seems so, cause it works fine on macOS/windows, right clicking doesn't give me anything.

F-keys

you mean "function keys"? Haven't tested that yet...

[derekxkwan]

not sure about this one, the relevant function in hammergui are hammergui_dobindfocus which calls the tcl function (defined via sys_gui call later in the file) hammergui_ispatcher, which seems to compare the current active canvas symbol according to pd (I think that's what bind Canvas does?) to whatever [active] decided x->x_cvname is (the unsigned long returned by canvas_getcurrent with .x and .c at the ends)

TLDR: don't know if this is totally under our control?

[derekxkwan]

focus (i think) binds Canvas to hammerfocusin and hammerfocusout
static void hammergui_dobindfocus(t_hammergui *snk) { // post("hammergui_dobindfocus"); sys_vgui("bind Canvas <<hammerfocusin>> \ {if {[hammergui_ispatcher %%W]} \ {pdsend {%s _focus %%W 1}}}\n", snk->g_psgui->s_name); sys_vgui("bind Canvas <<hammerfocusout>> \ {if {[hammergui_ispatcher %%W]} \ {pdsend {%s _focus %%W 0}}}\n", snk->g_psgui->s_name); }

with hammergui_ispatcher here

sys_gui("proc hammergui_ispatcher {cv} {\n"); sys_gui(" if {[string range $cv 0 1] == \".x\""); sys_gui(" && [string range $cv end-1 end] == \".c\"} {\n"); sys_gui(" return 1} else {return 0}\n"); sys_gui("}\n");

haven't dug through the pd tcl side of things so much yet so I might be wrong, but it looks like the "bind Canvas" bit is the thing passing the canvas name to hammergui_ispatcher(?) (i'm guessing that hammerfocusin and hammerfocusout are the named events and the following ifs are callback functinos with %%W being the passed argument) which means "bind Canvas" works differently on different platforms and doesn't pass the same defined symbol

(found in active.c)
sprintf(buf, ".x%lx.c", (unsigned long)canvas_getcurrent());

on right-mouse clicks in linux as it apparently does on other platforms? Further digging around pd's tcl code might prove me wrong, but that's my assumption at the moment...

[porres]

This objects gets the canvas name/id (.x%lx.c) into a symbol variable (x->x_cvname). In "active_dofocus" we get a symbol and a float. The symbol is the canvas name and the float is the activity (1 or 0). So we do compare in 'active_dofocus' if the incoming canvas name is the same as x->x_cvname, and report the float value in the output.

So, when you click on another canvas, we get a (.x%lx.c) ID which is the same x->x_cvname and a float value of "0", saying it's inactive.

I tested in Linux and what happens when you right click on the canvas is that it does get the x->x_cvname symbol and a value of "0" in the same way as if you clicked on another window. This doesn't happen for macOS/Windows, no message is given in these cases.

So yeah, this object doesn't really work for linux as Pd in linux somehow thinks the window is inactive when you right click on the window...

The only way I can think of fixing this is finding a way to know if we right clicked on the window and ignore the incoming message when that happens. I'm sure there's an object out there that caputres right clicking.

[porres]

The only way I can think of fixing this is finding a way to know if we right clicked on the window and ignore the incoming message when that happens.

An alternative could be to try and see if this is actually a bug for Pd in Linux and fix things upstream. I just found out that [iemguts/receive] canvas has a similar issue. See: pure-data/pure-data#843

[porres]

I tested my fix and it all seems to work fine. I just don't like that it was pretty pretty hacky...

I'm just filtering the output when you have a right click.

but I still believe this should be investigated in Vanilla.