[Smtk-developers] Operator View

[David Thompson]

Hi Bob,

It is possible to get the attribute system from a session already:

    https://gitlab.kitware.com/cmb/smtk/blob/master/smtk/model/Session.h#L337

You can then ask for all the definitions that inherit the base "operator" and figure out which operators are applicable to a given selection.

    David

> On Oct 20, 2016, at 18:35, Bob Obara <bob.obara at kitware.com> wrote:
> 
> Hi Dave,
> 
> 
> Robert M. O'Bara, MEng.
> Assistant Director of Scientific Computing
> 
> Kitware Inc.
> 28 Corporate Drive
> Suite 101
> Clifton Park, NY 12065
> 
> Phone: (518) 881- 4931
> 
> 
> 
> 
>> On Oct 20, 2016, at 6:14 PMEDT, David Thompson <david.thompson at kitware.com> wrote:
>> 
>> Hi Bob,
>> 
>>> So I’m designing the operator view base calls - which would be used as the default GUI for an operator.  I just wanted to describe some of the design:
>>> 
>>> 1. It assumes that the operator is defined by a single attribute definition/attribute - the old way was reusing the existing instanced attribute view.  The reason for doing this is to know where to grab the association information.
>> 
>> Does this mean that each view will have its own attribute-instance? I like it, but be aware that it will lead to frustration in some cases: people sometimes expect a way to re-apply the same operation again (with the same arguments which are not the default arguments) but the view will appear to have forgotten their previous configuration.
>> 
> 
> No - I was more going after the fact that right now an operator could be defined by multiple attributes (it inherited this functionality because under the covers it uses an instance view which can have multiple attribute definitions).
> 
> Actually what I would like to do is to change things so that an operator is defined as an attribute definition and an object that can perform the operation - for example a session already has the operators registered - what is missing is the ability to getting the attribute definitions directly from the session instead of instantiating the operator itself.  This way we determine what operations are valid based on the entities selected.  It would also allow us to hold onto the attribute (which would have the previously entered values).
> 
> Does that make sense?
> 
> Bob
> 
>> For instance, saving to a file requires a filename. The attribute definition cannot provide a meaningful default, so every time users go to save, they will be asked to enter the same filename.
>> 
>> One workaround would be to provide operators with a virtual "auto-populate" method that would get called to set up the operator's attribute (for example, by filling in the filename from the "url" string property on the selected model/session).
>> 
>>> 2. In addition to the top level view attribute it will also have 
>>> 
>>> a. auto_apply attribute indicating that by default this operation does not need to use the View but instead can be automatically applied.  This can be over ridden by a setting on the “operation manager”
>>> 
>>> b. no_apply attribute indicating that the operator does not need an apply button
>>> 
>>> 3. If the operation requires more than one model entity - a list box will be displayed instead of a combo box.  (if it takes in a single entity than it will still use a combo box)
>>> 
>>> If you have any comments or suggestions let me know!
>> 
>> I don't know how easy it would be with Qt, but it would be nice for each operator that can both be auto-applied and accept non-default item-values to accept 2 triggers ("apply with defaults" or "customize first"), so that you don't have to change a setting in the "operation manager" twice (once before the operation you want to customize and once afterwards).
>> 
>> 	David
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20161020/b985e2cd/attachment-0001.html>