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 <[email protected]> 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 <[email protected]> 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 <[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 >>> >> > >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
