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