Hey PD gurus,
I used to use PD a lot but haven't much for the last year or more. Now I'm getting back in to it and finding that the UI is just really clunky and awkward and makes the workflow really painful. I build website UIs professionally in JavaScript (see http://www.zillow.com/search/RealEstateSearch.htm for an example of a UI I built, everything except the Flash). I also have on-the-job experience in design and usability, as well as coding skills in Python and some exposure to C, C++ and Java. I'd like to start pitching in specifically on GUI and chrome improvements in the trunk for the core PD UI. How would I go about getting started? I noticed the page at http://puredata.info/dev/GuiIdeashas some outstanding requests from the community, it seems like the best thing is to start there. I'd also like to integrate with the developer community to ensure that UI improvements (specifically, better keyboard support and smoothing out some glaring dialog/chrome issues) don't have a negative impact on realtime audio performance.
Best,
David
Hey,
Glad to hear you are interested in working on the GUI, there is a lot
that needs to be done, and a lot that can be done without too much
difficulty. The GuiIdeas page is a good place to start, I'll happily
give you pointers where I can. For me, I think the most burning
issue is the Path and Startup preferences panes. They are really
broken and cause lots of confusion. So if you are interested, you
could start by sketching up the UI for those in straight Tcl/Tk, and
then we can get it integrated into Pd itself.
I am not sure what you mean by 'chrome' though. Also, have you tried
a recent nightly build of Pd-extended? I have smoothed out most of
the keyboard issues, I think.
.hc
On May 3, 2008, at 6:04 AM, David Golightly wrote:
Hey PD gurus,
I used to use PD a lot but haven't much for the last year or more.
Now I'm getting back in to it and finding that the UI is just
really clunky and awkward and makes the workflow really painful. I
build website UIs professionally in JavaScript (see http:// www.zillow.com/search/RealEstateSearch.htm for an example of a UI I
built, everything except the Flash). I also have on-the-job
experience in design and usability, as well as coding skills in
Python and some exposure to C, C++ and Java. I'd like to start
pitching in specifically on GUI and chrome improvements in the
trunk for the core PD UI. How would I go about getting started? I
noticed the page at http://puredata.info/dev/GuiIdeas has some
outstanding requests from the community, it seems like the best
thing is to start there. I'd also like to integrate with the
developer community to ensure that UI improvements (specifically,
better keyboard support and smoothing out some glaring dialog/ chrome issues) don't have a negative impact on realtime audio
performance.Best,
David
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
If you are not part of the solution, you are part of the problem.
I am not sure what you mean by 'chrome' though.
http://www.37signals.com/svn/archives2/lingo_chrome.php
to get OS chrome on Tk, it may be as simple as a 'require Tktile'
On Sat, 2008-05-03 at 05:16 -0400, cdr wrote:
I am not sure what you mean by 'chrome' though.
http://www.37signals.com/svn/archives2/lingo_chrome.php
to get OS chrome on Tk, it may be as simple as a 'require Tktile'
http://www.catb.org/~esr/jargon/html/C/chrome.html
On Sat, 2008-05-03 at 05:16 -0400, cdr wrote:
I am not sure what you mean by 'chrome' though.
http://www.37signals.com/svn/archives2/lingo_chrome.php
to get OS chrome on Tk, it may be as simple as a 'require Tktile'
and tile http://wiki.tcl.tk/13636 is now part of tk8.5 http://tcl.tk/software/tcltk/8.5.tml
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hey david!
if you want to collect some ideas how a real usable and pretty interface for a modular environment could look like, have a look at http://synthmaker.co.uk/about.html it's got bendable links... you never have to leave edit mode... and have a look at how ALL interface elements as bitmap & vector knobs, sliders or wavedraw display consist of modules themselve. the environment is off course not as powerful as pd, but the interface is just a joy to work with.
greetings, fabb
On Sat, May 3, 2008 at 6:04 AM, David Golightly davigoli@gmail.com wrote:
Hey PD gurus,
I used to use PD a lot but haven't much for the last year or more. Now I'm getting back in to it and finding that the UI is just really clunky and awkward and makes the workflow really painful. I build website UIs professionally in JavaScript (see http://www.zillow.com/search/RealEstateSearch.htm for an example of a UI I built, everything except the Flash). I also have on-the-job experience in design and usability, as well as coding skills in Python and some exposure to C, C++ and Java. I'd like to start pitching in specifically on GUI and chrome improvements in the trunk for the core PD UI. How would I go about getting started? I noticed the page at http://puredata.info/dev/GuiIdeas has some outstanding requests from the community, it seems like the best thing is to start there. I'd also like to integrate with the developer community to ensure that UI improvements (specifically, better keyboard support and smoothing out some glaring dialog/chrome issues) don't have a negative impact on realtime audio performance.
Best,
David
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Langsam Wieder hat gesagt: // Langsam Wieder wrote:
if you want to collect some ideas how a real usable and pretty interface for a modular environment could look like, have a look at http://synthmaker.co.uk/about.html it's got bendable links... you never have to leave edit mode... and have a look at how ALL interface elements as bitmap & vector knobs, sliders or wavedraw display consist of modules themselve. the environment is off course not as powerful as pd, but the interface is just a joy to work with.
I've never worked with that, however I'm always irritated, when patching environments have their cord connections flow left to right instead of top to bottom. IMO that's such a waste of space in languages, that are written horizontally. If you look at the "Midi to Poly" object here: http://synthmaker.co.uk/images/components%20L.png you'll see that most of it is just an empty grey rectangle, whose width is just there to make room for the object name. If the in/outlets were top and bottom as in Pd and Max, the box could be much smaller without losing any information.
Of course if objects are just icons instead of works, left-to-right can work, but as Matju once said: "a word says more than a thousand pictures" - icons are very limited. No wonder, SynthMaker also includes a (quite nice) text editor for dsp code.
Frank Barknecht _ ______footils.org__
I think it would be cool, if users had the possibility to decide themselves whether they want to use richer graphics display in their patches. to create an interface like in synthmaker, you need for example opengl features inside the patcher window. I know that people already do that and it seems to work well, but it is not supported by pure pd, one reason for which is that the tcl/tk patcher system is too much integrated in the pd core. what is so bad about, if you create [ADSR] that it comes as a nice little control gui with all the knobs already included? it is not true that words are "better" than images. and it is not true that more information in a patch means "better". I think you are right from the viewpoint of a programming user, but users that just want higher level usuability want better graphics at least the *possibility* to add graphical UI features. but this is quite a lot of work...
a good example for me are web-pages. you really don't want to read all the code behind. you want it to work and have a nice UI. with pd you also want a nice interface for the "performing" situation.
btw. we need to make pd run in a browser environment.
marius.
Frank Barknecht wrote:
Hallo, Langsam Wieder hat gesagt: // Langsam Wieder wrote:
if you want to collect some ideas how a real usable and pretty interface for a modular environment could look like, have a look at http://synthmaker.co.uk/about.html it's got bendable links... you never have to leave edit mode... and have a look at how ALL interface elements as bitmap & vector knobs, sliders or wavedraw display consist of modules themselve. the environment is off course not as powerful as pd, but the interface is just a joy to work with.
I've never worked with that, however I'm always irritated, when patching environments have their cord connections flow left to right instead of top to bottom. IMO that's such a waste of space in languages, that are written horizontally. If you look at the "Midi to Poly" object here: http://synthmaker.co.uk/images/components%20L.png you'll see that most of it is just an empty grey rectangle, whose width is just there to make room for the object name. If the in/outlets were top and bottom as in Pd and Max, the box could be much smaller without losing any information.
Of course if objects are just icons instead of works, left-to-right can work, but as Matju once said: "a word says more than a thousand pictures" - icons are very limited. No wonder, SynthMaker also includes a (quite nice) text editor for dsp code.
Ciao
Le 3 mai 08 à 15:41, marius schebella a écrit :
I think it would be cool, if users had the possibility to decide themselves whether they want to use richer graphics display in their patches. to create an interface like in synthmaker, you need for example opengl features inside the patcher window. I know that people already do that and it seems to work well, but it is not supported by pure pd, one reason for which is that the tcl/tk patcher system is too much integrated in the pd core. what is so bad about, if you create [ADSR] that it comes as a nice little control gui with all the knobs already included?
OK, here a small ADSL interface with knobs ;)
It works with Pd version 0.39.3-extended. I don't know why but
[image] doesn't work with pd-0.40.3-extended-20080315
Maybe some people would be interested to 'design' some abstractions.
Problem : the size. 9.9 Ko :)
++
Jack
it is not true that words are "better" than images. and it is not true that more information in a patch means "better". I think you are right from the viewpoint of a programming user, but users that just want higher level usuability want better graphics at least the *possibility* to add graphical UI features. but this is
quite a lot of work...a good example for me are web-pages. you really don't want to read all the code behind. you want it to work and have a nice UI. with pd you also want a nice interface for the "performing" situation.
btw. we need to make pd run in a browser environment.
marius.
Frank Barknecht wrote:
Hallo, Langsam Wieder hat gesagt: // Langsam Wieder wrote:
if you want to collect some ideas how a real usable and pretty interface for a modular environment could look like, have a look at http://synthmaker.co.uk/about.html it's got bendable links... you never have to leave edit mode... and have a look at how ALL interface elements as bitmap & vector knobs, sliders or wavedraw display consist of modules themselve. the environment is off course not as powerful as pd, but the
interface is just a joy to work with.I've never worked with that, however I'm always irritated, when patching environments have their cord connections flow left to right instead of top to bottom. IMO that's such a waste of space in languages, that are written horizontally. If you look at the "Midi to Poly" object here: http://synthmaker.co.uk/images/components%20L.png you'll see that most of it is just an empty grey rectangle, whose width is just there to make room for the object name. If the in/outlets were top and bottom as in Pd and Max, the box could be
much smaller without losing any information.Of course if objects are just icons instead of works, left-to-right can work, but as Matju once said: "a word says more than a thousand pictures" - icons are very limited. No wonder, SynthMaker also includes a (quite nice) text editor for dsp code.
Ciao
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Jack wrote:
Le 3 mai 08 à 15:41, marius schebella a écrit :
I think it would be cool, if users had the possibility to decide themselves whether they want to use richer graphics display in their patches. to create an interface like in synthmaker, you need for example opengl features inside the patcher window. I know that people already do that and it seems to work well, but it is not supported by pure pd, one reason for which is that the tcl/tk patcher system is too much integrated in the pd core. what is so bad about, if you create [ADSR] that it comes as a nice little control gui with all the knobs already included?
OK, here a small ADSL interface with knobs ;) It works with Pd version 0.39.3-extended. I don't know why but [image] doesn't work with pd-0.40.3-extended-20080315 Maybe some people would be interested to 'design' some abstractions. Problem : the size. 9.9 Ko :)
there is also [iem_image] in the iemgui library, which I think has slightly more features. from a graphical UI viewpoint the knobs do not really look good. nor does the bang. but in general I like the idea of more abstractions like this. btw, I was surprised to see that images work on GOPs!
marius.
On May 3, 2008, at 6:03 PM, Jack wrote:
Le 3 mai 08 à 15:41, marius schebella a écrit :
I think it would be cool, if users had the possibility to decide themselves whether they want to use richer graphics display in their patches. to create an interface like in synthmaker, you need for example
opengl features inside the patcher window. I know that people already do
that and it seems to work well, but it is not supported by pure pd, one reason for which is that the tcl/tk patcher system is too much integrated in the pd core. what is so bad about, if you create [ADSR] that it comes as a nice little control gui with all the knobs already included?OK, here a small ADSL interface with knobs ;) It works with Pd version 0.39.3-extended. I don't know why but
[image] doesn't work with pd-0.40.3-extended-20080315 Maybe some people would be interested to 'design' some abstractions. Problem : the size. 9.9 Ko :)
Nice GUI patch! The image is working for me on 0.40.3- extended-20080502 on mac os x/intel.
.hc
++
Jack
<ADSRinterface.zip>
it is not true that words are "better" than images. and it is not
true that more information in a patch means "better". I think you are right from the viewpoint of a programming user, but users that just want higher level usuability want better graphics at least the *possibility* to add graphical UI features. but this is
quite a lot of work...a good example for me are web-pages. you really don't want to read
all the code behind. you want it to work and have a nice UI. with pd you also want a nice interface for the "performing"
situation.btw. we need to make pd run in a browser environment.
marius.
Frank Barknecht wrote:
Hallo, Langsam Wieder hat gesagt: // Langsam Wieder wrote:
if you want to collect some ideas how a real usable and pretty interface for a modular environment could look like, have a look at http://synthmaker.co.uk/about.html it's got bendable links... you never have to leave edit mode... and have a look at how ALL interface elements as bitmap & vector knobs, sliders or wavedraw display consist of modules themselve. the environment is off course not as powerful as pd, but the
interface is just a joy to work with.I've never worked with that, however I'm always irritated, when patching environments have their cord connections flow left to right instead of top to bottom. IMO that's such a waste of space in languages, that are written horizontally. If you look at the
"Midi to Poly" object here: http://synthmaker.co.uk/images/components%20L.png you'll see that most of it is just an empty grey rectangle, whose width is just there to make room for the object name. If the in/outlets were top and bottom as in Pd and Max, the box could be
much smaller without losing any information.Of course if objects are just icons instead of works, left-to-right can work, but as Matju once said: "a word says more than a thousand pictures" - icons are very limited. No wonder, SynthMaker also includes a (quite nice) text editor for dsp code.
Ciao
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
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
Hi List...
http://video.google.com/videoplay?docid=-2991739314359132538
Maybe a question to who ever used "ann", or maybe the two developers
Johannes Zmoelnig and Davide Morelli
I posted a link...
Do you think "ann" is powerful and fast enough to do something like
that ??
Would be nice to hear your opinion about that
Thanks Luigi
nice! in the description of the algorithm they talk about some pending patents... I guess they use more than simple ann comparison to get this working in realtime on a game console. for basic gestures it might work, but you have a 3d space (which means a lot of data) and no clear start and end trigger for your movements, so to me this looks like a challenging task... but if you manage to somehow calibrate your data before you send it to ann (maybe normalize x, y, z and time? or use statistic methods to get more meaningful values, also think how a gesture's start and end can be found) then ann hopefully does the rest. marius.
Luigi Rensinghoff wrote:
Hi List...
http://video.google.com/videoplay?docid=-2991739314359132538
Maybe a question to who ever used "ann", or maybe the two developers Johannes Zmoelnig and Davide Morelli
I posted a link...
Do you think "ann" is powerful and fast enough to do something like that ??
Would be nice to hear your opinion about that
Thanks Luigi
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo!
in the description of the algorithm they talk about some pending patents... I guess they use more than simple ann comparison to get this working in realtime on a game console.
Yes, I also would not use a feedforward neural network (as implemented in ann) for this. You have to use a model which also incorporates time.
For example a hidden markov model or echo state network (= special kind of recurrent neural network) should work.
(The second is currently the topic of my thesis - so maybe I will make some similar examples in summer, when I have some time again ... ;)
LG Georg
Hi,
On Sun, 2008-05-04 at 08:37 +0200, Georg Holzmann wrote:
in the description of the algorithm they talk about some pending patents... I guess they use more than simple ann comparison to get this working in realtime on a game console.
Yes, I also would not use a feedforward neural network (as implemented in ann) for this. You have to use a model which also incorporates time.
Hm. You can incorporate changes over time using a standard feedforward ANN by wrapping your time-ordered vectors over a given time period into a single input vector and increasing the number of inputs to the network accordingly. But of course this introduces latency and other problems (e.g. it could massively increase the number of training examples required).
Pd has the ann_td external, which provides a 'time delay' neural network which I believe incorporates time using a method similar to that described above.
For example a hidden markov model or echo state network (= special kind of recurrent neural network) should work.
I'm intrigued! Presumably these approaches avoid the latency problem by maintaining the network's state? Are there other advantages -- easier to train?
Jamie
Hallo!
Hm. You can incorporate changes over time using a standard feedforward ANN by wrapping your time-ordered vectors over a given time period into a single input vector and increasing the number of inputs to the network accordingly. But of course this introduces latency and other problems (e.g. it could massively increase the number of training examples required).
Pd has the ann_td external, which provides a 'time delay' neural network which I believe incorporates time using a method similar to that described above.
Yes of course, one other possibility is to use time delayed neural networks ...
For example a hidden markov model or echo state network (= special kind of recurrent neural network) should work.
I'm intrigued! Presumably these approaches avoid the latency problem by maintaining the network's state? Are there other advantages -- easier to train?
Hm ... I did not think about latency ... but if you do not process the data in blocks there should not be a significant latency (also for the time delay NN) ?
However, the advantage of the echo state network is that training is linear and you cannot get in a suboptimal solution as with feedforward neural networks (where the error surface has multiple local minimas) - see for example http://www.scholarpedia.org/article/Echo_state_network for a short introduction. And it is recurrent - so in general more powerful ... from the link above: "On a number of benchmark tasks, ESNs have starkly outperformed all other methods of nonlinear dynamical modelling"
If you are interested, I implemented ESNs (with various extensions) in a C++ library with python bindings: http://aureservoir.sourceforge.net/, a PD external will hopefully follow in summer ...
LG Georg
Hi all
very interesting, really..
yet it does take me away more and more from my inital question ;-)
And a practical solution to implement some simplicistic gesture
recognition in PD..
..and wait for the summer, when the PD bindings are ready...
I hope there will be some creative, artisitic examples then..
Best Regards
Luigi
Am 04.05.2008 um 13:59 schrieb Georg Holzmann:
Hallo!
Hm. You can incorporate changes over time using a standard
feedforward ANN by wrapping your time-ordered vectors over a given time period
into a single input vector and increasing the number of inputs to the
network accordingly. But of course this introduces latency and other problems (e.g. it could massively increase the number of training examples required).Pd has the ann_td external, which provides a 'time delay' neural
network which I believe incorporates time using a method similar to that described above.Yes of course, one other possibility is to use time delayed neural networks ...
For example a hidden markov model or echo state network (=
special kind of recurrent neural network) should work.I'm intrigued! Presumably these approaches avoid the latency
problem by maintaining the network's state? Are there other advantages --
easier to train?Hm ... I did not think about latency ... but if you do not process the data in blocks there should not be a significant latency (also for the time delay NN) ?
However, the advantage of the echo state network is that training is linear and you cannot get in a suboptimal solution as with feedforward neural networks (where the error surface has multiple local minimas) - see for example http://www.scholarpedia.org/article/Echo_state_network for a short introduction. And it is recurrent - so in general more powerful ... from the link
above: "On a number of benchmark tasks, ESNs have starkly outperformed all other methods of nonlinear dynamical modelling"If you are interested, I implemented ESNs (with various extensions)
in a C++ library with python bindings: http:// aureservoir.sourceforge.net/, a PD external will hopefully follow in summer ...LG Georg
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
---------------------------------------<
Luigi Rensinghoff luigi.rensinghoff@freenet.de skype:gigischinke ichat:gigicarlo
Hallo, marius schebella hat gesagt: // marius schebella wrote:
what is so bad about, if you create [ADSR] that it comes as a nice little control gui with all the knobs already included? it is not true that words are "better" than images. and it is not true that more information in a patch means "better". I think you are right from the viewpoint of a programming user, but users that just want higher level usuability want better graphics at least the *possibility* to add graphical UI features. but this is quite a lot of work...
Most of my patches only use a handful of Pd core objects, like maybe (guessing) 50 builtins and some externals. However on my disk there are hundreds of abstractions, that I use. If I would need to think of and design icons for each of these, I would not use abstractions and I would feel severly limited in what I could express with Pd. Concrete example: What icons should I use for the ~60 abstractions in the list-abs collection? It's no problem to express their functionality using words, but icons would be horribly confusing. Oh, and yes: I'm a programming user here, but I believe most Pd users are programming users, and the others rely on the work of programming users.
Frank Barknecht _ ______footils.org__
On May 5, 2008, at 10:07 PM, Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
what is so bad about, if you create [ADSR] that it comes as a nice little control gui with all the knobs already included? it is not true that words are "better" than images. and it is not
true that more information in a patch means "better". I think you are right from the viewpoint of a programming user, but users that just want higher level usuability want better graphics at least the *possibility* to add graphical UI features. but this is
quite a lot of work...Most of my patches only use a handful of Pd core objects, like maybe (guessing) 50 builtins and some externals. However on my disk there are hundreds of abstractions, that I use. If I would need to think of and design icons for each of these, I would not use abstractions and I would feel severly limited in what I could express with Pd. Concrete example: What icons should I use for the ~60 abstractions in the list-abs collection? It's no problem to express their functionality using words, but icons would be horribly confusing. Oh, and yes: I'm a programming user here, but I believe most Pd users are programming users, and the others rely on the work of programming users.
Pd definitely needs text, text is a great, flexible symbol system for
representing a massive array of words. But I also think that some
iconic objects would be nice, like jMax's trigger or Max/MSP's gate.
.hc
Ciao
Frank Barknecht _
______footils.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
There is no way to peace, peace is the way. -A.J. Muste
Am 06.05.2008 um 20:23 schrieb Hans-Christoph Steiner:
Pd definitely needs text, text is a great, flexible symbol system for representing a massive array of words. But I also think that some iconic objects would be nice, like jMax's trigger or Max/MSP's gate.
there is another vital thing missing in the core: a knob. http://footils.org/cms/show/20
we've got button (=bang), switch (=toggle), radio-button and slider
as representations of real life input methods on a synth, mixer or
whatever electronic instrument.
there is no reason why exactly the knob should be left out.
why should I need a knob in enviroments without limitations of confiend spaces like lets say a hardware-mixing-desk. Beside it is not really convienent to use it with a mouse.
Am 06.05.2008 um 20:23 schrieb Hans-Christoph Steiner:
Pd definitely needs text, text is a great, flexible symbol system for representing a massive array of words. But I also think that some iconic objects would be nice, like jMax's trigger or Max/MSP's gate.
there is another vital thing missing in the core: a knob. http://footils.org/cms/show/20
we've got button (=bang), switch (=toggle), radio-button and slider as representations of real life input methods on a synth, mixer or whatever electronic instrument. there is no reason why exactly the knob should be left out.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue May 06, 2008 at 01:39:53PM +0200, brandt@subnet.at wrote:
why should I need a knob in enviroments without limitations of confiend spaces like lets say a hardware-mixing-desk. Beside it is not really convienent to use it with a mouse.
knob is one of the best input 'device' for mouse
first you can do the limitlesss thing.
ive never seen a slider that 'wraps around'. it would look weird. not like a knob where spinning 360 makes sense
plus with different buttons or even combinations of buttons, wheels, scrolling regions, and gestures, you can get pretty expressive in the granularity of the dynamic changes
a proper x/y multitouch multi-param pad is essential as well..
hey franz!
left to right makes sense with the synthmaker environment, as each module (can) have hint texts for their in- and outputs: http://img517.imageshack.us/img517/581/smhelptexttu4.png i miss these little help texts in pd as i have to look for each module (when i found it) what each input means. sure, when you've been working with pd for years, you don't need this, but it's definately a help. hovering tips would be nice at least.
and you can, but you probably won't perform in this view. you can drag your interface together (from several subpatches levels) and just display this for the performance. like this http://www.synthmaker.co.uk/images/alieno/alieno%20M.png
and hey matt: at least some sort of bent links would make sense, as horizontal links in pd are the worst, overseeing prone. maybe something not user bendable, auto bending like in plogue bidule: http://img147.imageshack.us/img147/6782/ploguebidulexv5.png
greetings fabb
On Sat, May 3, 2008 at 12:21 PM, Frank Barknecht fbar@footils.org wrote:
I've never worked with that, however I'm always irritated, when patching environments have their cord connections flow left to right instead of top to bottom. IMO that's such a waste of space in languages, that are written horizontally. If you look at the "Midi to Poly" object here: http://synthmaker.co.uk/images/components%20L.png you'll see that most of it is just an empty grey rectangle, whose width is just there to make room for the object name. If the in/outlets were top and bottom as in Pd and Max, the box could be much smaller without losing any information.
On Sat, May 3, 2008 at 3:27 PM, Matt Barber brbrofsvl@gmail.com wrote:
I would really be opposed to bendable patch cords, or especially the segmented patch cord style in Max/MSP. It seems to me these types of connections reinforce bad habits, as users are not encouraged to modularize, economize, etc. and they tend to lead to the most unreadable (and uneditable!) "spider webs" in complex projects. PD's style forces one to be explicit, but causes some extra (and IMO, worthwile) work to make an ergonomic interface for performers. I think the inclusion of send and receive symbols in the graphical objects is one of the best ideas in PD, because it allows one to easily keep the engine hidden and out of sight, and obviates much of the need for hideable or segmented cables.
Also, I have had students who came from Max/MSP who created the kind of huge, sprawling, everything-in-one-window kind of patch they got used to doing in Max. We found that by hiding more and more things in subpatches and abstractions, we could cut down on CPU quite a bit. I assume this means tcl/tk redraws entire windows often, but I don't know the details. At any rate, I don't think introducing the segmented patch cables would necessarily result in an explosion of unreadable patches, but I think the "clunkiness" of PDs interface encourages thoughtfulness and efficiency, which are invaluable in pedagogical situations.
When I see stuff like fancy icons etc, I'm always a bit afraid that those of us on low res machines (1024x768 in my case) would get really screwed in the end as one cool, large, fancy, chromey module would take up half the screen! IMO tiny pd boxes are always better as they save space and increase whitespace, increasing readability ... and a well named abstraction is more powerful then loads of graphics. Those signal inlet, outlet signs in SynthMaker are annoyingly large too, whereas in PD a thicker line is completely obvious enough.
I guess it all comes down to who PD is aimed at ... people who need a fancy interface or people who want to get some work done. (ohhh I went there!)
What I would like would be a unified set of common interface elements as already suggested. A better [knob] would be nice for instance
2 bits
On Sat, 2008-05-03 at 12:21 +0200, Frank Barknecht wrote:
Hallo, Langsam Wieder hat gesagt: // Langsam Wieder wrote:
if you want to collect some ideas how a real usable and pretty interface for a modular environment could look like, have a look at http://synthmaker.co.uk/about.html it's got bendable links... you never have to leave edit mode... and have a look at how ALL interface elements as bitmap & vector knobs, sliders or wavedraw display consist of modules themselve. the environment is off course not as powerful as pd, but the interface is just a joy to work with.
I've never worked with that, however I'm always irritated, when patching environments have their cord connections flow left to right instead of top to bottom. IMO that's such a waste of space in languages, that are written horizontally. If you look at the "Midi to Poly" object here: http://synthmaker.co.uk/images/components%20L.png you'll see that most of it is just an empty grey rectangle, whose width is just there to make room for the object name. If the in/outlets were top and bottom as in Pd and Max, the box could be much smaller without losing any information.
Of course if objects are just icons instead of works, left-to-right can work, but as Matju once said: "a word says more than a thousand pictures" - icons are very limited. No wonder, SynthMaker also includes a (quite nice) text editor for dsp code.
Ciao
Dan Wilcox robotcowboy.com
Hey folks,
My interest (at first) would not be to add anything or enhance the appearance of things; I'm more interested in helping to improve the PD workflow by making PD easier to use.
Something like an optional "snap to grid" feature for instance would be nice for auto-aligning and cleaning up patches. While I understand the argument that bending patch cords increases the visual noise of a patch, it's already noisy when patch cords cross at acute angles or when the data flows from bottom to top (which is necessary to do many things in PD). Perhaps creating some logic to bend patch cords at right angles only, tracing the aforementioned grid? I won't have time to work on this at first though, so it's worth thinking about for a while.
I agree that the startup paths dialog needs a lot of help - when you run PD-extended it's already full of paths for externals, leaving you nowhere to put your own paths!
I get really annoyed that there's no way to bulk-edit GUI elements (vsliders, etc.). For instance, if you draw a whole bunch of vsliders, then realize that you forgot to set "no init" to "init", you have to manually open each one and click the button. To make matters worse, they tile automatically, so after a number of the vslider properties dialogs have been open, the buttons to close the dialog are below the bottom of the screen!
I would also really like it if you could do all of your basic patching in PD without using the mouse. Perhaps some key bindings like (in edit mode):
<tab> to select an object, cycling through the objects/messages in the current patch (<shift-tab> to reverse) <enter> to type in the selected object/message <shift-arrow> to select one of the selected object's outlets <space> to create a new patch cord <tab> to cycle through the rest of the objects on the page (<shift-tab> to reverse, or <esc> to cancel the operation)
also, when typing in an object or message, pressing <esc> should "blur" (deselect) the object/message, restoring its previous value ("cancel"); <tab> should select the next object for editing, and <shift-enter> should "blur" the object, setting its value to what you just typed.
Does PD currently have any key bindings guidelines? I'd be interested in finding out what's already taken (though none of the combinations I mentioned above appear to be currently in use).
What do you all think about this? I'm starting to dive into the tk, it looks like however almost all of the GUI is in pd/src/u_main.tk, which at around 4300 lines is substantially larger than any of the C src files. It would be nice if we could organize this a little better by breaking up the large source file into smaller, more module files, though I haven't yet investigated how much work that would be, and anyways we can live with the current organization if it's too much trouble.
So, I'm interested in starting with fixing some of the messy dialogs, then working toward getting a mouse-less edit mode.
-David
On Sat, May 3, 2008 at 10:05 AM, Dan Wilcox danomatika@gmail.com wrote:
When I see stuff like fancy icons etc, I'm always a bit afraid that those of us on low res machines (1024x768 in my case) would get really screwed in the end as one cool, large, fancy, chromey module would take up half the screen! IMO tiny pd boxes are always better as they save space and increase whitespace, increasing readability ... and a well named abstraction is more powerful then loads of graphics. Those signal inlet, outlet signs in SynthMaker are annoyingly large too, whereas in PD a thicker line is completely obvious enough.
I guess it all comes down to who PD is aimed at ... people who need a fancy interface or people who want to get some work done. (ohhh I went there!)
What I would like would be a unified set of common interface elements as already suggested. A better [knob] would be nice for instance
2 bits
On Sat, 2008-05-03 at 12:21 +0200, Frank Barknecht wrote:
Hallo, Langsam Wieder hat gesagt: // Langsam Wieder wrote:
if you want to collect some ideas how a real usable and pretty interface for a modular environment could look like, have a look at http://synthmaker.co.uk/about.html it's got bendable links... you never have to leave edit mode... and have a look at how ALL interface elements as bitmap & vector knobs, sliders or wavedraw display consist of modules themselve. the environment is off course not as powerful as pd, but the interface is just a joy to work with.
I've never worked with that, however I'm always irritated, when patching environments have their cord connections flow left to right instead of top to bottom. IMO that's such a waste of space in languages, that are written horizontally. If you look at the "Midi to Poly" object here: http://synthmaker.co.uk/images/components%20L.png you'll see that most of it is just an empty grey rectangle, whose width is just there to make room for the object name. If the in/outlets were top and bottom as in Pd and Max, the box could be much smaller without losing any information.
Of course if objects are just icons instead of works, left-to-right can work, but as Matju once said: "a word says more than a thousand pictures" - icons are very limited. No wonder, SynthMaker also includes a (quite nice) text editor for dsp code.
Ciao
Dan Wilcox robotcowboy.com http://www.robotcowboy.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On May 3, 2008, at 8:06 PM, David Golightly wrote:
Hey folks,
My interest (at first) would not be to add anything or enhance the
appearance of things; I'm more interested in helping to improve the
PD workflow by making PD easier to use.
Hear, hear!
Something like an optional "snap to grid" feature for instance
would be nice for auto-aligning and cleaning up patches.
Sounds good.
While I understand the argument that bending patch cords increases
the visual noise of a patch, it's already noisy when patch cords
cross at acute angles or when the data flows from bottom to top
(which is necessary to do many things in PD). Perhaps creating
some logic to bend patch cords at right angles only, tracing the
aforementioned grid? I won't have time to work on this at first
though, so it's worth thinking about for a while.
The linearity of the patch cords makes it easier to trace the path of
them. You don't have to follow the cords with your eye, but instead
it is just readily apparent.
I agree that the startup paths dialog needs a lot of help - when
you run PD-extended it's already full of paths for externals,
leaving you nowhere to put your own paths!
I think there should be a subwindow with a line for each path entry,
then + and - buttons for editing the entries. Then if there are lots
of entries, that subwindow would scroll. There is a Tk 'listbox"
which would work for this (seen in action in the Help Browser).
I get really annoyed that there's no way to bulk-edit GUI elements
(vsliders, etc.). For instance, if you draw a whole bunch of
vsliders, then realize that you forgot to set "no init" to "init",
you have to manually open each one and click the button. To make
matters worse, they tile automatically, so after a number of the
vslider properties dialogs have been open, the buttons to close the
dialog are below the bottom of the screen!
That would be quite useful.
I would also really like it if you could do all of your basic
patching in PD without using the mouse. Perhaps some key bindings
like (in edit mode):<tab> to select an object, cycling through the objects/messages in
the current patch (<shift-tab> to reverse) <enter> to type in the selected object/message <shift-arrow> to select one of the selected object's outlets <space> to create a new patch cord <tab> to cycle through the rest of the objects on the page (<shift- tab> to reverse, or <esc> to cancel the operation)also, when typing in an object or message, pressing <esc> should
"blur" (deselect) the object/message, restoring its previous value
("cancel"); <tab> should select the next object for editing, and
<shift-enter> should "blur" the object, setting its value to what
you just typed.Does PD currently have any key bindings guidelines? I'd be
interested in finding out what's already taken (though none of the
combinations I mentioned above appear to be currently in use).
There are quite a few that are taken. I think the key is to make
sure that none of the standards for each platform are overridden, and
that we use the standards on each platform.
What do you all think about this? I'm starting to dive into the
tk, it looks like however almost all of the GUI is in pd/src/ u_main.tk, which at around 4300 lines is substantially larger than
any of the C src files. It would be nice if we could organize this
a little better by breaking up the large source file into smaller,
more module files, though I haven't yet investigated how much work
that would be, and anyways we can live with the current
organization if it's too much trouble.
u_main.tk is a mess. It needs to be cleaned up in a big way. I
think to start with, it is possible to tack more stuff on, then
reorganize it. I am planning on refactoring u_main.tk after I get
the 0.40.3-extended release out. I talked with Miller about it, it
sounds like he is willing to accept such changes.
So, I'm interested in starting with fixing some of the messy
dialogs, then working toward getting a mouse-less edit mode.
Sounds great, keep us posted on what you are working on, and post
questions when you have them!
.hc
-David
On Sat, May 3, 2008 at 10:05 AM, Dan Wilcox danomatika@gmail.com
wrote: When I see stuff like fancy icons etc, I'm always a bit afraid that
those of us on low res machines (1024x768 in my case) would get
really screwed in the end as one cool, large, fancy, chromey module
would take up half the screen! IMO tiny pd boxes are always better
as they save space and increase whitespace, increasing
readability ... and a well named abstraction is more powerful then
loads of graphics. Those signal inlet, outlet signs in SynthMaker
are annoyingly large too, whereas in PD a thicker line is
completely obvious enough.I guess it all comes down to who PD is aimed at ... people who need
a fancy interface or people who want to get some work done. (ohhh I
went there!)What I would like would be a unified set of common interface
elements as already suggested. A better [knob] would be nice for
instance2 bits
On Sat, 2008-05-03 at 12:21 +0200, Frank Barknecht wrote:
Hallo, Langsam Wieder hat gesagt: // Langsam Wieder wrote:
if you want to collect some ideas how a real usable and pretty interface for a modular environment could look like, have a look at http://synthmaker.co.uk/about.html it's got bendable links... you never have to leave edit mode... and have a look at how ALL interface elements as bitmap & vector knobs, sliders or wavedraw display consist of modules themselve. the environment is off course not as powerful as pd, but the
interface
is just a joy to work with.
I've never worked with that, however I'm always irritated, when patching environments have their cord connections flow left to right instead of top to bottom. IMO that's such a waste of space in languages, that are written horizontally. If you look at the "Midi to Poly" object here: http://synthmaker.co.uk/images/components%20L.png you'll see that most of it is just an empty grey rectangle, whose width is just there to make room for the object name. If the in/outlets were top and bottom as in Pd and Max, the box could be
much smaller without losing any information.Of course if objects are just icons instead of works, left-to-right can work, but as Matju once said: "a word says more than a thousand pictures" - icons are very limited. No wonder, SynthMaker also includes a (quite nice) text editor for dsp code.
Ciao
Dan Wilcox robotcowboy.com
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
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
On Sat May 03, 2008 at 11:06:04AM -0700, David Golightly wrote:
Hey folks,
My interest (at first) would not be to add anything or enhance the appearance of things; I'm more interested in helping to improve the PD workflow by making PD easier to use.
Something like an optional "snap to grid" feature for instance would be nice for auto-aligning and cleaning up patches. While I understand the argument that bending patch cords increases the visual noise of a patch, it's already noisy when patch cords cross at acute angles or when the data flows from bottom to top (which is necessary to do many things in PD). Perhaps creating some logic to bend patch cords at right angles only, tracing the aforementioned grid? I won't have time to work on this at first though, so it's worth thinking about for a while.
I agree that the startup paths dialog needs a lot of help - when you run PD-extended it's already full of paths for externals, leaving you nowhere to put your own paths!
I get really annoyed that there's no way to bulk-edit GUI elements (vsliders, etc.). For instance, if you draw a whole bunch of vsliders, then realize that you forgot to set "no init" to "init", you have to manually open each one and click the button. To make matters worse, they tile automatically, so after a number of the vslider properties dialogs have been open, the buttons to close the dialog are below the bottom of the screen!
I would also really like it if you could do all of your basic patching in PD without using the mouse. Perhaps some key bindings like (in edit mode):
<tab> to select an object, cycling through the objects/messages in the current patch (<shift-tab> to reverse) <enter> to type in the selected object/message <shift-arrow> to select one of the selected object's outlets <space> to create a new patch cord <tab> to cycle through the rest of the objects on the page (<shift-tab> to reverse, or <esc> to cancel the operation)
also, when typing in an object or message, pressing <esc> should "blur" (deselect) the object/message, restoring its previous value ("cancel"); <tab> should select the next object for editing, and <shift-enter> should "blur" the object, setting its value to what you just typed.
Does PD currently have any key bindings guidelines? I'd be interested in finding out what's already taken (though none of the combinations I mentioned above appear to be currently in use).
What do you all think about this? I'm starting to dive into the tk, it looks like however almost all of the GUI is in pd/src/u_main.tk, which at around 4300 lines is substantially larger than any of the C src files. It would be nice if we could organize this a little better by breaking up the large source file into smaller, more module files, though I haven't yet investigated how much work that would be, and anyways we can live with the current organization if it's too much trouble.
So, I'm interested in starting with fixing some of the messy dialogs, then working toward getting a mouse-less edit mode.
youve been around long enough to know that DesireData exists, right?
it has everything you described, at least in some imperfect state
-David
On Sat, May 3, 2008 at 10:05 AM, Dan Wilcox danomatika@gmail.com wrote:
When I see stuff like fancy icons etc, I'm always a bit afraid that those of us on low res machines (1024x768 in my case) would get really screwed in the end as one cool, large, fancy, chromey module would take up half the screen! IMO tiny pd boxes are always better as they save space and increase whitespace, increasing readability ... and a well named abstraction is more powerful then loads of graphics. Those signal inlet, outlet signs in SynthMaker are annoyingly large too, whereas in PD a thicker line is completely obvious enough.
I guess it all comes down to who PD is aimed at ... people who need a fancy interface or people who want to get some work done. (ohhh I went there!)
What I would like would be a unified set of common interface elements as already suggested. A better [knob] would be nice for instance
2 bits
On Sat, 2008-05-03 at 12:21 +0200, Frank Barknecht wrote:
Hallo, Langsam Wieder hat gesagt: // Langsam Wieder wrote:
if you want to collect some ideas how a real usable and pretty interface for a modular environment could look like, have a look at http://synthmaker.co.uk/about.html it's got bendable links... you never have to leave edit mode... and have a look at how ALL interface elements as bitmap & vector knobs, sliders or wavedraw display consist of modules themselve. the environment is off course not as powerful as pd, but the interface is just a joy to work with.
I've never worked with that, however I'm always irritated, when patching environments have their cord connections flow left to right instead of top to bottom. IMO that's such a waste of space in languages, that are written horizontally. If you look at the "Midi to Poly" object here: http://synthmaker.co.uk/images/components%20L.png you'll see that most of it is just an empty grey rectangle, whose width is just there to make room for the object name. If the in/outlets were top and bottom as in Pd and Max, the box could be much smaller without losing any information.
Of course if objects are just icons instead of works, left-to-right can work, but as Matju once said: "a word says more than a thousand pictures" - icons are very limited. No wonder, SynthMaker also includes a (quite nice) text editor for dsp code.
Ciao
Dan Wilcox robotcowboy.com http://www.robotcowboy.com
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
On 03/05/2008, at 20.06, David Golightly wrote:
So, I'm interested in starting with fixing some of the messy
dialogs, then working toward getting a mouse-less edit mode.
That sounds great. I especially like your focus on editing objects
prefs.
For the path/lib pref panel, the attached is what i got at when i
stalled.
actually do it while learning tcl/tk and getting into Pd src. This
sketching need no edits to Pd source code but tries to black-box test
first. Depending on the actual implementation one might need to patch
s_path.c, hence recompile Pd to do a full test (as opposed to just
swap main.tk). IOhannes recently got a patch for adding more path/
libs into Vanilla that gives more then 10 variables to work with in
the Tcl side of Pd. A better fix would be to use another format (not
assumed in my test) then pd_path0, pd_path1, ..., pd_pathN - like a
'pd_path' array.
On May 8, 2008, at 9:18 PM, Steffen Juul wrote:
On 03/05/2008, at 20.06, David Golightly wrote:
So, I'm interested in starting with fixing some of the messy
dialogs, then working toward getting a mouse-less edit mode.That sounds great. I especially like your focus on editing objects
prefs.For the path/lib pref panel, the attached is what i got at when i
stalled.
- It's super messy and only trying to sketch an idea on how to
actually do it while learning tcl/tk and getting into Pd src. This
sketching need no edits to Pd source code but tries to black-box
test first. Depending on the actual implementation one might need
to patch s_path.c, hence recompile Pd to do a full test (as opposed
to just swap main.tk). IOhannes recently got a patch for adding
more path/libs into Vanilla that gives more then 10 variables to
work with in the Tcl side of Pd. A better fix would be to use
another format (not assumed in my test) then pd_path0,
pd_path1, ..., pd_pathN - like a 'pd_path' array.
This test looks like a great start. If it could have in-place
editing and the ability to change the order, it would be perfect!
The path/startup stuff should already be in place for this to plug
into, thanks to IOhannes' patch.
.hc
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
Ok, after a busy week this is what I've been able to come up with for the Path dialog. I'm thinking about adapting this UI for the Startup dialog - shouldn't be hard to do - except instead of choosing directories you want to enter arbitrary text. Still, have a look and let me know what you think - I've set up some various key bindings so I want to make sure it seems usable for everyone. So far I've only tested this on Mac OS X, so feedback on other platforms would be nice. I'll probably get a Windows build at some point as well.
-David
On Thu, May 8, 2008 at 4:12 PM, Hans-Christoph Steiner hans@eds.org wrote:
On May 8, 2008, at 9:18 PM, Steffen Juul wrote:
On 03/05/2008, at 20.06, David Golightly wrote:
So, I'm interested in starting with fixing some of the messy dialogs, then working toward getting a mouse-less edit mode.
That sounds great. I especially like your focus on editing objects prefs.
For the path/lib pref panel, the attached is what i got at when i stalled.
- It's super messy and only trying to sketch an idea on how to actually do
it while learning tcl/tk and getting into Pd src. This sketching need no edits to Pd source code but tries to black-box test first. Depending on the actual implementation one might need to patch s_path.c, hence recompile Pd to do a full test (as opposed to just swap main.tk). IOhannes recently got a patch for adding more path/libs into Vanilla that gives more then 10 variables to work with in the Tcl side of Pd. A better fix would be to use another format (not assumed in my test) then pd_path0, pd_path1, ..., pd_pathN - like a 'pd_path' array.
This test looks like a great start. If it could have in-place editing and the ability to change the order, it would be perfect!
The path/startup stuff should already be in place for this to plug into, thanks to IOhannes' patch.
.hc
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
On 10/05/2008, at 19.48, David Golightly wrote:
Ok, after a busy week this is what I've been able to come up with
for the Path dialog.
Looking really good! The browse functionality is a fair idiom in a
such GUI as oppose to entering text, i think.
"One" comment: I have a beef with the functionality of the buttons.
Not the Cancel one. The others. 'Apply' does something. 'Ok' does
'apply' plus 'cancel'. 'Save...' does 'Apply' plus saves. But it says
the list is only gonna work from next time Pd is lunched, why i don't
get the 'Apply' and 'Ok'. 'Ok' should do save and cancel. Thats all
one wants, anit?
I'm thinking about adapting this UI for the Startup dialog -
shouldn't be hard to do - except instead of choosing directories
you want to enter arbitrary text.
I haven't checked your code but i suppose most "proc's" can be reused?
I've set up some various key bindings so I want to make sure it
seems usable for everyone.
Nice. What are they?
So far I've only tested this on Mac OS X
OS X.4 here.
On Sat, May 10, 2008 at 12:36 PM, Steffen Juul stffn@dibidut.dk wrote:
On 10/05/2008, at 19.48, David Golightly wrote:
Ok, after a busy week this is what I've been able to come up with for the
Path dialog.
Looking really good! The browse functionality is a fair idiom in a such GUI as oppose to entering text, i think.
Thanks! I've often been kind of frustrated that I have to type in the full directory name rather than simply browsing to it. For the keyboard-inclined, however, text entry should still be possible.
"One" comment: I have a beef with the functionality of the buttons. Not the Cancel one. The others. 'Apply' does something. 'Ok' does 'apply' plus 'cancel'. 'Save...' does 'Apply' plus saves. But it says the list is only gonna work from next time Pd is lunched, why i don't get the 'Apply' and 'Ok'. 'Ok' should do save and cancel. Thats all one wants, anit?
I agree. I've preserved the pre-existing functionality for those buttons from before, but do we really need both "Save" and "Apply"? Currently, "Save" also "saves preferences" (verbose & use standard extensions). I think that should also happen when you click "Apply", so we can do away with the "Save" button, and also make sure that the message about needing to restart PD pops up when you click "OK" or "Apply".
I'm thinking about adapting this UI for the Startup dialog - shouldn't be
hard to do - except instead of choosing directories you want to enter arbitrary text.
I haven't checked your code but i suppose most "proc's" can be reused?
I've set up some various key bindings so I want to make sure it seems
usable for everyone.
Nice. What are they?
Default key bindings for the listbox widget give you "up" and "down" keys to select, I've added "Delete" to delete the current selection, and "Return" to open the browse dialog (same as pressing "Edit").
So far I've only tested this on Mac OS X
OS X.4 here.
And, here's a version with an updated Startup dialog. Simply copy this to bin/pd.tk (make a backup first!) to try it out.
On Sat, May 10, 2008 at 12:48 PM, David Golightly davigoli@gmail.com wrote:
On Sat, May 10, 2008 at 12:36 PM, Steffen Juul stffn@dibidut.dk wrote:
On 10/05/2008, at 19.48, David Golightly wrote:
Ok, after a busy week this is what I've been able to come up with for the
Path dialog.
Looking really good! The browse functionality is a fair idiom in a such GUI as oppose to entering text, i think.
Thanks! I've often been kind of frustrated that I have to type in the full directory name rather than simply browsing to it. For the keyboard-inclined, however, text entry should still be possible.
"One" comment: I have a beef with the functionality of the buttons. Not the Cancel one. The others. 'Apply' does something. 'Ok' does 'apply' plus 'cancel'. 'Save...' does 'Apply' plus saves. But it says the list is only gonna work from next time Pd is lunched, why i don't get the 'Apply' and 'Ok'. 'Ok' should do save and cancel. Thats all one wants, anit?
I agree. I've preserved the pre-existing functionality for those buttons from before, but do we really need both "Save" and "Apply"? Currently, "Save" also "saves preferences" (verbose & use standard extensions). I think that should also happen when you click "Apply", so we can do away with the "Save" button, and also make sure that the message about needing to restart PD pops up when you click "OK" or "Apply".
I'm thinking about adapting this UI for the Startup dialog - shouldn't be
hard to do - except instead of choosing directories you want to enter arbitrary text.
I haven't checked your code but i suppose most "proc's" can be reused?
I've set up some various key bindings so I want to make sure it seems
usable for everyone.
Nice. What are they?
Default key bindings for the listbox widget give you "up" and "down" keys to select, I've added "Delete" to delete the current selection, and "Return" to open the browse dialog (same as pressing "Edit").
So far I've only tested this on Mac OS X
OS X.4 here.
I tried this with pd extended 0.40-3, but did not get a startup pref window at all and the path window was very small and empty. (os x, 10.5.) marius.
David Golightly wrote:
And, here's a version with an updated Startup dialog. Simply copy this to bin/pd.tk http://pd.tk (make a backup first!) to try it out.
On Sat, May 10, 2008 at 12:48 PM, David Golightly <davigoli@gmail.com mailto:davigoli@gmail.com> wrote:
On Sat, May 10, 2008 at 12:36 PM, Steffen Juul <stffn@dibidut.dk <mailto:stffn@dibidut.dk>> wrote: On 10/05/2008, at 19.48, David Golightly wrote: Ok, after a busy week this is what I've been able to come up with for the Path dialog. Looking really good! The browse functionality is a fair idiom in a such GUI as oppose to entering text, i think. Thanks! I've often been kind of frustrated that I have to type in the full directory name rather than simply browsing to it. For the keyboard-inclined, however, text entry should still be possible. "One" comment: I have a beef with the functionality of the buttons. Not the Cancel one. The others. 'Apply' does something. 'Ok' does 'apply' plus 'cancel'. 'Save...' does 'Apply' plus saves. But it says the list is only gonna work from next time Pd is lunched, why i don't get the 'Apply' and 'Ok'. 'Ok' should do save and cancel. Thats all one wants, anit? I agree. I've preserved the pre-existing functionality for those buttons from before, but do we really need both "Save" and "Apply"? Currently, "Save" also "saves preferences" (verbose & use standard extensions). I think that should also happen when you click "Apply", so we can do away with the "Save" button, and also make sure that the message about needing to restart PD pops up when you click "OK" or "Apply". I'm thinking about adapting this UI for the Startup dialog - shouldn't be hard to do - except instead of choosing directories you want to enter arbitrary text. I haven't checked your code but i suppose most "proc's" can be reused? I've set up some various key bindings so I want to make sure it seems usable for everyone. Nice. What are they? Default key bindings for the listbox widget give you "up" and "down" keys to select, I've added "Delete" to delete the current selection, and "Return" to open the browse dialog (same as pressing "Edit"). So far I've only tested this on Mac OS X OS X.4 here.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Well scratch that then, perhaps that will only work when you're building pd on your own machine. If you launch Pd from Terminal, you might see error output in that terminal window - that would be helpful to have.
On Sat, May 10, 2008 at 3:17 PM, marius schebella < marius.schebella@gmail.com> wrote:
I tried this with pd extended 0.40-3, but did not get a startup pref window at all and the path window was very small and empty. (os x, 10.5.) marius.
David Golightly wrote:
And, here's a version with an updated Startup dialog. Simply copy this to bin/pd.tk http://pd.tk (make a backup first!) to try it out.
On Sat, May 10, 2008 at 12:48 PM, David Golightly <davigoli@gmail.commailto: davigoli@gmail.com> wrote:
On Sat, May 10, 2008 at 12:36 PM, Steffen Juul <stffn@dibidut.dk mailto:stffn@dibidut.dk> wrote:
On 10/05/2008, at 19.48, David Golightly wrote: Ok, after a busy week this is what I've been able to come up with for the Path dialog. Looking really good! The browse functionality is a fair idiom in a such GUI as oppose to entering text, i think.
Thanks! I've often been kind of frustrated that I have to type in the full directory name rather than simply browsing to it. For the keyboard-inclined, however, text entry should still be possible.
"One" comment: I have a beef with the functionality of the buttons. Not the Cancel one. The others. 'Apply' does something. 'Ok' does 'apply' plus 'cancel'. 'Save...' does 'Apply' plus saves. But it says the list is only gonna work from next time Pd is lunched, why i don't get the 'Apply' and 'Ok'. 'Ok' should do save and cancel. Thats all one wants, anit?
I agree. I've preserved the pre-existing functionality for those buttons from before, but do we really need both "Save" and "Apply"? Currently, "Save" also "saves preferences" (verbose & use standard extensions). I think that should also happen when you click "Apply", so we can do away with the "Save" button, and also make sure that the message about needing to restart PD pops up when you click "OK" or "Apply".
I'm thinking about adapting this UI for the Startup dialog - shouldn't be hard to do - except instead of choosing directories you want to enter arbitrary text. I haven't checked your code but i suppose most "proc's" can be reused? I've set up some various key bindings so I want to make sure it seems usable for everyone. Nice. What are they?
Default key bindings for the listbox widget give you "up" and "down" keys to select, I've added "Delete" to delete the current selection, and "Return" to open the browse dialog (same as pressing "Edit").
So far I've only tested this on Mac OS X OS X.4 here.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Just verified against my own install of Pd-extended-0.40.3 on OS X 10.4 - enough differences exist otherwise in the nightlies that this version of the file will only work with 0.41.4.
Attached is an updated (slightly bugfixed) version.
So... what's the procedure for checking in to svn :)?
-David
On Sat, May 10, 2008 at 4:24 PM, David Golightly davigoli@gmail.com wrote:
Well scratch that then, perhaps that will only work when you're building pd on your own machine. If you launch Pd from Terminal, you might see error output in that terminal window - that would be helpful to have.
On Sat, May 10, 2008 at 3:17 PM, marius schebella < marius.schebella@gmail.com> wrote:
I tried this with pd extended 0.40-3, but did not get a startup pref window at all and the path window was very small and empty. (os x, 10.5.) marius.
David Golightly wrote:
And, here's a version with an updated Startup dialog. Simply copy this to bin/pd.tk http://pd.tk (make a backup first!) to try it out.
On Sat, May 10, 2008 at 12:48 PM, David Golightly <davigoli@gmail.commailto: davigoli@gmail.com> wrote:
On Sat, May 10, 2008 at 12:36 PM, Steffen Juul <stffn@dibidut.dk mailto:stffn@dibidut.dk> wrote:
On 10/05/2008, at 19.48, David Golightly wrote: Ok, after a busy week this is what I've been able to come up with for the Path dialog. Looking really good! The browse functionality is a fair idiom in a such GUI as oppose to entering text, i think.
Thanks! I've often been kind of frustrated that I have to type in the full directory name rather than simply browsing to it. For the keyboard-inclined, however, text entry should still be possible.
"One" comment: I have a beef with the functionality of the buttons. Not the Cancel one. The others. 'Apply' does something. 'Ok' does 'apply' plus 'cancel'. 'Save...' does 'Apply' plus saves. But it says the list is only gonna work from next time Pd is lunched, why i don't get the 'Apply' and 'Ok'. 'Ok' should do save and cancel. Thats all one wants, anit?
I agree. I've preserved the pre-existing functionality for those buttons from before, but do we really need both "Save" and "Apply"? Currently, "Save" also "saves preferences" (verbose & use standard extensions). I think that should also happen when you click "Apply", so we can do away with the "Save" button, and also make sure that the message about needing to restart PD pops up when you click "OK" or "Apply".
I'm thinking about adapting this UI for the Startup dialog - shouldn't be hard to do - except instead of choosing directories you want to enter arbitrary text. I haven't checked your code but i suppose most "proc's" can be reused? I've set up some various key bindings so I want to make sure it seems usable for everyone. Nice. What are they?
Default key bindings for the listbox widget give you "up" and "down" keys to select, I've added "Delete" to delete the current selection, and "Return" to open the browse dialog (same as pressing "Edit").
So far I've only tested this on Mac OS X OS X.4 here.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 11/05/2008, at 2.25, David Golightly wrote:
So... what's the procedure for checking in to svn :)?
(FWIW.) To make a patch and submit it to the patch-tracker as SF.
Then a few things can happen (and some combinations):
Miller doesn't accept it and it doesn't get into vanilla 3) Hans subs
the patch to SVN and use it for Pd-extended.
Wow, what an improvement! I like it a lot. I have some comments:
panel would be narrower?
where it is a common thing. On Mac OS X, it should just be OK and
Cancel. On Windows, there should be Apply. I think GNOME has moved
away from Apply, but I don't know anything about KDE.
things clearer, I think. Like maybe Up/Down on the right side, and
then Add..., Edit..., and Delete on the bottom? Or maybe just
changing Up and Down to arrows?
entering values should be embedded into the panel instead of a
popup. Also, it doesn't seem to work for me (I am using 0.41-4
vanilla). I can't add items to the list.
I think once this is worked out, the best plan would be to submit a
patch to the tracker and assign it to Miller. Then I'll also include
it in Pd-extended.
.hc
On May 11, 2008, at 2:25 AM, David Golightly wrote:
Just verified against my own install of Pd-extended-0.40.3 on OS X
10.4 - enough differences exist otherwise in the nightlies that
this version of the file will only work with 0.41.4.Attached is an updated (slightly bugfixed) version.
So... what's the procedure for checking in to svn :)?
-David
On Sat, May 10, 2008 at 4:24 PM, David Golightly
davigoli@gmail.com wrote: Well scratch that then, perhaps that will only work when you're
building pd on your own machine. If you launch Pd from Terminal,
you might see error output in that terminal window - that would be
helpful to have.On Sat, May 10, 2008 at 3:17 PM, marius schebella
marius.schebella@gmail.com wrote: I tried this with pd extended 0.40-3, but did not get a startup
pref window at all and the path window was very small and empty.
(os x, 10.5.) marius.David Golightly wrote: And, here's a version with an updated Startup dialog. Simply copy
this to bin/pd.tk http://pd.tk (make a backup first!) to try it out.On Sat, May 10, 2008 at 12:48 PM, David Golightly
<davigoli@gmail.com mailto:davigoli@gmail.com> wrote:On Sat, May 10, 2008 at 12:36 PM, Steffen Juul <stffn@dibidut.dk mailto:stffn@dibidut.dk> wrote:
On 10/05/2008, at 19.48, David Golightly wrote: Ok, after a busy week this is what I've been able to
come up with for the Path dialog.
Looking really good! The browse functionality is a fair
idiom in a such GUI as oppose to entering text, i think.
Thanks! I've often been kind of frustrated that I have to type in the full directory name rather than simply browsing to it. For the keyboard-inclined, however, text entry should still be possible.
"One" comment: I have a beef with the functionality of the buttons. Not the Cancel one. The others. 'Apply' does
something. 'Ok' does 'apply' plus 'cancel'. 'Save...' does 'Apply' plus saves. But it says the list is only gonna work from next
time Pd is lunched, why i don't get the 'Apply' and 'Ok'. 'Ok'
should do save and cancel. Thats all one wants, anit?I agree. I've preserved the pre-existing functionality for those buttons from before, but do we really need both "Save" and
"Apply"? Currently, "Save" also "saves preferences" (verbose &
use standard extensions). I think that should also happen when you click "Apply", so we can do away with the "Save" button, and also make sure that the message about needing to restart PD pops up when you click "OK" or "Apply".I'm thinking about adapting this UI for the Startup
dialog - shouldn't be hard to do - except instead of choosing directories you want to enter arbitrary text.
I haven't checked your code but i suppose most "proc's" can be reused? I've set up some various key bindings so I want to make
sure it seems usable for everyone.
Nice. What are they?
Default key bindings for the listbox widget give you "up" and
"down" keys to select, I've added "Delete" to delete the current
selection, and "Return" to open the browse dialog (same as pressing "Edit").So far I've only tested this on Mac OS X OS X.4 here.
--
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
<u_main.tk> _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
http://at.or.at/hans/
On Sun, May 11, 2008 1:29 pm, Hans-Christoph Steiner wrote:
- about the Apply button, I think it should only show up on platforms
where it is a common thing. On Mac OS X, it should just be OK and Cancel. On Windows, there should be Apply. I think GNOME has moved away from Apply, but I don't know anything about KDE.
KDE seam to have both Apply and OK (and Cancel). But i don't think the actual UI need be platform dependent. That is, i think it matters less then having multiple buttons with different names that hint much the same functionally but don't nessacarily supply that functionality. Apply, Ok and Save in this case - as explained earlier.
One easy solution is to remove the Save button and add the save functionality to the Ok button. And then either remove also the Apply button or add the save functionality to that also. So where
Save:= Saves changes to file ready for next startup of Pd Cancel:= Cancels i.e. quit the dialog
we have:
Case i: Cancel Apply:= Save Ok:= Apply + Cancel
Case ii: Cancel Ok:= Save + Cancel
That said, I'd like to underline that i think the improvements already done are much more impotent then this clearing of confusion of the UI. I shall rest my case now (or submit a patch).
I just thought of one other thing: I think it would be very useful
if Path, Startup, Audio Settings, and MIDI settings where all tabs in
one panel, instead of four separate panels.
.hc
On May 11, 2008, at 1:29 PM, Hans-Christoph Steiner wrote:
Wow, what an improvement! I like it a lot. I have some comments:
- minor thing, maybe there could be less space on the sides, so the
panel would be narrower?
- about the Apply button, I think it should only show up on
platforms where it is a common thing. On Mac OS X, it should just
be OK and Cancel. On Windows, there should be Apply. I think
GNOME has moved away from Apply, but I don't know anything about KDE.
- some separation of the buttons on the right column would make
things clearer, I think. Like maybe Up/Down on the right side, and
then Add..., Edit..., and Delete on the bottom? Or maybe just
changing Up and Down to arrows?
- the startup thing is trickier. I think that the textfield for
entering values should be embedded into the panel instead of a
popup. Also, it doesn't seem to work for me (I am using 0.41-4
vanilla). I can't add items to the list.I think once this is worked out, the best plan would be to submit a
patch to the tracker and assign it to Miller. Then I'll also
include it in Pd-extended..hc
On May 11, 2008, at 2:25 AM, David Golightly wrote:
Just verified against my own install of Pd-extended-0.40.3 on OS X
10.4 - enough differences exist otherwise in the nightlies that
this version of the file will only work with 0.41.4.Attached is an updated (slightly bugfixed) version.
So... what's the procedure for checking in to svn :)?
-David
On Sat, May 10, 2008 at 4:24 PM, David Golightly
davigoli@gmail.com wrote: Well scratch that then, perhaps that will only work when you're
building pd on your own machine. If you launch Pd from Terminal,
you might see error output in that terminal window - that would be
helpful to have.On Sat, May 10, 2008 at 3:17 PM, marius schebella
marius.schebella@gmail.com wrote: I tried this with pd extended 0.40-3, but did not get a startup
pref window at all and the path window was very small and empty.
(os x, 10.5.) marius.David Golightly wrote: And, here's a version with an updated Startup dialog. Simply copy
this to bin/pd.tk http://pd.tk (make a backup first!) to try it
out.On Sat, May 10, 2008 at 12:48 PM, David Golightly
<davigoli@gmail.com mailto:davigoli@gmail.com> wrote:On Sat, May 10, 2008 at 12:36 PM, Steffen Juul <stffn@dibidut.dk mailto:stffn@dibidut.dk> wrote:
On 10/05/2008, at 19.48, David Golightly wrote: Ok, after a busy week this is what I've been able to
come up with for the Path dialog.
Looking really good! The browse functionality is a fair
idiom in a such GUI as oppose to entering text, i think.
Thanks! I've often been kind of frustrated that I have to type in the full directory name rather than simply browsing to it. For
the keyboard-inclined, however, text entry should still be possible."One" comment: I have a beef with the functionality of the buttons. Not the Cancel one. The others. 'Apply' does
something. 'Ok' does 'apply' plus 'cancel'. 'Save...' does 'Apply' plus saves. But it says the list is only gonna work from next
time Pd is lunched, why i don't get the 'Apply' and 'Ok'. 'Ok'
should do save and cancel. Thats all one wants, anit?I agree. I've preserved the pre-existing functionality for those buttons from before, but do we really need both "Save" and
"Apply"? Currently, "Save" also "saves preferences" (verbose &
use standard extensions). I think that should also happen when you click "Apply", so we can do away with the "Save" button, and also make sure that the message about needing to restart PD pops up when you click "OK" or "Apply".I'm thinking about adapting this UI for the Startup
dialog - shouldn't be hard to do - except instead of choosing directories you want to enter arbitrary text.
I haven't checked your code but i suppose most "proc's" can be reused? I've set up some various key bindings so I want to make
sure it seems usable for everyone.
Nice. What are they?
Default key bindings for the listbox widget give you "up" and
"down" keys to select, I've added "Delete" to delete the current
selection, and "Return" to open the browse dialog (same as pressing "Edit").So far I've only tested this on Mac OS X OS X.4 here.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
<u_main.tk> _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
http://at.or.at/hans/
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
Hans-Christoph Steiner wrote:
I just thought of one other thing: I think it would be very useful if Path, Startup, Audio Settings, and MIDI settings where all tabs in one panel, instead of four separate panels.
Thanks Hans, for bringing that up, I second that. I think it is better organized, if there is one preferences or settings menu, that will let you change all different things. I also think that the audio settings should not be split, like it is now (in extended?) preferences - audio midi and the media - portaudio/jack settings. I think these could be unified, too.
marius.
Oops, one other detail with the "encode" proc. While namespaces are
probably the current way to handle function names, they are not used
for any other functions in u_main.tk So for this function, I think
it should be called something like pdtk_encodelist without the
namespace, then grouped with pdtk_encode. Something like this:
proc pdtk_encodelist {listdata} { set outlist {} foreach this_path $listdata { if {0==[string match "" $this_path]} { lappend outlist [pdtk_encodedialog $this_path] } } return $outlist }
Then perhaps namespaces can be introduced later as a more systematic
approach.
.hc
On May 11, 2008, at 3:15 PM, Hans-Christoph Steiner wrote:
I just thought of one other thing: I think it would be very useful
if Path, Startup, Audio Settings, and MIDI settings where all tabs
in one panel, instead of four separate panels..hc
On May 11, 2008, at 1:29 PM, Hans-Christoph Steiner wrote:
Wow, what an improvement! I like it a lot. I have some comments:
- minor thing, maybe there could be less space on the sides, so
the panel would be narrower?
- about the Apply button, I think it should only show up on
platforms where it is a common thing. On Mac OS X, it should just
be OK and Cancel. On Windows, there should be Apply. I think
GNOME has moved away from Apply, but I don't know anything about KDE.
- some separation of the buttons on the right column would make
things clearer, I think. Like maybe Up/Down on the right side,
and then Add..., Edit..., and Delete on the bottom? Or maybe just
changing Up and Down to arrows?
- the startup thing is trickier. I think that the textfield for
entering values should be embedded into the panel instead of a
popup. Also, it doesn't seem to work for me (I am using 0.41-4
vanilla). I can't add items to the list.I think once this is worked out, the best plan would be to submit
a patch to the tracker and assign it to Miller. Then I'll also
include it in Pd-extended..hc
On May 11, 2008, at 2:25 AM, David Golightly wrote:
Just verified against my own install of Pd-extended-0.40.3 on OS
X 10.4 - enough differences exist otherwise in the nightlies that
this version of the file will only work with 0.41.4.Attached is an updated (slightly bugfixed) version.
So... what's the procedure for checking in to svn :)?
-David
On Sat, May 10, 2008 at 4:24 PM, David Golightly
davigoli@gmail.com wrote: Well scratch that then, perhaps that will only work when you're
building pd on your own machine. If you launch Pd from Terminal,
you might see error output in that terminal window - that would
be helpful to have.On Sat, May 10, 2008 at 3:17 PM, marius schebella
marius.schebella@gmail.com wrote: I tried this with pd extended 0.40-3, but did not get a startup
pref window at all and the path window was very small and empty.
(os x, 10.5.) marius.David Golightly wrote: And, here's a version with an updated Startup dialog. Simply
copy this to bin/pd.tk http://pd.tk (make a backup first!) to
try it out.On Sat, May 10, 2008 at 12:48 PM, David Golightly
<davigoli@gmail.com mailto:davigoli@gmail.com> wrote:On Sat, May 10, 2008 at 12:36 PM, Steffen Juul <stffn@dibidut.dk mailto:stffn@dibidut.dk> wrote:
On 10/05/2008, at 19.48, David Golightly wrote: Ok, after a busy week this is what I've been able to
come up with for the Path dialog.
Looking really good! The browse functionality is a fair
idiom in a such GUI as oppose to entering text, i think.
Thanks! I've often been kind of frustrated that I have to
type in the full directory name rather than simply browsing to it.
For the keyboard-inclined, however, text entry should still be possible."One" comment: I have a beef with the functionality of the buttons. Not the Cancel one. The others. 'Apply' does
something. 'Ok' does 'apply' plus 'cancel'. 'Save...' does 'Apply' plus saves. But it says the list is only gonna work from next
time Pd is lunched, why i don't get the 'Apply' and 'Ok'. 'Ok'
should do save and cancel. Thats all one wants, anit?I agree. I've preserved the pre-existing functionality for those buttons from before, but do we really need both "Save" and
"Apply"? Currently, "Save" also "saves preferences" (verbose &
use standard extensions). I think that should also happen when you click "Apply", so we can do away with the "Save" button, and also make sure that the message about needing to restart PD pops up when
you click "OK" or "Apply".I'm thinking about adapting this UI for the Startup
dialog - shouldn't be hard to do - except instead of choosing directories you want to enter arbitrary text.
I haven't checked your code but i suppose most "proc's"
can be reused?
I've set up some various key bindings so I want to
make sure it seems usable for everyone.
Nice. What are they?
Default key bindings for the listbox widget give you "up" and
"down" keys to select, I've added "Delete" to delete the current
selection, and "Return" to open the browse dialog (same as pressing "Edit").So far I've only tested this on Mac OS X OS X.4 here.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
<u_main.tk> _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
http://at.or.at/hans/
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
This is all great feedback, guys - keep it coming. Keep in mind I'm still learning Tcl/Tk, so some of these ideas, while excellent, are a little beyond my technical grasp at this point and may be improvements that we make incrementally over time. Also, I have a limited amount of my time to budget for this kind of work - I also work full-time and make music too - so I think prioritizing some of these ideas into subsequent releases is probably the best way to get them into Pd.
Some points:
each list item, and also tried to look for a way to edit list items in place, but couldn't figure out how to make that work in Tcl/Tk, so I settled on the popup box. The bug you saw with that not working, Hans, I've since fixed.
wasn't wholly satisfied with it and found that it introduced more problems than it solved. For example, what if you select multiple Paths and then click "Edit"? What is that supposed to do?
really cool, but it seems like it's a lot more work to do that, since Tk's default listbox widget only wants to deal with arrays of strings.
removed everywhere and folded into "Apply" ("OK" does "Apply" + "Cancel"). I think what it originally was supposed to do was give you an opportunity to test settings without saving them, but for that, I think it's best to have something like a "Revert settings" button instead. Also, I think this functionality is so marginal that we can remove it altogether.
MIDI) should all be different tabs in the same dialog. However, that seems like a feature that can be added at a later time; for now, I'd like to focus on finishing up the improvements that we already have, so we can try & get them into Vanilla, then perhaps go through the menu system at some point and re-evaluate how that's structured, maybe do some further improvements with some of the other menus too. Plus I'm itching to get on to improving the UI widget settings boxes.
having everything keyboard-accessible, which includes stuff like tab order, so I think it's probably best to keep around the buttons for list editing commands for now, although we can certainly investigate ways to reduce the size they take up on the screen.
I'm going to spend some spare time over the next few days working out some of the remaining kinks, then I'll re-post the patch for review before submitting it to the tracker. Thanks again to everyone who has taken time to look at the proposed changes!
If anyone has specific ideas to improve the layout of these dialogs, it would be amazing to see some sort of low-fi sketch of what you have in mind, just black outlines with text on a white background would be fine. Also, if anyone has some more advanced Tk wizardry they'd like to impart, or could point me to some better resources, I'd be most grateful - Google has been a lot less helpful than I've experienced with other languages/platforms.
Thanks, David
On Sun, May 11, 2008 at 7:57 AM, Hans-Christoph Steiner hans@eds.org wrote:
Oops, one other detail with the "encode" proc. While namespaces are probably the current way to handle function names, they are not used for any other functions in u_main.tk So for this function, I think it should be called something like pdtk_encodelist without the namespace, then grouped with pdtk_encode. Something like this:
proc pdtk_encodelist {listdata} { set outlist {} foreach this_path $listdata { if {0==[string match "" $this_path]} { lappend outlist [pdtk_encodedialog $this_path] } } return $outlist }
Then perhaps namespaces can be introduced later as a more systematic approach.
.hc
On May 11, 2008, at 3:15 PM, Hans-Christoph Steiner wrote:
I just thought of one other thing: I think it would be very useful if Path, Startup, Audio Settings, and MIDI settings where all tabs in one panel, instead of four separate panels.
.hc
On May 11, 2008, at 1:29 PM, Hans-Christoph Steiner wrote:
Wow, what an improvement! I like it a lot. I have some comments:
- minor thing, maybe there could be less space on the sides, so the panel
would be narrower?
- about the Apply button, I think it should only show up on platforms
where it is a common thing. On Mac OS X, it should just be OK and Cancel. On Windows, there should be Apply. I think GNOME has moved away from Apply, but I don't know anything about KDE.
- some separation of the buttons on the right column would make things
clearer, I think. Like maybe Up/Down on the right side, and then Add..., Edit..., and Delete on the bottom? Or maybe just changing Up and Down to arrows?
- the startup thing is trickier. I think that the textfield for entering
values should be embedded into the panel instead of a popup. Also, it doesn't seem to work for me (I am using 0.41-4 vanilla). I can't add items to the list.
I think once this is worked out, the best plan would be to submit a patch to the tracker and assign it to Miller. Then I'll also include it in Pd-extended.
.hc
On May 11, 2008, at 2:25 AM, David Golightly wrote:
Just verified against my own install of Pd-extended-0.40.3 on OS X 10.4 - enough differences exist otherwise in the nightlies that this version of the file will only work with 0.41.4.
Attached is an updated (slightly bugfixed) version.
So... what's the procedure for checking in to svn :)?
-David
On Sat, May 10, 2008 at 4:24 PM, David Golightly davigoli@gmail.com wrote:
Well scratch that then, perhaps that will only work when you're building pd on your own machine. If you launch Pd from Terminal, you might see error output in that terminal window - that would be helpful to have.
On Sat, May 10, 2008 at 3:17 PM, marius schebella < marius.schebella@gmail.com> wrote:
I tried this with pd extended 0.40-3, but did not get a startup pref window at all and the path window was very small and empty. (os x, 10.5.) marius.
David Golightly wrote:
And, here's a version with an updated Startup dialog. Simply copy this to bin/pd.tk http://pd.tk (make a backup first!) to try it out.
On Sat, May 10, 2008 at 12:48 PM, David Golightly < davigoli@gmail.com mailto:davigoli@gmail.com> wrote:
On Sat, May 10, 2008 at 12:36 PM, Steffen Juul <stffn@dibidut.dk mailto:stffn@dibidut.dk> wrote:
On 10/05/2008, at 19.48, David Golightly wrote: Ok, after a busy week this is what I've been able to come
up with for the Path dialog.
Looking really good! The browse functionality is a fair idiom
in a such GUI as oppose to entering text, i think.
Thanks! I've often been kind of frustrated that I have to type in the full directory name rather than simply browsing to it. For the keyboard-inclined, however, text entry should still be possible.
"One" comment: I have a beef with the functionality of the buttons. Not the Cancel one. The others. 'Apply' does
something. 'Ok' does 'apply' plus 'cancel'. 'Save...' does 'Apply' plus saves. But it says the list is only gonna work from next time Pd is lunched, why i don't get the 'Apply' and 'Ok'. 'Ok' should do save and cancel. Thats all one wants, anit?
I agree. I've preserved the pre-existing functionality for those buttons from before, but do we really need both "Save" and "Apply"? Currently, "Save" also "saves preferences" (verbose & use standard extensions). I think that should also happen when you click "Apply", so we can do away with the "Save" button, and also make sure that the message about needing to restart PD pops up when you click "OK" or "Apply".
I'm thinking about adapting this UI for the Startup
dialog - shouldn't be hard to do - except instead of choosing directories you want to enter arbitrary text.
I haven't checked your code but i suppose most "proc's" can
be reused?
I've set up some various key bindings so I want to make
sure it seems usable for everyone.
Nice. What are they?
Default key bindings for the listbox widget give you "up" and "down" keys to select, I've added "Delete" to delete the current selection, and "Return" to open the browse dialog (same as pressing "Edit").
So far I've only tested this on Mac OS X OS X.4 here.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
<u_main.tk>_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
http://at.or.at/hans/
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
David Golightly wrote:
Keep in mind I'm still learning Tcl/Tk, so some of these ideas, while excellent, are a little beyond my technical grasp at this point and may be improvements that we make incrementally over time. Also, I have a limited amount of my time to budget for this kind of work
david, if you spend 1 hour on coding and one hour on documenting of how to get to that step, (instead of 2 hours coding), then the chance that more people will be able to jump in is bigger. tcl/tk is new to most people. being able to concentrate on design and ui aspects would make life easier. the hard part is to get started. marius.
On 14/05/2008, at 0.16, marius schebella wrote:
David Golightly wrote:
Keep in mind I'm still learning Tcl/Tk, so some of these ideas, while excellent, are a little beyond my technical grasp at this point and may be
improvements that we make incrementally over time. Also, I have a limited
amount of my time to budget for this kind of workdavid, if you spend 1 hour on coding and one hour on documenting of how to
get to that step, (instead of 2 hours coding), then the chance that more people will be able to jump in is bigger. tcl/tk is new to most
people. being able to concentrate on design and ui aspects would make life easier. the hard part is to get started.
Especially since the names in Tk are to my experience somewhat
different to what one put in the search bar, ie. of my/your(?)/normal
vocabulary.
Example: tabs ~= notebook. See http://wiki.tcl.tk/2298
Ok, with the path/startup dialogs, this is about the feature set I'd like to end up with for now. Please, everyone, review it for usability & obvious bugs, and if it looks good I'll submit it as a patch.
Thanks,
David
On Tue, May 13, 2008 at 11:53 PM, Steffen Juul stffn@dibidut.dk wrote:
On 14/05/2008, at 0.16, marius schebella wrote:
David Golightly wrote:
Keep in mind I'm still learning Tcl/Tk, so some of these ideas, while excellent, are a little beyond my technical grasp at this point and may be improvements that we make incrementally over time. Also, I have a limited amount of my time to budget for this kind of work
david, if you spend 1 hour on coding and one hour on documenting of how to get to that step, (instead of 2 hours coding), then the chance that more people will be able to jump in is bigger. tcl/tk is new to most people. being able to concentrate on design and ui aspects would make life easier. the hard part is to get started.
Especially since the names in Tk are to my experience somewhat different to what one put in the search bar, ie. of my/your(?)/normal vocabulary.
Example: tabs ~= notebook. See http://wiki.tcl.tk/2298
A note on the latest changes: I removed all the list manipulation buttons and added the following bindings:
"Enter" to change the selected item.
I kept around the "New..." button, since it may not be immediately obvious to newbies how to add new things to the list.
I also removed the "Save all settings" button and folded its action in to the "Apply" command (and, by extension, the OK command). I played around with trying to get an in-place editable listbox control for the Startup dialog, but to no avail - it's apparently no trivial task in Tcl/Tk. Perhaps for a future revision. However, the popup dialog functions effective the same, as "Enter" will submit your edit and "Esc" will cancel; once you get used to it it shouldn't be much different.
I'm also now centering the dialog windows on the screen. I'd like to do this also (especially) for the "Properties" dialogs that are used to edit GUI controls. Tk like to try and "cascade" new dialogs as they appear; this is too clever by half, and really annoying once if you do a lot of editing. But I've only tested this centering behavior on my own Macbook 15" screen, so it would be great if others could verify it's still usable on other screen sizes.
One other thing: these dialogs can now be resized, but they appear at their minimum size, so you can't shrink them any further (you can only expand them).
Please let me know what you think and as always let me know if you run into any trouble!
Thanks, David
On Sat, May 17, 2008 at 6:06 PM, David Golightly davigoli@gmail.com wrote:
Ok, with the path/startup dialogs, this is about the feature set I'd like to end up with for now. Please, everyone, review it for usability & obvious bugs, and if it looks good I'll submit it as a patch.
Thanks,
David
On Tue, May 13, 2008 at 11:53 PM, Steffen Juul stffn@dibidut.dk wrote:
On 14/05/2008, at 0.16, marius schebella wrote:
David Golightly wrote:
Keep in mind I'm still learning Tcl/Tk, so some of these ideas, while excellent, are a little beyond my technical grasp at this point and may be improvements that we make incrementally over time. Also, I have a limited amount of my time to budget for this kind of work
david, if you spend 1 hour on coding and one hour on documenting of how to get to that step, (instead of 2 hours coding), then the chance that more people will be able to jump in is bigger. tcl/tk is new to most people. being able to concentrate on design and ui aspects would make life easier. the hard part is to get started.
Especially since the names in Tk are to my experience somewhat different to what one put in the search bar, ie. of my/your(?)/normal vocabulary.
Example: tabs ~= notebook. See http://wiki.tcl.tk/2298
Very nice! The mouse/keyboard interactive is well done, I only worry
that the buttons are now too sparse. I think delete and edit buttons
would still be useful, maybe people don't use keyboard shortcuts at all.
Also, on Mac OS X, Delete is not commonly used, so it would be good
to also have BackSpace work for deleting. Or maybe Cmd-BackSpace
since that is what is used for deleting in the Finder.
.hc
On May 18, 2008, at 9:46 AM, David Golightly wrote:
A note on the latest changes: I removed all the list manipulation
buttons and added the following bindings:
- The list items can be re-ordered by drag-and-drop.
- Clicking on a list item allows you to edit it.
- Clicking anywhere else in the listbox allows you to add a new
list item.
- You can also traverse the list using up and down arrow keys, then
press "Enter" to change the selected item.
- Press "Delete" to delete the currently selected list item.
I kept around the "New..." button, since it may not be immediately
obvious to newbies how to add new things to the list.I also removed the "Save all settings" button and folded its action
in to the "Apply" command (and, by extension, the OK command). I
played around with trying to get an in-place editable listbox
control for the Startup dialog, but to no avail - it's apparently
no trivial task in Tcl/Tk. Perhaps for a future revision.
However, the popup dialog functions effective the same, as "Enter"
will submit your edit and "Esc" will cancel; once you get used to
it it shouldn't be much different.I'm also now centering the dialog windows on the screen. I'd like
to do this also (especially) for the "Properties" dialogs that are
used to edit GUI controls. Tk like to try and "cascade" new
dialogs as they appear; this is too clever by half, and really
annoying once if you do a lot of editing. But I've only tested
this centering behavior on my own Macbook 15" screen, so it would
be great if others could verify it's still usable on other screen
sizes.One other thing: these dialogs can now be resized, but they appear
at their minimum size, so you can't shrink them any further (you
can only expand them).Please let me know what you think and as always let me know if you
run into any trouble!Thanks, David
On Sat, May 17, 2008 at 6:06 PM, David Golightly
davigoli@gmail.com wrote: Ok, with the path/startup dialogs, this is about the feature set
I'd like to end up with for now. Please, everyone, review it for
usability & obvious bugs, and if it looks good I'll submit it as a
patch.Thanks,
David
On Tue, May 13, 2008 at 11:53 PM, Steffen Juul stffn@dibidut.dk
wrote:On 14/05/2008, at 0.16, marius schebella wrote:
David Golightly wrote: Keep in mind I'm still learning Tcl/Tk, so some of these ideas, while excellent, are a little beyond my technical grasp at this point and may be improvements that we make incrementally over time. Also, I have a limited
amount of my time to budget for this kind of workdavid, if you spend 1 hour on coding and one hour on documenting of how to
get to that step, (instead of 2 hours coding), then the chance that more people will be able to jump in is bigger. tcl/tk is new to most
people. being able to concentrate on design and ui aspects would make life easier. the hard part is to get started.Especially since the names in Tk are to my experience somewhat
different to what one put in the search bar, ie. of my/your(?)/ normal vocabulary.Example: tabs ~= notebook. See http://wiki.tcl.tk/2298
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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
As requested, I've put back the "Edit" and "Delete" buttons and added BackSpace as a Delete event for Mac OS X. I couldn't get Cmd-BackSpace to fire effectively, but perhaps someone knows something I don't about getting that to work.
On Sun, May 18, 2008 at 7:15 AM, Hans-Christoph Steiner hans@eds.org wrote:
Very nice! The mouse/keyboard interactive is well done, I only worry that the buttons are now too sparse. I think delete and edit buttons would still be useful, maybe people don't use keyboard shortcuts at all.
Also, on Mac OS X, Delete is not commonly used, so it would be good to also have BackSpace work for deleting. Or maybe Cmd-BackSpace since that is what is used for deleting in the Finder.
.hc
On May 18, 2008, at 9:46 AM, David Golightly wrote:
A note on the latest changes: I removed all the list manipulation buttons and added the following bindings:
- The list items can be re-ordered by drag-and-drop.
- Clicking on a list item allows you to edit it.
- Clicking anywhere else in the listbox allows you to add a new list item.
- You can also traverse the list using up and down arrow keys, then press
"Enter" to change the selected item.
- Press "Delete" to delete the currently selected list item.
I kept around the "New..." button, since it may not be immediately obvious to newbies how to add new things to the list.
I also removed the "Save all settings" button and folded its action in to the "Apply" command (and, by extension, the OK command). I played around with trying to get an in-place editable listbox control for the Startup dialog, but to no avail - it's apparently no trivial task in Tcl/Tk. Perhaps for a future revision. However, the popup dialog functions effective the same, as "Enter" will submit your edit and "Esc" will cancel; once you get used to it it shouldn't be much different.
I'm also now centering the dialog windows on the screen. I'd like to do this also (especially) for the "Properties" dialogs that are used to edit GUI controls. Tk like to try and "cascade" new dialogs as they appear; this is too clever by half, and really annoying once if you do a lot of editing. But I've only tested this centering behavior on my own Macbook 15" screen, so it would be great if others could verify it's still usable on other screen sizes.
One other thing: these dialogs can now be resized, but they appear at their minimum size, so you can't shrink them any further (you can only expand them).
Please let me know what you think and as always let me know if you run into any trouble!
Thanks, David
On Sat, May 17, 2008 at 6:06 PM, David Golightly davigoli@gmail.com wrote:
Ok, with the path/startup dialogs, this is about the feature set I'd like to end up with for now. Please, everyone, review it for usability & obvious bugs, and if it looks good I'll submit it as a patch.
Thanks,
David
On Tue, May 13, 2008 at 11:53 PM, Steffen Juul stffn@dibidut.dk wrote:
On 14/05/2008, at 0.16, marius schebella wrote:
David Golightly wrote:
Keep in mind I'm still learning Tcl/Tk, so some of these ideas, while excellent, are a little beyond my technical grasp at this point and may be improvements that we make incrementally over time. Also, I have a limited amount of my time to budget for this kind of work
david, if you spend 1 hour on coding and one hour on documenting of how to get to that step, (instead of 2 hours coding), then the chance that more people will be able to jump in is bigger. tcl/tk is new to most people. being able to concentrate on design and ui aspects would make life easier. the hard part is to get started.
Especially since the names in Tk are to my experience somewhat different to what one put in the search bar, ie. of my/your(?)/normal vocabulary.
Example: tabs ~= notebook. See http://wiki.tcl.tk/2298
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
Looks good to me. This is already a massive improvement over what is
there. I don't know if you are sick of working on it, but I thought
I'd throw a couple of minor ideas:
stretch with the resizing window. Then you could see more of those
flags.
center of the screen? I think you can get that info using [winfo
rootx .] and [winfo rooty .]
.hc
On May 18, 2008, at 7:26 PM, David Golightly wrote:
As requested, I've put back the "Edit" and "Delete" buttons and
added BackSpace as a Delete event for Mac OS X. I couldn't get Cmd- BackSpace to fire effectively, but perhaps someone knows something
I don't about getting that to work.On Sun, May 18, 2008 at 7:15 AM, Hans-Christoph Steiner
hans@eds.org wrote:Very nice! The mouse/keyboard interactive is well done, I only
worry that the buttons are now too sparse. I think delete and edit
buttons would still be useful, maybe people don't use keyboard
shortcuts at all.Also, on Mac OS X, Delete is not commonly used, so it would be good
to also have BackSpace work for deleting. Or maybe Cmd-BackSpace
since that is what is used for deleting in the Finder..hc
On May 18, 2008, at 9:46 AM, David Golightly wrote:
A note on the latest changes: I removed all the list manipulation
buttons and added the following bindings:
- The list items can be re-ordered by drag-and-drop.
- Clicking on a list item allows you to edit it.
- Clicking anywhere else in the listbox allows you to add a new
list item.
- You can also traverse the list using up and down arrow keys,
then press "Enter" to change the selected item.
- Press "Delete" to delete the currently selected list item.
I kept around the "New..." button, since it may not be immediately
obvious to newbies how to add new things to the list.I also removed the "Save all settings" button and folded its
action in to the "Apply" command (and, by extension, the OK
command). I played around with trying to get an in-place editable
listbox control for the Startup dialog, but to no avail - it's
apparently no trivial task in Tcl/Tk. Perhaps for a future
revision. However, the popup dialog functions effective the same,
as "Enter" will submit your edit and "Esc" will cancel; once you
get used to it it shouldn't be much different.I'm also now centering the dialog windows on the screen. I'd like
to do this also (especially) for the "Properties" dialogs that are
used to edit GUI controls. Tk like to try and "cascade" new
dialogs as they appear; this is too clever by half, and really
annoying once if you do a lot of editing. But I've only tested
this centering behavior on my own Macbook 15" screen, so it would
be great if others could verify it's still usable on other screen
sizes.One other thing: these dialogs can now be resized, but they appear
at their minimum size, so you can't shrink them any further (you
can only expand them).Please let me know what you think and as always let me know if you
run into any trouble!Thanks, David
On Sat, May 17, 2008 at 6:06 PM, David Golightly
davigoli@gmail.com wrote: Ok, with the path/startup dialogs, this is about the feature set
I'd like to end up with for now. Please, everyone, review it for
usability & obvious bugs, and if it looks good I'll submit it as a
patch.Thanks,
David
On Tue, May 13, 2008 at 11:53 PM, Steffen Juul stffn@dibidut.dk
wrote:On 14/05/2008, at 0.16, marius schebella wrote:
David Golightly wrote: Keep in mind I'm still learning Tcl/Tk, so some of these ideas, while excellent, are a little beyond my technical grasp at this point and may be
improvements that we make incrementally over time. Also, I have a limited
amount of my time to budget for this kind of workdavid, if you spend 1 hour on coding and one hour on documenting of how
to get to that step, (instead of 2 hours coding), then the chance that more people will be able to jump in is bigger. tcl/tk is new to most
people. being able to concentrate on design and ui aspects would make life easier. the hard part is to get started.Especially since the names in Tk are to my experience somewhat
different to what one put in the search bar, ie. of my/your(?)/ normal vocabulary.Example: tabs ~= notebook. See http://wiki.tcl.tk/2298
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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<u_main.tk>
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
Hans-Christoph Steiner wrote:
- it would be useful if the "startup flags" entry widget would stretch
with the resizing window. Then you could see more of those flags.
i admit that i haven't looked at it, but what you describe reminds me awfully of Micro$oft's VisualStudio 6, which would give you a popup with a 20 character wide text-field to add include-paths,... think of all the fun i had when adding my 5th include-path in this field (i even had a hard time remembering whether i already had added a certain path as i would have to navigate within this field) from my pov, it was one of the major improvements in newer releases of this software to add expandable multi-line fields for this.
so yes, i think this is a good proposal
fgmasdr IOhannes
Oops, found a little bug: double-clicking on an empty cell through
up an error dialog.
Also, an idea: if you just draw that popup entry box just below the
listbox with the OK button, add a Cancel button, then use "pack
forget" when the user hits OK or Cancel. Just a thought. That mini-
popup window is the only thing about these panels that is weird, I
guess that why I still am thinking about how to ditch it.
.hc
On May 19, 2008, at 7:09 PM, Hans-Christoph Steiner wrote:
Looks good to me. This is already a massive improvement over what
is there. I don't know if you are sick of working on it, but I
thought I'd throw a couple of minor ideas:
- it would be useful if the "startup flags" entry widget would
stretch with the resizing window. Then you could see more of those
flags.
- perhaps the windows should open above the Pd window instead of
the center of the screen? I think you can get that info using
[winfo rootx .] and [winfo rooty .].hc
On May 18, 2008, at 7:26 PM, David Golightly wrote:
As requested, I've put back the "Edit" and "Delete" buttons and
added BackSpace as a Delete event for Mac OS X. I couldn't get
Cmd-BackSpace to fire effectively, but perhaps someone knows
something I don't about getting that to work.On Sun, May 18, 2008 at 7:15 AM, Hans-Christoph Steiner
hans@eds.org wrote:Very nice! The mouse/keyboard interactive is well done, I only
worry that the buttons are now too sparse. I think delete and
edit buttons would still be useful, maybe people don't use
keyboard shortcuts at all.Also, on Mac OS X, Delete is not commonly used, so it would be
good to also have BackSpace work for deleting. Or maybe Cmd- BackSpace since that is what is used for deleting in the Finder..hc
On May 18, 2008, at 9:46 AM, David Golightly wrote:
A note on the latest changes: I removed all the list manipulation
buttons and added the following bindings:
- The list items can be re-ordered by drag-and-drop.
- Clicking on a list item allows you to edit it.
- Clicking anywhere else in the listbox allows you to add a new
list item.
- You can also traverse the list using up and down arrow keys,
then press "Enter" to change the selected item.
- Press "Delete" to delete the currently selected list item.
I kept around the "New..." button, since it may not be
immediately obvious to newbies how to add new things to the list.I also removed the "Save all settings" button and folded its
action in to the "Apply" command (and, by extension, the OK
command). I played around with trying to get an in-place
editable listbox control for the Startup dialog, but to no avail
- it's apparently no trivial task in Tcl/Tk. Perhaps for a
future revision. However, the popup dialog functions effective
the same, as "Enter" will submit your edit and "Esc" will cancel;
once you get used to it it shouldn't be much different.I'm also now centering the dialog windows on the screen. I'd
like to do this also (especially) for the "Properties" dialogs
that are used to edit GUI controls. Tk like to try and "cascade"
new dialogs as they appear; this is too clever by half, and
really annoying once if you do a lot of editing. But I've only
tested this centering behavior on my own Macbook 15" screen, so
it would be great if others could verify it's still usable on
other screen sizes.One other thing: these dialogs can now be resized, but they
appear at their minimum size, so you can't shrink them any
further (you can only expand them).Please let me know what you think and as always let me know if
you run into any trouble!Thanks, David
On Sat, May 17, 2008 at 6:06 PM, David Golightly
davigoli@gmail.com wrote: Ok, with the path/startup dialogs, this is about the feature set
I'd like to end up with for now. Please, everyone, review it for
usability & obvious bugs, and if it looks good I'll submit it as
a patch.Thanks,
David
On Tue, May 13, 2008 at 11:53 PM, Steffen Juul stffn@dibidut.dk
wrote:On 14/05/2008, at 0.16, marius schebella wrote:
David Golightly wrote: Keep in mind I'm still learning Tcl/Tk, so some of these ideas, while excellent,
are a little beyond my technical grasp at this point and may be
improvements that we make incrementally over time. Also, I have a limited
amount of my time to budget for this kind of workdavid, if you spend 1 hour on coding and one hour on documenting of how
to get to that step, (instead of 2 hours coding), then the chance that more people will be able to jump in is bigger. tcl/tk is new to most
people. being able to concentrate on design and ui aspects would make life easier. the hard part is to get started.Especially since the names in Tk are to my experience somewhat
different to what one put in the search bar, ie. of my/your(?)/ normal vocabulary.Example: tabs ~= notebook. See http://wiki.tcl.tk/2298
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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<u_main.tk>
"[W]e have invented the technology to eliminate scarcity, but we
are deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
Here's a revised copy with a few minor changes (the "startup flags" field now expands to fill the window, you can resize the startup command popup arbitrarily).
I'm wondering about the protocol of introducing dependencies in PD. It seems that BWidget gives us a widget that we can use for the listbox ( http://tcllib.sourceforge.net/BWman/ListBox.html), however, it's perhaps not distributed with older distributions of Tcl/Tk. BWidget is distributed with Tcllib, which is apparently a default library packaged with most installs of Tcl, http://wiki.tcl.tk/12099 says that it comes by default with the ActiveState distro, with .deb and .rpm packages, and it was installed by default on my Mac OS X 10.4 distribution. But it's not guaranteed to be installed with ALL distributions of Tcl/Tk - I just have no idea exactly how many users might lack it.
Failing that, the popup should behave exactly as inline editing does, even though it looks a little strange. You can still use the keyboard to navigate: down, down, enter, type, enter, up, enter, esc... Just think of it as inline listbox editing with extra window chrome :)
On Mon, May 19, 2008 at 11:37 AM, Hans-Christoph Steiner hans@eds.org wrote:
Oops, found a little bug: double-clicking on an empty cell through up an error dialog.
Also, an idea: if you just draw that popup entry box just below the listbox with the OK button, add a Cancel button, then use "pack forget" when the user hits OK or Cancel. Just a thought. That mini-popup window is the only thing about these panels that is weird, I guess that why I still am thinking about how to ditch it.
.hc
On May 19, 2008, at 7:09 PM, Hans-Christoph Steiner wrote:
Looks good to me. This is already a massive improvement over what is there. I don't know if you are sick of working on it, but I thought I'd throw a couple of minor ideas:
- it would be useful if the "startup flags" entry widget would stretch with
the resizing window. Then you could see more of those flags.
- perhaps the windows should open above the Pd window instead of the center
of the screen? I think you can get that info using [winfo rootx .] and [winfo rooty .]
.hc
On May 18, 2008, at 7:26 PM, David Golightly wrote:
As requested, I've put back the "Edit" and "Delete" buttons and added BackSpace as a Delete event for Mac OS X. I couldn't get Cmd-BackSpace to fire effectively, but perhaps someone knows something I don't about getting that to work.
On Sun, May 18, 2008 at 7:15 AM, Hans-Christoph Steiner hans@eds.org wrote:
Very nice! The mouse/keyboard interactive is well done, I only worry that the buttons are now too sparse. I think delete and edit buttons would still be useful, maybe people don't use keyboard shortcuts at all.
Also, on Mac OS X, Delete is not commonly used, so it would be good to also have BackSpace work for deleting. Or maybe Cmd-BackSpace since that is what is used for deleting in the Finder.
.hc
On May 18, 2008, at 9:46 AM, David Golightly wrote:
A note on the latest changes: I removed all the list manipulation buttons and added the following bindings:
- The list items can be re-ordered by drag-and-drop.
- Clicking on a list item allows you to edit it.
- Clicking anywhere else in the listbox allows you to add a new list item.
- You can also traverse the list using up and down arrow keys, then press
"Enter" to change the selected item.
- Press "Delete" to delete the currently selected list item.
I kept around the "New..." button, since it may not be immediately obvious to newbies how to add new things to the list.
I also removed the "Save all settings" button and folded its action in to the "Apply" command (and, by extension, the OK command). I played around with trying to get an in-place editable listbox control for the Startup dialog, but to no avail - it's apparently no trivial task in Tcl/Tk. Perhaps for a future revision. However, the popup dialog functions effective the same, as "Enter" will submit your edit and "Esc" will cancel; once you get used to it it shouldn't be much different.
I'm also now centering the dialog windows on the screen. I'd like to do this also (especially) for the "Properties" dialogs that are used to edit GUI controls. Tk like to try and "cascade" new dialogs as they appear; this is too clever by half, and really annoying once if you do a lot of editing. But I've only tested this centering behavior on my own Macbook 15" screen, so it would be great if others could verify it's still usable on other screen sizes.
One other thing: these dialogs can now be resized, but they appear at their minimum size, so you can't shrink them any further (you can only expand them).
Please let me know what you think and as always let me know if you run into any trouble!
Thanks, David
On Sat, May 17, 2008 at 6:06 PM, David Golightly davigoli@gmail.com wrote:
Ok, with the path/startup dialogs, this is about the feature set I'd like to end up with for now. Please, everyone, review it for usability & obvious bugs, and if it looks good I'll submit it as a patch.
Thanks,
David
On Tue, May 13, 2008 at 11:53 PM, Steffen Juul stffn@dibidut.dk wrote:
On 14/05/2008, at 0.16, marius schebella wrote:
David Golightly wrote:
Keep in mind I'm still learning Tcl/Tk, so some of these ideas, while excellent, are a little beyond my technical grasp at this point and may be improvements that we make incrementally over time. Also, I have a limited amount of my time to budget for this kind of work
david, if you spend 1 hour on coding and one hour on documenting of how to get to that step, (instead of 2 hours coding), then the chance that more people will be able to jump in is bigger. tcl/tk is new to most people. being able to concentrate on design and ui aspects would make life easier. the hard part is to get started.
Especially since the names in Tk are to my experience somewhat different to what one put in the search bar, ie. of my/your(?)/normal vocabulary.
Example: tabs ~= notebook. See http://wiki.tcl.tk/2298
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
<u_main.tk>
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PS I was unable to reproduce that issue where you saw an error message from clicking on an empty cell. For me, clicking on empty cells just brought up the "Add new item" dialog. Could this be a difference of platform/TclTk version? I'm running 8.5 on OS X 10.4. I'd also like to get the specific error message if you can get it.
Thanks,
David
On Mon, May 19, 2008 at 10:07 PM, David Golightly davigoli@gmail.com wrote:
Here's a revised copy with a few minor changes (the "startup flags" field now expands to fill the window, you can resize the startup command popup arbitrarily).
I'm wondering about the protocol of introducing dependencies in PD. It seems that BWidget gives us a widget that we can use for the listbox ( http://tcllib.sourceforge.net/BWman/ListBox.html), however, it's perhaps not distributed with older distributions of Tcl/Tk. BWidget is distributed with Tcllib, which is apparently a default library packaged with most installs of Tcl, http://wiki.tcl.tk/12099 says that it comes by default with the ActiveState distro, with .deb and .rpm packages, and it was installed by default on my Mac OS X 10.4 distribution. But it's not guaranteed to be installed with ALL distributions of Tcl/Tk - I just have no idea exactly how many users might lack it.
Failing that, the popup should behave exactly as inline editing does, even though it looks a little strange. You can still use the keyboard to navigate: down, down, enter, type, enter, up, enter, esc... Just think of it as inline listbox editing with extra window chrome :)
On Mon, May 19, 2008 at 11:37 AM, Hans-Christoph Steiner hans@eds.org wrote:
Oops, found a little bug: double-clicking on an empty cell through up an error dialog.
Also, an idea: if you just draw that popup entry box just below the listbox with the OK button, add a Cancel button, then use "pack forget" when the user hits OK or Cancel. Just a thought. That mini-popup window is the only thing about these panels that is weird, I guess that why I still am thinking about how to ditch it.
.hc
On May 19, 2008, at 7:09 PM, Hans-Christoph Steiner wrote:
Looks good to me. This is already a massive improvement over what is there. I don't know if you are sick of working on it, but I thought I'd throw a couple of minor ideas:
- it would be useful if the "startup flags" entry widget would stretch
with the resizing window. Then you could see more of those flags.
- perhaps the windows should open above the Pd window instead of the
center of the screen? I think you can get that info using [winfo rootx .] and [winfo rooty .]
.hc
On May 18, 2008, at 7:26 PM, David Golightly wrote:
As requested, I've put back the "Edit" and "Delete" buttons and added BackSpace as a Delete event for Mac OS X. I couldn't get Cmd-BackSpace to fire effectively, but perhaps someone knows something I don't about getting that to work.
On Sun, May 18, 2008 at 7:15 AM, Hans-Christoph Steiner hans@eds.org wrote:
Very nice! The mouse/keyboard interactive is well done, I only worry that the buttons are now too sparse. I think delete and edit buttons would still be useful, maybe people don't use keyboard shortcuts at all.
Also, on Mac OS X, Delete is not commonly used, so it would be good to also have BackSpace work for deleting. Or maybe Cmd-BackSpace since that is what is used for deleting in the Finder.
.hc
On May 18, 2008, at 9:46 AM, David Golightly wrote:
A note on the latest changes: I removed all the list manipulation buttons and added the following bindings:
- The list items can be re-ordered by drag-and-drop.
- Clicking on a list item allows you to edit it.
- Clicking anywhere else in the listbox allows you to add a new list
item.
- You can also traverse the list using up and down arrow keys, then press
"Enter" to change the selected item.
- Press "Delete" to delete the currently selected list item.
I kept around the "New..." button, since it may not be immediately obvious to newbies how to add new things to the list.
I also removed the "Save all settings" button and folded its action in to the "Apply" command (and, by extension, the OK command). I played around with trying to get an in-place editable listbox control for the Startup dialog, but to no avail - it's apparently no trivial task in Tcl/Tk. Perhaps for a future revision. However, the popup dialog functions effective the same, as "Enter" will submit your edit and "Esc" will cancel; once you get used to it it shouldn't be much different.
I'm also now centering the dialog windows on the screen. I'd like to do this also (especially) for the "Properties" dialogs that are used to edit GUI controls. Tk like to try and "cascade" new dialogs as they appear; this is too clever by half, and really annoying once if you do a lot of editing. But I've only tested this centering behavior on my own Macbook 15" screen, so it would be great if others could verify it's still usable on other screen sizes.
One other thing: these dialogs can now be resized, but they appear at their minimum size, so you can't shrink them any further (you can only expand them).
Please let me know what you think and as always let me know if you run into any trouble!
Thanks, David
On Sat, May 17, 2008 at 6:06 PM, David Golightly davigoli@gmail.com wrote:
Ok, with the path/startup dialogs, this is about the feature set I'd like to end up with for now. Please, everyone, review it for usability & obvious bugs, and if it looks good I'll submit it as a patch.
Thanks,
David
On Tue, May 13, 2008 at 11:53 PM, Steffen Juul stffn@dibidut.dk wrote:
On 14/05/2008, at 0.16, marius schebella wrote:
David Golightly wrote:
> Keep in mind I'm > still learning Tcl/Tk, so some of these ideas, while excellent, are a > little beyond my technical grasp at this point and may be > improvements > that we make incrementally over time. Also, I have a limited amount > of > my time to budget for this kind of work >
david, if you spend 1 hour on coding and one hour on documenting of how to get to that step, (instead of 2 hours coding), then the chance that more people will be able to jump in is bigger. tcl/tk is new to most people. being able to concentrate on design and ui aspects would make life easier. the hard part is to get started.
Especially since the names in Tk are to my experience somewhat different to what one put in the search bar, ie. of my/your(?)/normal vocabulary.
Example: tabs ~= notebook. See http://wiki.tcl.tk/2298
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
<u_main.tk>
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Just tried your new version, very nice, I think it's sorted, except
one tiny bug with the resizing of "Add new startup command". I think
you'll want to set a minimum window width, since you can resize it
smaller and make the OK button disappear.
You might look into the Tile/ttk widgets, they are now included in
Tcl/Tk 8.5. I'd like to use 8.5 for Pd-extended 0.41, so they would
be there. For example, a ttk::notebook could be used to host all of
the pref panes into a single window.
About the error, I just dropped your u_main.tk into Pd-vanilla
0.41-4, so that uses the version of Tcl/Tk included with Mac OS X,
8.4.7. I have Tcl/Tk 8.4.18 installed, it might be using that. But
I definitely don't have 8.5 Here's the error:
Startup panel:
can't use empty string as operand of "+"
can't use empty string as operand of "+"
while executing
"expr {$height + $top}"
(procedure "ScrollBox::dbl_click" line 8)
invoked from within
"ScrollBox::dbl_click .gfxstub5b1230 dlg_Startup::edit
dlg_Startup::add 65 45"
(command bound to event)
Path pane:
can't use empty string as operand of "+" can't use empty string as operand of "+" while executing "expr {$height + $top}" (procedure "ScrollBox::dbl_click" line 8) invoked from within "ScrollBox::dbl_click .gfxstub5b1930 dlg_Path::edit dlg_Path::add 81 42" (command bound to event)
.hc
On May 20, 2008, at 8:32 AM, David Golightly wrote:
PS I was unable to reproduce that issue where you saw an error
message from clicking on an empty cell. For me, clicking on empty
cells just brought up the "Add new item" dialog. Could this be a
difference of platform/TclTk version? I'm running 8.5 on OS X
10.4. I'd also like to get the specific error message if you can
get it.Thanks,
David
On Mon, May 19, 2008 at 10:07 PM, David Golightly
davigoli@gmail.com wrote: Here's a revised copy with a few minor changes (the "startup flags"
field now expands to fill the window, you can resize the startup
command popup arbitrarily).I'm wondering about the protocol of introducing dependencies in
PD. It seems that BWidget gives us a widget that we can use for
the listbox (http://tcllib.sourceforge.net/BWman/ListBox.html),
however, it's perhaps not distributed with older distributions of
Tcl/Tk. BWidget is distributed with Tcllib, which is apparently a
default library packaged with most installs of Tcl, http:// wiki.tcl.tk/12099 says that it comes by default with the
ActiveState distro, with .deb and .rpm packages, and it was
installed by default on my Mac OS X 10.4 distribution. But it's
not guaranteed to be installed with ALL distributions of Tcl/Tk - I
just have no idea exactly how many users might lack it.Failing that, the popup should behave exactly as inline editing
does, even though it looks a little strange. You can still use the
keyboard to navigate: down, down, enter, type, enter, up, enter,
esc... Just think of it as inline listbox editing with extra
window chrome :)On Mon, May 19, 2008 at 11:37 AM, Hans-Christoph Steiner
hans@eds.org wrote:Oops, found a little bug: double-clicking on an empty cell through
up an error dialog.Also, an idea: if you just draw that popup entry box just below the
listbox with the OK button, add a Cancel button, then use "pack
forget" when the user hits OK or Cancel. Just a thought. That
mini-popup window is the only thing about these panels that is
weird, I guess that why I still am thinking about how to ditch it..hc
On May 19, 2008, at 7:09 PM, Hans-Christoph Steiner wrote:
Looks good to me. This is already a massive improvement over what
is there. I don't know if you are sick of working on it, but I
thought I'd throw a couple of minor ideas:
- it would be useful if the "startup flags" entry widget would
stretch with the resizing window. Then you could see more of
those flags.
- perhaps the windows should open above the Pd window instead of
the center of the screen? I think you can get that info using
[winfo rootx .] and [winfo rooty .].hc
On May 18, 2008, at 7:26 PM, David Golightly wrote:
As requested, I've put back the "Edit" and "Delete" buttons and
added BackSpace as a Delete event for Mac OS X. I couldn't get
Cmd-BackSpace to fire effectively, but perhaps someone knows
something I don't about getting that to work.On Sun, May 18, 2008 at 7:15 AM, Hans-Christoph Steiner
hans@eds.org wrote:Very nice! The mouse/keyboard interactive is well done, I only
worry that the buttons are now too sparse. I think delete and
edit buttons would still be useful, maybe people don't use
keyboard shortcuts at all.Also, on Mac OS X, Delete is not commonly used, so it would be
good to also have BackSpace work for deleting. Or maybe Cmd- BackSpace since that is what is used for deleting in the Finder..hc
On May 18, 2008, at 9:46 AM, David Golightly wrote:
A note on the latest changes: I removed all the list
manipulation buttons and added the following bindings:
- The list items can be re-ordered by drag-and-drop.
- Clicking on a list item allows you to edit it.
- Clicking anywhere else in the listbox allows you to add a new
list item.
- You can also traverse the list using up and down arrow keys,
then press "Enter" to change the selected item.
- Press "Delete" to delete the currently selected list item.
I kept around the "New..." button, since it may not be
immediately obvious to newbies how to add new things to the list.I also removed the "Save all settings" button and folded its
action in to the "Apply" command (and, by extension, the OK
command). I played around with trying to get an in-place
editable listbox control for the Startup dialog, but to no avail
- it's apparently no trivial task in Tcl/Tk. Perhaps for a
future revision. However, the popup dialog functions effective
the same, as "Enter" will submit your edit and "Esc" will
cancel; once you get used to it it shouldn't be much different.I'm also now centering the dialog windows on the screen. I'd
like to do this also (especially) for the "Properties" dialogs
that are used to edit GUI controls. Tk like to try and
"cascade" new dialogs as they appear; this is too clever by
half, and really annoying once if you do a lot of editing. But
I've only tested this centering behavior on my own Macbook 15"
screen, so it would be great if others could verify it's still
usable on other screen sizes.One other thing: these dialogs can now be resized, but they
appear at their minimum size, so you can't shrink them any
further (you can only expand them).Please let me know what you think and as always let me know if
you run into any trouble!Thanks, David
On Sat, May 17, 2008 at 6:06 PM, David Golightly
davigoli@gmail.com wrote: Ok, with the path/startup dialogs, this is about the feature set
I'd like to end up with for now. Please, everyone, review it
for usability & obvious bugs, and if it looks good I'll submit
it as a patch.Thanks,
David
On Tue, May 13, 2008 at 11:53 PM, Steffen Juul
stffn@dibidut.dk wrote:On 14/05/2008, at 0.16, marius schebella wrote:
David Golightly wrote: Keep in mind I'm still learning Tcl/Tk, so some of these ideas, while excellent,
are a little beyond my technical grasp at this point and may be
improvements that we make incrementally over time. Also, I have a limited
amount of my time to budget for this kind of workdavid, if you spend 1 hour on coding and one hour on documenting of how
to get to that step, (instead of 2 hours coding), then the chance that
more people will be able to jump in is bigger. tcl/tk is new to most
people. being able to concentrate on design and ui aspects would make life easier. the hard part is to get started.Especially since the names in Tk are to my experience somewhat
different to what one put in the search bar, ie. of my/your(?)/ normal vocabulary.Example: tabs ~= notebook. See http://wiki.tcl.tk/2298
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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<u_main.tk>
"[W]e have invented the technology to eliminate scarcity, but we
are deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
"It is convenient to imagine a power beyond us because that means
we don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
Ok, how does this look?
I was still unable to reproduce the clicking bug, but I changed the code to avoid the scenario that your stack trace seems to indicate as the problem, hopefully you won't see it any more.
Turns out I also have Tcl/Tk 8.4.7. Don't know where I got the idea I had 8.5 installed. So it seems either the tcllib or the Tile/ttk widgets might be a good bet for the next revision to these dialogs. One goal here also I think is to eventually provide a good basis for further customization of the Pd environment and UI, which will of course require someone to delve in the C for some of it, although perhaps to the extent that some customization can be done in pure Tcl/Tk, C work can be avoided.
Thanks again,
David
On Tue, May 20, 2008 at 3:00 AM, Hans-Christoph Steiner hans@eds.org wrote:
Just tried your new version, very nice, I think it's sorted, except one tiny bug with the resizing of "Add new startup command". I think you'll want to set a minimum window width, since you can resize it smaller and make the OK button disappear.
You might look into the Tile/ttk widgets, they are now included in Tcl/Tk 8.5. I'd like to use 8.5 for Pd-extended 0.41, so they would be there. For example, a ttk::notebook could be used to host all of the pref panes into a single window.
About the error, I just dropped your u_main.tk into Pd-vanilla 0.41-4, so that uses the version of Tcl/Tk included with Mac OS X, 8.4.7. I have Tcl/Tk 8.4.18 installed, it might be using that. But I definitely don't have 8.5 Here's the error:
Startup panel:
can't use empty string as operand of "+" can't use empty string as operand of "+" while executing "expr {$height + $top}" (procedure "ScrollBox::dbl_click" line 8) invoked from within "ScrollBox::dbl_click .gfxstub5b1230 dlg_Startup::edit dlg_Startup::add 65 45" (command bound to event)
Path pane:
can't use empty string as operand of "+" can't use empty string as operand of "+" while executing "expr {$height + $top}" (procedure "ScrollBox::dbl_click" line 8) invoked from within "ScrollBox::dbl_click .gfxstub5b1930 dlg_Path::edit dlg_Path::add 81 42" (command bound to event)
.hc
On May 20, 2008, at 8:32 AM, David Golightly wrote:
PS I was unable to reproduce that issue where you saw an error message from clicking on an empty cell. For me, clicking on empty cells just brought up the "Add new item" dialog. Could this be a difference of platform/TclTk version? I'm running 8.5 on OS X 10.4. I'd also like to get the specific error message if you can get it.
Thanks,
David
On Mon, May 19, 2008 at 10:07 PM, David Golightly davigoli@gmail.com wrote:
Here's a revised copy with a few minor changes (the "startup flags" field now expands to fill the window, you can resize the startup command popup arbitrarily).
I'm wondering about the protocol of introducing dependencies in PD. It seems that BWidget gives us a widget that we can use for the listbox ( http://tcllib.sourceforge.net/BWman/ListBox.html), however, it's perhaps not distributed with older distributions of Tcl/Tk. BWidget is distributed with Tcllib, which is apparently a default library packaged with most installs of Tcl, http://wiki.tcl.tk/12099 says that it comes by default with the ActiveState distro, with .deb and .rpm packages, and it was installed by default on my Mac OS X 10.4 distribution. But it's not guaranteed to be installed with ALL distributions of Tcl/Tk - I just have no idea exactly how many users might lack it.
Failing that, the popup should behave exactly as inline editing does, even though it looks a little strange. You can still use the keyboard to navigate: down, down, enter, type, enter, up, enter, esc... Just think of it as inline listbox editing with extra window chrome :)
On Mon, May 19, 2008 at 11:37 AM, Hans-Christoph Steiner hans@eds.org wrote:
Oops, found a little bug: double-clicking on an empty cell through up an error dialog.
Also, an idea: if you just draw that popup entry box just below the listbox with the OK button, add a Cancel button, then use "pack forget" when the user hits OK or Cancel. Just a thought. That mini-popup window is the only thing about these panels that is weird, I guess that why I still am thinking about how to ditch it.
.hc
On May 19, 2008, at 7:09 PM, Hans-Christoph Steiner wrote:
Looks good to me. This is already a massive improvement over what is there. I don't know if you are sick of working on it, but I thought I'd throw a couple of minor ideas:
- it would be useful if the "startup flags" entry widget would stretch
with the resizing window. Then you could see more of those flags.
- perhaps the windows should open above the Pd window instead of the
center of the screen? I think you can get that info using [winfo rootx .] and [winfo rooty .]
.hc
On May 18, 2008, at 7:26 PM, David Golightly wrote:
As requested, I've put back the "Edit" and "Delete" buttons and added BackSpace as a Delete event for Mac OS X. I couldn't get Cmd-BackSpace to fire effectively, but perhaps someone knows something I don't about getting that to work.
On Sun, May 18, 2008 at 7:15 AM, Hans-Christoph Steiner hans@eds.org wrote:
Very nice! The mouse/keyboard interactive is well done, I only worry that the buttons are now too sparse. I think delete and edit buttons would still be useful, maybe people don't use keyboard shortcuts at all.
Also, on Mac OS X, Delete is not commonly used, so it would be good to also have BackSpace work for deleting. Or maybe Cmd-BackSpace since that is what is used for deleting in the Finder.
.hc
On May 18, 2008, at 9:46 AM, David Golightly wrote:
A note on the latest changes: I removed all the list manipulation buttons and added the following bindings:
- The list items can be re-ordered by drag-and-drop.
- Clicking on a list item allows you to edit it.
- Clicking anywhere else in the listbox allows you to add a new list
item.
- You can also traverse the list using up and down arrow keys, then
press "Enter" to change the selected item.
- Press "Delete" to delete the currently selected list item.
I kept around the "New..." button, since it may not be immediately obvious to newbies how to add new things to the list.
I also removed the "Save all settings" button and folded its action in to the "Apply" command (and, by extension, the OK command). I played around with trying to get an in-place editable listbox control for the Startup dialog, but to no avail - it's apparently no trivial task in Tcl/Tk. Perhaps for a future revision. However, the popup dialog functions effective the same, as "Enter" will submit your edit and "Esc" will cancel; once you get used to it it shouldn't be much different.
I'm also now centering the dialog windows on the screen. I'd like to do this also (especially) for the "Properties" dialogs that are used to edit GUI controls. Tk like to try and "cascade" new dialogs as they appear; this is too clever by half, and really annoying once if you do a lot of editing. But I've only tested this centering behavior on my own Macbook 15" screen, so it would be great if others could verify it's still usable on other screen sizes.
One other thing: these dialogs can now be resized, but they appear at their minimum size, so you can't shrink them any further (you can only expand them).
Please let me know what you think and as always let me know if you run into any trouble!
Thanks, David
On Sat, May 17, 2008 at 6:06 PM, David Golightly davigoli@gmail.com wrote:
Ok, with the path/startup dialogs, this is about the feature set I'd like to end up with for now. Please, everyone, review it for usability & obvious bugs, and if it looks good I'll submit it as a patch.
Thanks,
David
On Tue, May 13, 2008 at 11:53 PM, Steffen Juul stffn@dibidut.dk wrote:
On 14/05/2008, at 0.16, marius schebella wrote:
David Golightly wrote: > >> Keep in mind I'm >> still learning Tcl/Tk, so some of these ideas, while excellent, are >> a >> little beyond my technical grasp at this point and may be >> improvements >> that we make incrementally over time. Also, I have a limited amount >> of >> my time to budget for this kind of work >> > > david, > if you spend 1 hour on coding and one hour on documenting of how to > get > to that step, (instead of 2 hours coding), then the chance that more > people will be able to jump in is bigger. tcl/tk is new to most > people. > being able to concentrate on design and ui aspects would make life > easier. the hard part is to get started. >
Especially since the names in Tk are to my experience somewhat different to what one put in the search bar, ie. of my/your(?)/normal vocabulary.
Example: tabs ~= notebook. See http://wiki.tcl.tk/2298
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
<u_main.tk>
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Since it's been a few days since my last update, and I haven't received any responses, I submitted patch #1971585 to SourceForge, including the updates to the Path and Startup dialogs. Any further suggestions are still welcome; I will be investigating consolidation of the 4 preferences dialogs into a tabbed dialog of some sort (a la Tk notebook). However, perhaps an earlier priority for me will be figuring out some improvements to GUI control dialogs; perhaps bulk-editing/updates modeled (I think) on the iTunes UI for editing the metadata on multiple songs.
Anyways, thank you to everyone who offered feedback and code reviews to my efforts! Much appreciated. I'm grateful to be able to contribute code to a piece of software that has been so useful to me in the past.
Best, David
On Wed, May 21, 2008 at 8:50 PM, David Golightly davigoli@gmail.com wrote:
Ok, how does this look?
I was still unable to reproduce the clicking bug, but I changed the code to avoid the scenario that your stack trace seems to indicate as the problem, hopefully you won't see it any more.
Turns out I also have Tcl/Tk 8.4.7. Don't know where I got the idea I had 8.5 installed. So it seems either the tcllib or the Tile/ttk widgets might be a good bet for the next revision to these dialogs. One goal here also I think is to eventually provide a good basis for further customization of the Pd environment and UI, which will of course require someone to delve in the C for some of it, although perhaps to the extent that some customization can be done in pure Tcl/Tk, C work can be avoided.
Thanks again,
David
On Tue, May 20, 2008 at 3:00 AM, Hans-Christoph Steiner hans@eds.org wrote:
Just tried your new version, very nice, I think it's sorted, except one tiny bug with the resizing of "Add new startup command". I think you'll want to set a minimum window width, since you can resize it smaller and make the OK button disappear.
You might look into the Tile/ttk widgets, they are now included in Tcl/Tk 8.5. I'd like to use 8.5 for Pd-extended 0.41, so they would be there. For example, a ttk::notebook could be used to host all of the pref panes into a single window.
About the error, I just dropped your u_main.tk into Pd-vanilla 0.41-4, so that uses the version of Tcl/Tk included with Mac OS X, 8.4.7. I have Tcl/Tk 8.4.18 installed, it might be using that. But I definitely don't have 8.5 Here's the error:
Startup panel:
can't use empty string as operand of "+" can't use empty string as operand of "+" while executing "expr {$height + $top}" (procedure "ScrollBox::dbl_click" line 8) invoked from within "ScrollBox::dbl_click .gfxstub5b1230 dlg_Startup::edit dlg_Startup::add 65 45" (command bound to event)
Path pane:
can't use empty string as operand of "+" can't use empty string as operand of "+" while executing "expr {$height + $top}" (procedure "ScrollBox::dbl_click" line 8) invoked from within "ScrollBox::dbl_click .gfxstub5b1930 dlg_Path::edit dlg_Path::add 81 42" (command bound to event)
.hc
On May 20, 2008, at 8:32 AM, David Golightly wrote:
PS I was unable to reproduce that issue where you saw an error message from clicking on an empty cell. For me, clicking on empty cells just brought up the "Add new item" dialog. Could this be a difference of platform/TclTk version? I'm running 8.5 on OS X 10.4. I'd also like to get the specific error message if you can get it.
Thanks,
David
On Mon, May 19, 2008 at 10:07 PM, David Golightly davigoli@gmail.com wrote:
Here's a revised copy with a few minor changes (the "startup flags" field now expands to fill the window, you can resize the startup command popup arbitrarily).
I'm wondering about the protocol of introducing dependencies in PD. It seems that BWidget gives us a widget that we can use for the listbox ( http://tcllib.sourceforge.net/BWman/ListBox.html), however, it's perhaps not distributed with older distributions of Tcl/Tk. BWidget is distributed with Tcllib, which is apparently a default library packaged with most installs of Tcl, http://wiki.tcl.tk/12099 says that it comes by default with the ActiveState distro, with .deb and .rpm packages, and it was installed by default on my Mac OS X 10.4 distribution. But it's not guaranteed to be installed with ALL distributions of Tcl/Tk - I just have no idea exactly how many users might lack it.
Failing that, the popup should behave exactly as inline editing does, even though it looks a little strange. You can still use the keyboard to navigate: down, down, enter, type, enter, up, enter, esc... Just think of it as inline listbox editing with extra window chrome :)
On Mon, May 19, 2008 at 11:37 AM, Hans-Christoph Steiner hans@eds.org wrote:
Oops, found a little bug: double-clicking on an empty cell through up an error dialog.
Also, an idea: if you just draw that popup entry box just below the listbox with the OK button, add a Cancel button, then use "pack forget" when the user hits OK or Cancel. Just a thought. That mini-popup window is the only thing about these panels that is weird, I guess that why I still am thinking about how to ditch it.
.hc
On May 19, 2008, at 7:09 PM, Hans-Christoph Steiner wrote:
Looks good to me. This is already a massive improvement over what is there. I don't know if you are sick of working on it, but I thought I'd throw a couple of minor ideas:
- it would be useful if the "startup flags" entry widget would stretch
with the resizing window. Then you could see more of those flags.
- perhaps the windows should open above the Pd window instead of the
center of the screen? I think you can get that info using [winfo rootx .] and [winfo rooty .]
.hc
On May 18, 2008, at 7:26 PM, David Golightly wrote:
As requested, I've put back the "Edit" and "Delete" buttons and added BackSpace as a Delete event for Mac OS X. I couldn't get Cmd-BackSpace to fire effectively, but perhaps someone knows something I don't about getting that to work.
On Sun, May 18, 2008 at 7:15 AM, Hans-Christoph Steiner hans@eds.org wrote:
Very nice! The mouse/keyboard interactive is well done, I only worry that the buttons are now too sparse. I think delete and edit buttons would still be useful, maybe people don't use keyboard shortcuts at all.
Also, on Mac OS X, Delete is not commonly used, so it would be good to also have BackSpace work for deleting. Or maybe Cmd-BackSpace since that is what is used for deleting in the Finder.
.hc
On May 18, 2008, at 9:46 AM, David Golightly wrote:
A note on the latest changes: I removed all the list manipulation buttons and added the following bindings:
- The list items can be re-ordered by drag-and-drop.
- Clicking on a list item allows you to edit it.
- Clicking anywhere else in the listbox allows you to add a new list
item.
- You can also traverse the list using up and down arrow keys, then
press "Enter" to change the selected item.
- Press "Delete" to delete the currently selected list item.
I kept around the "New..." button, since it may not be immediately obvious to newbies how to add new things to the list.
I also removed the "Save all settings" button and folded its action in to the "Apply" command (and, by extension, the OK command). I played around with trying to get an in-place editable listbox control for the Startup dialog, but to no avail - it's apparently no trivial task in Tcl/Tk. Perhaps for a future revision. However, the popup dialog functions effective the same, as "Enter" will submit your edit and "Esc" will cancel; once you get used to it it shouldn't be much different.
I'm also now centering the dialog windows on the screen. I'd like to do this also (especially) for the "Properties" dialogs that are used to edit GUI controls. Tk like to try and "cascade" new dialogs as they appear; this is too clever by half, and really annoying once if you do a lot of editing. But I've only tested this centering behavior on my own Macbook 15" screen, so it would be great if others could verify it's still usable on other screen sizes.
One other thing: these dialogs can now be resized, but they appear at their minimum size, so you can't shrink them any further (you can only expand them).
Please let me know what you think and as always let me know if you run into any trouble!
Thanks, David
On Sat, May 17, 2008 at 6:06 PM, David Golightly davigoli@gmail.com wrote:
Ok, with the path/startup dialogs, this is about the feature set I'd like to end up with for now. Please, everyone, review it for usability & obvious bugs, and if it looks good I'll submit it as a patch.
Thanks,
David
On Tue, May 13, 2008 at 11:53 PM, Steffen Juul stffn@dibidut.dk wrote:
> > On 14/05/2008, at 0.16, marius schebella wrote: > > David Golightly wrote: >> >>> Keep in mind I'm >>> still learning Tcl/Tk, so some of these ideas, while excellent, are >>> a >>> little beyond my technical grasp at this point and may be >>> improvements >>> that we make incrementally over time. Also, I have a limited >>> amount of >>> my time to budget for this kind of work >>> >> >> david, >> if you spend 1 hour on coding and one hour on documenting of how to >> get >> to that step, (instead of 2 hours coding), then the chance that more >> people will be able to jump in is bigger. tcl/tk is new to most >> people. >> being able to concentrate on design and ui aspects would make life >> easier. the hard part is to get started. >> > > Especially since the names in Tk are to my experience somewhat > different to what one put in the search bar, ie. of my/your(?)/normal > vocabulary. > > Example: tabs ~= notebook. See http://wiki.tcl.tk/2298 >
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
<u_main.tk>
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Everything is working quite well. My only issue with it is what I
mentioned before, the popup text entry box for editing. But it is
definitely usable as it is now.
Thanks for taking this on!
.hc
On May 25, 2008, at 2:22 AM, David Golightly wrote:
Since it's been a few days since my last update, and I haven't
received any responses, I submitted patch #1971585 to SourceForge,
including the updates to the Path and Startup dialogs. Any further
suggestions are still welcome; I will be investigating
consolidation of the 4 preferences dialogs into a tabbed dialog of
some sort (a la Tk notebook). However, perhaps an earlier priority
for me will be figuring out some improvements to GUI control
dialogs; perhaps bulk-editing/updates modeled (I think) on the
iTunes UI for editing the metadata on multiple songs.Anyways, thank you to everyone who offered feedback and code
reviews to my efforts! Much appreciated. I'm grateful to be able
to contribute code to a piece of software that has been so useful
to me in the past.Best, David
On Wed, May 21, 2008 at 8:50 PM, David Golightly
davigoli@gmail.com wrote: Ok, how does this look?I was still unable to reproduce the clicking bug, but I changed the
code to avoid the scenario that your stack trace seems to indicate
as the problem, hopefully you won't see it any more.Turns out I also have Tcl/Tk 8.4.7. Don't know where I got the
idea I had 8.5 installed. So it seems either the tcllib or the
Tile/ttk widgets might be a good bet for the next revision to these
dialogs. One goal here also I think is to eventually provide a
good basis for further customization of the Pd environment and UI,
which will of course require someone to delve in the C for some of
it, although perhaps to the extent that some customization can be
done in pure Tcl/Tk, C work can be avoided.Thanks again,
David
On Tue, May 20, 2008 at 3:00 AM, Hans-Christoph Steiner
hans@eds.org wrote:Just tried your new version, very nice, I think it's sorted, except
one tiny bug with the resizing of "Add new startup command". I
think you'll want to set a minimum window width, since you can
resize it smaller and make the OK button disappear.You might look into the Tile/ttk widgets, they are now included in
Tcl/Tk 8.5. I'd like to use 8.5 for Pd-extended 0.41, so they
would be there. For example, a ttk::notebook could be used to host
all of the pref panes into a single window.About the error, I just dropped your u_main.tk into Pd-vanilla
0.41-4, so that uses the version of Tcl/Tk included with Mac OS X,
8.4.7. I have Tcl/Tk 8.4.18 installed, it might be using that.
But I definitely don't have 8.5 Here's the error:Startup panel:
can't use empty string as operand of "+" can't use empty string as operand of "+" while executing "expr {$height + $top}" (procedure "ScrollBox::dbl_click" line 8) invoked from within "ScrollBox::dbl_click .gfxstub5b1230 dlg_Startup::edit
dlg_Startup::add 65 45" (command bound to event)Path pane:
can't use empty string as operand of "+" can't use empty string as operand of "+" while executing "expr {$height + $top}" (procedure "ScrollBox::dbl_click" line 8) invoked from within "ScrollBox::dbl_click .gfxstub5b1930 dlg_Path::edit dlg_Path::add
81 42" (command bound to event).hc
On May 20, 2008, at 8:32 AM, David Golightly wrote:
PS I was unable to reproduce that issue where you saw an error
message from clicking on an empty cell. For me, clicking on empty
cells just brought up the "Add new item" dialog. Could this be a
difference of platform/TclTk version? I'm running 8.5 on OS X
10.4. I'd also like to get the specific error message if you can
get it.Thanks,
David
On Mon, May 19, 2008 at 10:07 PM, David Golightly
davigoli@gmail.com wrote: Here's a revised copy with a few minor changes (the "startup
flags" field now expands to fill the window, you can resize the
startup command popup arbitrarily).I'm wondering about the protocol of introducing dependencies in
PD. It seems that BWidget gives us a widget that we can use for
the listbox (http://tcllib.sourceforge.net/BWman/ListBox.html),
however, it's perhaps not distributed with older distributions of
Tcl/Tk. BWidget is distributed with Tcllib, which is apparently a
default library packaged with most installs of Tcl, http:// wiki.tcl.tk/12099 says that it comes by default with the
ActiveState distro, with .deb and .rpm packages, and it was
installed by default on my Mac OS X 10.4 distribution. But it's
not guaranteed to be installed with ALL distributions of Tcl/Tk -
I just have no idea exactly how many users might lack it.Failing that, the popup should behave exactly as inline editing
does, even though it looks a little strange. You can still use
the keyboard to navigate: down, down, enter, type, enter, up,
enter, esc... Just think of it as inline listbox editing with
extra window chrome :)On Mon, May 19, 2008 at 11:37 AM, Hans-Christoph Steiner
hans@eds.org wrote:Oops, found a little bug: double-clicking on an empty cell
through up an error dialog.Also, an idea: if you just draw that popup entry box just below
the listbox with the OK button, add a Cancel button, then use
"pack forget" when the user hits OK or Cancel. Just a thought.
That mini-popup window is the only thing about these panels that
is weird, I guess that why I still am thinking about how to ditch it..hc
On May 19, 2008, at 7:09 PM, Hans-Christoph Steiner wrote:
Looks good to me. This is already a massive improvement over
what is there. I don't know if you are sick of working on it,
but I thought I'd throw a couple of minor ideas:
- it would be useful if the "startup flags" entry widget would
stretch with the resizing window. Then you could see more of
those flags.
- perhaps the windows should open above the Pd window instead of
the center of the screen? I think you can get that info using
[winfo rootx .] and [winfo rooty .].hc
On May 18, 2008, at 7:26 PM, David Golightly wrote:
As requested, I've put back the "Edit" and "Delete" buttons and
added BackSpace as a Delete event for Mac OS X. I couldn't get
Cmd-BackSpace to fire effectively, but perhaps someone knows
something I don't about getting that to work.On Sun, May 18, 2008 at 7:15 AM, Hans-Christoph Steiner
hans@eds.org wrote:Very nice! The mouse/keyboard interactive is well done, I only
worry that the buttons are now too sparse. I think delete and
edit buttons would still be useful, maybe people don't use
keyboard shortcuts at all.Also, on Mac OS X, Delete is not commonly used, so it would be
good to also have BackSpace work for deleting. Or maybe Cmd- BackSpace since that is what is used for deleting in the Finder..hc
On May 18, 2008, at 9:46 AM, David Golightly wrote:
A note on the latest changes: I removed all the list
manipulation buttons and added the following bindings:
- The list items can be re-ordered by drag-and-drop.
- Clicking on a list item allows you to edit it.
- Clicking anywhere else in the listbox allows you to add a new
list item.
- You can also traverse the list using up and down arrow keys,
then press "Enter" to change the selected item.
- Press "Delete" to delete the currently selected list item.
I kept around the "New..." button, since it may not be
immediately obvious to newbies how to add new things to the list.I also removed the "Save all settings" button and folded its
action in to the "Apply" command (and, by extension, the OK
command). I played around with trying to get an in-place
editable listbox control for the Startup dialog, but to no
avail - it's apparently no trivial task in Tcl/Tk. Perhaps for
a future revision. However, the popup dialog functions
effective the same, as "Enter" will submit your edit and "Esc"
will cancel; once you get used to it it shouldn't be much
different.I'm also now centering the dialog windows on the screen. I'd
like to do this also (especially) for the "Properties" dialogs
that are used to edit GUI controls. Tk like to try and
"cascade" new dialogs as they appear; this is too clever by
half, and really annoying once if you do a lot of editing. But
I've only tested this centering behavior on my own Macbook 15"
screen, so it would be great if others could verify it's still
usable on other screen sizes.One other thing: these dialogs can now be resized, but they
appear at their minimum size, so you can't shrink them any
further (you can only expand them).Please let me know what you think and as always let me know if
you run into any trouble!Thanks, David
On Sat, May 17, 2008 at 6:06 PM, David Golightly
davigoli@gmail.com wrote: Ok, with the path/startup dialogs, this is about the feature
set I'd like to end up with for now. Please, everyone, review
it for usability & obvious bugs, and if it looks good I'll
submit it as a patch.Thanks,
David
On Tue, May 13, 2008 at 11:53 PM, Steffen Juul
stffn@dibidut.dk wrote:On 14/05/2008, at 0.16, marius schebella wrote:
David Golightly wrote: Keep in mind I'm still learning Tcl/Tk, so some of these ideas, while excellent,
are a little beyond my technical grasp at this point and may be
improvements that we make incrementally over time. Also, I have a limited
amount of my time to budget for this kind of workdavid, if you spend 1 hour on coding and one hour on documenting of
how to get to that step, (instead of 2 hours coding), then the chance that
more people will be able to jump in is bigger. tcl/tk is new to most
people. being able to concentrate on design and ui aspects would make life easier. the hard part is to get started.Especially since the names in Tk are to my experience somewhat
different to what one put in the search bar, ie. of my/your(?)/ normal vocabulary.Example: tabs ~= notebook. See http://wiki.tcl.tk/2298
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http:// lists.puredata.info/listinfo/pd-list
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<u_main.tk>
"[W]e have invented the technology to eliminate scarcity, but we
are deliberately throwing it away to benefit those who profit
from scarcity." -John Gilmore
"It is convenient to imagine a power beyond us because that means
we don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how
to realize his wishes. Now that he can realize them, he must
either change them, or perish. -William Carlos Williams
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
Hi David
on my 1280x800 screen the window can not fully display. see attached screenshot. it would be very nice if it worked for this screen resolution.
thanks eni
David Golightly wrote:
Ok, with the path/startup dialogs, this is about the feature set I'd like to end up with for now. Please, everyone, review it for usability & obvious bugs, and if it looks good I'll submit it as a patch.
Thanks,
David
On Tue, May 13, 2008 at 11:53 PM, Steffen Juul stffn@dibidut.dk wrote:
On 14/05/2008, at 0.16, marius schebella wrote:
David Golightly wrote:
Keep in mind I'm still learning Tcl/Tk, so some of these ideas, while excellent, are a little beyond my technical grasp at this point and may be improvements that we make incrementally over time. Also, I have a limited amount of my time to budget for this kind of work
david, if you spend 1 hour on coding and one hour on documenting of how to get to that step, (instead of 2 hours coding), then the chance that more people will be able to jump in is bigger. tcl/tk is new to most people. being able to concentrate on design and ui aspects would make life easier. the hard part is to get started.
Especially since the names in Tk are to my experience somewhat different to what one put in the search bar, ie. of my/your(?)/normal vocabulary.
Example: tabs ~= notebook. See http://wiki.tcl.tk/2298
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think we can do this incrementally. I'll try including what you
have in Pd-extended when you are ready.
As for help, I find that #tcl on freenode IRC is quite helpful. Some
of the devs hang out there and often help out.
.hc
On May 13, 2008, at 9:44 PM, David Golightly wrote:
This is all great feedback, guys - keep it coming. Keep in mind
I'm still learning Tcl/Tk, so some of these ideas, while excellent,
are a little beyond my technical grasp at this point and may be
improvements that we make incrementally over time. Also, I have a
limited amount of my time to budget for this kind of work - I also
work full-time and make music too - so I think prioritizing some of
these ideas into subsequent releases is probably the best way to
get them into Pd.Some points:
- On the Startup dialog: I wasn't satisfied with the popup box for
editing each list item, and also tried to look for a way to edit
list items in place, but couldn't figure out how to make that work
in Tcl/Tk, so I settled on the popup box. The bug you saw with
that not working, Hans, I've since fixed.
- I played around with the idea of multiple select in the
listboxes, but wasn't wholly satisfied with it and found that it
introduced more problems than it solved. For example, what if you
select multiple Paths and then click "Edit"? What is that supposed
to do?
- Having buttons inline with the list items in the listboxes would
also be really cool, but it seems like it's a lot more work to do
that, since Tk's default listbox widget only wants to deal with
arrays of strings.
- I agree with the idea that the "Save all settings" button should
be removed everywhere and folded into "Apply" ("OK" does "Apply" +
"Cancel"). I think what it originally was supposed to do was give
you an opportunity to test settings without saving them, but for
that, I think it's best to have something like a "Revert settings"
button instead. Also, I think this functionality is so marginal
that we can remove it altogether.
- I also agree that the four Preferences menus (Path, Startup,
Audio, and MIDI) should all be different tabs in the same dialog.
However, that seems like a feature that can be added at a later
time; for now, I'd like to focus on finishing up the improvements
that we already have, so we can try & get them into Vanilla, then
perhaps go through the menu system at some point and re-evaluate
how that's structured, maybe do some further improvements with some
of the other menus too. Plus I'm itching to get on to improving
the UI widget settings boxes.
- I'll see what I can do to remove those extra buttons. I really
like having everything keyboard-accessible, which includes stuff
like tab order, so I think it's probably best to keep around the
buttons for list editing commands for now, although we can
certainly investigate ways to reduce the size they take up on the
screen.I'm going to spend some spare time over the next few days working
out some of the remaining kinks, then I'll re-post the patch for
review before submitting it to the tracker. Thanks again to
everyone who has taken time to look at the proposed changes!If anyone has specific ideas to improve the layout of these
dialogs, it would be amazing to see some sort of low-fi sketch of
what you have in mind, just black outlines with text on a white
background would be fine. Also, if anyone has some more advanced
Tk wizardry they'd like to impart, or could point me to some better
resources, I'd be most grateful - Google has been a lot less
helpful than I've experienced with other languages/platforms.Thanks, David
On Sun, May 11, 2008 at 7:57 AM, Hans-Christoph Steiner
hans@eds.org wrote:Oops, one other detail with the "encode" proc. While namespaces
are probably the current way to handle function names, they are not
used for any other functions in u_main.tk So for this function, I
think it should be called something like pdtk_encodelist without
the namespace, then grouped with pdtk_encode. Something like this:proc pdtk_encodelist {listdata} { set outlist {} foreach this_path $listdata { if {0==[string match "" $this_path]} { lappend outlist [pdtk_encodedialog $this_path] } } return $outlist }
Then perhaps namespaces can be introduced later as a more
systematic approach..hc
On May 11, 2008, at 3:15 PM, Hans-Christoph Steiner wrote:
I just thought of one other thing: I think it would be very
useful if Path, Startup, Audio Settings, and MIDI settings where
all tabs in one panel, instead of four separate panels..hc
On May 11, 2008, at 1:29 PM, Hans-Christoph Steiner wrote:
Wow, what an improvement! I like it a lot. I have some comments:
- minor thing, maybe there could be less space on the sides, so
the panel would be narrower?
- about the Apply button, I think it should only show up on
platforms where it is a common thing. On Mac OS X, it should
just be OK and Cancel. On Windows, there should be Apply. I
think GNOME has moved away from Apply, but I don't know anything
about KDE.
- some separation of the buttons on the right column would make
things clearer, I think. Like maybe Up/Down on the right side,
and then Add..., Edit..., and Delete on the bottom? Or maybe
just changing Up and Down to arrows?
- the startup thing is trickier. I think that the textfield for
entering values should be embedded into the panel instead of a
popup. Also, it doesn't seem to work for me (I am using 0.41-4
vanilla). I can't add items to the list.I think once this is worked out, the best plan would be to submit
a patch to the tracker and assign it to Miller. Then I'll also
include it in Pd-extended..hc
On May 11, 2008, at 2:25 AM, David Golightly wrote:
Just verified against my own install of Pd-extended-0.40.3 on OS
X 10.4 - enough differences exist otherwise in the nightlies
that this version of the file will only work with 0.41.4.Attached is an updated (slightly bugfixed) version.
So... what's the procedure for checking in to svn :)?
-David
On Sat, May 10, 2008 at 4:24 PM, David Golightly
davigoli@gmail.com wrote: Well scratch that then, perhaps that will only work when you're
building pd on your own machine. If you launch Pd from
Terminal, you might see error output in that terminal window -
that would be helpful to have.On Sat, May 10, 2008 at 3:17 PM, marius schebella
marius.schebella@gmail.com wrote: I tried this with pd extended 0.40-3, but did not get a startup
pref window at all and the path window was very small and empty.
(os x, 10.5.) marius.David Golightly wrote: And, here's a version with an updated Startup dialog. Simply
copy this to bin/pd.tk http://pd.tk (make a backup first!) to
try it out.On Sat, May 10, 2008 at 12:48 PM, David Golightly
<davigoli@gmail.com mailto:davigoli@gmail.com> wrote:On Sat, May 10, 2008 at 12:36 PM, Steffen Juul <stffn@dibidut.dk mailto:stffn@dibidut.dk> wrote:
On 10/05/2008, at 19.48, David Golightly wrote: Ok, after a busy week this is what I've been able to
come up with for the Path dialog.
Looking really good! The browse functionality is a fair
idiom in a such GUI as oppose to entering text, i think.
Thanks! I've often been kind of frustrated that I have to
type in the full directory name rather than simply browsing to it.
For the keyboard-inclined, however, text entry should still be possible."One" comment: I have a beef with the functionality of the buttons. Not the Cancel one. The others. 'Apply' does
something. 'Ok' does 'apply' plus 'cancel'. 'Save...' does 'Apply' plus saves. But it says the list is only gonna work from next
time Pd is lunched, why i don't get the 'Apply' and 'Ok'. 'Ok'
should do save and cancel. Thats all one wants, anit?I agree. I've preserved the pre-existing functionality for
those buttons from before, but do we really need both "Save" and
"Apply"? Currently, "Save" also "saves preferences" (verbose
& use standard extensions). I think that should also happen when you click "Apply", so we can do away with the "Save" button, and also make sure that the message about needing to restart PD pops up
when you click "OK" or "Apply".I'm thinking about adapting this UI for the Startup
dialog - shouldn't be hard to do - except instead of choosing directories you want to enter arbitrary text.
I haven't checked your code but i suppose most "proc's"
can be reused?
I've set up some various key bindings so I want to
make sure it seems usable for everyone.
Nice. What are they?
Default key bindings for the listbox widget give you "up" and
"down" keys to select, I've added "Delete" to delete the current
selection, and "Return" to open the browse dialog (same as pressing
"Edit").So far I've only tested this on Mac OS X OS X.4 here.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
<u_main.tk> _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
http://at.or.at/hans/
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
"[W]e have invented the technology to eliminate scarcity, but we
are deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
There is no way to peace, peace is the way. -A.J. Muste
Hi, I have a suggestion for interface design changes, probably not simple to impliment though;
I would like a debug mode where there was realtime visual feedback in the patching window of where signal and data are flowing (rather than having to attach numbers, toggles and bangs to outputs to see the information move and diagnose a mis-patching) kind of half the point of a visual programing language I had thought.
-joseph
2008/5/14 Hans-Christoph Steiner hans@eds.org:
I think we can do this incrementally. I'll try including what you have in Pd-extended when you are ready.
As for help, I find that #tcl on freenode IRC is quite helpful. Some of the devs hang out there and often help out.
.hc
On May 13, 2008, at 9:44 PM, David Golightly wrote:
This is all great feedback, guys - keep it coming. Keep in mind I'm still learning Tcl/Tk, so some of these ideas, while excellent, are a little beyond my technical grasp at this point and may be improvements that we make incrementally over time. Also, I have a limited amount of my time to budget for this kind of work - I also work full-time and make music too - so I think prioritizing some of these ideas into subsequent releases is probably the best way to get them into Pd.
Some points:
- On the Startup dialog: I wasn't satisfied with the popup box for editing
each list item, and also tried to look for a way to edit list items in place, but couldn't figure out how to make that work in Tcl/Tk, so I settled on the popup box. The bug you saw with that not working, Hans, I've since fixed.
- I played around with the idea of multiple select in the listboxes, but
wasn't wholly satisfied with it and found that it introduced more problems than it solved. For example, what if you select multiple Paths and then click "Edit"? What is that supposed to do?
- Having buttons inline with the list items in the listboxes would also be
really cool, but it seems like it's a lot more work to do that, since Tk's default listbox widget only wants to deal with arrays of strings.
- I agree with the idea that the "Save all settings" button should be
removed everywhere and folded into "Apply" ("OK" does "Apply" + "Cancel"). I think what it originally was supposed to do was give you an opportunity to test settings without saving them, but for that, I think it's best to have something like a "Revert settings" button instead. Also, I think this functionality is so marginal that we can remove it altogether.
- I also agree that the four Preferences menus (Path, Startup, Audio, and
MIDI) should all be different tabs in the same dialog. However, that seems like a feature that can be added at a later time; for now, I'd like to focus on finishing up the improvements that we already have, so we can try & get them into Vanilla, then perhaps go through the menu system at some point and re-evaluate how that's structured, maybe do some further improvements with some of the other menus too. Plus I'm itching to get on to improving the UI widget settings boxes.
- I'll see what I can do to remove those extra buttons. I really like
having everything keyboard-accessible, which includes stuff like tab order, so I think it's probably best to keep around the buttons for list editing commands for now, although we can certainly investigate ways to reduce the size they take up on the screen.
I'm going to spend some spare time over the next few days working out some of the remaining kinks, then I'll re-post the patch for review before submitting it to the tracker. Thanks again to everyone who has taken time to look at the proposed changes!
If anyone has specific ideas to improve the layout of these dialogs, it would be amazing to see some sort of low-fi sketch of what you have in mind, just black outlines with text on a white background would be fine. Also, if anyone has some more advanced Tk wizardry they'd like to impart, or could point me to some better resources, I'd be most grateful - Google has been a lot less helpful than I've experienced with other languages/platforms.
Thanks, David
On Sun, May 11, 2008 at 7:57 AM, Hans-Christoph Steiner hans@eds.org wrote:
Oops, one other detail with the "encode" proc. While namespaces are probably the current way to handle function names, they are not used for any other functions in u_main.tk So for this function, I think it should be called something like pdtk_encodelist without the namespace, then grouped with pdtk_encode. Something like this:
proc pdtk_encodelist {listdata} { set outlist {} foreach this_path $listdata { if {0==[string match "" $this_path]} { lappend outlist [pdtk_encodedialog $this_path] } } return $outlist }
Then perhaps namespaces can be introduced later as a more systematic approach.
.hc
On May 11, 2008, at 3:15 PM, Hans-Christoph Steiner wrote:
I just thought of one other thing: I think it would be very useful if Path, Startup, Audio Settings, and MIDI settings where all tabs in one panel, instead of four separate panels.
.hc
On May 11, 2008, at 1:29 PM, Hans-Christoph Steiner wrote:
Wow, what an improvement! I like it a lot. I have some comments:
- minor thing, maybe there could be less space on the sides, so the
panel would be narrower?
- about the Apply button, I think it should only show up on platforms
where it is a common thing. On Mac OS X, it should just be OK and Cancel. On Windows, there should be Apply. I think GNOME has moved away from Apply, but I don't know anything about KDE.
- some separation of the buttons on the right column would make things
clearer, I think. Like maybe Up/Down on the right side, and then Add..., Edit..., and Delete on the bottom? Or maybe just changing Up and Down to arrows?
- the startup thing is trickier. I think that the textfield for
entering values should be embedded into the panel instead of a popup. Also, it doesn't seem to work for me (I am using 0.41-4 vanilla). I can't add items to the list.
I think once this is worked out, the best plan would be to submit a patch to the tracker and assign it to Miller. Then I'll also include it in Pd-extended.
.hc
On May 11, 2008, at 2:25 AM, David Golightly wrote:
Just verified against my own install of Pd-extended-0.40.3 on OS X 10.4
- enough differences exist otherwise in the nightlies that this version of
the file will only work with 0.41.4.
Attached is an updated (slightly bugfixed) version.
So... what's the procedure for checking in to svn :)?
-David
On Sat, May 10, 2008 at 4:24 PM, David Golightly davigoli@gmail.com wrote:
Well scratch that then, perhaps that will only work when you're building pd on your own machine. If you launch Pd from Terminal, you might see error output in that terminal window - that would be helpful to have.
On Sat, May 10, 2008 at 3:17 PM, marius schebella < marius.schebella@gmail.com> wrote:
I tried this with pd extended 0.40-3, but did not get a startup pref window at all and the path window was very small and empty. (os x, 10.5.) marius.
David Golightly wrote:
And, here's a version with an updated Startup dialog. Simply copy this to bin/pd.tk http://pd.tk (make a backup first!) to try it out.
On Sat, May 10, 2008 at 12:48 PM, David Golightly < davigoli@gmail.com mailto:davigoli@gmail.com> wrote:
On Sat, May 10, 2008 at 12:36 PM, Steffen Juul < stffn@dibidut.dk mailto:stffn@dibidut.dk> wrote:
On 10/05/2008, at 19.48, David Golightly wrote: Ok, after a busy week this is what I've been able to
come up with for the Path dialog.
Looking really good! The browse functionality is a fair
idiom in a such GUI as oppose to entering text, i think.
Thanks! I've often been kind of frustrated that I have to type in the full directory name rather than simply browsing to it. For the keyboard-inclined, however, text entry should still be possible.
"One" comment: I have a beef with the functionality of the buttons. Not the Cancel one. The others. 'Apply' does
something. 'Ok' does 'apply' plus 'cancel'. 'Save...' does 'Apply' plus saves. But it says the list is only gonna work from next time Pd is lunched, why i don't get the 'Apply' and 'Ok'. 'Ok' should do save and cancel. Thats all one wants, anit?
I agree. I've preserved the pre-existing functionality for those buttons from before, but do we really need both "Save" and "Apply"? Currently, "Save" also "saves preferences" (verbose & use standard extensions). I think that should also happen when you click "Apply", so we can do away with the "Save" button, and also make sure that the message about needing to restart PD pops up when you click "OK" or "Apply".
I'm thinking about adapting this UI for the Startup
dialog - shouldn't be hard to do - except instead of choosing directories you want to enter arbitrary text.
I haven't checked your code but i suppose most "proc's" can
be reused?
I've set up some various key bindings so I want to make
sure it seems usable for everyone.
Nice. What are they?
Default key bindings for the listbox widget give you "up" and "down" keys to select, I've added "Delete" to delete the current selection, and "Return" to open the browse dialog (same as pressing "Edit").
So far I've only tested this on Mac OS X OS X.4 here.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
<u_main.tk>_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
http://at.or.at/hans/
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
There is no way to peace, peace is the way. -A.J. Muste
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi list, i'm looking for an hex2rgb converter abstraction? someone can help me or i should use php (or python) scripting for it?
thanks Husk
What form is your hex in? A symbol or a list?
On Thu, 15 May 2008 09:52:34 +0800 husk husk00@gmail.com wrote:
Hi list, i'm looking for an hex2rgb converter abstraction? someone can help me or i should use php (or python) scripting for it?
thanks Husk
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, husk hat gesagt: // husk wrote:
i'm looking for an hex2rgb converter abstraction? someone can help me or i should use php (or python) scripting for it?
Maybe this: http://lists.puredata.info/pipermail/pd-list/2006-03/036005.html
Frank
Le Thu, 15 May 2008 09:52:34 +0800, husk husk00@gmail.com a écrit :
Hi list, i'm looking for an hex2rgb converter abstraction? someone can help me or i should use php (or python) scripting for it?
you can use the PDMTL [convert.hex2dec] abstraction then [pack f f f] the value for RGB
bye
O.
Hi,
I haven't been following the thread, but I wanted to leave a couple of
sugestions that I had here:
I gues it would be nice that while typing an object (any kind of object)
text editor
would make a line break that really remains there.
A couple of weeks ago we also taked about the possibility of having
user-defined color themes. I think that could be quite interesting,
because you could have a brighter theme to work at home, a darker for
concert/performance, etc. etc. Hans told us where to find the color
scheme, but I didn't find the Tk color codes yet (ok, I tried a bit, but
not too much). A small applet to define the pd-colors would be great, but
that's already too much to ask, there are probably more important stuff
first.
Best,
João Pais
On May 14, 2008, at 4:56 PM, João Pais wrote:
Hi,
I haven't been following the thread, but I wanted to leave a couple
of sugestions that I had here:I gues it would be nice that while typing an object (any kind of
object)
- home / end / ctrl-a / ctrl-arrow / ctrl-del would work, like a
normal text editor
I added Home/End to Pd-extended and submitted a patch to the
tracker. Ctrl-A would be tricky on Windows and GNU/Linux since that
is also select-all, but I added it on Mac OS X, since that is a
default binding on Mac OS X text apps.
http://sourceforge.net/tracker/index.php? func=detail&aid=1964023&group_id=55736&atid=478072
This change is all in pd.tk/u_main.tk so you could easily add your
own bindings, no compiling necessary.
- return finishes it (like clicking outside). except for coments,
where it would make a line break that really remains there.
Hmm, good idea, maybe I'll do it another time..
A couple of weeks ago we also taked about the possibility of having
user-defined color themes. I think that could be quite interesting,
because you could have a brighter theme to work at home, a darker
for concert/performance, etc. etc. Hans told us where to find the
color scheme, but I didn't find the Tk color codes yet (ok, I tried
a bit, but not too much). A small applet to define the pd-colors
would be great, but that's already too much to ask, there are
probably more important stuff first.
Sounds useful, patches welcome!
.hc
Best,
João Pais
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
A couple of weeks ago we also taked about the possibility of having
user-defined color themes. I think that could be quite interesting,
because you could have a brighter theme to work at home, a darker for
concert/performance, etc. etc. Hans told us where to find the color
scheme, but I didn't find the Tk color codes yet (ok, I tried a bit,
but not too much). A small applet to define the pd-colors would be
great, but that's already too much to ask, there are probably more
important stuff first.Sounds useful, patches welcome!
actually, if these settings could be controlled by pd itself, it would be
quite easy to make a patch to manage these issues. or then just implement
it on the interface's menus, maybe it makes more sense with the current pd
structure.
On May 15, 2008, at 2:17 AM, João Pais wrote:
A couple of weeks ago we also taked about the possibility of
having user-defined color themes. I think that could be quite
interesting, because you could have a brighter theme to work at
home, a darker for concert/performance, etc. etc. Hans told us
where to find the color scheme, but I didn't find the Tk color
codes yet (ok, I tried a bit, but not too much). A small applet
to define the pd-colors would be great, but that's already too
much to ask, there are probably more important stuff first.Sounds useful, patches welcome!
actually, if these settings could be controlled by pd itself, it
would be quite easy to make a patch to manage these issues. or then
just implement it on the interface's menus, maybe it makes more
sense with the current pd structure.
you are exactly right, and luckily, it's already possible:
.hc
All information should be free. - the hacker ethic
A couple of weeks ago we also taked about the possibility of having user-defined color themes. I think that could be quite interesting, because you could have a brighter theme to work at home, a darker for concert/performance, etc. etc. Hans told us where to find the color scheme, but I didn't find the Tk color codes yet (ok, I tried a bit, but not too much). A small applet to define the pd-colors would be great, but that's already too much to ask, there are probably more important stuff first.
Sounds useful, patches welcome!
actually, if these settings could be controlled by pd itself, it would be quite easy to make a patch to manage these issues. or then just implement it on the interface's menus, maybe it makes more sense with the current pd structure.
you are exactly right, and luckily, it's already possible:
great. I can do a pd patch with a GUI to set up these parameters (I just
can't say yet when it will be finished).
But I still think that it would be better if these settings would be read
by pd itself, and loaded through a patch by the user. For example, the
patch I c(w)ould write would output a text file with the pd-theme, and pd
would access this file on startup (then an extra parameter would be added
to pd).
I also think that the settings should at a later point be done in Tcl/Tk
menus, but for now I guess the xxx.pd-theme text file would be enough. An
even more mature option would be a tcl/tk dynamic window/menu with all the
themes stored on the path, and it would only be necessary to click on one
to make it work.
but first things first: if anyone wants really to work in it and has no
hurry, I can start up the "pd theme chooser".
On May 15, 2008, at 1:39 PM, João Pais wrote:
A couple of weeks ago we also taked about the possibility of having user-defined color themes. I think that could be quite interesting, because you could have a brighter theme to work at home, a darker for concert/performance, etc. etc. Hans told us where to find the color scheme, but I didn't find the Tk color codes yet (ok, I tried a bit, but not too much). A small applet to define the pd-colors would be great, but that's already too much to ask, there are probably more important stuff first.
Sounds useful, patches welcome!
actually, if these settings could be controlled by pd itself, it would be quite easy to make a patch to manage these issues. or then just implement it on the interface's menus, maybe it makes more sense with the current pd structure.
you are exactly right, and luckily, it's already possible:
great. I can do a pd patch with a GUI to set up these parameters (I
just can't say yet when it will be finished). But I still think that it would be better if these settings would
be read by pd itself, and loaded through a patch by the user. For
example, the patch I c(w)ould write would output a text file with
the pd-theme, and pd would access this file on startup (then an
extra parameter would be added to pd).I also think that the settings should at a later point be done in
Tcl/Tk menus, but for now I guess the xxx.pd-theme text file would
be enough. An even more mature option would be a tcl/tk dynamic
window/menu with all the themes stored on the path, and it would
only be necessary to click on one to make it work.but first things first: if anyone wants really to work in it and
has no hurry, I can start up the "pd theme chooser".
I am thinking of creating 'startup.pd', which would be a pd patch
that is autmoatically loaded by Pd when it is started. Then people
could configure their own settings in the form of a Pd patch, for
things that are more complicated than the preferences allow.
.hc
-- Friedenstr. 58 10249 Berlin Deutschland Tel +49 30 42020091 Mob +49 162 6843570 jmmmpais@googlemail.com skype: jmmmpjmmmp http://www.puredata.org/Members/jmmmp IBM Thinkpad R51, XP, Pd-Ext-0.39-2-t5, Pd Van 0.40-t2
kill your television
Hans-Christoph Steiner wrote:
I am thinking of creating 'startup.pd', which would be a pd patch
that is autmoatically loaded by Pd when it is started. Then people
could configure their own settings in the form of a Pd patch, for
things that are more complicated than the preferences allow.
I am not sure, if this is really a good solution, it could conflict with the -open statement or patches that people already use on startup. what you want to achieve is really more a settings issue, that has to be set once, but you don't want an annoying startup patch everytime. I am thinking of other programs, where you want to set your own environment, and how that is handled. some programs open up a default new canvas (word, blender...), some show up an "assistant" that asks you what you want to do (?...), but none opens up a document just for settings. maybe your startup.pd should be a patch, called settings.pd and will open when you chose it from the menu - "workspace settings". but write to a settings file. maybe people want different settings for different patches, then the individual settings should be loadable with a [patchsettings theme1] abstraction that you throw into your patch and the argument refers to a "pd style sheet". marius.
On May 15, 2008, at 5:10 PM, marius schebella wrote:
Hans-Christoph Steiner wrote:
I am thinking of creating 'startup.pd', which would be a pd patch
that is autmoatically loaded by Pd when it is started. Then
people could configure their own settings in the form of a Pd
patch, for things that are more complicated than the preferences
allow.I am not sure, if this is really a good solution, it could conflict
with the -open statement or patches that people already use on
startup. what you want to achieve is really more a settings issue, that has
to be set once, but you don't want an annoying startup patch
everytime. I am thinking of other programs, where you want to set your own
environment, and how that is handled. some programs open up a default new canvas (word, blender...), some
show up an "assistant" that asks you what you want to do (?...),
but none opens up a document just for settings. maybe your startup.pd should be a patch, called settings.pd and
will open when you chose it from the menu - "workspace settings".
but write to a settings file. maybe people want different settings for different patches, then
the individual settings should be loadable with a [patchsettings
theme1] abstraction that you throw into your patch and the argument
refers to a "pd style sheet". marius.
startup.pd would just a way to load/save settings like any other. It
could be easily optional, so if there was no startup.pd, it wouldn't
do anything. I would make it load invisibly, or perhaps it would be
embedded in the Pd window... just ideas at the this point.D
.hc
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent
controls you." - Richard M. Stallman
On 16 May 2008, at 1:10 AM, marius schebella wrote:
some programs open up a default new canvas (word, blender...), some
show up an "assistant" that asks you what you want to do (?...), but none opens up a document just for settings.
.. Vim does
simon
simon wise wrote:
On 16 May 2008, at 1:10 AM, marius schebella wrote:
some programs open up a default new canvas (word, blender...), some show up an "assistant" that asks you what you want to do (?...), but none opens up a document just for settings.
.. Vim does
simon
don't know what you mean. the settings for vim are in ~/.vimrc and when you type vim, there is what I would call an assistant.
~ VIM - Vi IMproved
~
~ version 7.0.234
~ by Bram Moolenaar et al.
~ Vim is open source and freely distributable
~
~ Become a registered Vim user!
~ type :help register<Enter> for information
~ ~ type :q<Enter> to exit
~ type :help<Enter> or <F1> for on-line help
~ type :help version7<Enter> for version info
marius.
I would expect to be able to send a message like:
[; pd canvas_fill red(
and have it change the patch background instead of manually editing pd.tk, but I get:
pd: unknown message canvas_fill red
on version 0.40.3--extended-20071212. Is/will it be possible?
Martin
This is what is possible now:
http://lists.puredata.info/pipermail/pd-list/2008-05/062202.html
Your message idea sounds worth implementing, if you want to take a
crack at it.
.hc
On May 15, 2008, at 5:12 PM, Martin Peach wrote:
I would expect to be able to send a message like:
[; pd canvas_fill red(
and have it change the patch background instead of manually editing
pd.tk, but I get:pd: unknown message canvas_fill red
on version 0.40.3--extended-20071212. Is/will it be possible?
Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith
actually, if these settings could be controlled by pd itself, it would be quite easy to make a patch to manage these issues. or then just implement it on the interface's menus, maybe it makes more sense with the current pd structure.
you are exactly right, and luckily, it's already possible:
nice, I was just looking at it. sys_gui is just fresh, right?
isn't it really possible to make the changes apply automatically? if not,
it's a step in the good direction, but it's still not really great.
Ah, a couple more issues I had somewhere (well, more like details, not
really important): [or was there a feature request link somewhere? I only
know the bug report one]
as before. but if using a dual screen, windows that were saved on the
other screen always appear in the main screen once they're reopened (but
the coordinates match). (I'm on xp, and my main screen on the right side,
if that makes a difference)
that's just a detail, but I get used to divide the screen in a certain way
(also to make sure I'm always controling the console while having my
patches + hdsp mixer open). everytime I open pd I have to drag the window
to the corner of the screen
On May 15, 2008, at 2:22 PM, João Pais wrote:
actually, if these settings could be controlled by pd itself, it would be quite easy to make a patch to manage these issues. or then just implement it on the interface's menus, maybe it makes more sense with the current pd structure.
you are exactly right, and luckily, it's already possible:
nice, I was just looking at it. sys_gui is just fresh, right? isn't it really possible to make the changes apply automatically?
if not, it's a step in the good direction, but it's still not
really great.Ah, a couple more issues I had somewhere (well, more like details,
not really important): [or was there a feature request link
somewhere? I only know the bug report one]
- dual screen compatibility. pd patches always open in the same
position as before. but if using a dual screen, windows that were
saved on the other screen always appear in the main screen once
they're reopened (but the coordinates match). (I'm on xp, and my
main screen on the right side, if that makes a difference)
Please submit a bug report.
- is it possible to give the coordinates for the pd window to
appear? that's just a detail, but I get used to divide the screen
in a certain way (also to make sure I'm always controling the
console while having my patches + hdsp mixer open). everytime I
open pd I have to drag the window to the corner of the screen
Try this:
.hc
--
Friedenstr. 58 10249 Berlin Deutschland Tel +49 30 42020091 Mob +49 162 6843570 jmmmpais@googlemail.com skype: jmmmpjmmmp http://www.puredata.org/Members/jmmmp IBM Thinkpad R51, XP, Pd-Ext-0.39-2-t5, Pd Van 0.40-t2
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
- is it possible to give the coordinates for the pd window to
appear? that's just a detail, but I get used to divide the screen in a certain way (also to make sure I'm always controling the console while having my patches + hdsp mixer open). everytime I open pd I have to drag the window to the corner of the screen
Try this:
very nice, thanks.
this and what you just sent before could then be the first stones of the
"startup.pd" patch you mentioned, that would set up the working
environment theme.
would it be possible for startup.pd to be loaded "hidden"? it doesn't
bother me, but some people might find it too complicated when too much
material opens up. for example, another tick box named "xXx" could make
that window appear/disappear.
actually when I start pd I have a patch with my working environment
already popping up - but that's only to list the patches that I'm working
on at the moment, so that they're only a click away. but maybe that's also
interesting to other people as well? so the working features so far could
be pd window position, color theme, favorite files list.
apparently the color scheme gets renewed when Tk "grabs" a window. if I
change the scheme, and also something in the patch, when I try to close
and pd asks to discard changes the color scheme gets updated (but only in
the window that was "activated"). I guess it might be possible to include
a message in sys_gui to bang the windows after a colorscheme message? or
maybe to all open windows?
João
On May 15, 2008, at 2:17 AM, João Pais wrote:
A couple of weeks ago we also taked about the possibility of having user-defined color themes. I think that could be quite interesting, because you could have a brighter theme to work at home, a darker for concert/performance, etc. etc. Hans told us where to find the color scheme, but I didn't find the Tk color codes yet (ok, I tried a bit, but not too much). A small applet to define the pd-colors would be great, but that's already too much to ask, there are probably more important stuff first.
Sounds useful, patches welcome!
actually, if these settings could be controlled by pd itself, it would be quite easy to make a patch to manage these issues. or then just implement it on the interface's menus, maybe it makes more sense with the current pd structure.
you are exactly right, and luckily, it's already possible:
Hmm, I can't reproduce this on Mac OS X 10.4.11/Intel with Pd- extended 0.40.3-20080517
.hc
On May 20, 2008, at 5:47 PM, João Pais wrote:
apparently the color scheme gets renewed when Tk "grabs" a window.
if I change the scheme, and also something in the patch, when I try
to close and pd asks to discard changes the color scheme gets
updated (but only in the window that was "activated"). I guess it
might be possible to include a message in sys_gui to bang the
windows after a colorscheme message? or maybe to all open windows?João
On May 15, 2008, at 2:17 AM, João Pais wrote:
A couple of weeks ago we also taked about the possibility of having user-defined color themes. I think that could be quite interesting, because you could have a brighter theme to work at home, a darker for concert/performance, etc. etc. Hans told us where to find the color scheme, but I didn't find the Tk color codes yet (ok, I tried a bit, but not too much). A small applet to define the pd-colors would be great, but that's already too much to ask, there are probably more important stuff first.
Sounds useful, patches welcome!
actually, if these settings could be controlled by pd itself, it would be quite easy to make a patch to manage these issues. or then just implement it on the interface's menus, maybe it makes more sense with the current pd structure.
you are exactly right, and luckily, it's already possible:
-- Friedenstr. 58 10249 Berlin Deutschland Tel +49 30 42020091 Mob +49 162 6843570 jmmmpais@googlemail.com skype: jmmmpjmmmp http://www.puredata.org/Members/jmmmp IBM Thinkpad R51, XP, Ubuntu GG Pd-Ext-0.39-2-t5, Pd Van 0.40-t2
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
Hmm, I can't reproduce this on Mac OS X 10.4.11/Intel with Pd-extended
0.40.3-20080517
I was playing a bit with it - it also works if a patch/subpatch window is
closed and reopened. but anyway, if possible, an instant implementation
would be the most desirable. only that way it would be possible to make a
psychadelic canvas, yeah!
2 details:
then they'll have the canvas color. if possible, it would make sense to
use the object box color, I guess. but there was no gop parameter, is it
possbile to make one?
just wanted to give notice.
Ah, by the way, on your original patch the msg_nlet parameter was misnamed.
(still on 0.40.3-extended-20080515 XP)
.hc
On May 20, 2008, at 5:47 PM, João Pais wrote:
apparently the color scheme gets renewed when Tk "grabs" a window. if I
change the scheme, and also something in the patch, when I try to close
and pd asks to discard changes the color scheme gets updated (but only
in the window that was "activated"). I guess it might be possible to
include a message in sys_gui to bang the windows after a colorscheme
message? or maybe to all open windows?João
On May 15, 2008, at 2:17 AM, João Pais wrote:
A couple of weeks ago we also taked about the possibility of having user-defined color themes. I think that could be quite interesting, because you could have a brighter theme to work at home, a darker for concert/performance, etc. etc. Hans told us where to find the color scheme, but I didn't find the Tk color codes yet (ok, I tried a bit, but not too much). A small applet to define the pd-colors would be great, but that's already too much to ask, there are probably more important stuff first.
Sounds useful, patches welcome!
actually, if these settings could be controlled by pd itself, it would be quite easy to make a patch to manage these issues. or then just implement it on the interface's menus, maybe it makes more sense with the current pd structure.
you are exactly right, and luckily, it's already possible:
--Friedenstr. 58 10249 Berlin Deutschland Tel +49 30 42020091 Mob +49 162 6843570 jmmmpais@googlemail.com skype: jmmmpjmmmp http://www.puredata.org/Members/jmmmp IBM Thinkpad R51, XP, Ubuntu GG Pd-Ext-0.39-2-t5, Pd Van 0.40-t2
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either change
them, or perish. -William Carlos Williams
ah, one other thing:
when pasting something that is outside the visible window, the window
arrows don't show up automatically anymore. that is, you get the arrows
only after doing something with the window size (and maybe making it
redraw).
here's a patch to demonstrate this. this happens in both windows and
ubuntu, afair.
it also happens with data structures, when some created graphics are too
big for the window.
João Pais
Hi,
I haven't been following the thread, but I wanted to leave a couple of
sugestions that I had here:I gues it would be nice that while typing an object (any kind of object)
- home / end / ctrl-a / ctrl-arrow / ctrl-del would work, like a normal
text editor
I added Home/End to Pd-extended and submitted a patch to the tracker.
Ctrl-A would be tricky on Windows and GNU/Linux since that is also
select-all, but I added it on Mac OS X, since that is a default binding
on Mac OS X text apps.http://sourceforge.net/tracker/index.php? func=detail&aid=1964023&group_id=55736&atid=478072
This change is all in pd.tk/u_main.tk so you could easily add your own
bindings, no compiling necessary.
- return finishes it (like clicking outside). except for coments, where
it would make a line break that really remains there.
Hmm, good idea, maybe I'll do it another time..
A couple of weeks ago we also taked about the possibility of having
user-defined color themes. I think that could be quite interesting,
because you could have a brighter theme to work at home, a darker for
concert/performance, etc. etc. Hans told us where to find the color
scheme, but I didn't find the Tk color codes yet (ok, I tried a bit,
but not too much). A small applet to define the pd-colors would be
great, but that's already too much to ask, there are probably more
important stuff first.Sounds useful, patches welcome!
.hc
Best,
João Pais
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
That bug is fixed on Pd-extended 0.40.3-20080515 on Mac OS X/Intel, I
think it should be fixed on the other platforms as well. I am not
sure whether Miller has accepted that patch yet, but it should be in
the tracker.
.hc
On May 15, 2008, at 1:10 PM, João Pais wrote:
ah, one other thing:
when pasting something that is outside the visible window, the
window arrows don't show up automatically anymore. that is, you get
the arrows only after doing something with the window size (and
maybe making it redraw).here's a patch to demonstrate this. this happens in both windows
and ubuntu, afair.it also happens with data structures, when some created graphics
are too big for the window.João Pais
Hi,
I haven't been following the thread, but I wanted to leave a
couple of sugestions that I had here:I gues it would be nice that while typing an object (any kind of
object)
- home / end / ctrl-a / ctrl-arrow / ctrl-del would work, like a
normal text editor
I added Home/End to Pd-extended and submitted a patch to the
tracker. Ctrl-A would be tricky on Windows and GNU/Linux since
that is also select-all, but I added it on Mac OS X, since that is
a default binding on Mac OS X text apps.http://sourceforge.net/tracker/index.php? func=detail&aid=1964023&group_id=55736&atid=478072
This change is all in pd.tk/u_main.tk so you could easily add your
own bindings, no compiling necessary.
- return finishes it (like clicking outside). except for coments,
where it would make a line break that really remains there.
Hmm, good idea, maybe I'll do it another time..
A couple of weeks ago we also taked about the possibility of
having user-defined color themes. I think that could be quite
interesting, because you could have a brighter theme to work at
home, a darker for concert/performance, etc. etc. Hans told us
where to find the color scheme, but I didn't find the Tk color
codes yet (ok, I tried a bit, but not too much). A small applet
to define the pd-colors would be great, but that's already too
much to ask, there are probably more important stuff first.Sounds useful, patches welcome!
.hc
Best,
João Pais
Computer science is no more related to the computer than astronomy
is related to the telescope. -Edsger Dykstra-- Friedenstr. 58 10249 Berlin Deutschland Tel +49 30 42020091 Mob +49 162 6843570 jmmmpais@googlemail.com skype: jmmmpjmmmp http://www.puredata.org/Members/jmmmp IBM Thinkpad R51, XP, Pd-Ext-0.39-2-t5, Pd Van 0.40-t2<window- arrows.pd>
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
David Golightly wrote:
Well scratch that then, perhaps that will only work when you're building pd on your own machine. If you launch Pd from Terminal, you might see error output in that terminal window - that would be helpful to have.
ok, I first tested with 0.40, that did not work, I now tried with 0.41-4 and think your patch is is already a great improvement compared to the current situation. here are some things that you may consider. up down buttons should be beside each other, maybe it is also possible to align buttons, please try to get rid of as many buttons as possible, reduce whatever is not needed. for example, the edit button is not necessary, if you can double click on the path, everybody will understand that. even better would be, if you could edit inside the list without the popup edit line. maybe it is also possible to drag the lines around with the mouse (without up/down buttons). and also click after the last line to add a new path. maybe the add/new could be the last line. or below the last line, or there is an empty line, that you can double click to add a new path. delete could also be a small button beside each line, so that you don't have to select and then click on a button on the right side. (what about multiple select?). add could also be named "new". I immediately tried to resize the window to make it bigger, but resize is not enabled, of course drag and drop from the file manager would be nice. I like that the mouse wheel is working, the scrollbar only changes, if I move the mouse with a certain speed. when I move it slowly, the scrollbar is stuck. also, when I use up / down buttons, then it would be nice it the scrollbar would move according to the position of the selection. since I am on osx, I don't know how to add paths inside the application, which is a bundle. when I click on cancel I get an error in the console: NavGetReply failed, -128 but, it seems to cancel without problems. when I click on the red X to close the window instead of cancel I get an error in a tcl/tk popup: invalid command name "path_cancel" invalid command name "path_cancel" while executing "path_cancel .gfxstub33a690" (command for "WM_DELETE_WINDOW" window manager protocol)
"apply" button and save all settings seem redundant. OK should save. apply might make sense if you want to save, but continue editing (=save, but don't close window). but usually you don't work that long in the path editor to need that functionality. not sure what verbose and "use standard extension are for? after some time I had problems with the mouse focus. maybe because of to much dragging. but a click would select another line as the one the mouse was over. and of course after delete ctrl z for undo would be nice... still, after all I like the improvements so far, and any small improvement is already a lot of work, so thanks!!! marius.
On Sat, May 10, 2008 at 3:17 PM, marius schebella <marius.schebella@gmail.com mailto:marius.schebella@gmail.com> wrote:
I tried this with pd extended 0.40-3, but did not get a startup pref window at all and the path window was very small and empty. (os x, 10.5.) marius. David Golightly wrote: And, here's a version with an updated Startup dialog. Simply copy this to bin/pd.tk <http://pd.tk> <http://pd.tk> (make a backup first!) to try it out. On Sat, May 10, 2008 at 12:48 PM, David Golightly <davigoli@gmail.com <mailto:davigoli@gmail.com> <mailto:davigoli@gmail.com <mailto:davigoli@gmail.com>>> wrote: On Sat, May 10, 2008 at 12:36 PM, Steffen Juul <stffn@dibidut.dk <mailto:stffn@dibidut.dk> <mailto:stffn@dibidut.dk <mailto:stffn@dibidut.dk>>> wrote: On 10/05/2008, at 19.48, David Golightly wrote: Ok, after a busy week this is what I've been able to come up with for the Path dialog. Looking really good! The browse functionality is a fair idiom in a such GUI as oppose to entering text, i think. Thanks! I've often been kind of frustrated that I have to type in the full directory name rather than simply browsing to it. For the keyboard-inclined, however, text entry should still be possible. "One" comment: I have a beef with the functionality of the buttons. Not the Cancel one. The others. 'Apply' does something. 'Ok' does 'apply' plus 'cancel'. 'Save...' does 'Apply' plus saves. But it says the list is only gonna work from next time Pd is lunched, why i don't get the 'Apply' and 'Ok'. 'Ok' should do save and cancel. Thats all one wants, anit? I agree. I've preserved the pre-existing functionality for those buttons from before, but do we really need both "Save" and "Apply"? Currently, "Save" also "saves preferences" (verbose & use standard extensions). I think that should also happen when you click "Apply", so we can do away with the "Save" button, and also make sure that the message about needing to restart PD pops up when you click "OK" or "Apply". I'm thinking about adapting this UI for the Startup dialog - shouldn't be hard to do - except instead of choosing directories you want to enter arbitrary text. I haven't checked your code but i suppose most "proc's" can be reused? I've set up some various key bindings so I want to make sure it seems usable for everyone. Nice. What are they? Default key bindings for the listbox widget give you "up" and "down" keys to select, I've added "Delete" to delete the current selection, and "Return" to open the browse dialog (same as pressing "Edit"). So far I've only tested this on Mac OS X OS X.4 here. ------------------------------------------------------------------------ _______________________________________________ PD-list@iem.at <mailto:PD-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sat, 2008-05-03 at 12:21 +0200, Frank Barknecht wrote:
I've never worked with that, however I'm always irritated, when patching environments have their cord connections flow left to right instead of top to bottom. IMO that's such a waste of space in languages, that are written horizontally. If you look at the "Midi to Poly" object here: http://synthmaker.co.uk/images/components%20L.png you'll see that most of it is just an empty grey rectangle, whose width is just there to make room for the object name. If the in/outlets were top and bottom as in Pd and Max, the box could be much smaller without losing any information.
I agree.
However, I'm quite warming to chord-less patching a la circle:
http://www.futureaudioworkshop.com/
IMO, this looks like a really nice and well-thought-through UI. Although I am definitely not suggesting Pd should go down that route -- Pd and Circle are two very different beasts!
Jamie
On Mon, 2008-05-05 at 13:49 +0100, Jamie Bullock wrote:
On Sat, 2008-05-03 at 12:21 +0200, Frank Barknecht wrote:
I've never worked with that, however I'm always irritated, when patching environments have their cord connections flow left to right instead of top to bottom. IMO that's such a waste of space in languages, that are written horizontally. If you look at the "Midi to Poly" object here: http://synthmaker.co.uk/images/components%20L.png you'll see that most of it is just an empty grey rectangle, whose width is just there to make room for the object name. If the in/outlets were top and bottom as in Pd and Max, the box could be much smaller without losing any information.
I agree.
However, I'm quite warming to chord-less patching a la circle:
http://www.futureaudioworkshop.com/
IMO, this looks like a really nice and well-thought-through UI. Although I am definitely not suggesting Pd should go down that route -- Pd and Circle are two very different beasts!
Jamie
Hmmm why is it called "Free Audio Workshop" when "Circle will be available for €149.00 / $199.00" ... ?
Dan Wilcox robotcowboy.com
On Monday 05 May 2008 18:53:53 Dan Wilcox wrote:
On Mon, 2008-05-05 at 13:49 +0100, Jamie Bullock wrote:
However, I'm quite warming to chord-less patching a la circle:
http://www.futureaudioworkshop.com/
Jamie
Hmmm why is it called "Free Audio Workshop" when "Circle will be available for €149.00 / $199.00" ... ?
Simply because it is not called "Free Audio Workshop" ?
It's nice but too 'heavy' (for eyes) for me. And i think this
interface need more ressources from a computer than PD.
But sure, it would be nice if someone have time to improve PD interface.
++
Jack
Le 3 mai 08 à 11:34, Langsam Wieder a écrit :
hey david!
if you want to collect some ideas how a real usable and pretty interface for a modular environment could look like, have a look at http://synthmaker.co.uk/about.html it's got bendable links... you never have to leave edit mode... and have a look at how ALL interface elements as bitmap & vector knobs, sliders or wavedraw display consist of modules themselve. the environment is off course not as powerful as pd, but the interface is just a joy to work with.
greetings, fabb
On Sat, May 3, 2008 at 6:04 AM, David Golightly
davigoli@gmail.com wrote:Hey PD gurus,
I used to use PD a lot but haven't much for the last year or
more. Now I'm getting back in to it and finding that the UI is just really
clunky and awkward and makes the workflow really painful. I build website UIs professionally in JavaScript (see http://www.zillow.com/search/RealEstateSearch.htm for an example
of a UI I built, everything except the Flash). I also have on-the-job
experience in design and usability, as well as coding skills in Python and some
exposure to C, C++ and Java. I'd like to start pitching in specifically on
GUI and chrome improvements in the trunk for the core PD UI. How would I
go about getting started? I noticed the page at http://puredata.info/dev/ GuiIdeas has some outstanding requests from the community, it seems like
the best thing is to start there. I'd also like to integrate with the
developer community to ensure that UI improvements (specifically, better
keyboard support and smoothing out some glaring dialog/chrome issues) don't
have a negative impact on realtime audio performance.Best,
David
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