<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi John,</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">The one example concerning overriding defaults would be with respects to the Numerics. For example the default pre-conditioner of the solver might differ for different workflows right? Another possible example could be workflows that are idealizations of a more complex workflow?</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Bob</div><div id="AppleMailSignature"><br>Sent from my iPad</div><div><br>On Nov 23, 2016, at 3:27 PM, John Tourtellott <<a href="mailto:john.tourtellott@kitware.com">john.tourtellott@kitware.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>With regard to Label, you could still support it "inline" with the definition, and allow the View to override it. (And in turn, allow a workflow spec to override a view-specified Label, I suppose.) However, I'm not sure I like this, since it is the inverse of the standard css-inheritance paradigm. If we want to keep it simple, I would move it to the view, even though I know I'll complain about it later :)<br><br></div>As for workflows overriding default values:<br><ul><li>I don't foresee multiple/different workflows sharing the same attribute definitions, but maybe my thinking is too limited here.</li><li>If there are use-cases for that (different workflows using variations of the same definitions), then we might want the workflows to override other definition characteristics in addition to the default value.<br></li></ul><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 23, 2016 at 3:03 PM, David Thompson <span dir="ltr"><<a href="mailto:david.thompson@kitware.com" target="_blank">david.thompson@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> ... There is one possible change I would like to propose and wanted to get your feedback on concerning how attribute definitions and item definitions are currently defined. ... Note that how the information is to be represented in a GUI is (for the most part) not part of these classes but is represented in the Views. The one exception are the Labels. They represent the alternative way of displaying the "type" information of the attribute definition and the "name" information of the item definition.<br>
<span class="">><br>
> Since in 5.0, the GUI generation will support specifying where items should be placed within a View's widgets that are rendering the information, I was wondering if moving the label information into View structure would make more sense.<br>
<br>
</span>I agree that labels belong with the view, not the items/attributes.<br>
<span class=""><br>
> It would allow workflows to customize how the type and name info is displayed (as well as allowing for localization).<br>
><br>
> Along those lines I was wondering if we should support allowing the Workflow the ability to "override" the default values of Items since (based on the assumption that a default values may be workflow specific).<br>
<br>
</span>That seems reasonable.<br>
<br>
> Happy Thanksgiving!<br>
<br>
Many happy returns of the morrow!<br>
<br>
David<br>
______________________________<wbr>_________________<br>
Smtk-developers mailing list<br>
<a href="mailto:Smtk-developers@smtk.org">Smtk-developers@smtk.org</a><br>
<a href="http://public.kitware.com/mailman/listinfo/smtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/smtk-<wbr>developers</a><br>
</blockquote></div><br></div>
</div></blockquote></body></html>