wxlua-users Mailing List for wxLua (Page 3)

Klaas Holwerda wrote:
> John Labenski wrote:
>
>>
>> I will start using SVN, I'm not sure why people like it so much, but
>> it seems like the way to go.
>
> And better first read this, before you do. Line endings!
>
> http://www.zope.org/DevHome/Subversion/SubversionConfigurationForLineEndings 
>
And currently using this script to correct all files, and set the 
property for files already in svn.
On Unix i run it, and i see them on windows appearing after an update, 
so it seems to work.
But need to check a bit more, since files still are LF only on windows, 
maybe a new checkout??

#!/bin/sh

# This script normalizes the newlines in all files in
# a directory and adds the svn:eol-style property
# Author: Ben Wolfe - 10/2008
# Made recursive Klaas Holwerda

path=`pwd`

# get a flat list of all files under the current directory



echo create filelist from $SOURCEDIR
find -name \.svn -prune -o -name *.bak -o -name .#* -o -type f -print  > 
filelist.txt

filelist=`cat filelist.txt`

for i in $filelist
do
    #check subversion for this property
    x=`svn propget svn:eol-style $i`
    if [ ! -n "$x" ]
    then
            # get the file's extension
            ext=`echo "$i" | awk -F . '{print $NF}'`

            # This is an "if list contains" method for shell scripts
            # check if ext is one of the text based extensions
            case $ext in
                    
java|jsp|css|js|xml|sql|txt|properties|tld|tag|html|htm|sh|h|cpp|lua|inl|bat|xrc|c|xpm|cvg|svg|drx|drw|rc)
                            #echo No svn:eol-style prop: $i . Adding now.
                            dos2unix -a $i
                            svn propset svn:eol-style "native" $i
                            ;;
                    *)
                            echo not handled extension: $ext $i
                            ;;
            esac
    fi
done

echo "done"

John Labenski wrote:

> 
> I will start using SVN, I'm not sure why people like it so much, but
> it seems like the way to go.

And better first read this, before you do. Line endings!

http://www.zope.org/DevHome/Subversion/SubversionConfigurationForLineEndings

I think i now need to set them by hand.

Klaas


-- 
Unclassified


------------------------------------------------------------------------------------------------------------
Disclaimer:

If you are not the intended recipient of this email, please notify the sender and delete it. 
Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden. 
Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s). 
Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578.
------------------------------------------------------------------------------------------------------------

John Labenski wrote:
> On Mon, Oct 12, 2009 at 3:28 AM, Klaas Holwerda
> <db...@nl...> wrote:
>> John Labenski wrote:
>>> to make them work in both 2.8 and 2.9 since I think they'd be pretty
>>> unreadable by the time I'd be done.
>> Maybe its an idea to make two trees of binding files??
> 
> I will start using SVN, I'm not sure why people like it so much, but
> it seems like the way to go.

I meant only a seconds version for the bindings directory.
That way things get less fuzzy.

For wxAr2tD i switched to SVN last week. The best thing about SVN is moving 
files and directories becomes possible. Also the commit mail is one for every 
commit, not per file. I uses as client i use http://rapidsvn.tigris.org/ which 
works well.


> I think we can do away with %class %enum and use class and enum
> followed by { } instead of looking for %endclass and %endenum, change
> %define to #define, but we'll still need #define_string. Basically,
> make it as C/C++ like as possible. Many of the %XXX tags were made to
> catch errors and to be very easy to process.

But there is things like %rename %operator, but maybe even those can somehow be 
defined in the interface files. I see @python things like this in the interface 
*.h files.

         @beginWxPythonOnly
         In place of a single overloaded method name, wxPython implements the 
following methods:
             - ClientToScreen(point): Accepts and returns a wxPoint
             - ClientToScreenXY(x, y): Returns a 2-tuple, (x, y)
         @endWxPythonOnly


> I have yet to try generating the doxygen XML files, I think that's
> what you mean. Parsing the C++ might be just as easy, but we'll have
> to see.

I generated the XML from the files. Just a very small part down here.
Doxygen parses things well, and a lot of info is in there. Nice is that it 
already combines doxygen doc tags with the parameters. (imagine would could use 
them for in a binding, lua IDE, lua debugger ).
I think it would save time to use it. I wonder how good Lua is with XML, but i 
estimate that fits well. Still C++ would make things more structured and general 
to use i assume.

Anyway, it more a time problem, right! :-(

Regards,

Klaas

   <compounddef id="classwxColour" kind="class" prot="public">
     <compoundname>wxColour</compoundname>
     <basecompoundref refid="classwxObject" prot="public" 
virt="non-virtual">wxObject</basecompoundref>
     <includes refid="colour_8h" local="no">colour.h</includes>
       <sectiondef kind="user-defined">
       <memberdef kind="function" 
id="classwxColour_1362d7d0a873b770d6623d4cd547868a0" prot="public" static="no" 
const="no" explicit="no" inline="no" virt="non-virtual">
         <type>void</type>
         <definition>void wxColour::Set</definition>
         <argsstring>(unsigned char red, unsigned char green, unsigned char 
blue, unsigned char alpha=wxALPHA_OPAQUE)</argsstring>
         <name>Set</name>
         <param>
           <type>unsigned char</type>
           <declname>red</declname>
         </param>
         <param>
           <type>unsigned char</type>
           <declname>green</declname>
         </param>
         <param>
           <type>unsigned char</type>
           <declname>blue</declname>
         </param>
         <param>
           <type>unsigned char</type>
           <declname>alpha</declname>
           <defval>wxALPHA_OPAQUE</defval>
         </param>

-------------------
       <memberdef kind="function" 
id="classwxColour_1e114ff88fe3a07477d111baa01c1b325" prot="public" static="no" 
const="no" explicit="no" inline="no" virt="non-virtual">
         <type></type>
         <definition>wxColour::wxColour</definition>
         <argsstring>(const wxString &amp;colourName)</argsstring>
         <name>wxColour</name>
         <param>
           <type>const <ref refid="classwxString" 
kindref="compound">wxString</ref> &amp;</type>
           <declname>colourName</declname>
         </param>
         <briefdescription>
         </briefdescription>
         <detaileddescription>
<para><parameterlist kind="param"><parameteritem>
<parameternamelist>
<parametername>colourName</parametername>
</parameternamelist>
<parameterdescription>
<para>The colour name. </para></parameterdescription>
</parameteritem>
</parameterlist>
</para>        </detaileddescription>
         <inbodydescription>
         </inbodydescription>
         <location file="C:/data/art2d/wxWidgets-2.9.0/interface/wx/colour.h" 
line="77"/>
       </memberdef>




-- 
Unclassified


------------------------------------------------------------------------------------------------------------
Disclaimer:

If you are not the intended recipient of this email, please notify the sender and delete it. 
Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden. 
Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s). 
Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578.
------------------------------------------------------------------------------------------------------------

On Mon, Oct 12, 2009 at 3:28 AM, Klaas Holwerda
<db...@nl...> wrote:
> John Labenski wrote:
>>
>> to make them work in both 2.8 and 2.9 since I think they'd be pretty
>> unreadable by the time I'd be done.
>
> Maybe its an idea to make two trees of binding files??

I will start using SVN, I'm not sure why people like it so much, but
it seems like the way to go.

> What I want to do is to use the
>>
>> interface files that wxWidgets 2.9 uses to generate their docs. That's
>> going to be a big job since the generator will have to be completely
>> rewritten and they are going to have to be changed a bit. The idea is
>> that once we switch to their interface files we will no longer have to
>> maintain our own copy.
>
> I understand, but what i don;t understand is how you want to do it.
> How do you want to deal with all the %xxx directives. I assume they will
> still be needed??

I think we can do away with %class %enum and use class and enum
followed by { } instead of looking for %endclass and %endenum, change
%define to #define, but we'll still need #define_string. Basically,
make it as C/C++ like as possible. Many of the %XXX tags were made to
catch errors and to be very easy to process.

> Do you plan to do that in Lua or C++? If there would be a C++ solution, it
> might be usable for many other wrappers for wxWidgets.
> And that would be great for me :-)

Probably in Lua because it's so easy to create large complicated
tables of the data. I might be able to use quite a bit from the
current parser.

> I have a XML pull parser in wxArt2D, it might be easier in use then reading
> the complete DOM tree first, and parsing that. But i don't know.

I have yet to try generating the doxygen XML files, I think that's
what you mean. Parsing the C++ might be just as easy, but we'll have
to see.

Regards,
    John

John Labenski wrote:

> I tried compiling wxLua a long time ago with 2.9 and it was pretty
> bad. 

I am using just only a certain amount, and using some typedefs, i could deal 
with most problems.

I am really hesitant to hack away at the current bindings to try
> to make them work in both 2.8 and 2.9 since I think they'd be pretty
> unreadable by the time I'd be done. 

Maybe its an idea to make two trees of binding files??

What I want to do is to use the
> interface files that wxWidgets 2.9 uses to generate their docs. That's
> going to be a big job since the generator will have to be completely
> rewritten and they are going to have to be changed a bit. The idea is
> that once we switch to their interface files we will no longer have to
> maintain our own copy.

I understand, but what i don;t understand is how you want to do it.
How do you want to deal with all the %xxx directives. I assume they will still 
be needed??
Do you plan to do that in Lua or C++? If there would be a C++ solution, it might 
be usable for many other wrappers for wxWidgets.
And that would be great for me :-)

I have a XML pull parser in wxArt2D, it might be easier in use then reading the 
complete DOM tree first, and parsing that. But i don't know.

Regards,

Klaas

-- 
Unclassified


------------------------------------------------------------------------------------------------------------
Disclaimer:

If you are not the intended recipient of this email, please notify the sender and delete it. 
Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden. 
Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s). 
Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578.
------------------------------------------------------------------------------------------------------------

John Labenski wrote:

> 
> How do you declare your class in the interface files?

as next, and before that was oke, seems i was just lucky or there was no 
delete_function before.

%class a2dFeedbackIdPinMapping
%endclass

But now i changed it to this, and all is oke:

%class a2dCanvasObject::a2dFeedbackIdPinMapping
%endclass

Thanks,

Klaas



-- 
Unclassified


------------------------------------------------------------------------------------------------------------
Disclaimer:

If you are not the intended recipient of this email, please notify the sender and delete it. 
Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden. 
Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s). 
Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578.
------------------------------------------------------------------------------------------------------------

Sorry about the delay, this now works in CVS. Declare them in the
interface files as:

%define_object wxPoint wxDefaultPosition

Regards,
    John



On Wed, Sep 23, 2009 at 1:20 AM, John Labenski <jla...@gm...> wrote:
> On Tue, Sep 22, 2009 at 11:45 AM, Klaas Holwerda
> <db...@nl...> wrote:
>> Hi John,
>>
>> Is there a way to wrap the objects mentioned below in several wrap files?
>> The actual wrapping of the class is in one of them.
>> If this is not so simple, i will make a unique *.i file just for this class.
>> But it looks more like a general issue, so maybe it can be solved more
>> elegantly.
>
> I believe that it can be made to work. I just figured out how to
> implement dual base classes without too much overhead. I'll look into
> this next.
>
> Regards,
>    John
>

On Sun, Oct 11, 2009 at 3:38 PM, klaas.holwerda <ng...@kl...> wrote:
> Hi John,
>
> Did you already do something with 2.9?
> I was stuck with wxStEdit already. (most problems were very easy to
> solve stc2wx etc. just removed. But some lines/things i did not understand.
> Next would be wxLua, but since it depends on wxStEdit i wonder if i
> should give it a try already, or better wait.
> For wxArt2D it was just a few corrections and compiling for Unicode to
> make it work. Hopefully the  bakefile etc.  will  be oke in the same way.

I tried compiling wxLua a long time ago with 2.9 and it was pretty
bad. I am really hesitant to hack away at the current bindings to try
to make them work in both 2.8 and 2.9 since I think they'd be pretty
unreadable by the time I'd be done. What I want to do is to use the
interface files that wxWidgets 2.9 uses to generate their docs. That's
going to be a big job since the generator will have to be completely
rewritten and they are going to have to be changed a bit. The idea is
that once we switch to their interface files we will no longer have to
maintain our own copy.

Regards,
    John

On Sun, Oct 11, 2009 at 3:32 PM, klaas.holwerda <ng...@kl...> wrote:
> Hi John,
>
> Mostly want without a problem. But a nested class does not work anymore.
> Like:
> class A2DCANVASDLLEXP a2dCanvasObject: public a2dEvtHandler
> {
>    class A2DCANVASDLLEXP a2dFeedbackIdPinMapping : public a2dFeedbackId
> ...........
> The a2dFeedbackIdPinMapping class gets wrongly wrapped, down here
> a2dCanvasObject:: was missing.
> Don't know why it worked before.
>
> I get wrapped like:
>
> void wxLua_a2dFeedbackIdPinMapping_delete_function(void** p)
> {
>    a2dCanvasObject::a2dFeedbackIdPinMapping* o =
> (a2dCanvasObject::a2dFeedbackIdPinMapping*)(*p);
>    delete o;
> }

It should it be
wxLua_a2dCanvasObject_a2dFeedbackIdPinMapping_delete_function(). I
wonder why you don't get that. I just tried this and it seems to
generate the right code (though it can't compile).

%class %delete wxPoint::wxPointSub
    wxPoint::wxPointSub()
%endclass

How do you declare your class in the interface files?

Regards,
    John

Hi John,

Did you already do something with 2.9?
I was stuck with wxStEdit already. (most problems were very easy to 
solve stc2wx etc. just removed. But some lines/things i did not understand.
Next would be wxLua, but since it depends on wxStEdit i wonder if i 
should give it a try already, or better wait.
For wxArt2D it was just a few corrections and compiling for Unicode to 
make it work. Hopefully the  bakefile etc.  will  be oke in the same way.

Not in a hurry with this, just curious.

Klaas

Hi John,

Mostly want without a problem. But a nested class does not work anymore.
Like:
class A2DCANVASDLLEXP a2dCanvasObject: public a2dEvtHandler
{
    class A2DCANVASDLLEXP a2dFeedbackIdPinMapping : public a2dFeedbackId
...........

The a2dFeedbackIdPinMapping class gets wrongly wrapped, down here 
a2dCanvasObject:: was missing.
Don't know why it worked before.

I get wrapped like:

void wxLua_a2dFeedbackIdPinMapping_delete_function(void** p)
{
    a2dCanvasObject::a2dFeedbackIdPinMapping* o = 
(a2dCanvasObject::a2dFeedbackIdPinMapping*)(*p);
    delete o;
}

Regards,

Klaas



John Labenski wrote:
> You must remove the %encapsulate and %noclassinfo tags in your
> bindings if you use the current CVS and for the next wxLua version.
>
> I have finally got around to generating delete functions for each
> class instead of creating a wxObject subclass that would encapsulate
> and delete the member variable to the non-wxObject class wxLua wraps.
> The new way is faster, smaller, simpler, and more typesafe.
>   

You must remove the %encapsulate and %noclassinfo tags in your
bindings if you use the current CVS and for the next wxLua version.

I have finally got around to generating delete functions for each
class instead of creating a wxObject subclass that would encapsulate
and delete the member variable to the non-wxObject class wxLua wraps.
The new way is faster, smaller, simpler, and more typesafe.

The %noclassinfo tag is not necessary since if your bindings has the
correct inheritance hierarchy we know if it is derived from a
wxObject. There is no penalty if you decide to not expose to wxLua
that your class is derived from a wxObject, but you will be unable to
call wxDynamicCast() to change the type.

Regards,
    John