[PD-dev] Fwd: pd-gui's tests and Qs on singletons

[IOhannes m zmölnig]

just in case,enybody was wondering about the beginning of this conversation.

fgmasrd
IOhannes


-------- Original Message --------
Subject: pd-gui's tests and Qs on singletons
Date: Tue, 18 Dec 2012 20:00:35 +0100
From: IOhannes m zmölnig <zmoelnig at iem.at>
To: Hans-Christoph Steiner <hans at at.or.at>

hi hans,

so i did a number of tests, and of course found one case, where my
solution did not behave as it should :-)
   starting one pd and then one pd-gui, would result in having 2
instances running (starting another pd-gui would correctly delegate to
the last pd-gui, but the 1st pd-gui would not delegate to the first pd)
anyhow, the problem was not related to the less strict test, but due to
moving the test to before the singleton check.

i have now corrected my code and ran a couple of codes and all seem to
behave correctly. (see attachment).
all tests were run on debian wheezy/sid using xfce4 (xfwm4) with 8
virtual desktops.



while doing so and looking at your new changes, i came up with a couple
of questions:

#1 singletons and window focus
do you know why the singleton check raises the pdgui and focuses to it?
that is, why does the check whether another pd-gui is running  changes
window focus and eventually switches the desktop?
i understand that we probably want to raise the focus once we decide to
load an abstraction into a running instance, but simply checking whether
there's already an instance running should not raise focus.
i have experimentally moved the window focus/raise code to the
receive_args-proc, and it seems to behave exactly as intended.
but now i can start multiple instances of Pd (not! pd-guis) on different
desktops, and the 2nd Pd will not try to move itself to the desktop of
the 1st instance. (the current (0.43) behaviour is very annoying if you
work with multiple instances of Pd on multiple virtual desktops)


#2 unique singleton key
i changed the singleton key from "PUREDATA" to the normalized scriptname
(same for PUREDATA_MANAGER) ... this was already mentioned in some
TODO-comments, but i wonder why it hasn't been done yet?
i tested and it allows to have start two pd-guis from different
locations (e.g. /tmp/pd1/tcl/pd-gui.tcl and /tmp/Pd2/tcl/pd-gui.tcl) and
they do not interact with each other.
this basically means that you can have pd-vanilla and PdX (since they
will have different paths to pd-gui.tcl) running at the same time and
they won't interfere with one another.
i tested with pathnames with spaces in it, and couldn't find any
problems so far.


#3 unique keys for dde
i see that you use "Pure Data" as the topicname for the new w32 dde stuff.
again, would it make sense to use the scriptname? or do you expect problems?

#4 catching "package require dde" errors?
any reason why you don't conditionally import the "dde" package?
giving the user a friendly error message ala "opening new abstractions
in running Pd's won't work: missing DDE package" is probably more
user-friendly than having a tcl-error popup.
even though the w32 Pd-environment is quite controlled, the change would
be very simple and allow people to focus on real problems.


it would be nice if you could provide some answers :-)

fgmasdr
IOhannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pdguitests.txt.gz
Type: application/x-gzip
Size: 619 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20121218/0e72c7db/attachment.bin>