Miller do you mean to extend the single-open mechanism from the doc files to the 'file>open' menu? Like when you try to open a C file in Geany while it is already open, Geany will pop the existing one rather than open a second instance. For a code editor that makes sense. And Pd is a code editor after all. But it is a code interpreter at the same time, which is exactly why Pd is so great for education and prototyping. And for an interpreter it doesn't always make sense to prohibit multiple instances of a program, it just depends on the nature of the work. Let me give an example: Martin Brinkmann's Chaosmonster (http://www.martin-brinkmann.de/pd-patches.html) is an wonderful sound generator on a small patch. Depending on parameter settings it can produce very different sounds and it's fun to load a few of them. I know people who use the patch in live performance. Imagine their surprise when Pd refuses to load more than one.
The question when multiple instances are useful or potentionally harmful is complex. Even when loading from 'menu>open' is restricted to a single instance (which I hope is not going to be default behavior), it is still possible to edit multiple instances of an abstraction, causing the confusion and frustration that I remember indeed from my first year with Pd. Probably there's even more details and possible situations than we've discussed so far. On the other hand, it is true that a single-instance-from-menu mechanism would not raise patch-compatibility issues. So you could evaluate the effect in classroom and pd community, then decide if it is worth keeping it. By the way my own current use case for multiple instances is unrelated to the menu. I'm working on a mouse widget that communicates with a pd patch as properties dialog. In other words it uses Pd's own message system and widgets to set its properties. Some advantages of this arrangement were unexpected and I was just about to praise Pd for its self-supportiveness and flexibility when stumbling into the new no-duplicates behavior. At least for this project the issue is solved. More about it later. And thanks for listening to pd users even under the pressure of the upcoming semester. On 9/23/18, Miller Puckette <m...@ucsd.edu> wrote: > actually, it's probably not a serious problem that one can multiply open > help > files (if one really wants to), so probably it's not worth fixing this. > > On the other hand, a naive user on a Mac would expect that clicking on a > file in the "finder", if Pd already has the file open, would show the user > the open file instead of opening another copy. > > Supposing the "open" menu called "pd open" with the third nonzero argument, > but if "pd open" acted as it does now so that one could programmatically > open multiple copies of a patch, would this permit you to do what you're > planning? (I think that this would be patch-level back compatible). > > cheers > Miller > > On Sun, Sep 23, 2018 at 11:52:54AM +0200, katja wrote: >> Thanks Miller for this quick yet powerful fix. >> >> It currently operates on patches as opened from the window menu. Help >> patches can still be opened more than once from the contextual menu. I >> verified that this can be fixed by calling glob_open() instead of >> glob_evalfile() from open_via_helppath() in s_path.c: >> >> glob_open(0, gensym((char*)basename), gensym(dirbuf), (t_floatarg)1); >> >> However to make it work, the prototype of glob_open() must be declared >> when compiling s_path.c, otherwise the float argument is not passed >> correctly for some reason (while the file and dir name are, isn't that >> odd?) >> >> Katja >> >> On 9/23/18, Miller Puckette <m...@ucsd.edu> wrote: >> > Well, I ended up simply reverting to the old behavior but leaving a hook >> > in >> > so that users can specifically ask only to open a patch once. >> > >> > cheers >> > M >> > >> > On Sun, Sep 23, 2018 at 12:10:01AM +0200, Antoine Rousseau wrote: >> >> Yes I realized that. So it should be something more specific. >> >> Why not a wider scope object, like [pdconfig], that would take "once" >> >> as >> >> an >> >> argument? >> >> >> >> Antoine Rousseau >> >> http://www.metalu.net <http://metalu.net> __ >> >> http://www.metaluachahuter.com/ >> >> <http://www.metaluachahuter.com/compagnies/al1-ant1/> >> >> >> >> >> >> >> >> Le sam. 22 sept. 2018 ?? 23:55, Roman Haefeli <reduz...@gmail.com> a >> >> ??crit : >> >> >> >> > On Sat, 2018-09-22 at 23:29 +0200, Antoine Rousseau wrote: >> >> > > Of course [once] would be much better than [lock].... >> >> > >> >> > [once] is taken by iemlib. Not that I think every library in >> >> > existence >> >> > should be considered regarding name conflicts when introducing new >> >> > objects to Pd, but I feel that [once] is in wide use and adding a >> >> > [once] with totally different behavior would be a bold move. >> >> > >> >> > Roman_______________________________________________ >> >> > Pd-list@lists.iem.at mailing list >> >> > UNSUBSCRIBE and account-management -> >> >> > https://lists.puredata.info/listinfo/pd-list >> >> > >> > >> >> _______________________________________________ >> >> Pd-list@lists.iem.at mailing list >> >> UNSUBSCRIBE and account-management -> >> >> https://lists.puredata.info/listinfo/pd-list >> > >> > >> > >> > >> > _______________________________________________ >> > Pd-list@lists.iem.at mailing list >> > UNSUBSCRIBE and account-management -> >> > https://lists.puredata.info/listinfo/pd-list >> > >> >> >> >> _______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
