I noticed PD uses Tk and it's a bit clunky in that respect.. Have the devs considered Wx instead?
Yep, but there are some more pressing issues... including finalizing part of the GUI which is more easily prototyped in TK. So don't hold your breath or anything.
cheers Miller
On Tue, Sep 09, 2003 at 10:48:03AM +0200, Frank Barknecht wrote:
Hallo, Greg Hazel hat gesagt: // Greg Hazel wrote:
I noticed PD uses Tk and it's a bit clunky in that respect.. Have the devs considered Wx instead?
Yes. Something like that is on Miller's TODO list.
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Seems like in 0.37 the X cursor does not delete cables - I'm forced to click on them, then select 'Cut' from the Edit menu. Is this by design?
In general should I give feedback on the current release version, or the current test version?
Yep, this is not a bug, it's a feature (man, if I had a dollar for each time I have said that ;-). This is also the case in 0.36 (it is more Max style, I think). Using the delete key should do the same so you don't have to use the menu. Oh, and you can bring it back with ctrl+z now :-)
Cheers Soeren
Greg Hazel wrote:
Seems like in 0.37 the X cursor does not delete cables - I'm forced to click on them, then select 'Cut' from the Edit menu. Is this by design?
Hm, that was my first guess, but delete didn't seem to do anything. I just figured out that "Backspace" works, but "Delete" does not. Maybe that's the bug?
-----Original Message----- From: Søren Bovbjerg [mailto:bovbjerg@musik.auc.dk] Sent: Tuesday, September 09, 2003 12:48 PM To: Greg Hazel Cc: pd-list@iem.at Subject: Re: [PD] 0.37 must 'Cut' cables?
Yep, this is not a bug, it's a feature (man, if I had a dollar for each time I have said that ;-). This is also the case in 0.36 (it is more Max style, I think). Using the delete key should do the same so you don't have to use the menu. Oh, and you can bring it back with ctrl+z now :-)
Cheers Soeren
Greg Hazel wrote:
Seems like in 0.37 the X cursor does not delete cables - I'm
forced to
click on them, then select 'Cut' from the Edit menu. Is this
by design?
On Tue, 9 Sep 2003, Greg Hazel wrote:
Hm, that was my first guess, but delete didn't seem to do anything. I just figured out that "Backspace" works, but "Delete" does not. Maybe that's the bug?
On my machine, one "Delete" key works, but not the one on the keypad.
In addition, neither "Delete" key works for deleting characters inside an object box.
Apparently I am using version 0.36, but I think it's something fairly recent from the CVS. Has anything about that been fixed in the last month(s) ?
Mathieu Bouchard http://artengine.ca/matju
Wow, this is like deja vu, man. I swear everything was even worded the same way when 0.36 came out.
Pall Thayer artist/teacher Fjolbrautaskolinn vid Armula http://www.this.is/pallit http://www.this.is/pallit/isjs http://www.this.is/pallit/harmony http://130.208.220.190/panse
----- Original Message ----- From: "Søren Bovbjerg" bovbjerg@musik.auc.dk To: "Greg Hazel" gah@thalassocracy.org Cc: pd-list@iem.at Sent: Tuesday, September 09, 2003 7:47 PM Subject: Re: [PD] 0.37 must 'Cut' cables?
Yep, this is not a bug, it's a feature (man, if I had a dollar for each time I have said that ;-). This is also the case in 0.36 (it is more Max style, I think). Using the delete key should do the same so you don't have to use the menu. Oh, and you can bring it back with ctrl+z now :-)
Cheers Soeren
Greg Hazel wrote:
Seems like in 0.37 the X cursor does not delete cables - I'm forced to click on them, then select 'Cut' from the Edit menu. Is this by design?
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Actually, I just switched to Pd from Max, and the Pd manual still says that X cuts cables, so when it didn't work I got confused. Never got the chance to try 0.36 really, since after I installed it I noticed 0.37 On that note - who maintains the documentation? Does it get rewritten ever? Not to be condescending, just wondering how that's handled. While I'm being a pest, is there or is there talk of a vst~ object?
-----Original Message----- From: pd-list-admin@iem.at [mailto:pd-list-admin@iem.at] On Behalf Of Pall Thayer Sent: Tuesday, September 09, 2003 1:48 PM To: Søren Bovbjerg; Greg Hazel Cc: pd-list@iem.at Subject: Re: [PD] 0.37 must 'Cut' cables?
Wow, this is like deja vu, man. I swear everything was even worded the same way when 0.36 came out.
Pall Thayer artist/teacher Fjolbrautaskolinn vid Armula http://www.this.is/pallit http://www.this.is/pallit/isjs http://www.this.is/pallit/harmony
----- Original Message ----- From: "Søren Bovbjerg" bovbjerg@musik.auc.dk To: "Greg Hazel" gah@thalassocracy.org Cc: pd-list@iem.at Sent: Tuesday, September 09, 2003 7:47 PM Subject: Re: [PD] 0.37 must 'Cut' cables?
Yep, this is not a bug, it's a feature (man, if I had a dollar for each time I have said that ;-). This is also the case in 0.36 (it is more Max style, I think). Using the delete key should do the same so you don't have to use the menu. Oh, and you can bring it back with ctrl+z now :-)
Cheers Soeren
Greg Hazel wrote:
Seems like in 0.37 the X cursor does not delete cables - I'm forced to click on them, then select 'Cut' from the Edit menu. Is this by design?
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hallo, Greg Hazel hat gesagt: // Greg Hazel wrote:
Seems like in 0.37 the X cursor does not delete cables - I'm forced to click on them, then select 'Cut' from the Edit menu. Is this by design?
Yes, but you can also use the Backspace or Delete keys. It was introduced to make accidental disconnects harder. I think, you will get used to it...
Frank Barknecht _ ______footils.org__
This feature is helpful, but it also slows down patch editing a bit. I wonder if it would be better to disconnect on click, but turn the cable a bright color (like red) when the mouse is over it. Undo would still be there to fix accidents.
Ben
On Tuesday 09 September 2003 11:53 am, Frank Barknecht wrote:
Hallo,
Greg Hazel hat gesagt: // Greg Hazel wrote:
Seems like in 0.37 the X cursor does not delete cables - I'm forced to click on them, then select 'Cut' from the Edit menu. Is this by design?
Yes, but you can also use the Backspace or Delete keys. It was introduced to make accidental disconnects harder. I think, you will get used to it...
ciao
Hallo, Ben Saylor hat gesagt: // Ben Saylor wrote:
This feature is helpful, but it also slows down patch editing a bit. I wonder if it would be better to disconnect on click, but turn the cable a bright color (like red) when the mouse is over it. Undo would still be there to fix accidents.
I don't think so. I was quite critical on the change at first, but now I like it that way. It's much more consistent with other apps' behaviour, where clicking or marking with a mouse does not delete anything. It is also more consistent with mouse behaviour at other places in Pd, for example selecting text in object boxes.
Although having to press Delete or Backspace (this should be fixed on all platforms, of course) is an added move it does not really slow down editing (IMO), because it also means less mistakes, for example when patch cords run very close next to each other.
I'm quite sure that new users who are not used to the old behaviour will feel more at home with the selection-cut cycle. I would rather propose the possibility to select more than one patch cord at once with a mouse move, like selecting multiple objects which is already possible.
Frank Barknecht _ ______footils.org__
i agree, when trying to cut two chords the almost totally overlap each other their whole length, it was near impossible to cut the right chord the old way, the way it works now it show you which one you are about to cut by highlighting it blue. much better usability, IMHO.
-josh
Frank Barknecht wrote:
Hallo, Ben Saylor hat gesagt: // Ben Saylor wrote:
This feature is helpful, but it also slows down patch editing a bit. I wonder if it would be better to disconnect on click, but turn the cable a bright color (like red) when the mouse is over it. Undo would still be there to fix accidents.
I don't think so. I was quite critical on the change at first, but now I like it that way. It's much more consistent with other apps' behaviour, where clicking or marking with a mouse does not delete anything. It is also more consistent with mouse behaviour at other places in Pd, for example selecting text in object boxes.
Although having to press Delete or Backspace (this should be fixed on all platforms, of course) is an added move it does not really slow down editing (IMO), because it also means less mistakes, for example when patch cords run very close next to each other.
I'm quite sure that new users who are not used to the old behaviour will feel more at home with the selection-cut cycle. I would rather propose the possibility to select more than one patch cord at once with a mouse move, like selecting multiple objects which is already possible.
ciao
[My thoughts, possibly a little late now, on the issue:]
I find it annoying that the icon is still an X. Typically this suggests that this is a cut function and not at all a select function.
Also, the act of selection when the only action possibly is 'delete' does seem redundant_ obviously accidental deletion is undesirable too, but the semantics of the current UI situation seem slightly off!
However, I don't have any alternatives to offer other than maybe wires not being selectable at all unless you hold down a modifier key which then allows you to delete wires with a single click.?!!!
Ed.
-----Original Message----- From: pd-list-admin@iem.at [mailto:pd-list-admin@iem.at] On Behalf Of Ben Saylor Sent: 10 September 2003 22:29 To: pd-list@iem.at Subject: Re: [PD] 0.37 must 'Cut' cables?
This feature is helpful, but it also slows down patch editing a bit. I wonder if it would be better to disconnect on click, but turn the cable a bright color (like red) when the mouse is over it. Undo would still be there to fix accidents.
Ben
On Tuesday 09 September 2003 11:53 am, Frank Barknecht wrote:
Hallo,
Greg Hazel hat gesagt: // Greg Hazel wrote:
Seems like in 0.37 the X cursor does not delete cables - I'm forced to click on them, then select 'Cut' from the Edit menu. Is this by design?
Yes, but you can also use the Backspace or Delete keys. It was introduced to make accidental disconnects harder. I think, you will get used to it...
ciao
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Edward George schrieb:
However, I don't have any alternatives to offer other than maybe wires not being selectable at all unless you hold down a modifier key which then allows you to delete wires with a single click.?!!!
...but then you run the risk to delete the wrong patch cord in overcrowded patches. I like it as it is now because I can see whether I selected the right one before actually deleting it. So, please keep it like this!
Olaf
..but the original suggestion of masking this extra functionality with a modifier key would be acceptable i think. although i've never felt the need to select an area of cables myself. maybe that's because my patches are always connection-spaghetti.
pix.
On Thu, 11 Sep 2003 23:15:37 +0200 Olaf Matthes olaf.matthes@gmx.de wrote:
Edward George schrieb:
However, I don't have any alternatives to offer other than maybe wires not being selectable at all unless you hold down a modifier key which then allows you to delete wires with a single click.?!!!
...but then you run the risk to delete the wrong patch cord in overcrowded patches. I like it as it is now because I can see whether I selected the right one before actually deleting it. So, please keep it like this!
Olaf
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
i agree, the X cursor is a confusing hold over from before. but i have thought of another use for selecting patch cables, i really wish i could grab an exiting cable and drag it to a new in/outlet. this would cut down the number actions needed when rewiring objects, which i do a lot.
I've picked up a couple of tcl/tk books to strengthen my knowledge of it so that i can look into doing this kind of stuff... but with the vaguae up-in-the-airness of the future gui toolkit for pd i'm a little hessitant to invest my time. i'll probably go ahead since from everything miller has said it sounds like any changes wouldnt happen for a while.
-josh
Edward George wrote:
[My thoughts, possibly a little late now, on the issue:]
I find it annoying that the icon is still an X. Typically this suggests that this is a cut function and not at all a select function.
Also, the act of selection when the only action possibly is 'delete' does seem redundant_ obviously accidental deletion is undesirable too, but the semantics of the current UI situation seem slightly off!
However, I don't have any alternatives to offer other than maybe wires not being selectable at all unless you hold down a modifier key which then allows you to delete wires with a single click.?!!!
Ed.
-----Original Message----- From: pd-list-admin@iem.at [mailto:pd-list-admin@iem.at] On Behalf Of Ben Saylor Sent: 10 September 2003 22:29 To: pd-list@iem.at Subject: Re: [PD] 0.37 must 'Cut' cables?
This feature is helpful, but it also slows down patch editing a bit. I wonder if it would be better to disconnect on click, but turn the cable a bright color (like red) when the mouse is over it. Undo would still be there to fix accidents.
Ben
On Tuesday 09 September 2003 11:53 am, Frank Barknecht wrote:
Hallo,
Greg Hazel hat gesagt: // Greg Hazel wrote:
Seems like in 0.37 the X cursor does not delete cables - I'm forced to click on them, then select 'Cut' from the Edit menu. Is this by design?
Yes, but you can also use the Backspace or Delete keys. It was introduced to make accidental disconnects harder. I think, you will get used to it...
ciao
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Thursday, Sep 11, 2003, at 23:46 Europe/Lisbon, Josh Steiner wrote:
i really wish i could grab an exiting cable and drag it to a new in/outlet. this would cut down the number actions needed when rewiring objects, which i do a lot.
That would be nice! What about segmented patch cords? I really miss those...
I.
Personally I find it very difficult to interpret segmented patch cords, they are just a lot harder to follow. But I suppose the lesson is patches will never be hard to follow (either way) if they are well constructed! PD patches that are well constructed look good, segmented patch cords make bad patches look good...
Ben
On Thursday, Sep 11, 2003, at 23:46 Europe/Lisbon, Josh Steiner wrote:
i really wish i could grab an exiting cable and drag it to a new in/outlet. this would cut down the number actions needed when rewiring objects, which i do a lot.
That would be nice! What about segmented patch cords? I really miss those...
I.
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Fri, 12 Sep 2003 ben@ekran.org wrote:
But I suppose the lesson is patches will never be hard to follow (either way) if they are well constructed! PD patches that are well constructed look good, segmented patch cords make bad patches look good...
You'd have a problem with my patches maybe? My work is essentially based on recursion, so in almost every patch I have a wire that goes on top on an object box, and doesn't have the possibility not to. That's not beautiful. (Oh yeah, I could use "send" and "receive", but it makes the diagram heavier.)
If you agree that having cords run over objects is ugly, could you tell me what I'm supposed to do to beautify patches that use recursion?
Also, I don't recall any other arguments against segmented patch cords than things along the lines of "if your patches didn't suck you wouldn't care for that feature". So I'm not sure what I am supposed to tell beginners about it without sounding bad. Are there any other arguments against?
Mathieu Bouchard http://artengine.ca/matju
if segmented patchcords are such a sin, why hasn't told the integrated circuit industry?
i'd agree ben's comment is a little off-the-cuff. the real answer is most certainly that it's simply more effort to impliment.
and i would suggest, to make your patches look nicer in the meantime, that you could try using send/receives if your patches look ugly with the present system. and i'd stress that this is more of a workaround than a design prescription.
pix.
On Fri, 12 Sep 2003 19:30:18 -0400 (EDT) Mathieu Bouchard matju@sympatico.ca wrote:
On Fri, 12 Sep 2003 ben@ekran.org wrote:
But I suppose the lesson is patches will never be hard to follow (either way) if they are well constructed! PD patches that are well constructed look good, segmented patch cords make bad patches look good...
You'd have a problem with my patches maybe? My work is essentially based on recursion, so in almost every patch I have a wire that goes on top on an object box, and doesn't have the possibility not to. That's not beautiful. (Oh yeah, I could use "send" and "receive", but it makes the diagram heavier.)
If you agree that having cords run over objects is ugly, could you tell me what I'm supposed to do to beautify patches that use recursion?
Also, I don't recall any other arguments against segmented patch cords than things along the lines of "if your patches didn't suck you wouldn't care for that feature". So I'm not sure what I am supposed to tell beginners about it without sounding bad. Are there any other arguments against?
Mathieu Bouchard http://artengine.ca/matju
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Saturday 13 September 2003 03:13, pix wrote:
if segmented patchcords are such a sin, why hasn't told the integrated circuit industry?
i'd agree ben's comment is a little off-the-cuff. the real answer is most certainly that it's simply more effort to impliment.
FWIW I'm of the same opinion - I've yet to see an electronic circuit schematic that doesn't segment all the nodes into horizontal and vertical segments.
Ok, maybe the analogy is poor, because in a circuit schematic, a line represents a single node, and not data flow, so a better example would be block diagrams or flow charts.
I think history has proved that clearly, most types of charts that connect boxes together are read more comfortably if the connections are composed of vertically and horizontally alligned segments.
I think this is obviously a wouldbenicetohavebutwhohasthetimetoimplementit issue.
Larry
On Sat, 13 Sep 2003, Larry Troxler wrote:
On Saturday 13 September 2003 03:13, pix wrote:
if segmented patchcords are such a sin, why hasn't told the integrated circuit industry?
I was about to say that, but I wanted my answer to remain short. Actually I've had call me because he would have liked to reuse jMax's patcher system for some kind of peculiar automated circuit design system he's working on. I don't recall exactly what I did say, but I recommended against jMax and against PureData.
Ok, maybe the analogy is poor, because in a circuit schematic, a line represents a single node, and not data flow, so a better example would be block diagrams or flow charts.
I don't understand what you say. By node I would understand inlet or outlet, using the meaning from Graph Theory. Of course what goes along the lines is not quite like in PureData, and rather is the propagation of voltage difference and current, without differentiation between inlets and outlets... but none of those differences seem to affect layout so much that segmented patchcords go from relevant to irrelevant...
Mathieu Bouchard http://artengine.ca/matju
On Sunday 14 September 2003 18:38, Mathieu Bouchard wrote:
On Sat, 13 Sep 2003, Larry Troxler wrote:
Ok, maybe the analogy is poor, because in a circuit schematic, a line represents a single node, and not data flow, so a better example would be block diagrams or flow charts.
I don't understand what you say. By node I would understand inlet or outlet, using the meaning from Graph Theory. Of course what goes along the lines is not quite like in PureData, and rather is the propagation of voltage difference and current, without differentiation between inlets and outlets... but none of those differences seem to affect layout so much that segmented patchcords go from relevant to irrelevant...
Mathieu Bouchard http://artengine.ca/matju
Well, I think this is venturing on OT now, because I don't think it matters very much. but in circuit theory, a node is a an idealization of a physical single point - all points in a circuit diagram of a node are really the same point in the sense that the node is idealized as a piece of infinitessimally low resistance conductor. Different branches of the circuit may attach to the node, and the total current flowing into to the node from all of the branches equals zero.
Maybe in graph theory a node is an inlet or outlet - if that is the case I think that the notion of a "node" in pure graph theory must be different then that of a "node" in circuit theory. In circuit diagrams, nothing propogates along the lines, because any connected group of lines is electrically a single point.
And I agree that this diversion is exactly just that, for that I am sorry :-)
Larry
hi,
I would rather have splines...
graphviz uses splines, splines are nice, and segments are ugly
K-wants-splines
Larry Troxler wrote: ...
I think history has proved that clearly, most types of charts that connect boxes together are read more comfortably if the connections are composed of vertically and horizontally alligned segments.
hi,
lately i find myself compulsively pressing ctrl + m all the time while testing patches.. anyone else would like to see the sendpanel stay open after sending a message?
cheers
xof
kristof.lauwers@logosfoundation.org
http://kristoflauwers.de.vu ____________________________________
Good idea... 0.38
thanks Miller
On Tue, Sep 16, 2003 at 12:38:58PM +0200, kristof lauwers wrote:
hi,
lately i find myself compulsively pressing ctrl + m all the time while testing patches.. anyone else would like to see the sendpanel stay open after sending a message?
cheers
xof
kristof.lauwers@logosfoundation.org
http://kristoflauwers.de.vu ____________________________________
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hmm, looks like Graphviz uses Tcl/Tk, and its open source so you can at least read the code, but the AT&T license seems to be GPLish in that the derived works have to be covered under the same license.
http://www.research.att.com/sw/tools/graphviz/
.hc
On Tuesday, Sep 16, 2003, at 06:12 America/New_York, Krzysztof Czaja wrote:
hi,
I would rather have splines...
graphviz uses splines, splines are nice, and segments are ugly
K-wants-splines
Larry Troxler wrote: ...
I think history has proved that clearly, most types of charts that connect boxes together are read more comfortably if the connections are composed of vertically and horizontally alligned segments.
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Fellows, If it's decided to start making the patch cables behave as splines, it would be best to make them slightly thicker, yellower, and make the externals look like meatballs.
Chris.
On Tue, Sep 16, 2003 at 09:03:26AM -0400, Hans-Christoph Steiner wrote:
Hmm, looks like Graphviz uses Tcl/Tk, and its open source so you can at least read the code, but the AT&T license seems to be GPLish in that the derived works have to be covered under the same license.
http://www.research.att.com/sw/tools/graphviz/
.hc
On Tuesday, Sep 16, 2003, at 06:12 America/New_York, Krzysztof Czaja wrote:
hi,
I would rather have splines...
graphviz uses splines, splines are nice, and segments are ugly
K-wants-splines
Larry Troxler wrote: ...
I think history has proved that clearly, most types of charts that connect boxes together are read more comfortably if the connections are composed of vertically and horizontally alligned segments.
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Well, there are just so many more urgent things I'm struggling with, and the more graphics bells and whistles there are lying around the more of my time goes into trying to maintain them. Otherwise I have nothing against the idea (except aesthetically, and it's not my intention to impose my aesthetics on others!)
On the original subject, I've dropped the "X" cursor (no longer meaningful) and tried to make "delete" and "backspace" work more rationally... thanks to all for the suggestions.
cheers Miller
On Sat, Sep 13, 2003 at 09:13:13AM +0200, pix wrote:
if segmented patchcords are such a sin, why hasn't told the integrated circuit industry?
i'd agree ben's comment is a little off-the-cuff. the real answer is most certainly that it's simply more effort to impliment.
and i would suggest, to make your patches look nicer in the meantime, that you could try using send/receives if your patches look ugly with the present system. and i'd stress that this is more of a workaround than a design prescription.
pix.
On Fri, 12 Sep 2003 19:30:18 -0400 (EDT) Mathieu Bouchard matju@sympatico.ca wrote:
On Fri, 12 Sep 2003 ben@ekran.org wrote:
But I suppose the lesson is patches will never be hard to follow (either way) if they are well constructed! PD patches that are well constructed look good, segmented patch cords make bad patches look good...
You'd have a problem with my patches maybe? My work is essentially based on recursion, so in almost every patch I have a wire that goes on top on an object box, and doesn't have the possibility not to. That's not beautiful. (Oh yeah, I could use "send" and "receive", but it makes the diagram heavier.)
If you agree that having cords run over objects is ugly, could you tell me what I'm supposed to do to beautify patches that use recursion?
Also, I don't recall any other arguments against segmented patch cords than things along the lines of "if your patches didn't suck you wouldn't care for that feature". So I'm not sure what I am supposed to tell beginners about it without sounding bad. Are there any other arguments against?
Mathieu Bouchard http://artengine.ca/matju
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
yes, this is by design
Greg Hazel wrote:
Seems like in 0.37 the X cursor does not delete cables - I'm forced to click on them, then select 'Cut' from the Edit menu. Is this by design?
In general should I give feedback on the current release version, or the current test version?
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
hi greg,
that's a feature. this way you cannot unintentionally cut a connection. use backspace (or ctrl-x) as a shortcut.
marius.
----- Original Message ----- From: "Greg Hazel" gah@thalassocracy.org To: pd-list@iem.at Sent: Tuesday, September 09, 2003 9:08 PM Subject: [PD] 0.37 must 'Cut' cables?
Seems like in 0.37 the X cursor does not delete cables - I'm forced to click on them, then select 'Cut' from the Edit menu. Is this by design?
In general should I give feedback on the current release version, or the current test version?
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
I don't know much about wxWindows, but Krzysztof's tot/widget/etc are demonstrating the benefits of having a Tcl GUI: a Pd patch could completely control the Pd GUI. It would be sad to lose this, but maybe wxWindows has a way to do this as well.
.hc
On Tuesday, Sep 9, 2003, at 12:00 America/New_York, Miller Puckette wrote:
Yep, but there are some more pressing issues... including finalizing part of the GUI which is more easily prototyped in TK. So don't hold your breath or anything.
cheers Miller
On Tue, Sep 09, 2003 at 10:48:03AM +0200, Frank Barknecht wrote:
Hallo, Greg Hazel hat gesagt: // Greg Hazel wrote:
I noticed PD uses Tk and it's a bit clunky in that respect.. Have the devs considered Wx instead?
Yes. Something like that is on Miller's TODO list.
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list