On Jul 10, 2011, at 11:28 PM, Jonathan Wilkes wrote:
--- On Mon, 7/11/11, Ivica Ico Bukvic ico@vt.edu wrote:
From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] Pd-extended 0.43 updates: lots of new editing
features To: "Jonathan Wilkes" jancsika@yahoo.com, "Hans-Christoph
Steiner" hans@at.or.at Cc: pd-list@iem.at Date: Monday, July 11, 2011, 2:56 AMJonathan Wilkes jancsika@yahoo.com wrote:
--- On Sun, 7/10/11, Hans-Christoph Steiner hans@at.or.at
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43 updates: lots
of new editing
features
To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Ivica Ico Bukvic" ico@vt.edu, pd-list@iem.at Date: Sunday, July 10, 2011, 7:25 PM
On Jul 9, 2011, at 8:07 PM, Jonathan Wilkes
wrote:
--- On Sat, 7/9/11, Hans-Christoph Steiner
wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD] Pd-extended 0.43
updates: lots
of new editing
features To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Ivica Ico Bukvic" ico@vt.edu, pd-list@iem.at Date: Saturday, July 9, 2011, 10:38 PM
On Jul 9, 2011, at 1:48 AM, Jonathan
Wilkes
wrote:
> > > --- On Sat, 7/9/11, Hans-Christoph
Steiner
wrote: > > [...] > >> The problem with forks is if
improvements
don't
migrate >> upstream. > > I think it's both a problem-with and
a
cause-of.
Yup, that makes sense.
>> Then we don't benefit from
sharing the
>> fixes. Making things migrate
upstream takes
time in >> itself. > > How does one figure out who has the
responsibility to
make sure > things migrate upstream (for
example:
[initbang] and
[closebang])?
Mostly by someone deciding its important
enough
that they
want to work on it themself, and then lots of testing
and
communication.
Ok. So in patch id#2838176, what is
Guenter's
idea for a clean
implementation of tooltips that you were
referring
to? I didn't
find anything on the user or dev list.
Hmm, I can't remember what Günter's proposal was,
but I do
have a vague idea of how to do it cleanly. I think it
should
be similar to the way its done in Max/MSP. Basically there is
a
standard function, something like nlet_info(), which returns the
tooltip
info.
Where would one define the standard function?
Pd would then check whether an object had that function
when it
loaded the binary, and if so register it in the tooltips.
This brings up an issue I've been wondering about since
learning a
little more about the canvas editor: why does the pd
gui send 'motion'
messages to pd? Why not, for example, just have a
tag for an inlet
rectangle and bind <Enter> and <Leave> to
it? Then you'd only be
sending messages from the gui for the events you care
about, instead of
tons of "motion" messages that don't trigger anything.
I may be way off the mark here, if I recall correctly I think that info is used for dragging stuff and similar actions.
Yes, it is, but I was just thinking that extending a wire from an
outlet, which sends a message to pd every mouse motion and walks
through the objects in the glist to see if it hit a box, could be
simplified if you just handled it on the gui end. Then only send a
message if the wire connection is successful, or if there is a
disconnection.But I guess you'd still have to send a message every pixel you drag
an object in editmode anyway.
For connections/cords, you've illustrated it well. Pd only tracks
whether they are connected or not, so it doesn't need to know the
position, especially during creation. For moving boxes, Pd would
mostly not need to know about the location, GUI objects would, but
that would be within the GUI object. The one thing I can think of
where Pd needs to know the location is with inlets and outlets, since
the position could change the program.
Changing the connection logic to be entirely in the GUI would be a
good place to start on this. I think pd-gui would just need to
communicate using the 'connect' message, then the disconnect, and
which cord is under the magic glass.
.hc
-Jonathan
.hc
>> Try getting a patch into the
Linux
kernel,
>> that'll make Pd seem like cake
;-)
> > Yes, I would hope that making changes
to the
core of
the largest > free software project in the history
of
computing is a
wee bit more > difficult than making changes to Pd.
Actually, there are much bigger projects
than
Linux, things
like Debian are quite a bit larger in scale.
I read a white paper on total development
cost of a
linux distro and
just remembered "linux". I think the distro
in
the paper was Fedora
9, which was estimated to be almost an order
of
magnitude more
expensive than the Linux kernel.
-Jonathan
.hc
> > -Jonathan > >> >> .hc >> >> >>> >>> -Jonathan >>> >>>> And >>>> anything assigned to
Miller and
reviewed
>> positively by >>>> IOhannes I'm >>>> going to defer any action
on until
Miller
>> responds. >>>> >>>> .hc >>>> >>>>> >>>>> -Jonathan >>>>> >>>>>> >>>>>> >>
>>>>>> Pd-list@iem.at >>>>>> mailing list >>>>>> UNSUBSCRIBE and
account-management
-> >> http://lists.puredata.info/listinfo/pd-list >>>>>> >>>>> >>>> >>>> >> >> >> >> >> >>
>> >> "[T]he greatest purveyor of
violence in
the world
today >> [is] my own government." - Martin
Luther
King,
Jr. >> >> >> >>
http://at.or.at/hans/
The arc of history bends towards justice.
- Dr. Martin Luther
King, Jr.
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork LinuxLaptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
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