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 _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
