hi list, hans,
i noticed that in the current autobuilds of Pd-extended the property dialogs for the gui-objects are missing the Apply-Button. Is that a bug or a feature? IMHO this is a bug - if you want to adjust for instance a canvas to be the same size as another object of unknown size you can do that with a few clicks and the help of the Apply button. If you have to click OK and then go to context menu->Properties, set the size, OK repeately to do that it's simply annoying.
m.
On Wed, 2012-01-25 at 22:51 +0100, Max wrote:
hi list, hans,
i noticed that in the current autobuilds of Pd-extended the property dialogs for the gui-objects are missing the Apply-Button. Is that a bug or a feature? IMHO this is a bug - if you want to adjust for instance a canvas to be the same size as another object of unknown size you can do that with a few clicks and the help of the Apply button. If you have to click OK and then go to context menu->Properties, set the size, OK repeately to do that it's simply annoying.
m. _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
That seems like a good enough reason, I brought back the Apply button to the iemgui Properties panel on Mac OS X. It was originally moved since the whole "OK, Apply, Cancel" is very Windows-like, but there isn't an easy way to make to work better, so the Apply button is back. IMHO, when you change the setting, it should take effect immediately.
.hc
Am 27.01.2012 um 02:50 schrieb Hans-Christoph Steiner:
On Wed, 2012-01-25 at 22:51 +0100, Max wrote:
i noticed that in the current autobuilds of Pd-extended the property dialogs for the gui-objects are missing the Apply-Button. Is that a bug or a feature? IMHO this is a bug - if you want to adjust for instance a canvas to be the same size as another object of unknown size you can do that with a few clicks and the help of the Apply button. If you have to click OK and then go to context menu->Properties, set the size, OK repeately to do that it's simply annoying.
That seems like a good enough reason, I brought back the Apply button to the iemgui Properties panel on Mac OS X. It was originally moved since the whole "OK, Apply, Cancel" is very Windows-like, but there isn't an easy way to make to work better, so the Apply button is back. IMHO, when you change the setting, it should take effect immediately.
great. i agree that ideally i'd like to be able to see that change happen immediately. even better: when grabbing the bottom-right corner i'd have an anchor to scale the object (see Max/MSP for that)… but until that feature is implemented i'm grateful to have Apply back ;)
m.
----- Original Message -----
From: Max abonnements@revolwear.com To: Hans-Christoph Steiner hans@at.or.at Cc: PD list pd-list@iem.at Sent: Friday, January 27, 2012 10:02 AM Subject: Re: [PD] Apply missing
Am 27.01.2012 um 02:50 schrieb Hans-Christoph Steiner:
On Wed, 2012-01-25 at 22:51 +0100, Max wrote:
i noticed that in the current autobuilds of Pd-extended the property
dialogs for the gui-objects are missing the Apply-Button. Is that a bug or a feature?
IMHO this is a bug - if you want to adjust for instance a canvas to be
the same size as another object of unknown size you can do that with a few clicks and the help of the Apply button. If you have to click OK and then go to context menu->Properties, set the size, OK repeately to do that it's simply annoying.
That seems like a good enough reason, I brought back the Apply button to the iemgui Properties panel on Mac OS X. It was originally moved since the whole "OK, Apply, Cancel" is very Windows-like, but there
isn't an
easy way to make to work better, so the Apply button is back. IMHO, when you change the setting, it should take effect immediately.
great. i agree that ideally i'd like to be able to see that change happen immediately. even better: when grabbing the bottom-right corner i'd have an anchor to scale the object (see Max/MSP for that)…
Also see: pd-l2ork
but until that feature is implemented i'm grateful to have Apply back ;)
m. _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Jan 27, 2012, at 11:26 AM, Jonathan Wilkes wrote:
----- Original Message -----
From: Max abonnements@revolwear.com To: Hans-Christoph Steiner hans@at.or.at Cc: PD list pd-list@iem.at Sent: Friday, January 27, 2012 10:02 AM Subject: Re: [PD] Apply missing
Am 27.01.2012 um 02:50 schrieb Hans-Christoph Steiner:
On Wed, 2012-01-25 at 22:51 +0100, Max wrote:
i noticed that in the current autobuilds of Pd-extended the property
dialogs for the gui-objects are missing the Apply-Button. Is that a bug or a feature?
IMHO this is a bug - if you want to adjust for instance a canvas to be
the same size as another object of unknown size you can do that with a few clicks and the help of the Apply button. If you have to click OK and then go to context menu->Properties, set the size, OK repeately to do that it's simply annoying.
That seems like a good enough reason, I brought back the Apply button to the iemgui Properties panel on Mac OS X. It was originally moved since the whole "OK, Apply, Cancel" is very Windows-like, but there
isn't an
easy way to make to work better, so the Apply button is back. IMHO, when you change the setting, it should take effect immediately.
great. i agree that ideally i'd like to be able to see that change happen immediately. even better: when grabbing the bottom-right corner i'd have an anchor to scale the object (see Max/MSP for that)…
Also see: pd-l2ork
I think you are referring to Ico trying to make the iemguis resizable live with a handle. I should finally get to releasing something useful form the tkwidgets lib, since that also includes resizing with a handle.
.hc
kill your television
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Max abonnements@revolwear.com; PD list pd-list@iem.at Sent: Friday, January 27, 2012 11:39 AM Subject: Re: [PD] Apply missing
On Jan 27, 2012, at 11:26 AM, Jonathan Wilkes wrote:
----- Original Message -----
From: Max abonnements@revolwear.com To: Hans-Christoph Steiner hans@at.or.at Cc: PD list pd-list@iem.at Sent: Friday, January 27, 2012 10:02 AM Subject: Re: [PD] Apply missing
Am 27.01.2012 um 02:50 schrieb Hans-Christoph Steiner:
On Wed, 2012-01-25 at 22:51 +0100, Max wrote:
i noticed that in the current autobuilds of Pd-extended the
property
dialogs for the gui-objects are missing the Apply-Button. Is that a bug
or a
feature?
IMHO this is a bug - if you want to adjust for instance a
canvas to be
the same size as another object of unknown size you can do that with a
few
clicks and the help of the Apply button. If you have to click OK and
then go to
context menu->Properties, set the size, OK repeately to do that
it's
simply annoying.
That seems like a good enough reason, I brought back the Apply
button to
the iemgui Properties panel on Mac OS X. It was originally moved
since
the whole "OK, Apply, Cancel" is very Windows-like, but
there
isn't an
easy way to make to work better, so the Apply button is back.
IMHO,
when you change the setting, it should take effect immediately.
great. i agree that ideally i'd like to be able to see that change
happen
immediately. even better: when grabbing the bottom-right corner i'd
have an
anchor to scale the object (see Max/MSP for that)…
Also see: pd-l2ork
I think you are referring to Ico trying to make the iemguis resizable live with a handle.
Yep. All the iemguis are resizable with a little anchor that appears when the object is selected. Very handy.
I should finally get to releasing something useful form the tkwidgets lib, since that also includes resizing with a handle.
Right, I remember that when I tried them. To make them useful is difficult, though, because iemguis have (rightly) set a precedent that gui objects can integrate naturally into a normal object chain. For example, it's not uncommon to find a [tgl] deep inside a subpatch somewhere and my friend running pd -nogui can still run my program. Or the user having a little UI subpatch that pops up or gets hidden as needed-- if you depend on the actual tk widget to exist in order for its properties to get set, then the user will get an error if for example they try to change its size or placement when it's not vis'd. So I guess on the one hand it's nice to separate gui from pd, but on the other you don't want to force the user to care about implementation details like, "when a subpatch closes and no one can see its contents, does it _really_ have a slider inside there?" If the answer is yes for pd-ish methods and no for tk/gui-related methods, things start to get tricky.
-Jonathan
.hc
kill your television
On Fri, Jan 27, 2012, at 09:21, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Max abonnements@revolwear.com; PD list pd-list@iem.at Sent: Friday, January 27, 2012 11:39 AM Subject: Re: [PD] Apply missing
On Jan 27, 2012, at 11:26 AM, Jonathan Wilkes wrote:
----- Original Message -----
From: Max abonnements@revolwear.com To: Hans-Christoph Steiner hans@at.or.at Cc: PD list pd-list@iem.at Sent: Friday, January 27, 2012 10:02 AM Subject: Re: [PD] Apply missing
Am 27.01.2012 um 02:50 schrieb Hans-Christoph Steiner:
On Wed, 2012-01-25 at 22:51 +0100, Max wrote:
i noticed that in the current autobuilds of Pd-extended the
property
dialogs for the gui-objects are missing the Apply-Button. Is that a bug
or a
feature?
IMHO this is a bug - if you want to adjust for instance a
canvas to be
the same size as another object of unknown size you can do that with a
few
clicks and the help of the Apply button. If you have to click OK and
then go to
context menu->Properties, set the size, OK repeately to do that
it's
simply annoying.
That seems like a good enough reason, I brought back the Apply
button to
the iemgui Properties panel on Mac OS X. It was originally moved
since
the whole "OK, Apply, Cancel" is very Windows-like, but
there
isn't an
easy way to make to work better, so the Apply button is back.
IMHO,
when you change the setting, it should take effect immediately.
great. i agree that ideally i'd like to be able to see that change
happen
immediately. even better: when grabbing the bottom-right corner i'd
have an
anchor to scale the object (see Max/MSP for that)…
Also see: pd-l2ork
I think you are referring to Ico trying to make the iemguis resizable live with a handle.
Yep. All the iemguis are resizable with a little anchor that appears when the object is selected. Very handy.
I should finally get to releasing something useful form the tkwidgets lib, since that also includes resizing with a handle.
Right, I remember that when I tried them. To make them useful is difficult, though, because iemguis have (rightly) set a precedent that gui objects can integrate naturally into a normal object chain. For example, it's not uncommon to find a [tgl] deep inside a subpatch somewhere and my friend running pd -nogui can still run my program. Or the user having a little UI subpatch that pops up or gets hidden as needed-- if you depend on the actual tk widget to exist in order for its properties to get set, then the user will get an error if for example they try to change its size or placement when it's not vis'd. So I guess on the one hand it's nice to separate gui from pd, but on the other you don't want to force the user to care about implementation details like, "when a subpatch closes and no one can see its contents, does it _really_ have a slider inside there?" If the answer is yes for pd-ish methods and no for tk/gui-related methods, things start to get tricky.
That is definitely an important point, and I think its something that the tkwidgets approach can also support. I'm thinking that when a tkwidgets object does not have a Tk representation, it could just store the messages destined for that Tk object. There are problems there too, I suppose, but it would be nice to avoid reimplementing the whole Tk object's data structure on the 'pd' side.
.hc
Am 27.01.2012 um 17:39 schrieb Hans-Christoph Steiner hans@at.or.at:
On Jan 27, 2012, at 11:26 AM, Jonathan Wilkes wrote:
From: Max abonnements@revolwear.com Am 27.01.2012 um 02:50 schrieb Hans-Christoph Steiner:
On Wed, 2012-01-25 at 22:51 +0100, Max wrote:
i noticed that in the current autobuilds of Pd-extended the property
dialogs for the gui-objects are missing the Apply-Button. Is that a bug or a feature?
IMHO this is a bug - if you want to adjust for instance a canvas to be
the same size as another object of unknown size you can do that with a few clicks and the help of the Apply button. If you have to click OK and then go to context menu->Properties, set the size, OK repeately to do that it's simply annoying.
That seems like a good enough reason, I brought back the Apply button to the iemgui Properties panel on Mac OS X. It was originally moved since the whole "OK, Apply, Cancel" is very Windows-like, but there
isn't an
easy way to make to work better, so the Apply button is back. IMHO, when you change the setting, it should take effect immediately.
great. i agree that ideally i'd like to be able to see that change happen immediately. even better: when grabbing the bottom-right corner i'd have an anchor to scale the object (see Max/MSP for that)…
Also see: pd-l2ork
I think you are referring to Ico trying to make the iemguis resizable live with a handle. I should finally get to releasing something useful form the tkwidgets lib, since that also includes resizing with a handle.
I just had another Idea how to solve this: Two buttons: Cancel and OK when you change some properties in the Dialog the OK Button becomes labeled Apply. If clicked on Apply, the new properties are applied and the Button becomes labeled OK. If you click OK the Dialog is closed. That way a double click on Apply will apply and close the dialog.
I haven't seen this anywhere before, so this might be strange to introduce a whole new button interaction concept, but I just wrote it down for someone to patent it. :) (or maybe I haven't seen this before because it is already patented? could be too..) m.
----- Original Message -----
From: Max abonnements@revolwear.com To: Hans-Christoph Steiner hans@at.or.at Cc: Jonathan Wilkes jancsika@yahoo.com; PD list pd-list@iem.at Sent: Saturday, February 2, 2013 1:32 AM Subject: Re: [PD] Apply missing
Am 27.01.2012 um 17:39 schrieb Hans-Christoph Steiner hans@at.or.at:
On Jan 27, 2012, at 11:26 AM, Jonathan Wilkes wrote:
From: Max abonnements@revolwear.com Am 27.01.2012 um 02:50 schrieb Hans-Christoph Steiner:
On Wed, 2012-01-25 at 22:51 +0100, Max wrote:
i noticed that in the current autobuilds of Pd-extended the
property
dialogs for the gui-objects are missing the Apply-Button. Is that a
bug or a
feature?
IMHO this is a bug - if you want to adjust for instance a
canvas to be
the same size as another object of unknown size you can do that
with a few
clicks and the help of the Apply button. If you have to click OK
and then go to
context menu->Properties, set the size, OK repeately to do that
it's
simply annoying.
That seems like a good enough reason, I brought back the Apply
button to
the iemgui Properties panel on Mac OS X. It was originally
moved since
the whole "OK, Apply, Cancel" is very Windows-like,
but there
isn't an
easy way to make to work better, so the Apply button is back.
IMHO,
when you change the setting, it should take effect immediately.
great. i agree that ideally i'd like to be able to see that
change happen
immediately. even better: when grabbing the bottom-right corner
i'd have an
anchor to scale the object (see Max/MSP for that)…
Also see: pd-l2ork
I think you are referring to Ico trying to make the iemguis resizable live
with a handle. I should finally get to releasing something useful form the tkwidgets lib, since that also includes resizing with a handle.
I just had another Idea how to solve this: Two buttons: Cancel and OK when you change some properties in the Dialog the OK Button becomes labeled Apply. If clicked on Apply, the new properties are applied and the Button becomes labeled OK. If you click OK the Dialog is closed. That way a double click on Apply will apply and close the dialog.
That would double the number of clicks for users who never want to use Apply.
-Jonathan
On 02/02/2013 02:06 AM, Jonathan Wilkes wrote:
----- Original Message -----
From: Max abonnements@revolwear.com To: Hans-Christoph Steiner hans@at.or.at Cc: Jonathan Wilkes jancsika@yahoo.com; PD list pd-list@iem.at Sent: Saturday, February 2, 2013 1:32 AM Subject: Re: [PD] Apply missing
Am 27.01.2012 um 17:39 schrieb Hans-Christoph Steiner hans@at.or.at:
On Jan 27, 2012, at 11:26 AM, Jonathan Wilkes wrote:
From: Max abonnements@revolwear.com Am 27.01.2012 um 02:50 schrieb Hans-Christoph Steiner:
On Wed, 2012-01-25 at 22:51 +0100, Max wrote: > > i noticed that in the current autobuilds of Pd-extended the
property
dialogs for the gui-objects are missing the Apply-Button. Is that a
bug or a
feature?
> IMHO this is a bug - if you want to adjust for instance a
canvas to be
the same size as another object of unknown size you can do that
with a few
clicks and the help of the Apply button. If you have to click OK
and then go to
context menu->Properties, set the size, OK repeately to do that
it's
simply annoying.
> That seems like a good enough reason, I brought back the Apply
button to
the iemgui Properties panel on Mac OS X. It was originally
moved since
the whole "OK, Apply, Cancel" is very Windows-like,
but there
isn't an
easy way to make to work better, so the Apply button is back.
IMHO,
when you change the setting, it should take effect immediately.
great. i agree that ideally i'd like to be able to see that
change happen
immediately. even better: when grabbing the bottom-right corner
i'd have an
anchor to scale the object (see Max/MSP for that)…
Also see: pd-l2ork
I think you are referring to Ico trying to make the iemguis resizable live
with a handle. I should finally get to releasing something useful form the tkwidgets lib, since that also includes resizing with a handle.
I just had another Idea how to solve this: Two buttons: Cancel and OK when you change some properties in the Dialog the OK Button becomes labeled Apply. If clicked on Apply, the new properties are applied and the Button becomes labeled OK. If you click OK the Dialog is closed. That way a double click on Apply will apply and close the dialog.
That would double the number of clicks for users who never want to use Apply.
I think that we should avoid patch fixes and do the right thing. I think we should follow the example of Pd itself, but then also GNOME and Mac OS X preferences: changes should take effect immediately without having to hit apply or OK. Then there should be unlimited undo for returning to previous states. The first part o that is not hard, the second part is. But since unlimited undo is working in some parts of pd-l2ork, we at least have a working example to draw from.
hc
On Feb 2, 2013 8:38 PM, "Hans-Christoph Steiner" hans@at.or.at wrote:
On 02/02/2013 02:06 AM, Jonathan Wilkes wrote:
----- Original Message -----
From: Max abonnements@revolwear.com To: Hans-Christoph Steiner hans@at.or.at Cc: Jonathan Wilkes jancsika@yahoo.com; PD list pd-list@iem.at Sent: Saturday, February 2, 2013 1:32 AM Subject: Re: [PD] Apply missing
Am 27.01.2012 um 17:39 schrieb Hans-Christoph Steiner hans@at.or.at:
On Jan 27, 2012, at 11:26 AM, Jonathan Wilkes wrote:
From: Max abonnements@revolwear.com Am 27.01.2012 um 02:50 schrieb Hans-Christoph Steiner: > On Wed, 2012-01-25 at 22:51 +0100, Max wrote: >> >> i noticed that in the current autobuilds of Pd-extended the
property
dialogs for the gui-objects are missing the Apply-Button. Is that a
bug or a
feature? >> IMHO this is a bug - if you want to adjust for instance a
canvas to be
the same size as another object of unknown size you can do that
with a few
clicks and the help of the Apply button. If you have to click OK
and then go to
context menu->Properties, set the size, OK repeately to do that
it's
simply annoying. >> > That seems like a good enough reason, I brought back the Apply
button to
> the iemgui Properties panel on Mac OS X. It was originally
moved since
> the whole "OK, Apply, Cancel" is very Windows-like,
but there
isn't an > easy way to make to work better, so the Apply button is back.
IMHO,
> when you change the setting, it should take effect immediately.
great. i agree that ideally i'd like to be able to see that
change happen
immediately. even better: when grabbing the bottom-right corner
i'd have an
anchor to scale the object (see Max/MSP for that)…
Also see: pd-l2ork
I think you are referring to Ico trying to make the iemguis
resizable live
with a handle. I should finally get to releasing something useful
form the
tkwidgets lib, since that also includes resizing with a handle.
I just had another Idea how to solve this: Two buttons: Cancel and OK
when you
change some properties in the Dialog the OK Button becomes labeled
Apply. If
clicked on Apply, the new properties are applied and the Button
becomes labeled
OK. If you click OK the Dialog is closed. That way a double click on Apply will apply and close the dialog.
That would double the number of clicks for users who never want to use Apply.
I think that we should avoid patch fixes and do the right thing. I think
we
should follow the example of Pd itself, but then also GNOME and Mac OS X preferences: changes should take effect immediately without having to hit apply or OK. Then there should be unlimited undo for returning to
previous
states. The first part o that is not hard, the second part is. But since unlimited undo is working in some parts of pd-l2ork, we at least have a working example to draw from.
What do you mean by "in some parts?" Can you give an example of where it does not work?
hc
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
On 02/02/2013 09:18 PM, Ivica Bukvic wrote:
On Feb 2, 2013 8:38 PM, "Hans-Christoph Steiner" hans@at.or.at wrote:
On 02/02/2013 02:06 AM, Jonathan Wilkes wrote:
----- Original Message -----
From: Max abonnements@revolwear.com To: Hans-Christoph Steiner hans@at.or.at Cc: Jonathan Wilkes jancsika@yahoo.com; PD list pd-list@iem.at Sent: Saturday, February 2, 2013 1:32 AM Subject: Re: [PD] Apply missing
Am 27.01.2012 um 17:39 schrieb Hans-Christoph Steiner hans@at.or.at:
On Jan 27, 2012, at 11:26 AM, Jonathan Wilkes wrote:
> From: Max abonnements@revolwear.com > Am 27.01.2012 um 02:50 schrieb Hans-Christoph Steiner: >> On Wed, 2012-01-25 at 22:51 +0100, Max wrote: >>> >>> i noticed that in the current autobuilds of Pd-extended the
property
> dialogs for the gui-objects are missing the Apply-Button. Is that a
bug or a
> feature? >>> IMHO this is a bug - if you want to adjust for instance a
canvas to be
> the same size as another object of unknown size you can do that
with a few
> clicks and the help of the Apply button. If you have to click OK
and then go to
> context menu->Properties, set the size, OK repeately to do that
it's
> simply annoying. >>> >> That seems like a good enough reason, I brought back the Apply
button to
>> the iemgui Properties panel on Mac OS X. It was originally
moved since
>> the whole "OK, Apply, Cancel" is very Windows-like,
but there
> isn't an >> easy way to make to work better, so the Apply button is back.
IMHO,
>> when you change the setting, it should take effect immediately. > > great. i agree that ideally i'd like to be able to see that
change happen
> immediately. even better: when grabbing the bottom-right corner
i'd have an
> anchor to scale the object (see Max/MSP for that)…
Also see: pd-l2ork
I think you are referring to Ico trying to make the iemguis
resizable live
with a handle. I should finally get to releasing something useful
form the
tkwidgets lib, since that also includes resizing with a handle.
I just had another Idea how to solve this: Two buttons: Cancel and OK
when you
change some properties in the Dialog the OK Button becomes labeled
Apply. If
clicked on Apply, the new properties are applied and the Button
becomes labeled
OK. If you click OK the Dialog is closed. That way a double click on Apply will apply and close the dialog.
That would double the number of clicks for users who never want to use Apply.
I think that we should avoid patch fixes and do the right thing. I think
we
should follow the example of Pd itself, but then also GNOME and Mac OS X preferences: changes should take effect immediately without having to hit apply or OK. Then there should be unlimited undo for returning to
previous
states. The first part o that is not hard, the second part is. But since unlimited undo is working in some parts of pd-l2ork, we at least have a working example to draw from.
What do you mean by "in some parts?" Can you give an example of where it does not work?
Setting a value in the properties of a slider.
.hc
states. The first part o that is not hard, the second part is. But
since
unlimited undo is working in some parts of pd-l2ork, we at least have a working example to draw from.
What do you mean by "in some parts?" Can you give an example of where
it
does not work?
Setting a value in the properties of a slider.
You are kidding, right? If the value changes in the UI, this should not be undoable. Otherwise, having that slider connected to a [metro 1] and random would starve memory within minutes, needless to mention make undo completely useless...
On Son, 2013-02-03 at 00:25 -0500, Ivica Ico Bukvic wrote:
states. The first part o that is not hard, the second part is. But
since
unlimited undo is working in some parts of pd-l2ork, we at least have a working example to draw from.
What do you mean by "in some parts?" Can you give an example of where
it
does not work?
Setting a value in the properties of a slider.
You are kidding, right? If the value changes in the UI, this should not be undoable. Otherwise, having that slider connected to a [metro 1] and random would starve memory within minutes, needless to mention make undo completely useless...
I guess Hans is talking about properties like color, sendname etc. The rationale is that those might be considered to be part of patch editing as opposed to changing slider values which could be considered part of patch usage.
Roman
On 03/02/2013 11:05, Roman Haefeli wrote:
On Son, 2013-02-03 at 00:25 -0500, Ivica Ico Bukvic wrote:
states. The first part o that is not hard, the second part is. But
since
unlimited undo is working in some parts of pd-l2ork, we at least have a working example to draw from.
What do you mean by "in some parts?" Can you give an example of where
it
does not work?
Setting a value in the properties of a slider.
You are kidding, right? If the value changes in the UI, this should not be undoable. Otherwise, having that slider connected to a [metro 1] and random would starve memory within minutes, needless to mention make undo completely useless...
I guess Hans is talking about properties like color, sendname etc. The rationale is that those might be considered to be part of patch editing as opposed to changing slider values which could be considered part of patch usage.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
undo-plugin ? Just check what you want to be able to undo ! Kidding ;) (almost)
Those are a part of the undo on pd-l2ork, as is changing properties of any other object, such as canvas and array (unlike pd-extended that in many cases fails to even acknowledge that the patch has been altered and needs to be saved, needless to mention add such change to its 1-step undo queue, e.g. try changing canvas properties and undoing it).
It would be nice if not spreading FUD were added to the mailing list netiquette... On Feb 3, 2013 5:07 AM, "Roman Haefeli" reduzent@gmail.com wrote:
On Son, 2013-02-03 at 00:25 -0500, Ivica Ico Bukvic wrote:
states. The first part o that is not hard, the second part is. But
since
unlimited undo is working in some parts of pd-l2ork, we at least
have a
working example to draw from.
What do you mean by "in some parts?" Can you give an example of where
it
does not work?
Setting a value in the properties of a slider.
You are kidding, right? If the value changes in the UI, this should not
be
undoable. Otherwise, having that slider connected to a [metro 1] and
random
would starve memory within minutes, needless to mention make undo
completely
useless...
I guess Hans is talking about properties like color, sendname etc. The rationale is that those might be considered to be part of patch editing as opposed to changing slider values which could be considered part of patch usage.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I stand corrected, sorry, I was mistaken before. Yes, the undo situation in Pd vanilla/extended is not good.
I didn't realize I'd become Microsoft, I thought I was just writing some software for people to freely use ;-)
.hc
On 02/03/2013 09:58 AM, Ivica Bukvic wrote:
Those are a part of the undo on pd-l2ork, as is changing properties of any other object, such as canvas and array (unlike pd-extended that in many cases fails to even acknowledge that the patch has been altered and needs to be saved, needless to mention add such change to its 1-step undo queue, e.g. try changing canvas properties and undoing it).
It would be nice if not spreading FUD were added to the mailing list netiquette... On Feb 3, 2013 5:07 AM, "Roman Haefeli" reduzent@gmail.com wrote:
On Son, 2013-02-03 at 00:25 -0500, Ivica Ico Bukvic wrote:
states. The first part o that is not hard, the second part is. But
since
unlimited undo is working in some parts of pd-l2ork, we at least
have a
working example to draw from.
What do you mean by "in some parts?" Can you give an example of where
it
does not work?
Setting a value in the properties of a slider.
You are kidding, right? If the value changes in the UI, this should not
be
undoable. Otherwise, having that slider connected to a [metro 1] and
random
would starve memory within minutes, needless to mention make undo
completely
useless...
I guess Hans is talking about properties like color, sendname etc. The rationale is that those might be considered to be part of patch editing as opposed to changing slider values which could be considered part of patch usage.
Roman
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
Speaking of Microsoft-like statements, are you apologizing for the fact that pd-extended's undo is bad or the fact that you misrepresented pd-l2ork's undo as being incomplete? ;-) On Feb 3, 2013 10:31 AM, "Hans-Christoph Steiner" hans@at.or.at wrote:
I stand corrected, sorry, I was mistaken before. Yes, the undo situation in Pd vanilla/extended is not good.
I didn't realize I'd become Microsoft, I thought I was just writing some software for people to freely use ;-)
.hc
On 02/03/2013 09:58 AM, Ivica Bukvic wrote:
Those are a part of the undo on pd-l2ork, as is changing properties of
any
other object, such as canvas and array (unlike pd-extended that in many cases fails to even acknowledge that the patch has been altered and needs to be saved, needless to mention add such change to its 1-step undo
queue,
e.g. try changing canvas properties and undoing it).
It would be nice if not spreading FUD were added to the mailing list netiquette... On Feb 3, 2013 5:07 AM, "Roman Haefeli" reduzent@gmail.com wrote:
On Son, 2013-02-03 at 00:25 -0500, Ivica Ico Bukvic wrote:
> states. The first part o that is not hard, the second part is. But
since
> unlimited undo is working in some parts of pd-l2ork, we at least
have a
> working example to draw from.
What do you mean by "in some parts?" Can you give an example of where
it
does not work?
Setting a value in the properties of a slider.
You are kidding, right? If the value changes in the UI, this should not
be
undoable. Otherwise, having that slider connected to a [metro 1] and
random
would starve memory within minutes, needless to mention make undo
completely
useless...
I guess Hans is talking about properties like color, sendname etc. The rationale is that those might be considered to be part of patch editing as opposed to changing slider values which could be considered part of patch usage.
Roman
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
From: Ivica Bukvic ico@vt.edu To: Roman Haefeli reduzent@gmail.com Cc: pd-list pd-list@iem.at Sent: Sunday, February 3, 2013 9:58 AM Subject: Re: [PD] Apply missing
Those are a part of the undo on pd-l2ork, as is changing properties of any other object, such as canvas and array (unlike pd-extended that in many cases fails to even acknowledge that the patch has been altered and needs to be saved, needless to mention add such change to its 1-step undo queue, e.g. try changing canvas properties and undoing it).
A clarification here-- if you make changes to an iemgui programmatically by sending messages to a receive-name, it doesn't get registered in the undo history. This is nice. Because Pd is extremely limited in the GUI widgets it provides, many people abuse iemguis to make things like file choosers and pop-up menus, or even do GUI animations, which produce lots of "transient" changes to iemguiproperties
It would be nice if not spreading FUD were added to the mailing list netiquette...
I recently added to the netiquette guide in an attempt to make newcomers feel more welcome on the list. The aim is to decrease posting anxiety, not increase it. We should remember technology lowers the cost to assuming good faith when people are wrong in cases like this, so please remain lazy and resist the urge to endlessly loop in symbolic vigilance:
[r reenter] | [spread FUD( | | [r stop] | | | [bang; reenter But I'm acting in bad faith so why do I care about not spreading FUD?( | | | [t b b] | | / [until] / | [add2 in bad faith( | / | / | / | / |/ [Netiquette guide says Don't spread FUD( | [s stop]
-Jonathan
On Feb 3, 2013 2:05 PM, "Jonathan Wilkes" jancsika@yahoo.com wrote:
From: Ivica Bukvic ico@vt.edu To: Roman Haefeli reduzent@gmail.com Cc: pd-list pd-list@iem.at Sent: Sunday, February 3, 2013 9:58 AM Subject: Re: [PD] Apply missing
Those are a part of the undo on pd-l2ork, as is changing properties of
any other object, such as canvas and array (unlike pd-extended that in many cases fails to even acknowledge that the patch has been altered and needs to be saved, needless to mention add such change to its 1-step undo queue, e.g. try changing canvas properties and undoing it).
A clarification here-- if you make changes to an iemgui programmatically
by sending
messages to a receive-name, it doesn't get registered in the undo history. This is nice. Because Pd is extremely limited in the GUI widgets it
provides,
many people abuse iemguis to make things like file choosers and pop-up menus, or even do GUI animations, which produce lots of "transient"
changes
to iemguiproperties
Yep. And that was a conscious decision to leave it that way.
It would be nice if not spreading FUD were added to the mailing list
netiquette...
I recently added to the netiquette guide in an attempt to make newcomers feel more welcome on the list. The aim is to decrease posting anxiety, not increase it. We should remember technology lowers the cost to assuming good faith when people are wrong in cases like this, so please remain lazy and resist the urge to endlessly loop in symbolic vigilance:
[r reenter] | [spread FUD( | | [r stop] | | | [bang; reenter But I'm acting in bad faith so why do I care about
not spreading FUD?(
| | | [t b b] | | / [until] / | [add2 in bad faith( | / | / | / | / |/ [Netiquette guide says Don't spread FUD( | [s stop]
-Jonathan
-
batinste -
Hans-Christoph Steiner -
Ivica Bukvic -
Ivica Ico Bukvic
-
Jonathan Wilkes -
Max -
Roman Haefeli