On Dec 18, 2012, at 2:01 PM, IOhannes m zmölnig wrote:

> 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.

I remember that part of the code being a pain to get right thru all of the 
possibilities...  remember, Windows and probably even GNOME are going to behave 
differently from XFCE and probably each other in regards to double-click/open 
behavior.


> 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)

I don't recall, but I imagine I had to do that to get Tk to respond correctly.


> #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.

I haven't done it because that stuff works, and it'll take a lot of testing on 
all platforms, Windows especially, to confirm there aren't problems or 
regressions.  

Also, I'm not convinced that it makes sense to have install of Pd its own 
island based on its install path.  For example, on Mac OS X, if I have 
Pd-extended 0.42.5 running and 0.43 as the default app for .pd files, 
double-clicking a .pd file will go to the running 0.42.5 and not the default 
0.43.  I'm not sure how this works on Windows, GNOME, etc. but Pd should behave 
the same.


> #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?

Basically the same answer as #2.


> #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.

dde is part of the standard Tcl install.  It is not an 'add-on'.  So the error 
would be useful since it would highlight that the Tcl install is 
broken/incomplete.  Since both vanilla and extended include Tcl and dde (or 
Miller is working on it) I don't see any gain to making it conditional, only 
needless complication.

.hc



_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Reply via email to