[Smtk-developers] SMTK operators in the UI

Fri May 22 10:25:53 EDT 2015

I’ve updated the Views Google Doc to better explain what I was suggesting last night :)  Your idea will work as well.

Bob

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 May 22, 2015, at 9:30 AM, Yumin Yuan <yumin.yuan at kitware.com> wrote:
> 
> Hi Dave,
> 
> That's a great summary and lots of nice ideas. We should create an issue on github with you email. But I agree with Bob, a short term solution will be more desirable currently.
> 
> Bob,
> 
> On Fri, May 22, 2015 at 7:42 AM, Robert Michael O'Bara <bob.obara at kitware.com <mailto:bob.obara at kitware.com>> wrote:
> Actually what I'm proposing is not a custom widget but better Gui options when dealing with file items in smtk. 
>  For example in instanced views we could add a component style option that states the name of the item that represents the cache of file names. I can show an example of this later today.  I'm running out the door for a car service this morning.
> 
> 
> Here is what I am thinking that could work. In the XML template, we already have "ShouldExist" for FileItemDefinition, which is to tell the dialog to be an Open or Save dialog. We can add a vector of strings in FileItem class (call it "recentExistingList"), and if "ShoudExist" is true,  recentExistingList  will cache the files that has been set to the FileItem, also in this case for qtFileItem widget, we will use a combobox instead of the textbox on the UI to present the list. This way, we don't have to touch anything else, and I agree "showing the recent file list" is a better UI option anyway.
> 
> Yumin
>  
> 
> 
> Sent from my iPad
> 
> On May 22, 2015, at 12:20 AM, David Thompson <david.thompson at kitware.com <mailto:david.thompson at kitware.com>> wrote:
> 
>> I certainly think that a custom widget on the client side (either the custom view entry or the file chooser with recent files listed) would be a lot easier to implement in the short term.
>> 
>>     David
>> 
>> 
>> 
>> On May 21, 2015, at 23:51, Robert Michael O'Bara <bob.obara at kitware.com <mailto:bob.obara at kitware.com>> wrote:
>> 
>>> Hi Guys,
>>> 
>>> First I want to say this really does a good job at describing some of the issues facing SMTK with future expansion and will have to be discussed more thoroughly (current funding is a bit tight right now in terms of solving this in general).
>>> 
>>> In terms of the Bathymetry issues - I think there might be a short term solution that could implemented relatively quickly.  Instead of thinking the user is selecting the Bathymetry using a discrete based item (with enums representing already loaded files), what if we represent it as a File Item instead and have the ability for the file item widget to remember the files that the user has already attempted to load?  One small drawback with this is that files that failed to load would still be listed but that might not be a bad trade-off.
>>> 
>>> An alternative would be to add an option in the View description to indicate that in addition to a file item, an attribute also includes a vector of strings that represent “quick” selectable files.  For example consider a definition of Bathymetry consisting of a file item definition called fname and another string item (which is not displayed directly) called already loaded files.  Initially the string item is empty (though in the future this could be pre-populated based on an user preference).  Each time a file is successfully loaded the server would add its name to the “already” loaded item which would then get passed back to the client on request.  In this case the definition does not need to be touched.
>>> 
>>> Does this make sense?
>>> 
>>> Bob
>>> 
>>> 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 <tel:%28518%29%20881-%204931>
>>> 
>>> 
>>> 
>>> 
>>>> On May 21, 2015, at 7:55 PM, David Thompson <david.thompson at kitware.com <mailto:david.thompson at kitware.com>> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> Yumin and I just had a chat about how to present a list of available bathymetry data to users in the operator panel. I'm sending this to summarize/record what we talked about (plus some related thoughts from talks with Rob about the mesh operator) and get feedback, if you have any, about custom user interfaces for operators.
>>>> 
>>>> The client-server separation means that when an operator (such as "apply bathymetry") runs on the server, any modifications it makes to its definition (such as adding to the enumeration of bathymetry files currently loaded) are not available on the client. The way the attribute reader works (skipping pre-existing definitions) means that transmitting changes from the server would not work without manually parsing the XML and making matching changes on the client. However, some operators do clearly have persistent and/or volatile state associated with them so it seems that SMTK should help applications maintain and present it.
>>>> 
>>>> Most of the solutions we came up with involve running some code on the client when an operator's result attribute is returned (in order to modify the attribute or the view). What's unclear to me is the best way to tie that code to the operator:
>>>> 
>>>> Operators are defined in libraries that must not have UI dependencies. So, any custom UI code must clearly be in a separate library. Multiple UIs (e.g., desktop Qt, web browser, mobile app) may each have a different custom UI for the same operator (or only some UIs may be custom for some operators). The same custom UI may be suitable for multiple operators of the same name (i.e., when multiple sessions provide the same operator with identical semantics on the client). Thus there need not be a 1:1 mapping between session plugins and custom-operator-UI plugins.
>>>> 
>>>> It seems that operators should not include markup specific to the view directly; multiple versions of the view (one for each platform's UI or for each application) may exist and could each mark up the same operator differently -- the same way many CSS files can mark up the same HTML to customize appearance.
>>>> 
>>>> It also seems that there should be an optional but strongly-enforced-when-present connection between the matching attribute systems on the client and server so that custom UIs are not applied to operators from sessions of different types. Is the string specifying the "actual" session type enough? (Note that SMTK does not robustly provide the actual session type to forwarding sessions, but perhaps it should.)
>>>> 
>>>> Since a custom UI may be optional, it is up to the application to enforce consistent loading of matching plugins on the server and client. For ModelBuilder, the smtkXXXSessionPlugin targets can specify that a matching ParaView-client-side plugin must also be loaded as needed. However, it is unclear what class would accept per-operator UI registration; what would invoke registered code on the UI side; and how the proper UI code would be identified given an operator and its session. What we can say is that the lifecycle of the UI involves:
>>>> 
>>>> 1. Creating the custom UI elements. This could be done (1) as soon as an Operator instance (and its specification attribute) is created or (2) when a view of the operator is requested (but before anything is known about the view so that the UI has an opportunity to modify the view). The latter makes the most sense because otherwise the custom UI will not have a parent widget or context in which to place itself.
>>>> 
>>>> 2. Signaling the UI when there is an event related to the operator. SMTK provides callbacks when an operator is about to be applied and when it has just completed. It might be nice for a base UI customization class to automatically register for these callbacks.
>>>> 
>>>> 3. Interacting with the possibly-remote Operator instance. Currently the Operator class only provides ableToOperate() and operate() methods. However some operators may provide feedback while the specification is in progress (e.g., the grow operator can indicate the faces that will result). Custom UIs will frequently wish to take advantage of this; how can SMTK accommodate more generic communication between the UI and operator?
>>>> 
>>>> 4. Destroying the UI. This could happen in tandem with the Operator instance and its attribute; or when its containing view is destroyed.
>>>> 
>>>> 	David
>>>> _______________________________________________
>>>> Smtk-developers mailing list
>>>> Smtk-developers at smtk.org <mailto:Smtk-developers at smtk.org>
>>>> http://public.kitware.com/mailman/listinfo/smtk-developers <http://public.kitware.com/mailman/listinfo/smtk-developers>
>>> 
> 
> _______________________________________________
> Smtk-developers mailing list
> Smtk-developers at smtk.org <mailto:Smtk-developers at smtk.org>
> http://public.kitware.com/mailman/listinfo/smtk-developers <http://public.kitware.com/mailman/listinfo/smtk-developers>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150522/c3c1216a/attachment.html>