Hans Roels a écrit :
I also think this would be a simple but very handy tool, (also in pd-vanilla...), at this moment I always have to 'navigate' a lot to open files...
One parenthesis...(
in win32 pd-vanilla it's possible to drag'n'drop patches from explorer, sometimes this trick can save a lot of clicks'n'time, this trick already available in 0.37(, when I've started to try puredata,) doesn't work in pd-extended.
Also if we double-click on the icon of a patch still on win32 platform, it opens an instance of pd, it would be nice if the patch was opened in the already loaded (the last one at least) instance of pd.
)... Thanks for attention.
On Dec 4, 2007, at 4:20 AM, Patrice Colet wrote:
Hans Roels a écrit :
I also think this would be a simple but very handy tool, (also in pd-vanilla...), at this moment I always have to 'navigate' a lot to open files...
One parenthesis...(
in win32 pd-vanilla it's possible to drag'n'drop patches from
explorer, sometimes this trick can save a lot of clicks'n'time, this trick
already available in 0.37(, when I've started to try puredata,) doesn't
work in pd-extended.
Really, how do you do that? I tried on Windows XP using pd-vanilla
0.39.2 and 0.40.2 and could not get any drag-n-drop to work.
Also if we double-click on the icon of a patch still on win32 platform, it opens an instance of pd, it would be nice if the patch
was opened in the already loaded (the last one at least) instance of pd.
That is an old, known bug. I saw this Miller's TODO. If you got this
working, and submitted a patch, I think he would be likely to accept it.
.hc
)... Thanks for attention.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
Also if we double-click on the icon of a patch still on win32 platform, it opens an instance of pd, it would be nice if the patch
was opened in the already loaded (the last one at least) instance of pd.That is an old, known bug. I saw this Miller's TODO. If you got this
working, and submitted a patch, I think he would be likely to accept it.
I'm also very curious about a solution for this, which is non-trivial on Windows. I failed to do it with DDE (because old-fashioned DDE doesn't seem to be really working with current Windows versions) and using the "find running PD process" method requires sending an "open patcher" inquiry to the TCL/TK part of the already-running PD which is beyond my TCL/TK capabilities (not to mention interest).
gr~~~
From: Thomas Grill gr@grrrr.org To: Hans-Christoph Steiner hans@eds.org CC: pd-list@iem.at Subject: Re: [PD] open recent Date: Tue, 04 Dec 2007 22:25:26 +0100
Also if we double-click on the icon of a patch still on win32 platform, it opens an instance of pd, it would be nice if the patch was opened in the already loaded (the last one at least) instance of pd.
That is an old, known bug. I saw this Miller's TODO. If you got this working, and submitted a patch, I think he would be likely to accept it.
I'm also very curious about a solution for this, which is non-trivial on Windows. I failed to do it with DDE (because old-fashioned DDE doesn't seem to be really working with current Windows versions) and using the "find running PD process" method requires sending an "open patcher" inquiry to the TCL/TK part of the already-running PD which is beyond my TCL/TK capabilities (not to mention interest).
There's EnumProcesses in the PSAPI. ( http://msdn2.microsoft.com/en-us/library/ms682629.aspx ) A newly started instance of pd could use it to determine that it wasn't the only pd running and quit. How would it pass the patch to the other pd? There must be a registry setting for this kind of thing, since, for example, Photoshop doesn't open a new instance whenever you double-click one of its documents.
Martin
Martin Peach schrieb:
From: Thomas Grill gr@grrrr.org To: Hans-Christoph Steiner hans@eds.org CC: pd-list@iem.at Subject: Re: [PD] open recent Date: Tue, 04 Dec 2007 22:25:26 +0100
Also if we double-click on the icon of a patch still on win32 platform, it opens an instance of pd, it would be nice if the patch was opened in the already loaded (the last one at least) instance of pd.
That is an old, known bug. I saw this Miller's TODO. If you got this working, and submitted a patch, I think he would be likely to
accept it.
I'm also very curious about a solution for this, which is non-trivial on Windows. I failed to do it with DDE (because old-fashioned DDE doesn't seem to be really working with current Windows versions) and using the "find running PD process" method requires sending an "open patcher" inquiry to the TCL/TK part of the already-running PD which is beyond my TCL/TK capabilities (not to mention interest).
There's EnumProcesses in the PSAPI. ( http://msdn2.microsoft.com/en-us/library/ms682629.aspx ) A newly started instance of pd could use it to determine that it wasn't the only pd running and quit. How would it pass the patch to the other pd? There must be a registry setting for this kind of thing, since, for example, Photoshop doesn't open a new instance whenever you double-click one of its documents.
It's easy to find out whether a PD is already running, but the running PD must have a possibility to receive a inter-process message from the second PD and load the patch. I spent some time on that a few months ago, and if i remember correctly the show-stopper for me was that i found out that i'd have to patch the TK part to get this running. And then, it wasn't that important to really try hard.
gr~~~
Thomas Grill wrote:
Martin Peach schrieb:
Also if we double-click on the icon of a patch still on win32 platform, it opens an instance of pd, it would be nice if the patch was opened in the already loaded (the last one at least) instance of pd.
That is an old, known bug. I saw this Miller's TODO. If you got this working, and submitted a patch, I think he would be likely to
accept it.
I'm also very curious about a solution for this, which is non-trivial
on
Windows. I failed to do it with DDE (because old-fashioned DDE doesn't seem to be really working with current Windows versions) and using the "find running PD process" method requires sending an "open patcher" inquiry to the TCL/TK part of the already-running PD which is beyond my TCL/TK capabilities (not to mention interest).
There's EnumProcesses in the PSAPI. ( http://msdn2.microsoft.com/en-us/library/ms682629.aspx ) A newly started instance of pd could use it to determine that it wasn't the only pd running and quit. How would it pass the patch to the other pd? There must be a registry setting for this kind of thing, since, for example, Photoshop doesn't open a new instance whenever you double-click one of its documents.
It's easy to find out whether a PD is already running, but the running PD must have a possibility to receive a inter-process message from the second PD and load the patch. I spent some time on that a few months ago, and if i remember correctly the show-stopper for me was that i found out that i'd have to patch the TK part to get this running. And then, it wasn't that important to really try hard.
It's definitely possible to specify that an application run only as a single instance, I have found the documentation on MSDN for Visual Basic's Project Builder but not the underlying code or API to do it in c.
Martin
I have to say i really have kinda always hoped for a open recent feature or a self writing .rc file that remembers the last file but figured that was way low on the totem pole..
Patrick Pagano Sound and Light Technologist School of Theatre and Dance University of Florida
Hans-Christoph Steiner a écrit :
On Dec 4, 2007, at 4:20 AM, Patrice Colet wrote:
Hans Roels a écrit :
I also think this would be a simple but very handy tool, (also in pd-vanilla...), at this moment I always have to 'navigate' a lot to open files...
One parenthesis...(
in win32 pd-vanilla it's possible to drag'n'drop patches from explorer, sometimes this trick can save a lot of clicks'n'time, this trick already available in 0.37(, when I've started to try puredata,) doesn't work in pd-extended.
Really, how do you do that? I tried on Windows XP using pd-vanilla 0.39.2 and 0.40.2 and could not get any drag-n-drop to work.
in proc open_file from
pd-vanilla/bin/pd.tk line 432:
catch { package require tkdnd dnd bindtarget . text/uri-list <Drop> { foreach file %D {open_file $file} } }
this stuff needs tkdndlib
pkgIndex.tcl for windows:
package ifneeded tkdnd 1.0 [list load [file join $dir libtkdnd10.dll] tkdnd]
in linux I believe we don't need this kind of code for loading tk libs if it's installed correctly
On Dec 4, 2007, at 7:55 PM, Patrice Colet wrote:
Hans-Christoph Steiner a écrit :
On Dec 4, 2007, at 4:20 AM, Patrice Colet wrote:
Hans Roels a écrit :
I also think this would be a simple but very handy tool, (also in pd-vanilla...), at this moment I always have to 'navigate' a lot to open files...
One parenthesis...(
in win32 pd-vanilla it's possible to drag'n'drop patches from
explorer, sometimes this trick can save a lot of clicks'n'time, this trick
already available in 0.37(, when I've started to try puredata,) doesn't
work in pd-extended.Really, how do you do that? I tried on Windows XP using pd- vanilla 0.39.2 and 0.40.2 and could not get any drag-n-drop to work.
in proc open_file from
pd-vanilla/bin/pd.tk line 432:
catch { package require tkdnd dnd bindtarget . text/uri-list <Drop> { foreach file %D {open_file $file} } }
this stuff needs tkdndlib
pkgIndex.tcl for windows:
package ifneeded tkdnd 1.0 [list load [file join $dir
libtkdnd10.dll] tkdnd]in linux I believe we don't need this kind of code for loading tk
libs if it's installed correctly
So you are saying if you install tkdnd, then the tkdnd features don't
work in Pd-extended?
It would be very nice to have tkdnd built and included as part of Pd-
extended. Any interest in taking this on? Basically, it looks like
the best way to do it would be to import the tkdnd source code into
pure-data CVS, then make it build and install automatically.
Shouldn't be too hard if tkdnd is easy to build. Certainly easier
than making Pd build with Cygwin :D.
.hc
All information should be free. - the hacker ethic
Hans-Christoph Steiner a écrit :
On Dec 4, 2007, at 7:55 PM, Patrice Colet wrote:
Hans-Christoph Steiner a écrit :
On Dec 4, 2007, at 4:20 AM, Patrice Colet wrote:
Hans Roels a écrit :
I also think this would be a simple but very handy tool, (also in pd-vanilla...), at this moment I always have to 'navigate' a lot to open files...
One parenthesis...(
in win32 pd-vanilla it's possible to drag'n'drop patches from explorer, sometimes this trick can save a lot of clicks'n'time, this trick already available in 0.37(, when I've started to try puredata,) doesn't work in pd-extended.
Really, how do you do that? I tried on Windows XP using pd-vanilla 0.39.2 and 0.40.2 and could not get any drag-n-drop to work.
in proc open_file from
pd-vanilla/bin/pd.tk line 432:
catch { package require tkdnd dnd bindtarget . text/uri-list <Drop> { foreach file %D {open_file $file} } }
this stuff needs tkdndlib
pkgIndex.tcl for windows:
package ifneeded tkdnd 1.0 [list load [file join $dir libtkdnd10.dll] tkdnd]
in linux I believe we don't need this kind of code for loading tk libs if it's installed correctly
So you are saying if you install tkdnd, then the tkdnd features don't work in Pd-extended?
It would be very nice to have tkdnd built and included as part of Pd-extended. Any interest in taking this on? Basically, it looks like the best way to do it would be to import the tkdnd source code into pure-data CVS, then make it build and install automatically. Shouldn't be too hard if tkdnd is easy to build. Certainly easier than making Pd build with Cygwin :D.
.hc
If the build-system could build and install this tklib and some other ones, it would be just fabulous, and also we would be able to improve the gui a lot more easily. Also I'm not sure about what would be the best place for putting the building code of this feature
On Dec 5, 2007, at 7:55 AM, Patrice Colet wrote:
Hans-Christoph Steiner a écrit :
On Dec 4, 2007, at 7:55 PM, Patrice Colet wrote:
Hans-Christoph Steiner a écrit :
On Dec 4, 2007, at 4:20 AM, Patrice Colet wrote:
Hans Roels a écrit :
I also think this would be a simple but very handy tool, (also in pd-vanilla...), at this moment I always have to 'navigate' a
lot to open files...One parenthesis...(
in win32 pd-vanilla it's possible to drag'n'drop patches from
explorer, sometimes this trick can save a lot of clicks'n'time, this
trick already available in 0.37(, when I've started to try puredata,) doesn't
work in pd-extended.Really, how do you do that? I tried on Windows XP using pd- vanilla 0.39.2 and 0.40.2 and could not get any drag-n-drop to
work.in proc open_file from
pd-vanilla/bin/pd.tk line 432:
catch { package require tkdnd dnd bindtarget . text/uri-list <Drop> { foreach file %D {open_file $file} } }
this stuff needs tkdndlib
pkgIndex.tcl for windows:
package ifneeded tkdnd 1.0 [list load [file join $dir
libtkdnd10.dll] tkdnd]in linux I believe we don't need this kind of code for loading tk
libs if it's installed correctlySo you are saying if you install tkdnd, then the tkdnd features
don't work in Pd-extended? It would be very nice to have tkdnd built and included as part of
Pd-extended. Any interest in taking this on? Basically, it looks
like the best way to do it would be to import the tkdnd source
code into pure-data CVS, then make it build and install
automatically. Shouldn't be too hard if tkdnd is easy to build.
Certainly easier than making Pd build with Cygwin :D. .hcIf the build-system could build and install this tklib and some
other ones, it would be just fabulous, and also we would be able to
improve the gui a lot more easily. Also I'm not sure about what
would be the best place for putting the building code of this feature
I originally started the 'extensions' section in CVS for adding
things like tkdnd. I think there could be 'extensions/tcltk' and in
there we could put things like tkdnd, tkpath, etc. There would be
extensions/tcltk/Makefile, which would call the build system for each
of the packages (tkdnd, tkpath, etc), Then in 'extensions/Makefile',
it would call 'extensions/tcltk/Makefile' to build and install the
whole thing.
That's how I was thinking about it, but it could probably be done
other ways too.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
-
bigswift＠cox.net -
Hans-Christoph Steiner -
Martin Peach -
Patrice Colet -
Thomas Grill