2010/4/17 Mathieu Bouchard matju@artengine.ca
On Fri, 16 Apr 2010, András Murányi wrote:
One (hard) aspect of GUI design in case of Pd is that the GUI widgets are
provided by Tcl/Tk at the moment, which does not allow for such kind of skinning, afaik.
Tcl/Tk up to 8.4 allow some amount of configuration... at least much more than has ever been used by anyone in pd.tk.
Tcl/Tk introduced the TkTile toolkit, for which I've heard that the big new feature is that you can skin it. I haven't tried it myself. Meanwhile, I'm using Pd-Extended with Tcl/Tk 8.5 while, officially, this very same version of Pd-Extended is said to "not support" Tcl/Tk 8.5. On top of that, Miller still wants to support Tcl/Tk 8.3 for some upcoming releases, and such things that were already becoming obsolete in 2003.
There has been talk, however, about migrating to another GUI toolkit.
Talk, talk, talk, it's only talk. Arguments, babble, bicker bicker bicker, brouhaha, it's only talk.
Well, lets be happy we have this wonderful ability to articulate words... ;o) As it has been mentioned, "anyone" can start porting Pd to another toolkit. The question for me here is, if Miller, Hans, and other core people are interested in leaving Tcl/Tk behind, and if yes, how soon?
Andras
On Sun, 2 May 2010, András Murányi wrote:
As it has been mentioned, "anyone" can start porting Pd to another toolkit.
Why would you care, that an unspecified person said "anyone" "can" do "whatever" on pd-list ? It isn't a sign of anything. Why don't you instead think about why the project really matters, and about what is needed to succeed at the task ?
The question for me here is, if Miller, Hans, and other core people are interested in leaving Tcl/Tk behind, and if yes, how soon?
If anyone cared, there would be a prototype already.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
2010/5/2 Mathieu Bouchard matju@artengine.ca
On Sun, 2 May 2010, András Murányi wrote:
As it has been mentioned, "anyone" can start porting Pd to another
toolkit.
Why would you care, that an unspecified person said "anyone" "can" do "whatever" on pd-list ? It isn't a sign of anything. Why don't you instead think about why the project really matters, and about what is needed to succeed at the task ?
I was implicitly ironic, based on our shared knowledge of more floating ideas than actual projects. I do think about why the project really matters. ;o) I think Pd shall get a proper language-independent API.
If you want to know why I don't start this project up myself, no it's not shyness or learned helplessness but the mere fact that i'm doing two jobs to survive and have no joules left for this. My bad.
The question for me here is, if Miller, Hans, and other core people are
interested in leaving Tcl/Tk behind, and if yes, how soon?
If anyone cared, there would be a prototype already.
Well, i just imagine it is not easy to have one's 'child' undergo such a severe operation, so one might not make up a decision or even publicly address the question so easily.
Andras
On Sun, 2 May 2010, András Murányi wrote:
I was implicitly ironic, based on our shared knowledge of more floating ideas than actual projects.
Well, there's no obvious difference between saying it ironically and saying it non-ironically. The fact is, someone could be saying the same thing and mean it. So, thanks for explaining the joke.
I think Pd shall get a proper language-independent API.
What would it be like ? What do you mean by "language-independent" ?
If you want to know why I don't start this project up myself, no it's not shyness or learned helplessness but the mere fact that i'm doing two jobs to survive and have no joules left for this. My bad.
But do you have enough "joules" left to explain what you have in mind ?
Well, i just imagine it is not easy to have one's 'child' undergo such a severe operation, so one might not make up a decision or even publicly address the question so easily.
Why does that sound like it's about hiding a shameful disease ?
And then why does this imply, that a language-independent API would have to be replacing the current Tk support ?... Maybe it doesn't, and it could be a good idea to have a dual system, for the sake of not making "irreversible changes"... but branching off code, by itself, is already not nearly as irreversible as what you can do with a scalpel on body parts...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
2010/5/3 Mathieu Bouchard matju@artengine.ca
On Sun, 2 May 2010, András Murányi wrote:
I was implicitly ironic, based on our shared knowledge of more floating
ideas than actual projects.
Well, there's no obvious difference between saying it ironically and saying it non-ironically. The fact is, someone could be saying the same thing and mean it. So, thanks for explaining the joke.
What's more, i'm in a constant state of irony towards the world i'm living in. (Sorry about it.)
I think Pd shall get a proper language-independent API.
What would it be like ? What do you mean by "language-independent" ?
Well, an API is normally language independent so it would not be a thing to mention. The layer which plays the role of the API currently, however, uses Tcl strings often.
If you want to know why I don't start this project up myself, no it's not
shyness or learned helplessness but the mere fact that i'm doing two jobs to survive and have no joules left for this. My bad.
But do you have enough "joules" left to explain what you have in mind ?
Yes, i do. But be sure it's fuzzy enough there that i cannot state a model by myself.
Well, i just imagine it is not easy to have one's 'child' undergo such a
severe operation, so one might not make up a decision or even publicly address the question so easily.
Why does that sound like it's about hiding a shameful disease ?
And then why does this imply, that a language-independent API would have to be replacing the current Tk support ?... Maybe it doesn't, and it could be a good idea to have a dual system, for the sake of not making "irreversible changes"... but branching off code, by itself, is already not nearly as irreversible as what you can do with a scalpel on body parts...
Maybe, maybe not, and this is really beyond my current knowledge. Forking, i suppose, will need a significant amount of additional resources, as Tcl plays a great part in current Pd. So i'm still interested in debating over Tcl - whether we think it's fast enough, smart enough, and future-proof enough to stay with.
Andras
On Mon, 3 May 2010, András Murányi wrote:
What's more, i'm in a constant state of irony towards the world i'm living in. (Sorry about it.)
No need to be sorry about that.
Well, an API is normally language independent so it would not be a thing to mention. The layer which plays the role of the API currently, however, uses Tcl strings often.
You mean pieces of Tcl code ?... Now if it only looked like Tcl data, instead, would it be better ?... In the end, a text representation has to be chosen, and it better be similar to an existing programming language.
Maybe, maybe not, and this is really beyond my current knowledge. Forking, i suppose, will need a significant amount of additional resources, as Tcl plays a great part in current Pd. So i'm still interested in debating over Tcl - whether we think it's fast enough, smart enough, and future-proof enough to stay with.
Well, have you considered that Tcl supports more gui toolkits than just Tk, and that Tk can also run in many different programming languages ? And also, Tk is open-source (and could be hacked to become faster), and it's possible to make Tk widgets that emulate Tk Canvas.
Thus instead of a one-piece Tcl/Tk yes/no question, it's more like four different questions... plus any additional possibilities that I'm not stating here.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On May 2, 2010, at 11:55 AM, András Murányi wrote:
2010/4/17 Mathieu Bouchard matju@artengine.ca On Fri, 16 Apr 2010, András Murányi wrote:
One (hard) aspect of GUI design in case of Pd is that the GUI
widgets are provided by Tcl/Tk at the moment, which does not allow
for such kind of skinning, afaik.Tcl/Tk up to 8.4 allow some amount of configuration... at least much
more than has ever been used by anyone in pd.tk.Tcl/Tk introduced the TkTile toolkit, for which I've heard that the
big new feature is that you can skin it. I haven't tried it myself.
Meanwhile, I'm using Pd-Extended with Tcl/Tk 8.5 while, officially,
this very same version of Pd-Extended is said to "not support" Tcl/ Tk 8.5. On top of that, Miller still wants to support Tcl/Tk 8.3 for
some upcoming releases, and such things that were already becoming
obsolete in 2003.There has been talk, however, about migrating to another GUI toolkit.
Talk, talk, talk, it's only talk. Arguments, babble, bicker bicker bicker, brouhaha, it's only talk.
Well, lets be happy we have this wonderful ability to articulate
words... ;o) As it has been mentioned, "anyone" can start porting Pd to another
toolkit. The question for me here is, if Miller, Hans, and other
core people are interested in leaving Tcl/Tk behind, and if yes, how
soon?
Tcl/Tk happens to be a good GUI toolkit for making cross-platform apps
that appear native on each platform. From my point of view, we should
just implement things better, changing the GUI toolkit is not going to
make as big a difference.
.hc
I spent 33 years and four months in active military service and during
that period I spent most of my time as a high class muscle man for Big
Business, for Wall Street and the bankers. - General Smedley Butler
Tcl/Tk happens to be a good GUI toolkit for making cross-platform apps that appear native on each platform. From my point of view, we should just implement things better, changing the GUI toolkit is not going to make as big a difference.
.hc
Matju told basically the same so i'm convinced. No Alexandrian solution hhhh :) Actually, do you consider the GUI or the GUI-core communication "slow" (ie a large performace potential in optimizing), or is just that we overdrive it sometimes? (Or is it like "smooth or not smooth"? ;o)
Andras
On May 6, 2010, at 7:28 PM, András Murányi wrote:
Tcl/Tk happens to be a good GUI toolkit for making cross-platform
apps that appear native on each platform. From my point of view, we
should just implement things better, changing the GUI toolkit is not
going to make as big a difference..hc
Matju told basically the same so i'm convinced. No Alexandrian
solution hhhh :) Actually, do you consider the GUI or the GUI-core communication
"slow" (ie a large performace potential in optimizing), or is just
that we overdrive it sometimes? (Or is it like "smooth or not
smooth"? ;o)
Some parts are extremely slow, like array redrawing and moving of
items on the canvas. These particular things can sometimes generate 1
megabyte a second of Tcl code. The same could be achieved by sending
the right 1 kilobyte per second, or even less.
.hc
http://at.or.at/hans/
On Thu, 6 May 2010, Hans-Christoph Steiner wrote:
Some parts are extremely slow, like array redrawing and moving of items on the canvas. These particular things can sometimes generate 1 megabyte a second of Tcl code. The same could be achieved by sending the right 1 kilobyte per second, or even less.
if bunches of floats could be sent in binary, it would save a lot of "bandwidth", too, but not as much as if they were trimmed to the strict minimum... we don't need 32 bits of precision to display on screen : 12 is enough.
the actual problem is not so much the "bandwidth", but all the parsing and unparsing. the [binary] command of Tcl can make things faster.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Fri, 7 May 2010, András Murányi wrote:
Actually, do you consider the GUI or the GUI-core communication "slow" (ie a large performace potential in optimizing), or is just that we overdrive it sometimes? (Or is it like "smooth or not smooth"? ;o)
a [#see] object is sending video over the GUI connection and displaying it in the patch. It's awfully slow in a way, but at the same time, it's impressive to see that so much data _can_ go through that pipe.
(but with a second TCP pipe, it could be much more efficient.)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
András Murányi -
Hans-Christoph Steiner -
Mathieu Bouchard