yeah i've been finding this a bit of a chore too, i think only prompting if the window has been altered is a fair comprimise (and perhaps bringing up "do you want to save?" instead of do you want to close?)
also on my pretty please pd request list is a "define shortcut keys mode" - i prefer just being able to press ctl-1 for an object rather than ctl-shift-1 - don't want to start a flame war on the merits of either, thought having a preferences file for individual pd wranglers to choose would be a way to keep everyone happy
and today i got to thinking that i'd like some kind of easy record mode... just to be able to press a key and have the current sounds playing recorded to file until i press the key again... and the audio files incrementally named automatically so that it requires no user intervention at the point of finding stuff, and no need to patch in a recording object.. this sounds like an abstraction that i'm fixing to make but i thought it would be a great feature to have built into the app.
all the best
adam
Yahoo! Cars NEW - sell your car and browse thousands of new and used cars online search now
Zitat von adam armfield adamairmailed@yahoo.com:
yeah i've been finding this a bit of a chore too, i think only
prompting if the window has been altered is a fair comprimise (and
perhaps bringing up "do you want to save?" instead of do you want to
close?)
this has been discussed thoroughly on this list: the final state (iirc) is, tht miller had no plans to change this behaviour back; he had good reasons for his arguments, which you can find by searching the archives.
asking for "save" rather than "really close" seems to be a good idea however.
also on my pretty please pd request list is a "define shortcut keys
mode" - i prefer just being able to press ctl-1 for an object rather
than ctl-shift-1 - don't want to start a flame war on the merits of
either, thought having a preferences file for individual pd wranglers to choose would be a way to keep everyone happy
now this would be nice to have: this way you could override the reluctant closing with the enforced closing.
mfg.adr. IOhannes
(Sorry IOhannes, missed the list on that one) Currently (at least on Mac OS X) Pd has no qualms about shutting down without question if the main window is closed, which seems a bit silly considering the proliferation of confirmation boxes elsewhere. I've lost quite a bit of work this way, accidentally using command-q (quit) rather than command-w (close window). I'm also in the questionable habit of using quit to bring up the save dialogue before quitting, which is fairly standard behavior in other applications.
That's not to mention that OS X usually has an Application/Window disconnect
- in that closing the windows of a program does not actually quit - so it is
especially unexpected on the Mac.
Update... I've also confirmed this is the behavior in Windows.
Cheers, Luke
On 4/10/06, zmoelnig@iem.at zmoelnig@iem.at wrote:
Zitat von adam armfield adamairmailed@yahoo.com:
yeah i've been finding this a bit of a chore too, i think only prompting if the window has been altered is a fair comprimise (and perhaps bringing up "do you want to save?" instead of do you want to close?)
this has been discussed thoroughly on this list: the final state (iirc) is, tht miller had no plans to change this behaviour back; he had good reasons for his arguments, which you can find by searching the archives.
asking for "save" rather than "really close" seems to be a good idea however.
also on my pretty please pd request list is a "define shortcut keys mode" - i prefer just being able to press ctl-1 for an object rather than ctl-shift-1 - don't want to start a flame war on the merits of either, thought having a preferences file for individual pd wranglers to choose would be a way to keep everyone happy
now this would be nice to have: this way you could override the reluctant closing with the enforced closing.
mfg.adr. IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Luke Iannini (pd) wrote:
(Sorry IOhannes, missed the list on that one) Currently (at least on Mac OS X) Pd has no qualms about shutting down without question if the main window is closed, which seems a bit silly considering the proliferation of confirmation boxes elsewhere. I've lost quite a bit of work this way, accidentally using command-q (quit) rather than command-w (close window). I'm also in the questionable habit of using quit to bring up the save dialogue before quitting, which is fairly standard behavior in other applications.
In Miller's pd 0.39 test 7 the only way to quit without being asked to save changes (except for crashing) is to hit the close box on the main window with the mouse. In pd.tk the line: wm protocol $name WM_DELETE_WINDOW [concat menu_close $name] ...is supposed to trap the window close box, if I understand it correctly...for some reason it doesn't get the main window. In g_editor.c: void canvas_menuclose(t_canvas *x, t_floatarg fforce) ...is supposed to find all 'dirty' windows and ask the user if they want them saved. This doesn't work with the main pd window. Perhaps someone knows why...are patchers not in the same list as the main window?
Martin
On Wed, 12 Apr 2006, Martin Peach wrote:
wm protocol $name WM_DELETE_WINDOW [concat menu_close $name] ...is supposed to trap the window close box, if I understand it correctly...for some reason it doesn't get the main window.
it's because it's inside "proc pdtk_canvas_new", which is only for canvases. You need to add an extra line in the main program (just outside of any proc {} section) that's like this:
wm protocol . WM_DELETE_WINDOW [concat menu_close .]
except that menu_close isn't designed to work with the "." (main) window so you'll have to figure out something that does... maybe:
wm protocol . WM_DELETE_WINDOW menu_quit
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Wed, 12 Apr 2006, Martin Peach wrote:
wm protocol $name WM_DELETE_WINDOW [concat menu_close $name] ...is supposed to trap the window close box, if I understand it correctly...for some reason it doesn't get the main window.
it's because it's inside "proc pdtk_canvas_new", which is only for canvases. You need to add an extra line in the main program (just outside of any proc {} section) that's like this:
wm protocol . WM_DELETE_WINDOW [concat menu_close .]
except that menu_close isn't designed to work with the "." (main) window so you'll have to figure out something that does... maybe:
wm protocol . WM_DELETE_WINDOW menu_quit
That last one seems to work well. Thanks, Mathieu!
Martin
-
adam armfield -
Luke Iannini (pd) -
Martin Peach -
Mathieu Bouchard -
zmoelnig＠iem.at