On 11/17/2017 07:44 AM, rolfm@dds.nl wrote:
hi
the working of the kiosk-plugin seems a bit inconsistent.
i'm on Windows 10, vanilla 0.48-0., using the plugin from GitHub (IEM).
hiding the menu-bar:
when the kiosk.cfg is in the plugin dir (@appdata)
- hiding works directly, after starting Pd first and then opening the
patch.
(this also is the case using Pd-extended)
- when opening the patch by double-click (binding of the extension)
the menu-bar hides AFTER clicking in the patch.
i don't know what exactly you mean by this.
when the kiosk.cfg is in the working directory:
-after starting Pd first, then opening the patch, hiding does not work at all.
how does Pd know about your working directory?
(same goes for Pd-extended)
- using the double-click method, again the menu-bar hides AFTER clicking
in the patch.
i guess this means that the behaviour is the same as with kiosk.cfg in the plugin dir.
while i don't fully understand your problem description, here's a thought:
kiosk works "per Pd instance" rather than per patch¹. (so it doesn't allow you to have the menu hidden on the "foo" and "bar" abstractions but not on all the other abstractions).
if kiosk.cfg is in the plugin-dir, the kiosk-plugin will be able to find it when Pd starts, and apply the configuration whenever a patch gets opened. if your kiosk.cfg lies besides your PATCH.pd (the main patch you try to open), and you double-click the PATCH.pd, then W32 will automatically make the PATCH.pd's directory the working directory into which it starts Pd. thus the plugin will be able to find the kiosk.cfg when starting up. however, if you first start Pd, and then navigate to PATCH.pd, the kiosk-plugin already has initialized (without finding a valid kiosk.cfg file) and will not read the new file. (Pd's working directory will be something like "C:" or %UserData% or whatelse)
gfmasdr IOhannes
¹ of course you could add a feature request if such a feature is of interest to you.