[PD] kiosk-plugin inconsistent behaviour?

[IOhannes m zmölnig]

On 11/17/2017 07:44 AM, rolfm at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20171117/8af154f6/attachment.sig>