Re: [PD] UI developer volunteering to help
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
[EMAIL PROTECTED] 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
[EMAIL PROTECTED] 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
[EMAIL PROTECTED] 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
Re: [PD] UI developer volunteering to help
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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
Re: [PD] UI developer volunteering to help - more suggestions
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: - if there are gops (like in my abstractions, you can try with [lbang]), 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? - when filled, objects loose transparency. it doesn't bother me, but I 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 [EMAIL PROTECTED] 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 -- Friedenstr. 58 10249 Berlin Deutschland Tel +49 30 42020091 Mob +49 162 6843570 [EMAIL PROTECTED] 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: [PD] UI developer volunteering to help
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
[EMAIL PROTECTED] 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
[EMAIL PROTECTED] 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
[EMAIL PROTECTED] 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
Re: [PD] UI developer volunteering to help - more suggestions
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 [EMAIL PROTECTED] 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help - more suggestions
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 [EMAIL PROTECTED] 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help - more suggestions
Hmm, I can't reproduce this on Mac OS X 10.4.11/Intel with Pd-extended 0.40.3-20080517 it works on a XP, 0.40.3-extended-20080515. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help - more suggestions
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help - more suggestions
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 registerEnter for information ~ ~ type :qEnter to exit ~ type :helpEnter or F1 for on-line help ~ type :help version7Enter for version info marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: [PD] UI developer volunteering to help
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 ___
Re: [PD] UI developer volunteering to help
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: [PD] UI developer volunteering to help
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help - more suggestions
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=detailaid=1964023group_id=55736atid=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 [EMAIL PROTECTED] 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 Description: Binary data ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help - more suggestions
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: color_scheme.pd Description: Binary data .hc All information should be free. - the hacker ethic ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help - more suggestions
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. -- Friedenstr. 58 10249 Berlin Deutschland Tel +49 30 42020091 Mob +49 162 6843570 [EMAIL PROTECTED] skype: jmmmpjmmmp http://www.puredata.org/Members/jmmmp IBM Thinkpad R51, XP, Pd-Ext-0.39-2-t5, Pd Van 0.40-t2 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help - more suggestions
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) - 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 -- Friedenstr. 58 10249 Berlin Deutschland Tel +49 30 42020091 Mob +49 162 6843570 [EMAIL PROTECTED] skype: jmmmpjmmmp http://www.puredata.org/Members/jmmmp IBM Thinkpad R51, XP, Pd-Ext-0.39-2-t5, Pd Van 0.40-t2 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help - more suggestions
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=detailaid=1964023group_id=55736atid=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 [EMAIL PROTECTED] skype: jmmmpjmmmp http://www.puredata.org/Members/jmmmp IBM Thinkpad R51, XP, Pd-Ext-0.39-2-t5, Pd Van 0.40-t2window- 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help - more suggestions
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 [EMAIL PROTECTED] 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help - more suggestions
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: move_pd_window.pd Description: Binary data .hc -- Friedenstr. 58 10249 Berlin Deutschland Tel +49 30 42020091 Mob +49 162 6843570 [EMAIL PROTECTED] 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help - more suggestions
- 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. -- Friedenstr. 58 10249 Berlin Deutschland Tel +49 30 42020091 Mob +49 162 6843570 [EMAIL PROTECTED] skype: jmmmpjmmmp http://www.puredata.org/Members/jmmmp IBM Thinkpad R51, XP, Pd-Ext-0.39-2-t5, Pd Van 0.40-t2 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help - more suggestions
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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
Re: [PD] UI developer volunteering to help - more suggestions
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 - return finishes it (like clicking outside). except for coments, where it 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help - more suggestions
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=detailaid=1964023group_id=55736atid=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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help - more suggestions
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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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 [EMAIL PROTECTED]
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
Re: [PD] UI developer volunteering to help
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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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
[EMAIL PROTECTED] 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
Re: [PD] UI developer volunteering to help
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 [EMAIL PROTECTED]:
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 [EMAIL PROTECTED]
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
Re: [PD] UI developer volunteering to help
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Sat, May 10, 2008 at 12:36 PM, Steffen Juul [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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/
Re: [PD] UI developer volunteering to help
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Sat, May 10, 2008 at 12:36 PM, Steffen Juul [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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
Re: [PD] UI developer volunteering to help
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). ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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
[EMAIL PROTECTED] 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
[EMAIL PROTECTED] 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
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
On Sat, May 10, 2008 at 12:36 PM, Steffen Juul [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] 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
Re: [PD] UI developer volunteering to help
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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Sat, May 10, 2008 at 12:36 PM, Steffen Juul [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]mailto: [EMAIL PROTECTED] wrote: On Sat, May 10, 2008 at 12:36 PM, Steffen Juul [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Sat, May 10, 2008 at 12:36 PM, Steffen Juul [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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
Re: [PD] UI developer volunteering to help
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): 1) Miller accepts it and it gets into vanilla section of SVN 2) 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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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. pref.test.tk Description: Binary data ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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. PGP.sig Description: Signierter Teil der Nachricht ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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 ? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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' ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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 -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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 [EMAIL PROTECTED] 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
Hello, 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. What I would welcome would be a richer set of GUI tools in vanilla, as sometimes knobs are more preferable to sliders, or you may want a 2d-slider for tying two dimensions to each other, but these are less important than the [pow~], [abs~], etc. objects mentioned in an earlier thread. Thanks, Matt 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 [EMAIL PROTECTED] 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
Re: [PD] UI developer volunteering to help
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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
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 [EMAIL PROTECTED] 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
Re: [PD] UI developer volunteering to help
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 [EMAIL PROTECTED] 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
Re: [PD] UI developer volunteering to help
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 [EMAIL PROTECTED] 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
[PD] UI developer volunteering to help
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
