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

Hans-Christoph Steiner hans at at.or.at
Tue Dec 18 23:29:30 CET 2012


On Dec 18, 2012, at 3:24 PM, IOhannes m zmölnig wrote:

> On 12/18/2012 20:48, Hans-Christoph Steiner wrote:
>> 
>> 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.
> 
> 
> the good thing is, that i don't think i have to care about w32.
> all the code i'm touching is right now protected by "x11" (hence linux).
> i'll try to check gnome and kde.
> 
>> 
>> I don't recall, but I imagine I had to do that to get Tk to respond correctly.
>> 
> 
> so right now it does respond correctly on my testsystem.
> again, let's wait for gnome and kde tests.
> 
> 
>> 
>>> #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.
> 
> again, the singleton code is only used on x11, so w32 shouldn't be a problem.
> i mainly implemented it because it said "TODO replace PUREDATA name with path so this code is a singleton based on".
> but i'm not specifically attached to it.
> probably i'll split that into a separate patch.

>> 
>> 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.
> 
> agreed.
> the question is, how should it behave on any platform - and later worry about making it the same on all platforms. i'm not saying that this is an easy task and should be tackled right now.
> but it would be good to have an idea what the actual target behaviour is like.
> 
> apart from that:
> what happens if on w32 if i add "open with" associations for .pd files to both PdX-0.42.5 and Pd-0.43.4 (so the user can choose which Pd they want to open a given .pd file with): if PdX-0.42.5 is running and i choose "open with...Pd-0.43.5", will it open with the correct Pd?

That sounds like the correct behavior in isolation, but I don't have a good sense of all the possibilities. It worked that way when I did one quick test of that using vanilla HEAD and Pd-extended 0.43.4. They use different "topic" names (Pure Data vs Pd extended) so that's probably why.

I have a vague recollection of Windows generally behaving that way, and not like Mac OS X, where it prefers the running version over any associations.

.hc


>>> #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.
> 
> yes. should behave the same.
> 
>> 
>> 
>>> #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.
> 
> 
> i don't see any bonus on having to click away an error window instead of having an error-notice in the pd-console (which i can choose to ignore or not).
> 
> but again, i'm not attached to that.
> 
> 
> fgmasdr
> IOhannes




More information about the Pd-dev mailing list