Converting old meshes

[bART Janssens-2]

Hi,

To ease the transition of some tests to generic primitives, I made an
XSLT converter that takes a pre-generic primitive polyhedron mesh and
translates it to a generic mesh. Is there any interest in adding this
to the source tree, and if so, where should it be put?

The file is attached, it can be used with an XSLT 2.0 processor such as saxonb.

Cheers,

--
Bart

<?xml version='1.0'?>
<xsl:stylesheet version='2.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform'>
        <!-- Copy everything not matched otherwise -->
        <xsl:template match="*">
                <xsl:copy>
                        <xsl:copy-of select="@*"/>
                        <xsl:apply-templates/>
                </xsl:copy>
        </xsl:template>
       
        <!-- Process the mesh arrays, just copying everything except polyhedra -->
        <xsl:template match="//mesh_arrays">
                <mesh_arrays>
                        <xsl:apply-templates select="* except polyhedra"/>
                        <xsl:if test="count(vertex_data) = 0">
                                        <vertex_data/>
                        </xsl:if>
                        <primitives>
                                <xsl:apply-templates select="polyhedra"/>
                        </primitives>
                </mesh_arrays>
        </xsl:template>
       
        <!-- Conversion of polyhedra -->
        <xsl:template match="polyhedra">
                <primitive type="polyhedron">
                        <structure>
                                <xsl:apply-templates select="* except (constant_data | uniform_data | face_varying_data)"/>
                        </structure>
                        <attributes>
                                <xsl:if test="count(constant_data) = 0">
                                        <arrays type="constant"/>
                                </xsl:if>
                                <xsl:if test="count(uniform_data) = 0">
                                        <arrays type="uniform"/>
                                </xsl:if>
                                <xsl:if test="count(face_varying_data) = 0">
                                        <arrays type="face_varying"/>
                                </xsl:if>
                                <xsl:apply-templates select="constant_data | uniform_data | face_varying_data"/>
                        </attributes>
                </primitive>
        </xsl:template>
       
        <!-- Conversion of mesh arrays -->
        <xsl:template match="clockwise_edges | face_first_loops | face_loop_counts | loop_first_edges">
                <array>
                        <xsl:attribute name="name"><xsl:value-of select="name()"/></xsl:attribute>
                        <xsl:attribute name="type">k3d::uint_t</xsl:attribute>
                        <xsl:value-of select="text()"/>
                </array>
        </xsl:template>
        <xsl:template match="edge_points">
                <array>
                        <xsl:attribute name="name"><xsl:value-of select="name()"/></xsl:attribute>
                        <xsl:attribute name="type">k3d::uint_t</xsl:attribute>
                        <xsl:value-of select="text()"/>
                        <metadata>
                                <pair name="k3d:domain">/points/indices()</pair>
                        </metadata>
                </array>
        </xsl:template>
        <xsl:template match="edge_selection">
                <array>
                        <xsl:attribute name="name">edge_selections</xsl:attribute>
                        <xsl:attribute name="type">k3d::double_t</xsl:attribute>
                        <xsl:value-of select="text()"/>
                        <metadata>
                                <pair name="k3d:selection-component">split_edge</pair>
                        </metadata>
                </array>
        </xsl:template>
        <xsl:template match="face_selection">
                <array>
                        <xsl:attribute name="name">face_selections</xsl:attribute>
                        <xsl:attribute name="type">k3d::double_t</xsl:attribute>
                        <xsl:value-of select="text()"/>
                        <metadata>
                                <pair name="k3d:selection-component">uniform</pair>
                        </metadata>
                </array>
        </xsl:template>
        <xsl:template match="face_materials">
                <array>
                        <xsl:attribute name="name"><xsl:value-of select="name()"/></xsl:attribute>
                        <xsl:attribute name="type">k3d::imaterial*</xsl:attribute>
                        <xsl:value-of select="text()"/>
                </array>
        </xsl:template>
        <xsl:template match="face_counts">
                <array name="shell_face_counts" type="k3d::uint_t">
                        <xsl:value-of select="text()"/>
                </array>
        </xsl:template>
        <xsl:template match="first_faces">
                <array name="shell_first_faces" type="k3d::uint_t">
                        <xsl:value-of select="text()"/>
                </array>
        </xsl:template>
        <xsl:template match="types">
                <array name="shell_types" type="k3d::int32_t">
                        <xsl:value-of select="replace(replace(text(), 'polygons', '0'), 'catmull_clark', '1')"/>
                </array>
        </xsl:template>
       
        <!-- Conversion of attribute arrays -->
        <xsl:template match="constant_data | uniform_data | face_varying_data">
                <arrays>
                        <xsl:attribute name="type"><xsl:value-of select="replace(name(), '_data', '')"/></xsl:attribute>
                        <xsl:apply-templates/>
                </arrays>
        </xsl:template>
</xsl:stylesheet>
------------------------------------------------------------------------------

_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> To ease the transition of some tests to generic primitives, I made an
> XSLT converter that takes a pre-generic primitive polyhedron mesh and
> translates it to a generic mesh. Is there any interest in adding this
> to the source tree, and if so, where should it be put?
>
> The file is attached, it can be used with an XSLT 2.0 processor such as saxonb.

I like the compactness of the XSLT, I wish we could use it for all
document upgrades, unfortunately I think it's a bit of a half-measure -
not acceptable for end-users as a separate tool.  If you have thoughts
on how we could incorporate this into the C++, I'd be very interested.

Cheers,
Tim


[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
url:www.k-3d.org
version:2.1
end:vcard

---

------------------------------------------------------------------------------

_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Thu, Jun 25, 2009 at 6:46 AM, Timothy M. Shead<tshead@...> wrote:
> I like the compactness of the XSLT, I wish we could use it for all
> document upgrades, unfortunately I think it's a bit of a half-measure -
> not acceptable for end-users as a separate tool.  If you have thoughts
> on how we could incorporate this into the C++, I'd be very interested.

One way to integrate this on the high level would be to create a
plugin that has three file properties:
- input file
- xslt file
- output file
That way, any XML transformation can be incorporated into the pipeline.

On the practical side, the problem is poor XSLT 2.0 support here.
Saxonb, which is a Java program, seems to be the only viable
implementation. This can of course still be called as an external
program, but it seems a bit messy to me, although almost everyone
should have java, so the Saxonb jar would not be much overhead.

Cheers,

--
Bart

------------------------------------------------------------------------------
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> On Thu, Jun 25, 2009 at 6:46 AM, Timothy M. Shead<tshead@...> wrote:
>> I like the compactness of the XSLT, I wish we could use it for all
>> document upgrades, unfortunately I think it's a bit of a half-measure -
>> not acceptable for end-users as a separate tool.  If you have thoughts
>> on how we could incorporate this into the C++, I'd be very interested.
>
> One way to integrate this on the high level would be to create a
> plugin that has three file properties:
> - input file
> - xslt file
> - output file
> That way, any XML transformation can be incorporated into the pipeline.
>
> On the practical side, the problem is poor XSLT 2.0 support here.
> Saxonb, which is a Java program, seems to be the only viable
> implementation. This can of course still be called as an external
> program, but it seems a bit messy to me, although almost everyone
> should have java, so the Saxonb jar would not be much overhead.

To clarify - I don't know whether XSLT is the right tool for the job or
not - I think there may be limitations on what can be expressed in XSLT;
there have been other attempts at XML-transformation languages, maybe
there's a library out there that we could incorporate.  Suggestions
definitely welcome ...

Cheers,
Tim

[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
url:www.k-3d.org
version:2.1
end:vcard

---

------------------------------------------------------------------------------

_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Daniel Scott Matthews]

On Sun, Jun 28, 2009 at 1:27 AM, Timothy M. Shead<tshead@...> wrote:
> To clarify - I don't know whether XSLT is the right tool for the job or
> not - I think there may be limitations on what can be expressed in XSLT;
> there have been other attempts at XML-transformation languages, maybe
> there's a library out there that we could incorporate.  Suggestions
> definitely welcome ...
>

http://www.cduce.org/ or http://xduce.sourceforge.net ?

------------------------------------------------------------------------------
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Sat, Jun 27, 2009 at 11:10 PM, Daniel Scott
Matthews<dsmatthews@...> wrote:
> On Sun, Jun 28, 2009 at 1:27 AM, Timothy M. Shead<tshead@...> wrote:
>> To clarify - I don't know whether XSLT is the right tool for the job or
>> not - I think there may be limitations on what can be expressed in XSLT;
>> there have been other attempts at XML-transformation languages, maybe
>> there's a library out there that we could incorporate.  Suggestions
>> definitely welcome ...
>>
>
> http://www.cduce.org/ or http://xduce.sourceforge.net ?

These look good as well, but I think they're not as mainstream as
XSLT. From my experience, XSLT (especially 2.0) is pretty powerful.
Are there any concrete use cases where you think it might fall short?

Cheers,

--
Bart

------------------------------------------------------------------------------
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Daniel Scott Matthews]

On Sun, Jun 28, 2009 at 11:05 PM, Bart Janssens
<bart.janssens@...> wrote:

>
> On Sat, Jun 27, 2009 at 11:10 PM, Daniel Scott
> Matthews<dsmatthews@...> wrote:
> > On Sun, Jun 28, 2009 at 1:27 AM, Timothy M. Shead<tshead@...> wrote:
> >> To clarify - I don't know whether XSLT is the right tool for the job or
> >> not - I think there may be limitations on what can be expressed in XSLT;
> >> there have been other attempts at XML-transformation languages, maybe
> >> there's a library out there that we could incorporate.  Suggestions
> >> definitely welcome ...
> >>
> >
> > http://www.cduce.org/ or http://xduce.sourceforge.net ?
>
> These look good as well, but I think they're not as mainstream as
> XSLT. From my experience, XSLT (especially 2.0) is pretty powerful.
> Are there any concrete use cases where you think it might fall short?
>

Not really, it is probably Turing complete, are speed and being type
safe important?

------------------------------------------------------------------------------
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Daniel Scott Matthews wrote:

> On Sun, Jun 28, 2009 at 11:05 PM, Bart Janssens
> <bart.janssens@...> wrote:
>> On Sat, Jun 27, 2009 at 11:10 PM, Daniel Scott
>> Matthews<dsmatthews@...> wrote:
>>> On Sun, Jun 28, 2009 at 1:27 AM, Timothy M. Shead<tshead@...> wrote:
>>>> To clarify - I don't know whether XSLT is the right tool for the job or
>>>> not - I think there may be limitations on what can be expressed in XSLT;
>>>> there have been other attempts at XML-transformation languages, maybe
>>>> there's a library out there that we could incorporate.  Suggestions
>>>> definitely welcome ...
>>>>
>>> http://www.cduce.org/ or http://xduce.sourceforge.net ?
>> These look good as well, but I think they're not as mainstream as
>> XSLT. From my experience, XSLT (especially 2.0) is pretty powerful.
>> Are there any concrete use cases where you think it might fall short?
>>
> Not really, it is probably Turing complete, are speed and being type
> safe important?

Apologies for my lack of clarity earlier.  Let me say this: handling
legacy data will always be critically important for users, so it needs
to be built into the application in a comprehensive way and not a
separate tool.  We currently have a reasonable approach for "upgrading"
legacy data in C++, but it involves hard-to-write / hard-to-comprehend
manual processing of the XML tree that is really verbose / fiddly.  XSLT
is nice, because it can be very compact and easy to understand for some
problems, but not others.  What I wish existed for C++ was some library
equivalent to Amara, see

http://xml3k.org/Amara

... what I like about Amara is that it provides a nice interface between
the "host" language (Python) and the XML, without creating
yet-another-procesing-language.  I might try to adapt some Amara-like
features to our XML layer and see whether that helps.

And while I'm on a tear, see

http://www.ibm.com/developerworks/library/x-xml2008prevw.html?ca=dgr-lnxw01XML-Future

for an interesting read on XML.

Cheers,
Tim


[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
url:www.k-3d.org
version:2.1
end:vcard

---

------------------------------------------------------------------------------

_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Timothy M. Shead wrote:

> What I wish existed for C++ was some library
> equivalent to Amara, see
>
> http://xml3k.org/Amara
>
> ... what I like about Amara is that it provides a nice interface between
> the "host" language (Python) and the XML, without creating
> yet-another-procesing-language.  I might try to adapt some Amara-like
> features to our XML layer and see whether that helps.

Following-up, I've added a (minimal subset of a) XPath parser using
Boost.Spirit, and I'm pretty pleased with the results: half our upgrade
functions have been reduced to exactly six lines of code apiece.  The
other half won't reduce quite so dramatically, but should still get much
simpler and easier to understand.  Bart: looking back at your XSLT
templates I see that we need to support a broader subset of XPath, but
could you take a look and see what you think?

Cheers,
Tim

[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
url:www.k-3d.org
version:2.1
end:vcard

---

------------------------------------------------------------------------------

_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Wed, Jul 1, 2009 at 4:16 AM, Timothy M. Shead<tshead@...> wrote:

> Timothy M. Shead wrote:
>
>> What I wish existed for C++ was some library
>> equivalent to Amara, see
>>
>> http://xml3k.org/Amara
>>
>> ... what I like about Amara is that it provides a nice interface between
>> the "host" language (Python) and the XML, without creating
>> yet-another-procesing-language.  I might try to adapt some Amara-like
>> features to our XML layer and see whether that helps.
>
> Following-up, I've added a (minimal subset of a) XPath parser using
> Boost.Spirit, and I'm pretty pleased with the results: half our upgrade
> functions have been reduced to exactly six lines of code apiece.  The
> other half won't reduce quite so dramatically, but should still get much

Cool!

> simpler and easier to understand.  Bart: looking back at your XSLT
> templates I see that we need to support a broader subset of XPath, but
> could you take a look and see what you think?

I haven't looked into it in detail, but my XPath skills are limited,
so I don't know if what I did in XSLT was the best approach. The thing
I like most about XSLT is the template applications, which avoid
needing to write the loops yourself.

Ideally, I'd like to convert some of your code to XSLT, and then see
how the two compare. In the long run, having a solution that uses
standard building blocks for XML-related operations seems like the
best thing to do, but it does have to do what we need, obviously.

I'm currently working on the ATK stuff, because I wanted to have a UI
test for the move tool before touching TweakPoints, and I think I'm
pretty close to having something that works.

Cheers,

--
Bart

------------------------------------------------------------------------------
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> I'm currently working on the ATK stuff, because I wanted to have a UI
> test for the move tool before touching TweakPoints, and I think I'm
> pretty close to having something that works.

Cool ... what does this entail?

Cheers,
Tim

[tshead.vcf]

---

begin:vcard
fn:Timothy Shead
n:Shead;Timothy
org:www.k-3d.org
email;internet:tshead@...
title:Founder
x-mozilla-html:FALSE
url:www.k-3d.org
version:2.1
end:vcard

---

------------------------------------------------------------------------------

_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Sun, Jul 5, 2009 at 7:19 PM, Timothy M. Shead<tshead@...> wrote:
>
> Bart Janssens wrote:
>
>> I'm currently working on the ATK stuff, because I wanted to have a UI
>> test for the move tool before touching TweakPoints, and I think I'm
>> pretty close to having something that works.
>
> Cool ... what does this entail?

I've adapted the ATK Event recorder to output only clicks on buttons
and menu items, and created very basic python bindings to replay the
output. The output from the recorder can be pasted into the Python
shell, and the action should happen. Example:
k3d.atk.root()["Untitled Document 1 -
K-3D"][0][1][0][0][0][1][0][0][1]["Create"][0][0][0].click()
should create a Polycube.

The commands themselves are a trace of all ATK objects up to the root.
If the object has a name, it is used as key, if not the index in the
parent is used. I the long term, all ATK objects within a parent
should get a unique name, given at widget construction time in the
NGUI code. I intend to tackle this on an as-needed, per-test basis.

The code will be available at http://k3d-bart.googlecode.com
(changeset 5b8e169dee09), assuming the push doesn't crash while I
sleep.

Cheers,

--
Bart

------------------------------------------------------------------------------
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Sun, Jul 5, 2009 at 11:09 PM, Bart Janssens<bart.janssens@...> wrote:

> I've adapted the ATK Event recorder to output only clicks on buttons
> and menu items, and created very basic python bindings to replay the
> output. The output from the recorder can be pasted into the Python
> shell, and the action should happen. Example:
> k3d.atk.root()["Untitled Document 1 -
> K-3D"][0][1][0][0][0][1][0][0][1]["Create"][0][0][0].click()
> should create a Polycube.
>
> The commands themselves are a trace of all ATK objects up to the root.
> If the object has a name, it is used as key, if not the index in the
> parent is used. I the long term, all ATK objects within a parent
> should get a unique name, given at widget construction time in the
> NGUI code. I intend to tackle this on an as-needed, per-test basis.

Tim:

Have you had a chance to take a look at this yet? I'd like to make a
UI test for some of the tools before starting on the update of
TweakPoints, but I need to be sure the Python ATK interface is going
in the right direction.

Cheers,

--
Bart

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

> On Sun, Jul 5, 2009 at 11:09 PM, Bart Janssens<bart.janssens@...> wrote:
>  
>> I've adapted the ATK Event recorder to output only clicks on buttons
>> and menu items, and created very basic python bindings to replay the
>> output. The output from the recorder can be pasted into the Python
>> shell, and the action should happen. Example:
>> k3d.atk.root()["Untitled Document 1 -
>> K-3D"][0][1][0][0][0][1][0][0][1]["Create"][0][0][0].click()
>> should create a Polycube.
>>
>> The commands themselves are a trace of all ATK objects up to the root.
>> If the object has a name, it is used as key, if not the index in the
>> parent is used. I the long term, all ATK objects within a parent
>> should get a unique name, given at widget construction time in the
>> NGUI code. I intend to tackle this on an as-needed, per-test basis.
>>    
>
> Tim:
>
> Have you had a chance to take a look at this yet? I'd like to make a
> UI test for some of the tools before starting on the update of
> TweakPoints, but I need to be sure the Python ATK interface is going
> in the right direction.
>
>  

Sorry for the slow response, I'm building a new system and haven't taken
a look at the code; the description sounds fine, though my hope was that
we might be able to use an existing Python / ATK bridge, even if we had
to do our own recording - did you look into the existing Python work?

As far as unique keys go, that's an expected problem (this is what
command-nodes used to solve).  You might consider using a combination of
widget class (I'm assuming it's available from ATK) and a unique number
for your keys.  So

["menubar1"]["menu2"]["menu1"]["Copy"]

Also, it would be interesting to look at alternative syntax, perhaps

menubar(1).menu(2).menu(1).menuitem("Copy")

... which would be more in the spirit of the rest of the Python API.

Cheers,
Tim



------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Sun, Jul 12, 2009 at 7:56 AM, Timothy M. Shead<tshead@...> wrote:
> Sorry for the slow response, I'm building a new system and haven't taken
> a look at the code; the description sounds fine, though my hope was that
> we might be able to use an existing Python / ATK bridge, even if we had
> to do our own recording - did you look into the existing Python work?

Yes, and I failed to get it to work. Getting our own binding seems
like much less hassle, and it should all remain confined to a simple
extra Python namespace in the k3d module.

> As far as unique keys go, that's an expected problem (this is what
> command-nodes used to solve).  You might consider using a combination of
> widget class (I'm assuming it's available from ATK) and a unique number
> for your keys.  So
>
> ["menubar1"]["menu2"]["menu1"]["Copy"]

Yes, this would be more readable. However, it's not a robust solution:
if a widget gets inserted, the numbering changes and the scrips break.
This means that whenever a UI test is written, we should make sure
stable names are defined for all AtkObjects in the path. In time, this
should get most of the UI covered. The index-based system remains
useful in case someone wants to do a quick script without modifying
the C++ code.

> Also, it would be interesting to look at alternative syntax, perhaps
>
> menubar(1).menu(2).menu(1).menuitem("Copy")

I propose to add attributes, since these are trivial to add at runtime
using setattr. We would then get:
menubar1.menu2.menu1.copy
I suggest making all names conform to certain guidelines that make
them suitable as attribute names in Python. The wrapping function for
ATK objects will scan the children, and use the object name if it is
suitable and unique, or create a unique name of the form <widget
type><index>. AtkActions are also detected, and for each action a
function is added, i.e. click().

Cheers,

--
Bart

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart Janssens wrote:

>> As far as unique keys go, that's an expected problem (this is what
>> command-nodes used to solve).  You might consider using a combination of
>> widget class (I'm assuming it's available from ATK) and a unique number
>> for your keys.  So
>>
>> ["menubar1"]["menu2"]["menu1"]["Copy"]
>>    
>
> Yes, this would be more readable. However, it's not a robust solution:
> if a widget gets inserted, the numbering changes and the scrips break.
> This means that whenever a UI test is written, we should make sure
> stable names are defined for all AtkObjects in the path. In time, this
> should get most of the UI covered. The index-based system remains
> useful in case someone wants to do a quick script without modifying
> the C++ code.
>  

There's no perfect way to handle this - no matter how robust your
scheme, you can always make a change that's big enough to break tests.  
So with that in mind:

The index-based naming system is less robust, since any addition /
change / reordering of widgets can break a test.

The alternative proposal is more robust, because you have a two-level
hierarchy of widget type / index within that type.  This significantly
reduces (doesn't eliminate) the possibility of breakage, since many
changes (involving other widgets) would no longer affect the order of
widgets of a given type.

>> Also, it would be interesting to look at alternative syntax, perhaps
>>
>> menubar(1).menu(2).menu(1).menuitem("Copy")
>>    
>
> I propose to add attributes, since these are trivial to add at runtime
> using setattr. We would then get:
> menubar1.menu2.menu1.copy
>  
The problem with attributes is that they aren't used anywhere else in
the Python API.  Also, you don't need to dynamically add stuff with the
proposed methods ... given a Python ATK object, I imagine that

object.menubar()

returns all menubars,

object.menubar(1)

returns the second menubar, and

object.menubar("foo")

returns the menubar with ATK name "foo".  Those methods could be
statically bound at compile-time, since the set of ATK widget types is
limited.

> I suggest making all names conform to certain guidelines that make
> them suitable as attribute names in Python. The wrapping function for
> ATK objects will scan the children, and use the object name if it is
> suitable and unique, or create a unique name of the form <widget
> type><index>. AtkActions are also detected, and for each action a
> function is added, i.e. click().
>  
Agreed, sounds like a winner.

Cheers,
Tim


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[Timothy M. Shead]

Bart:

You will note from the dashboard that the Python ATK dependency is
causing problems on OSX:

http://www.k-3d.org/cdash/viewBuildError.php?buildid=2339

I've committed some reorganization of the Python object model to make
the dependency conditional, and cleanup the link errors.  Just a "heads
up" that it isn't tested on Win32 ...

Cheers,
Tim


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development

[bART Janssens-2]

On Tue, Jul 14, 2009 at 6:16 AM, Timothy M. Shead<tshead@...> wrote:
> object.menubar(1)
>
> returns the second menubar, and
>
> object.menubar("foo")
>
> returns the menubar with ATK name "foo".  Those methods could be
> statically bound at compile-time, since the set of ATK widget types is
> limited.

OK, thanks to boost::mpl, all types are now added automatically. The
ATK event recorder now also records scripts directly to an editor, and
the first ATK test (for the Move tool) is in my repository. Currently,
only click events are recorded, and the viewport (which I think will
be the most difficult part) is not yet treated.

The editor is mostly a copy/paste from the regular Python editor, it
would be better to have some common base class for both, probably.

I also had to modify the spin button control in order to avoid double
activation, you might want to check if this has any unwanted
side-effects.

Cheers,

--
Bart

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
K3d-development mailing list
K3d-development@...
https://lists.sourceforge.net/lists/listinfo/k3d-development