[PD] vanilla dialog updates

[Dan Wilcox]

Thanks!

The first thing to check would be the data_dialog save & done buttons.

--------
Dan Wilcox
@danomatika <https://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Mar 20, 2016, at 6:16 PM, Miller Puckette <msp at ucsd.edu> wrote:
> 
> OK, up it goes :)
> 
> On Sun, Mar 20, 2016 at 06:07:48PM -0600, Dan Wilcox wrote:
>> Ok. I think it’s good. Should probably be tested on other platforms to be sure, but working fine for me on OSX.
>> 
>> As discussed, I changed dialog_data & pdtk_textwindow to the default dialog gray background.
>> 
>> --------
>> Dan Wilcox
>> @danomatika <https://twitter.com/danomatika>
>> danomatika.com <http://danomatika.com/>
>> robotcowboy.com <http://robotcowboy.com/>
>>> On Mar 20, 2016, at 11:43 AM, Miller Puckette <msp at ucsd.edu> wrote:
>>> 
>>> 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 at 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 at lists.iem.at mailing list
>>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>> 
>> 
> 
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160320/62655a36/attachment.html>