From Indu.Shukla at erdc.dren.mil  Thu Jul  9 11:26:06 2015
From: Indu.Shukla at erdc.dren.mil (Shukla, Indu ERDC-RDE-ITL-MS)
Date: Thu, 9 Jul 2015 15:26:06 +0000
Subject: [Smtk-developers] Help
In-Reply-To: <BDDCA9CA-5591-41E1-ABA9-B8A3755C9237@kitware.com>
References: <D1AF1FEF.3517%Indu.Shukla@erdc.dren.mil>
 <F8A1F7F7-E7C8-41B7-B145-95AC15629826@kitware.com>
 <F4AE1E1C401D1548B3DA6F6F5D785EA26A8C8A06@MS-EX2VKS.erdc.dren.mil>
 <E90CAA7A-4A88-4FC6-B897-B73CE41F19DB@kitware.com>
 <F4AE1E1C401D1548B3DA6F6F5D785EA26A8C8A2C@MS-EX2VKS.erdc.dren.mil>
 <38E3416D-EE69-48C0-ADF5-116825F7CBE2@kitware.com>
 <F4AE1E1C401D1548B3DA6F6F5D785EA26A8C8A45@MS-EX2VKS.erdc.dren.mil>
 <9FC775EB-A160-4F57-9D79-9A5FD828D9DB@kitware.com>
 <F4AE1E1C401D1548B3DA6F6F5D785EA26A8C8A65@MS-EX2VKS.erdc.dren.mil>
 <CAKkFzuewDiUW_ho0paeuAa8PJwvVk+Crk9m1H-HxhcxE2gsb0g@mail.gmail.com>
 <F4AE1E1C401D1548B3DA6F6F5D785EA26A8C8AE7@MS-EX2VKS.erdc.dren.mil>
 <CAKkFzudah+mRGtSR+9NQ+OqKTnDeyFytJKuBmEo-B7K6TKuVKQ@mail.gmail.com>
 <F4AE1E1C401D1548B3DA6F6F5D785EA26A8C8B0B@MS-EX2VKS.erdc.dren.mil>
 <CAKkFzucvfSoJa7Zeg8=FF4MFqUZkAtf8zEnNWpVqL7gzBuk=xg@mail.gmail.com>
 <F4AE1E1C401D1548B3DA6F6F5D785EA26A8C8B98@MS-EX2VKS.erdc.dren.mil>
 <9B9AEF6E-5BF3-4DCE-B0A6-C9F9139F6132@kitware.com>
 <F4AE1E1C401D1548B3DA6F6F5D785EA26A8C8C5C@MS-EX2VKS.erdc.dren.mil>
 <9BA62D55-7D5B-4C63-94F0-2F20AA720D27@kitware.com>
 <F4AE1E1C401D1548B3DA6F6F5D785EA26A8C8C89@MS-EX2VKS.erdc.dren.mil>
 <BDDCA9CA-5591-41E1-ABA9-B8A3755C9237@kitware.com>
Message-ID: <D1C3F52A.3821%Indu.Shukla@erdc.dren.mil>

David, Yumin

Your sample code helped me so much. I was able to retrieve each and every
value from the multiple instances of attribute definition. But still I am
stuck in one.
I want to find the path of file I found using the file browser.

This is the code I am trying to work.

mesh = asys.findAttribute('Model')
meshgr = mesh.findGroup('Existing')
meshVal = smtk.attribute.to_concrete(gr.find('ExistingMeshFile?))


Here?s the XML

<AttDef Type="Model" Label="Model" BaseType="" Version="0" Unique="true">
    <ItemDefinitions>
      <!--**********  Existing ***********-->
      <Group Name="Existing" Label="Existing" NumberOfRequiredGroups="1">
        <ItemDefinitions>
          <File Name="ExistingMeshFile" Label="Mesh file (*.2dm)"
NumberOfRequiredValues="1" FileFilters="CMB Edge, Surface and Volume Mesh
Files(*.1dm *.2dm *.3dm );;All files (*.*)">
            <DefaultValue>existing_mesh.2dm</DefaultValue>
          </File>
          <File Name="ExistingHOTFile" Label="HOT file (*.hot)"
NumberOfRequiredValues="1" FileFilters="CMB Edge, Surface and Volume Mesh
Files(*.hot);;All files (*.*)">
            <DefaultValue>existing_mesh.hot</DefaultValue>
          </File>
          <File Name="ExistingBCFile" Label="ADH bc file (*.bc)"
NumberOfRequiredValues="1" FileFilters="(*.bc);;All files (*.*)">
            <DefaultValue>existing_mesh.bc</DefaultValue>
          </File>
          <String Name="Description" Label="Description: "
NumberOfRequiredValues="1" MultipleLines="true"/>
        </ItemDefinitions>
      </Group>
      <!--**********  Planned ***********-->
      <Group Name="Planned" Label="Planned" NumberOfRequiredGroups="1">
        <ItemDefinitions>
          <File Name="PlannedMeshFile" Label="Mesh file (*.2dm)"
NumberOfRequiredValues="1" FileFilters="CMB Edge, Surface and Volume Mesh
Files(*.1dm *.2dm *.3dm );;All files (*.*)">
              <DefaultValue>planned_mesh.2dm</DefaultValue>
          </File>
          <File Name="PlannedHOTFile" Label="HOT file (*.hot)"
NumberOfRequiredValues="1" FileFilters="CMB Edge, Surface and Volume Mesh
Files(*.hot);;All files (*.*)">
            <DefaultValue>planned_mesh.hot</DefaultValue>
          </File>
          <File Name="PlannedBCFile" Label="ADH bc file (*.bc)"
NumberOfRequiredValues="1" FileFilters="(*.bc);;All files (*.*)">
            <DefaultValue>planned_mesh.bc</DefaultValue>
            </File>
          <String Name="Description" Label="Description: "
NumberOfRequiredValues="1" MultipleLines="true"/>
        </ItemDefinitions>
      </Group>
    </ItemDefinitions>
  </AttDef>

Thanks!

Indu



On 6/26/15, 3:37 PM, "David Thompson" <david.thompson at kitware.com> wrote:

>Hi Indu,
>
>> Tide and wind and the tabular entries in my form.  There will be no
>>fixed number of entries for tide and wind, they can vary according to
>>the situation. In this test example I sent you, I  only have  one each
>>for tide (Tide-0) and wind (Wind-0).
>> I need to know,
>> 1. How many of tide entries are there
>> 2. How many wind entries are there.
>
>tideAtts = asys.findAttributes('Tide')
>windAtts = asys.findAttributes('Wind')
>print len(tideAtts)
>print len(windAtts)
>
>You can then run "for tideAtt in tideAtts:" to process each tide or wind
>attribute in the returned list.
>
>> 3. Then access the items(Gage Station,{Station,Agency,Station ID}) and
>>its values (Gage Station,{station,0,1234})  of each tide and wind
>>entries. 
>
>Access to these items is as in the previous e-mail, except that you can
>access items by their integer position in the attribute:
>
>smtk.attribute.to_concrete(smtk.attribute.to_concrete(tideAtts[0].item(0))
>.item(0)).name()
>smtk.attribute.to_concrete(smtk.attribute.to_concrete(tideAtts[0].item(0))
>.item(0)).value(0)
>
>	David


From bob.obara at kitware.com  Fri Jul 17 14:21:38 2015
From: bob.obara at kitware.com (Robert Michael O'Bara)
Date: Fri, 17 Jul 2015 14:21:38 -0400
Subject: [Smtk-developers] Proposed Change to Attribute and Attribute Group
	Item Classes
Message-ID: <27287A4C-7E58-45C8-B492-E2D24C8A5124@kitware.com>

Hi All,

Some time ago a set of findXXX methods were add to the Attribute class in order to make accessing items easier.  For example findDouble(?a") would return a DoubleItemPtr whose name is a.  There is also a templated method called findAs which does pretty much the same thing findAs<DoubleItem>(?a?)

When this was done, the developer failed to notice that GroupItems also behave like Attributes in that they also contain Items and as a result it only has the original find() method.

I figured the reason that we have the explicit findXXX methods was to provide Python wrappings since the original findAs method could not be wrapped directly.  However, I discovered that there are Python  findAs methods being generated explicitly in the typesystem.xml (findAsDouble for example).

As a result we have findXXX and findAs style methods being used in both C++ and Python code.  I would like there to be only one style for each.
 
What I propose is that the findXXX methods be removed from the Attribute class and just leave the findAs template (and add it to GroupItem).  Also to add the findAs methods in the GroupItem Python wrapping.

Any comments?

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




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

From david.thompson at kitware.com  Tue Jul 21 08:48:24 2015
From: david.thompson at kitware.com (David Thompson)
Date: Tue, 21 Jul 2015 06:48:24 -0600
Subject: [Smtk-developers] Proposed Change to Attribute and Attribute
	Group Item Classes
In-Reply-To: <27287A4C-7E58-45C8-B492-E2D24C8A5124@kitware.com>
References: <27287A4C-7E58-45C8-B492-E2D24C8A5124@kitware.com>
Message-ID: <659F5C9E-73AC-4022-97F3-90D2C0D5E3C3@kitware.com>

Hi Bob,

> Some time ago a set of findXXX methods were add to the Attribute class in order to make accessing items easier.  For example findDouble(?a") would return a DoubleItemPtr whose name is a.  There is also a templated method called findAs which does pretty much the same thing findAs<DoubleItem>(?a?)

The idea is that the templated methods are for use in other templated code while the non-templated methods are more terse and thus easier to type and to read.

The non-templated methods can also be used in debuggers without issue, while the templated methods cannot always be invoked (at least on OS X, it depends on whether the templated method is directly invoked somewhere in the same execution unit as the stack frame you are debugging when you try to call the method).

> When this was done, the developer failed to notice that GroupItems also behave like Attributes in that they also contain Items and as a result it only has the original find() method.

Oops. Sorry.

> I figured the reason that we have the explicit findXXX methods was to provide Python wrappings since the original findAs method could not be wrapped directly.  However, I discovered that there are Python  findAs methods being generated explicitly in the typesystem.xml (findAsDouble for example).

At the time I wrote findDouble, I had not yet figured out how to add methods to typesystem.xml that would return items of the proper type.

> As a result we have findXXX and findAs style methods being used in both C++ and Python code.  I would like there to be only one style for each.
> 
> What I propose is that the findXXX methods be removed from the Attribute class and just leave the findAs template (and add it to GroupItem).  Also to add the findAs methods in the GroupItem Python wrapping.
> 
> Any comments?

I would prefer to fix GroupItem but keep the findXXX methods as convenience methods; I've really found the shorter, untemplated methods useful.

The findAsXXX() methods in typesystem.xml are defined on the Operator class. I am unhappy with the API consistency there, but there does not seem to be a simple fix. One problem with injecting methods via typesystem.xml is that subclasses do not inherit them; for example, if we add a Python findAsFoo method to class A then Python objects of some type B that inherits A will not have a findAsFoo method. To call findAsFoo, one must ask Python for the same object cast as type A.

    class A {
      Foo* findAsFoo(const std::string&) const;
    };
    class B : public A {
    };

    <object-type name="A">
      <add-function signature="findAsFoo(const std::string&amp;) const" .../>
    </object-type>
    <object-type name="B"/>

    import smtk
    instanceA = smtk.A()
    instanceB = smtk.B()
    instanceA.findAsFoo("x") # this will work
    instanceB.findAsFoo("x") # this will not work
    smtk.A(instanceB).findAsFoo("x") # will work if smtk.A(instanceB) exists

This means that injecting findAsXXX() methods would involve a lot of copied code in typesystem for IntItem, DoubleItem, StringItem, GroupItem, Operator (which inherits Attribute), and possibly others.

	David

From Indu.Shukla at erdc.dren.mil  Wed Jul 22 11:28:44 2015
From: Indu.Shukla at erdc.dren.mil (Shukla, Indu ERDC-RDE-ITL-MS)
Date: Wed, 22 Jul 2015 15:28:44 +0000
Subject: [Smtk-developers] (UNCLASSIFIED) Attribute question
Message-ID: <D1D520CD.3AAD%Indu.Shukla@erdc.dren.mil>

SMTK Developers,

I have a list of study as an attribute view. I am using this list of study as a drop down in my another tab.

This code snippet from of my Study tab from my sbi file


<Att Name="Study-0" Type="Study" ID="755a7651-ae02-4c8b-b503-48350b863898">

      <Items>

        <Group Name="ModelInformation">

          <String Name="modelused">SMTK</String>

          <String Name="studytimeframe">FY 2015</String>

          <String Name="modelversion">SMTK 4.0</String>

        </Group>

This is where I use it as a drop down


 <Att Name="Images-0" Type="Images" ID="04ddf225-6dc6-4570-8ad8-f99e461add41">

      <Items>

        <File Name="Images">

          <RecentValues>

            <Val>/Users/indushukla/Desktop/ISEP Files/CollectionFromShell.png</Val>

          </RecentValues>/Users/indushukla/Desktop/ISEP Files/CollectionFromShell.png</File>

        <String Name="ImageDescription">This belongs to study0</String>

        <String Name="Study" Expression="true">Study-0</String>

      </Items>

    </Att>


Here?s the python script I am using to access the Study-0 from the above code

image_att = asys.findAttributes('Images?)


for image in image_att:

        d={}

        if study_item.name()==smtk.attribute.to_concrete(image.item(2)).value(0):

            d['file'] = smtk.attribute.to_concrete(image.item(0)).value(0)

            d['description'] = smtk.attribute.to_concrete(image.item(1)).value(0)

            d[?Images'] = smtk.attribute.to_concrete(image.item(2)).value(0)

            lst.append(d)



But smtk.attribute.to_concrete(image.item(2)).value(0) doesn?t return any value while rest of them do. Do we access them differently?


Thanks,


Indu

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

From bob.obara at kitware.com  Fri Jul 24 16:30:50 2015
From: bob.obara at kitware.com (Robert Michael O'Bara)
Date: Fri, 24 Jul 2015 16:30:50 -0400
Subject: [Smtk-developers] Some Changes
Message-ID: <C91E3072-1F90-4B1E-8B11-3CB16A2FC3DD@kitware.com>

Hi All,

Couple of things:

1. I?ve created a smtk testing data repo on GitLab
2. TopLevel Views

I?ve adding the concept of a TopLevel View - by adding the xml attribute TopLevel = ?true? to a View Element or 
view->details().setAttribute(?TopLevel?, ?true?) you can indicate that the view is a top level view.  A SMTK or CMB application can now find all the top level view in an attribute system.  This now removes the need to hardcode the name of the view an application needs to look for (for example SimBuilder was looking for a View called SimBuilder and the export dialog was looking for a view called Export.

Any View can be a TopLevel View.  I?ve also simplified the qtUIManager class so you now only need to set the SMTK View to the Manager in order for the proper qtView to be generated.

3. I have an updated CMB branch that is compatible to these changes.

4. Removing Root Views

With the concept of a TopLevel View I?m planning on removing Root Views all together since they don?t really add any new functionality.  Instead you will be able to add the appropriate Root View Attributes (like default and invalid color) to any View.

Comments are welcome as always

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




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

From david.thompson at kitware.com  Fri Jul 24 16:51:16 2015
From: david.thompson at kitware.com (David Thompson)
Date: Fri, 24 Jul 2015 16:51:16 -0400
Subject: [Smtk-developers] Some Changes
In-Reply-To: <C91E3072-1F90-4B1E-8B11-3CB16A2FC3DD@kitware.com>
References: <C91E3072-1F90-4B1E-8B11-3CB16A2FC3DD@kitware.com>
Message-ID: <F261FECA-1F75-42CF-BB28-36D9E5BD64E0@kitware.com>

Hi Bob,

> 1. I?ve created a smtk testing data repo on GitLab...

Just double-checking:

1. Are you aware that SMTKTestData/cmb/smooth_surface.cmb is a mines+ground model? I know you were worried about that being OK to release.

2. Are you sure that all the files in the solidModels directory are OK to re-publish? I know some of the examples I got were from engineering sites that had restrictive licenses.

	David



From bob.obara at kitware.com  Fri Jul 24 17:44:30 2015
From: bob.obara at kitware.com (Robert Michael O'Bara)
Date: Fri, 24 Jul 2015 17:44:30 -0400
Subject: [Smtk-developers] SMTK DATA Repo
Message-ID: <D2DFC5B4-2A28-4B1F-A8A5-EE2FBFFEB562@kitware.com>

Hi All,

For the time being the repo has been deleted from GitLab.

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




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

From bob.obara at kitware.com  Tue Jul 28 13:28:40 2015
From: bob.obara at kitware.com (Robert Michael O'Bara)
Date: Tue, 28 Jul 2015 13:28:40 -0400
Subject: [Smtk-developers] qtRootView
Message-ID: <ECFD6934-DD20-4B26-AE23-D70F6084A18D@kitware.com>

Hi Yumin,

Why do Root Views have internal scroll areas while others like group views do not - is the scroll area really being created because the view is a top level one?

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




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

From yumin.yuan at kitware.com  Tue Jul 28 13:50:51 2015
From: yumin.yuan at kitware.com (Yumin Yuan)
Date: Tue, 28 Jul 2015 13:50:51 -0400
Subject: [Smtk-developers] qtRootView
In-Reply-To: <ECFD6934-DD20-4B26-AE23-D70F6084A18D@kitware.com>
References: <ECFD6934-DD20-4B26-AE23-D70F6084A18D@kitware.com>
Message-ID: <CAKkFzucw6pY9Pjq6wmTKDa9t1AkWinFcRPW02QRumR8AeQpNyw@mail.gmail.com>

Yes, the idea was that the top view should be scrollable since it is the
container of all other views, and we don't know how much space each view
really needs.

Yumin

On Tue, Jul 28, 2015 at 1:28 PM, Robert Michael O'Bara <
bob.obara at kitware.com> wrote:

> Hi Yumin,
>
> Why do Root Views have internal scroll areas while others like group views
> do not - is the scroll area really being created because the view is a top
> level one?
>
> 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150728/c2edea3d/attachment.html>