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 <[email protected]> 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/>

_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Reply via email to