I'm thinking the grey background is fine for them. At some point it would be good to have teh canvas background settable as an option, but that's too much for me to figure out right now.
Am I right that the 'pull request' on github is stable enough for me to try to merge?
cheers Miller
On Tue, Mar 15, 2016 at 10:54:58AM -0600, Dan Wilcox wrote:
Another question: should the text editing dialogs have a white background? I changed dialog_data (data structures) to have a white background and pdtk_textwindow ([text], [qlist], etc) already had a white background.
I’m asking as all other dialogs have the default light gray background while the canvases are always white. In my thinking this morning, the non-canvas windows/dialogs should not be white in order to differentiate them from any canvases.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Mar 15, 2016, at 10:48 AM, Dan Wilcox danomatika@gmail.com wrote:
Hello,
This is nice. What about the gop window? It is very difficult to practice without the "Apply" button.
The Apply button is only gone on OSX. It’s still there for Linux & Windows.
On OSX, I added live edits in the entry boxes and buttons, so if you type and press enter in any of them, the GOP is updated without closing the dialog. I also made tabbing between widget’s alot easier.
Here’s a demo video form Decmeber for dialog_gatom: https://www.youtube.com/watch?v=PZCjgIFMc9g https://www.youtube.com/watch?v=PZCjgIFMc9g
The smae approach is now used for dialog_iemgui, dialog_canvas, & dialog_array.
Concerning the preferences: startup/prefs/audio/midi menu, is that dreamable to have only one menu and toggles for the different topics? It will be easier to configure, and much more easy to understand when you "save all”.
My whole approach for this work was to make simple cleanups and updates. I decided not to change the base functionality too much in this pass. A few years ago, Jonathan Wilkes made a tabbed preferences pane as you suggested but, as far as I can tell, his work is not in vanilla.
For the midi, is it possible to have a "add device" button instead of a "use multiple device" one? With the GUI it is not possible tu use more than 3 interfaces and that can be mandatory with some MIDI devices.
As far as I can tell, the Multiple device button just gies you more options to choose from. By default it shows 4 devices, but will show up to 9 inputs and 9 outputs if there are that many available.
Admittedly, both dialog_audio & dialog_midi could be reworked (a lot of the gui could be reworked/cleanedup), but my approach this time is for an incremental update and not a rewrite yet.
For the mknob, vsl, toggle,... i would keep the "dimensions” header
My feeling is it’s so ugly and redundant considering the contextual labels (Width, Height, etc) explain what that section is about, ie. always the visual size. I made this change so dialog_iemgui would match dialog_gatom.
BTW, you still have an old header in mknob : ------------output-range----------, and its left value is at 1.27 instead of 0.
The header is on purpose. That screenshot is to demonstrate objects which utilize dialog_iemgui but are *not* built-in (aka vsl, tgl, bng, etc) still work with the dialog changes.
for the toggle i would group "nonzeero value" and "no init" under parameters
Again, I’m sticking to an incremental update this time, so I’m keeping the grouping of the controls the same.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list