Hi!
Closing a path pd asks me if I'm sure since 0.39. This is annoying and has been discussed here, but I can live with that.
Unfortunately, I found a real big problem around this bug: closing a patch via the pd message "menuclose", pd stops and asks "sure or not". This requires user interaction, which I wanted to avoid with the pd message.
Can I send to pd a message like "ctrl-shift-w", which means, close without any questions?
br, Piotr
Yep, try "menuclose 1".
By the way, I'm thinking of adding an option to allow clean windows to close without objecting, but am not sure what form this should take.. I think it's best to default to the most careful policy, but there should be a "settings" panel to defeat that. Or possibly, the patch itself should somehow declare itself precious, otherwise closing it doesn't complain. Not sure which way to go with it yet.
cheers Miller
On Wed, Sep 14, 2005 at 10:46:45AM +0200, Piotr Majdak wrote:
Hi!
Closing a path pd asks me if I'm sure since 0.39. This is annoying and has been discussed here, but I can live with that.
Unfortunately, I found a real big problem around this bug: closing a patch via the pd message "menuclose", pd stops and asks "sure or not". This requires user interaction, which I wanted to avoid with the pd message.
Can I send to pd a message like "ctrl-shift-w", which means, close without any questions?
br, Piotr
-- Piotr Majdak Institut f?r Schallforschung ?sterreichische Akademie der Wissenschaften Reichsratsstr. 17 A-1010 Wien Tel.: +43-1-4277-29511 Fax: +43-1-4277-9296 E-Mail: piotr@majdak.com WWW: http://www.kfs.oeaw.ac.at
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Miller Puckette wrote:
I'm thinking of adding an option to allow clean windows to close without objecting, but am not sure what form this should take.. I think it's best to default to the most careful policy, but there should be a "settings" panel to defeat that. Or possibly, the patch itself should somehow declare itself precious, otherwise closing it doesn't complain. Not sure which way to go with it yet.
How about if there is anything to 'Undo' in the Edit menu, the user is asked if they want to save the changes?
Martin
Well, there are two problems... first, in a performance you'd sure like
some way to avoid closing patches by accident, even if they're clean.
Second, it's possible to make a long audio recording into an array (for
example) without making the patch know it's "dirty".
I think the proper default behavior is the most careful one (the way it is now), but am not sure how to allow or encourage the user to override this, whether it should be selectively for individual patches, or as a global override, or even some combination of both.
cheers Miller
How about if there is anything to 'Undo' in the Edit menu, the user is asked if they want to save the changes?
Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Miller Puckette wrote:
Well, there are two problems... first, in a performance you'd sure like some way to avoid closing patches by accident, even if they're clean.
If this happens by accidentally hitting the close box or ctrl-w, perhaps a configurable way of enabling/disabling the close box and ctrl-w.
In pd.tk you have this to intercept the close box: wm protocol $name WM_DELETE_WINDOW [concat menu_close $name] and this to intercept Ctrl-W: if {$key == "w" || $key == "W"} {menu_close $topname}
..so probably both these bindings could be made conditional on some user-settable flag.
Second, it's possible to make a long audio recording into an array (for example) without making the patch know it's "dirty".
I notice there is a gl_dirty 'dirty' flag that gets tested in canvas_menuclose (at least in pd 038), I would guess that it could be set whenever _anything_ important has changed in the patch...
I think the proper default behavior is the most careful one (the way it is now),
I think asking if you want to save a help patch is both annoying and dangerous, since you might have accidentally changed the help patch which is usually not what you want Help patches should probably be read-only.
but am not sure how to allow or encourage the user to override this, whether it should be selectively for individual patches, or as a global override, or even some combination of both.
Possibly a checkbox on the main pd window near the 'compute audio' checkbox that would globally enable/disable the warning dialogs.
Martin
ok, i was a little confused by your UI change at first, but reading your reasoning, it makes a lot of sense. the fact that you can override the safe behavior with both a message and a keystroke is awsome and removed any objections i had. thanks.
-josh
Miller Puckette wrote:
Well, there are two problems... first, in a performance you'd sure like some way to avoid closing patches by accident, even if they're clean.
Second, it's possible to make a long audio recording into an array (for example) without making the patch know it's "dirty".I think the proper default behavior is the most careful one (the way it is now), but am not sure how to allow or encourage the user to override this, whether it should be selectively for individual patches, or as a global override, or even some combination of both.
cheers Miller
How about if there is anything to 'Undo' in the Edit menu, the user is asked if they want to save the changes?
Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
Well, there are two problems... first, in a performance you'd sure like some way to avoid closing patches by accident, even if they're clean.
This sounds sensible.
Second, it's possible to make a long audio recording into an array (for example) without making the patch know it's "dirty".
This however now is solved by practically getting rid of a patch's "dirty" state altogether, which to me sounds like throwing out the baby with the bathwater. Maybe we could get a little bit dirty again?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Fri, 16 Sep 2005, Frank Barknecht wrote:
Second, it's possible to make a long audio recording into an array (for example) without making the patch know it's "dirty".
This however now is solved by practically getting rid of a patch's "dirty" state altogether, which to me sounds like throwing out the baby with the bathwater. Maybe we could get a little bit dirty again?
Don't arrays have a dirty flag by themselves? they should.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Miller Puckette wrote:
panel to defeat that. Or possibly, the patch itself should somehow declare itself precious, otherwise closing it doesn't complain. Not sure which
now that would be really nice. (all of a sudden the new behaviour makes sense to me; i think in a general patch, most abstractions are considered non-precious but 1 (or several) "main" patches; to have all of them behave like precious is likely to be annoying) (but i'm telling you nothing new)
mfg.asd.r IOhannes
way to go with it yet.
i'd vote for per-patch flag.
mfg.gre.vcx IOhannes
Miller Puckette wrote:
Yep, try "menuclose 1".
Thanks!
By the way, I'm thinking of adding an option to allow clean windows to close without objecting, but am not sure what form this should take.. I think it's best to default to the most careful policy, but there should be a "settings" panel to defeat that. Or possibly, the patch itself should somehow declare itself precious, otherwise closing it doesn't complain. Not sure which way to go with it yet.
For the cetrainty of not closing a patch during a performance or while my patch records some important audio in a table, I'd like to put this patch in a "security mode": ask me before closing regardless the changes in the patch. For all other patches, I'd like to have a "normal mode", which means: ask me in case of changing the patch, not data. This would allow to use the help in a convienent way _and_ to have an additional security mechanism to prevent unwanted losses if I want.
Maybe a pd message would do it? [; pd security-mode 1;(
br, Piotr
-
Frank Barknecht -
IOhannes m zmoelnig -
Josh Steiner -
Martin Peach -
Mathieu Bouchard -
Miller Puckette -
Piotr Majdak