Hi,
I don't know if this is already being addressed in the rewrite-gui version...
I've always wondered why message boxes are not treated as gui elements, like number and symbol boxes, that is:
- they do not graph on parent
- they do not have a properties dialog with at least a send and receive
symbol
Is there some particular reason why it has been decided not to treat (or allow treating) message boxes as gui elements, or is it simply that it has never been felt as a priority to implement this feature? I mean, would it imply any drawback?
I've often wondered of message boxes, why they don't have some form of GUI to indicate when they're triggered (like the bang object). Sorry, this is an asside but I would like to know why.
Date: Mon, 8 Feb 2010 18:25:18 +0100 From: matteosistisette@gmail.com To: pd-list@iem.at Subject: [PD] shouldn't message boxes work as gui elements?
Hi,
I don't know if this is already being addressed in the rewrite-gui version...
I've always wondered why message boxes are not treated as gui elements, like number and symbol boxes, that is:
- they do not graph on parent
- they do not have a properties dialog with at least a send and receive
symbol
Is there some particular reason why it has been decided not to treat (or allow treating) message boxes as gui elements, or is it simply that it has never been felt as a priority to implement this feature? I mean, would it imply any drawback?
-- Matteo Sisti Sette matteosistisette@gmail.com http://www.matteosistisette.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Do you have a story that started on Hotmail? Tell us now http://clk.atdmt.com/UKM/go/195013117/direct/01/
Hi all,
Message boxes were written to share code with object boxes and comments, but hacked a bit to respond to mouse clicks.
Making them graph on parent would make sense (the only reason they weren't before is that in the very first graph-on-parent implementation one couldn't hide things by moving them out of the little red rectangle>)
cheers Miller
On Mon, Feb 08, 2010 at 05:33:35PM +0000, Andrew Faraday wrote:
I've often wondered of message boxes, why they don't have some form of GUI to indicate when they're triggered (like the bang object). Sorry, this is an asside but I would like to know why.
Date: Mon, 8 Feb 2010 18:25:18 +0100 From: matteosistisette@gmail.com To: pd-list@iem.at Subject: [PD] shouldn't message boxes work as gui elements?
Hi,
I don't know if this is already being addressed in the rewrite-gui version...
I've always wondered why message boxes are not treated as gui elements, like number and symbol boxes, that is:
- they do not graph on parent
- they do not have a properties dialog with at least a send and receive
symbol
Is there some particular reason why it has been decided not to treat (or allow treating) message boxes as gui elements, or is it simply that it has never been felt as a priority to implement this feature? I mean, would it imply any drawback?
-- Matteo Sisti Sette matteosistisette@gmail.com http://www.matteosistisette.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Do you have a story that started on Hotmail? Tell us now http://clk.atdmt.com/UKM/go/195013117/direct/01/ _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--- On Mon, 2/8/10, Matteo Sisti Sette matteosistisette@gmail.com wrote:
From: Matteo Sisti Sette matteosistisette@gmail.com Subject: [PD] shouldn't message boxes work as gui elements? To: "PD list" pd-list@iem.at Date: Monday, February 8, 2010, 6:25 PM Hi,
I don't know if this is already being addressed in the rewrite-gui version...
I've always wondered why message boxes are not treated as gui elements, like number and symbol boxes, that is:
- they do not graph on parent
- they do not have a properties dialog with at least a send
and receive symbol
Is there some particular reason why it has been decided not to treat (or allow treating) message boxes as gui elements, or is it simply that it has never been felt as a priority to implement this feature? I mean, would it imply any drawback?
I've thought about that, too. I made a feature request for an object (ID: 2799270) that would combine my_canvas with the message box's features. (Although now that I think about it, it should probably only have one inlet that handles all the GUI-specific messages, like [bng] does, and be visually different than a message box by default.)
As for nonlocal send and receive on the current msg box: you've already got a nonlocal send by starting the message box with a semicolon. I like that a lot more than nonlocal send/receive names that are hidden away in a properties dialog. (But unfortunately, there's no nonlocal receive for msg boxes.)
-Jonathan
-- Matteo Sisti Sette matteosistisette@gmail.com http://www.matteosistisette.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Jonathan Wilkes escribió:
As for nonlocal send and receive on the current msg box: you've already got a nonlocal send by starting the message box with a semicolon.
That's a different thing. It's not just a matter of being able or not being able to send a message to wherever, it is a matter of how the box behaves. As a user, would you be happy if you were filling a form and there was an input field with a label that says: "Please enter your name and surname, preceded by a semicolon, a newline, the word 'name' in all lower case without quotes, and a white space"?
:)
However, I think you are right in that the "gui-element message box" (like a numberbox for messages) should probably be a different object than the "traditional" message box, and (I add) it should probably not allow semicolon and embedded-target-syntax (i.e. sending messages to arbitrary targets included in the message itself) because you couldn't in any possible way preventing the user to use it (involuntarily) to send messages to the wrong target.
Hi
As for nonlocal send and receive on the current msg box: you've already got a nonlocal send by starting the message box with a semicolon.
That's a different thing. It's not just a matter of being able or not being able to send a message to wherever, it is a matter of how the box behaves. As a user, would you be happy if you were filling a form and there was an input field with a label that says: "Please enter your name and surname, preceded by a semicolon, a newline, the word 'name' in all lower case without quotes, and a white space"?
:)
However, I think you are right in that the "gui-element message box" (like a numberbox for messages) should probably be a different object than the "traditional" message box, and (I add) it should probably not allow semicolon and embedded-target-syntax (i.e. sending messages to arbitrary targets included in the message itself) because you couldn't in any possible way preventing the user to use it (involuntarily) to send messages to the wrong target.
I think for some situations the ; method is handy at although it may look weird at first it's just another convention.
I do agree that the GUI-visible object should be something slightly different without the send and possibly with gui-customization options like other guis (colour, font etc).. In the end more like a button.
Bests, Lorenzo
Lorenzo escribió:
I think for some situations the ; method is handy at although it may look weird at first it's just another convention.
Of course, more than handy, in many situations it can't be replaced by anything else (already existing in pd).
I wasn't suggesting it could be removed, I just meant that probably a version of the message box meant for gui shouldn't have it (and therefore the message box meant for gui should be a new one - though the traditional message box may be also included among the graph-on-parent objects, why not)
--- On Mon, 2/8/10, Matteo Sisti Sette matteosistisette@gmail.com wrote:
From: Matteo Sisti Sette matteosistisette@gmail.com Subject: Re: [PD] shouldn't message boxes work as gui elements? To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "PD list" pd-list@iem.at Date: Monday, February 8, 2010, 8:53 PM Jonathan Wilkes escribió:
As for nonlocal send and receive on the current msg
box: you've already got a nonlocal send by starting the message box with a semicolon.
That's a different thing. It's not just a matter of being able or not being able to send a message to wherever, it is a matter of how the box behaves. As a user, would you be happy if you were filling a form and there was an input field with a label that says: "Please enter your name and surname, preceded by a semicolon, a newline, the word 'name' in all lower case without quotes, and a white space"?
The syntax you're talking about it extremely useful. Even though you can do the same thing with [send] by setting the send-name with the right inlet, that gets extremely cumbersome when, say, initializing a bunch of values and using dollar signs. The following is much easier: [; $1-pitch 60; $1-metro 96; $1-oscbank 32; $1-salad-bar optional (
I find the semicolon atom to be a real time (and space) saver here.
:)
Oops, I almost chopped off your smiley by accident. :)
-Jonathan
Jonathan Wilkes escribió:
The syntax you're talking about it extremely useful. Even though you can do the same thing with [send] by setting the send-name with the right inlet, that gets extremely cumbersome when, say, initializing a bunch of values and using dollar signs. The following is much easier: [; $1-pitch 60; $1-metro 96; $1-oscbank 32; $1-salad-bar optional (
I wasn't questioning its usefulness. I use that syntax daily and would feel lost without it (btw in my previous post I erroneously said it can't be replaced by anything, while as you say, it can but it is extremely cumbersome)
I just meant that its existence doesn't in any way answer to the need of a "send symbol". My ironic example was meant to demonstrate that asking for "a box that automatically sends what you type into it to a given target" is not the same as asking for "a box capable of sending messages to any given target".
Thanks for this. I've been reading this discussion and tried multiple sends earlier with commas, which didn't work. It's multiple semicolons, so now I know
Date: Mon, 8 Feb 2010 14:56:38 -0800 From: jancsika@yahoo.com To: matteosistisette@gmail.com CC: pd-list@iem.at Subject: Re: [PD] shouldn't message boxes work as gui elements?
--- On Mon, 2/8/10, Matteo Sisti Sette matteosistisette@gmail.com wrote:
From: Matteo Sisti Sette matteosistisette@gmail.com Subject: Re: [PD] shouldn't message boxes work as gui elements? To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "PD list" pd-list@iem.at Date: Monday, February 8, 2010, 8:53 PM Jonathan Wilkes escribió:
As for nonlocal send and receive on the current msg
box: you've already got a nonlocal send by starting the message box with a semicolon.
That's a different thing. It's not just a matter of being able or not being able to send a message to wherever, it is a matter of how the box behaves. As a user, would you be happy if you were filling a form and there was an input field with a label that says: "Please enter your name and surname, preceded by a semicolon, a newline, the word 'name' in all lower case without quotes, and a white space"?
The syntax you're talking about it extremely useful. Even though you can do the same thing with [send] by setting the send-name with the right inlet, that gets extremely cumbersome when, say, initializing a bunch of values and using dollar signs. The following is much easier: [; $1-pitch 60; $1-metro 96; $1-oscbank 32; $1-salad-bar optional (
I find the semicolon atom to be a real time (and space) saver here.
:)
Oops, I almost chopped off your smiley by accident. :)
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now http://clk.atdmt.com/UKM/go/195013117/direct/01/
-
Andrew Faraday -
Jonathan Wilkes -
Lorenzo -
Matteo Sisti Sette -
Miller Puckette