wxlua-users — wxLua list for users and developers

[Wxlua-users] some notes

[Francesco M. <f18...@ya...>]

Hi,
    the website FAQ has been completed. Please feel free to propose 
changes, more Q&A or anything else.

I've also completed the install.html file and autopackage spec file.

One thing I think still needs to be done is:
1) remove bindings/wxwidgets/fl.i
2) remove samples/fldemo.wx.lua

I mean: FL is old and unmaintained. And it's not built together with wx. 
  Currently it doesn't work with wxLua (since it should be moved to 
bindings/wxfl and a new module should be created, isn't it?) so I think 
it's best to just remove it...

Francesco

[Wxlua-users] Re: wxLua for wxMac

[Francesco M. <f18...@ya...>]

Anders F Björklund ha scritto:
> Francesco Montorsi wrote:
> 
>> I'm quite sure the patch is good. Unfortunately I haven't got a Mac to 
>> test it nor John or Klaas, I think so your help is very useful!
> 
> No problem, but some of the issues encountered should
> be present on all the platforms ? Especially these two:
> 1) wxluaedit.cpp patch 2) wxlua.cpp + wxlsock.cpp patch
the absence of __WXMAC__ symbols can only be noticed when compiling on 
Mac :)

the inclusion of lua internal.h is strange - we don't need it on win or 
unix.

Last the addition of the wxSTENotebook is probably not required using 
the latest wxStEdit from CVS...

> 
>> I see in patch tracker comment that you had to tweak the lua makefile. 
>> Why did you use it ?
>> the configure script should do all checks for you and it will produce 
>> a modules/Makefile which should build lua without using lua's own 
>> makefile (which is not generated through configure and is placed in 
>> modules\lua\Makefile).,,
> 
> Okay, maybe that was uncalled for then... :-)
> I'm just kinda used to patching Lua for the Mac,
> so it mostly went out of old habit or something.
> 
> (see http://www.algonet.se/~afb/lua/)
ok, could you please check out the latest CVS of wxLua and try the 
configure script on your Mac ?

It would be very useful to know how much portable it is...


> 
>> On my linux, wx-config --rezflags returns:
>>
>> @true
>> Warning: --rezflags, along with Mac OS classic resource building is 
>> deprecated.  You should remove this from your Makefile and build .app 
>> bundles instead.
>>
>> but I have no idea what .app bundles are.
> 
> Deprecated doesn't mean "dead", though... :-)
;)

> It still works. I did a write-up on the subject
> for the Code::Blocks wiki, maybe it helps you:
> 
> http://wiki.codeblocks.org/index.php?title=Compiling_Code::Blocks_in_Mac_OS_X#Bundle_application_for_Mac 
I'll look deeper into this ASAP

> 
> 
>> If you could help making mac installation smoother, it would be great !
> 
> Sure, I can make an installer for it. (eventually)
interesting !
I think adding a folder like build\macbundle containing all required 
files could be enough ?
Would you require any change in build system (i.e. Makefiles)?
We manage them using Bakefile so I can help with it...

Francesco

[Wxlua-users] Re: wxstedit and other link problems

[Francesco M. <f18...@ya...>]

klaas.holwerda ha scritto:
> Francesco Montorsi wrote:
>> it's possible but not that elegant:
>>
>>
>>   <set var="POSTFIX">
>>     <if cond="WX_SHARED=='0'">_lib</if>
>>     <if cond="WX_SHARED=='1'">_dll</if>
>>   </set>
>>   <if cond="FORMAT!='autoconf'">
>>     <set var="BUILDDIR">$(FORMAT)$(WXLIBPOSTFIX)$(POSTFIX)</set>
>>   </if>
> Maybe it is better to still do this one only for wxstedit for the 
> moment, i think it will prevent a lot of confusion.
you're right; I've committed this change in wxCode CVS repo.

John, could we make a new release (tarball+zip) of wxStEdit before wxLua 
is out so to avoid problems to our users ?

Francesco

Re: [Wxlua-users] Re: wxLua for wxMac

[<af...@al...>]

Francesco Montorsi wrote:

> I'm quite sure the patch is good. Unfortunately I haven't got a Mac to  
> test it nor John or Klaas, I think so your help is very useful!

No problem, but some of the issues encountered should
be present on all the platforms ? Especially these two:
1) wxluaedit.cpp patch 2) wxlua.cpp + wxlsock.cpp patch

> I see in patch tracker comment that you had to tweak the lua makefile.  
> Why did you use it ?
> the configure script should do all checks for you and it will produce  
> a modules/Makefile which should build lua without using lua's own  
> makefile (which is not generated through configure and is placed in  
> modules\lua\Makefile).,,

Okay, maybe that was uncalled for then... :-)
I'm just kinda used to patching Lua for the Mac,
so it mostly went out of old habit or something.

(see http://www.algonet.se/~afb/lua/)

> On my linux, wx-config --rezflags returns:
>
> @true
> Warning: --rezflags, along with Mac OS classic resource building is  
> deprecated.  You should remove this from your Makefile and build .app  
> bundles instead.
>
> but I have no idea what .app bundles are.

Deprecated doesn't mean "dead", though... :-)
It still works. I did a write-up on the subject
for the Code::Blocks wiki, maybe it helps you:

http://wiki.codeblocks.org/index.php?title=Compiling_Code:: 
Blocks_in_Mac_OS_X#Bundle_application_for_Mac

> If you could help making mac installation smoother, it would be great !

Sure, I can make an installer for it. (eventually)

--anders

[Wxlua-users] Re: wxLua for wxMac

[Francesco M. <f18...@ya...>]

Hi,

Anders F Björklund ha scritto:
> I've posted a patch to the SourceForge tracker
> with some changes needed for wxMac compilation...
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=1444354&group_id=140042&atid=745326 
Thanks !
I'm quite sure the patch is good. Unfortunately I haven't got a Mac to 
test it nor John or Klaas, I think so your help is very useful!

> Applying that, and messing around with the configuration
> (like adding Scintilla and wxStEdit to wx, for instance)
> makes it compile and work on Mac OS X as well as the others.
> (tested on Mac OS X 10.3 with wxWidgets 2.6.1 for "Carbon")
I see in patch tracker comment that you had to tweak the lua makefile. 
Why did you use it ?
the configure script should do all checks for you and it will produce a 
modules/Makefile which should build lua without using lua's own makefile 
(which is not generated through configure and is placed in 
modules\lua\Makefile).,,


> One needs to run the usual `wx-config --rezflags` on the
> exe/binaries or bundle them up, but that is standard on Mac.
On my linux, wx-config --rezflags returns:

@true
Warning: --rezflags, along with Mac OS classic resource building is 
deprecated.  You should remove this from your Makefile and build .app 
bundles instead.

but I have no idea what .app bundles are.

If you could help making mac installation smoother, it would be great !

Francesco

[Wxlua-users] Re: wxstedit

[Francesco M. <f18...@ya...>]

klaas.holwerda ha scritto:
> Hi,
> 
> So after building the right release stedit.lib and debug steditd.lib,
> i now am sure that the app_wxluaedit for all flavours debug take the 
> wrong stedit.lib.
> For debug it should take steditd.lib not stedit.lib.
> If i change that by hand it work at least for debug and release correctly.
sorry!
You're right stedit.lib was always used. Now it should use the [u][d] 
postfix when required... can you try it out again ?

Francesco

[Wxlua-users] wxstedit

[klaas.holwerda <kho...@xs...>]

Hi,

So after building the right release stedit.lib and debug steditd.lib,
i now am sure that the app_wxluaedit for all flavours debug take the 
wrong stedit.lib.
For debug it should take steditd.lib not stedit.lib.
If i change that by hand it work at least for debug and release correctly.

leafs only the warning:

LINK : warning LNK4089: all references to "OLEAUT32.dll" discarded by 
/OPT:REF



Klaas

[Wxlua-users] wxLua for wxMac

[<af...@al...>]

Hi,
I've posted a patch to the SourceForge tracker
with some changes needed for wxMac compilation...

http://sourceforge.net/tracker/index.php? 
func=detail&aid=1444354&group_id=140042&atid=745326

Some of it applied to the general parts of wxLua,
it was missing a declaration and some inlines ?


Applying that, and messing around with the configuration
(like adding Scintilla and wxStEdit to wx, for instance)
makes it compile and work on Mac OS X as well as the others.
(tested on Mac OS X 10.3 with wxWidgets 2.6.1 for "Carbon")

One needs to run the usual `wx-config --rezflags` on the
exe/binaries or bundle them up, but that is standard on Mac.


Thanks for a great package,
--anders
http://www.algonet.se/~afb/

Re: [Wxlua-users] Re: wxstedit and other link problems

[klaas.holwerda <kho...@xs...>]

Francesco Montorsi wrote:
> it's possible but not that elegant:
>
>
>   <set var="POSTFIX">
>     <if cond="WX_SHARED=='0'">_lib</if>
>     <if cond="WX_SHARED=='1'">_dll</if>
>   </set>
>   <if cond="FORMAT!='autoconf'">
>     <set var="BUILDDIR">$(FORMAT)$(WXLIBPOSTFIX)$(POSTFIX)</set>
>   </if>
Maybe it is better to still do this one only for wxstedit for the 
moment, i think it will prevent a lot of confusion.

Klaas

Re: [Wxlua-users] Re: release date (was Re: changelog)

[John L. <jla...@gm...>]

On 3/6/06, k. holwerda <kla...@nl...> wrote:
>
>
> Francesco Montorsi wrote:
>
> > since there is still the MSVC problem I propose to move the release
> > date to this friday: 10/3, do you agree ?

Yes, there's always things that could be tested and problems hopefully fixe=
d.

-John Labenski

Re: [Wxlua-users] Re: wxstedit and other link problems

[k. h. <kla...@nl...>]

Francesco Montorsi wrote:

>
>> Anyway, i think batch build is the only feasible way to work with the 
>> bakefile generated project files on  VC.
>
> I've never completely understood this: why do you need to build more 
> than one configuration with MSVC projects ?
> For testing or for development or both ?

I would prefer to build only one configuration like in Cmake their is 
the ALLBuild target, which buils all othere target for the active 
configuration set to the ALLBuild target.

The problem is that if you use wx project files, their is no such 
overall target.
So all seperate targets have to be set by hand to a certain active 
target, this is bad if there are many.
So one goes to batch build, and selects the configurations of all 
targets which need to be build.

No that is doable, although also not ideal, since there are many 
flavours for each target, you best deselect all flavours for all targets 
first, and next select the release and debug multilib targets, and build 
those for all targets.

(The trick to deselect all, is selecting the first and Shift select the 
last and press the space bar)

> To test if a project compiles and works in all configs I think it's 
> best to use command line makefiles where you can script all builds; 
> for development I usually use IDE too but I always select 1 config and 
> I've never used batch builds.

As i explained above, if there are many targets, how do you set all 
seperate targets right.

Testing using makefiles is oke, but of course the project files need to 
work too.
Also i see no reason why i need to type (n)make first on the command 
line and next open a project file to start developing where this is also 
part of the project file.
 I only use project files when i can ;-)

>
>>
> yes, you're right.
> But currently it would require do a lot of changes in all components 
> bakefiles which would then turn useless as soon as future versions of 
> bakefile are out. So I prefer to make the Big Step in wxCode only when 
> I'm sure that they will be permanent changes ;)

I think we better mention this in the install.html, because  it is 
confusing.
So we must tell that wxstedit needs to be compiled in only one flavour(  
debug or release and what about the rest? ).
And that only this flavours sshould be used in wxLua too. The other make 
no sence, even when using makefile right?
Because using a debug wxstedit in a release wxLua is also wrong.

>
>> Do you have any idea how we can speed up the patches for bakefile?
>
> maybe reporting that the patch worked for you could help... e.g.:
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1376223&group_id=83016&atid=568031 
>

Did it :-))

>
>
>> Is there only a time problem, or are there other issues?
>
> basically, it's a time problem of Vaclav. He said he won't give me CVS 
> (or better SVN now) access because my patches often needs fixes before 
> being applied. And that's true :(


> Sometimes is very difficult to foresee all situations where some code 
> could be used...

That i can understand. But not having time was for me the excuse to give 
many people access to wxArt2D.
No progress is worse then solving a problem here and there when it pops up.
Go with the flow is my moto, and it pays off, does it not  ;-)

Klaas




-- 
Unclassified

Re: [Wxlua-users] Re: release date (was Re: changelog)

[k. h. <kla...@nl...>]

Francesco Montorsi wrote:

> since there is still the MSVC problem I propose to move the release 
> date to this friday: 10/3, do you agree ?

Good idea, i will try to test some more the coming week,

Klaas

-- 
Unclassified

[Wxlua-users] Re: wxstedit and other link problems

[Francesco M. <f18...@ya...>]

k. holwerda ha scritto:
> 
> 
> Francesco Montorsi wrote:
> 
>>
>>
>> I'll check it in MSVC asap!
>> Francesco
> 
> I will check too, but this weekend CVS was down, which i realized after 
> i thrown away my current wxLua checkout :-(.
yes, I've got a ton of internet problems too this weekend: gmane did not 
work for a long time and probably also my ISP had some problem... this 
basically stopped me so I think it's better to fix another day for a 
release... see my other mail

> Anyway, i think batch build is the only feasible way to work with the 
> bakefile generated project files on  VC.
I've never completely understood this: why do you need to build more 
than one configuration with MSVC projects ?
For testing or for development or both ?
To test if a project compiles and works in all configs I think it's best 
to use command line makefiles where you can script all builds; for 
development I usually use IDE too but I always select 1 config and I've 
never used batch builds.

> If not one has to set the active configuration by hand . Ths evening i 
> will check this evening is this is also the case for dependency projects.
> It would indeed be nice if wxCode used the same system as wxLua.
yes, you're right.
But currently it would require do a lot of changes in all components 
bakefiles which would then turn useless as soon as future versions of 
bakefile are out. So I prefer to make the Big Step in wxCode only when 
I'm sure that they will be permanent changes ;)

> Do you have any idea how we can speed up the patches for bakefile?
maybe reporting that the patch worked for you could help... e.g.:

http://sourceforge.net/tracker/index.php?func=detail&aid=1376223&group_id=83016&atid=568031


> Is there only a time problem, or are there other issues?
basically, it's a time problem of Vaclav. He said he won't give me CVS 
(or better SVN now) access because my patches often needs fixes before 
being applied. And that's true :(
Sometimes is very difficult to foresee all situations where some code 
could be used...

Francesco

[Wxlua-users] Re: release date (was Re: changelog)

[Francesco M. <f18...@ya...>]

Hi,

John Labenski ha scritto:
>>>> So that we can have some user feedback for the upcoming 2.6.3.0... ;)
>>> Agreed.
>> in this case, can we fix a release date ?
>> I would make 2.6.2.0 the 6/03, this monday. I'll be available all the
>> morning so I'll be able to do all packaging steps and upload archives to
>> SF release system...
> 
> Ok, sounds good. I'll try to be all done by monday. I can only test in
> MSW on monday though, unless I can get a machine here working again.
since there is still the MSVC problem I propose to move the release date 
to this friday: 10/3, do you agree ?

Francesco

Re: [Wxlua-users] Re: wxstedit and other link problems

[k. h. <kla...@nl...>]

Francesco Montorsi wrote:

>
>
> I'll check it in MSVC asap!
> Francesco

I will check too, but this weekend CVS was down, which i realized after 
i thrown away my current wxLua checkout :-(.
Anyway, i think batch build is the only feasible way to work with the 
bakefile generated project files on  VC.
If not one has to set the active configuration by hand . Ths evening i 
will check this evening is this is also the case for dependency projects.
It would indeed be nice if wxCode used the same system as wxLua.
Do you have any idea how we can speed up the patches for bakefile?
Is there only a time problem, or are there other issues?

Klaas


-- 
Unclassified

[Wxlua-users] Re: wxstedit and other link problems

[Francesco M. <f18...@ya...>]

[sending 2nd time - Gmane did not get the first message]

klaas.holwerda ha scritto:
> John Labenski wrote:
>> On 3/4/06, klaas.holwerda 
>> <kho...@xs...> wrote:
>>  
>>> And indeed app_wxluaedit app crashes in the class RTTI initalization
>>> stuff again.
>>> This is for sure because of the warning below. It must be somewhere
>>> solved in bakefile.
>>>    
>>>> --------------------Configuration: wxstedit - Win32
>>>> Debug--------------------
>>>> Linking...
>>>> LINK : warning LNK4098: defaultlib "MSVCRTD" conflicts with use of
>>>> other libs; use /NODEFAULTLIB:library
>>>>       
>>
>> I think this is because you have compiled wxStEdit in RELEASE?
>> Unfortunately the wxStEdit build files only output to a single dir so
>> you have to completely! clean it out and rebuild it.
>>   
> No this should not be the case, i have a steditd.lib and a stedit.lib. 
> And i used batch build.
> BUT it looks there is something not right. Since if i just force the 
> active configuration to build in debug, and rebuild all,
> i can also run app_wxluaedit (after a rebuild) without problem.
> At least what i saw in wxLua is that stedit.lib is linked always, i 
> changed it by hand to use wxsteditd.lib.
> But looking at the size of wxsteditd.lib and wxstedit.lib they are eqaul 
> ( binary too ).
> I am confused.
I'm not sure how batch builds work but as John said, wxStEdit object
files always go in the same folder so, unless MSVC does a 'clean
project' command between two builds automatically, the batch builds are
going to overlap...

I'll check it in MSVC asap!
Francesco

[Wxlua-users] Re: wxstedit and other link problems

[Francesco M. <f18...@ya...>]

[sending 2nd time - Gmane did not get the first message]

John Labenski ha scritto:
> I'm just using the wxCode bakefiles and I don't think there's a way to
> separate the output of the build files? Francesco, is that right? I've
> used the bakefiles for your projects as a starting point, but maybe
> I've missed something.
it's possible but not that elegant:


   <set var="POSTFIX">
     <if cond="WX_SHARED=='0'">_lib</if>
     <if cond="WX_SHARED=='1'">_dll</if>
   </set>
   <if cond="FORMAT!='autoconf'">
     <set var="BUILDDIR">$(FORMAT)$(WXLIBPOSTFIX)$(POSTFIX)</set>
   </if>

I plan to revolutionate all wxCode bakefiles as soon as my patches are
integrated in bakefile. Then, to setup a 'standard' component (i.e. a
component using standard folders like src/ and include/) only few lines
will be necessary in component's bakefiles to setup a powerful build
system like the one we currently have in wxLua ;)

Francesco

[Wxlua-users] Re: Updated XXX_rules.lua files for clarity and consistency

[Francesco M. <f18...@ya...>]

[sending 2nd time - Gmane did not get the first message]

John Labenski ha scritto:
> I have made some rather big changes to the rules files, but I hope
> everyone will agree that it's better to do it now than later. I think
> the variable names and comments make things a lot more clear. Let me
> know if anything is still not obvious or if something doesn't work.
now they look much easier to understand!
This will help indeed who is going to write his own rules.lua files !

Keep up the good work,
Francesco

[Wxlua-users] Re: screenshot wxluacan

[Francesco M. <f18...@ya...>]

[sending 2nd time - Gmane did not get the first message]

Francesco Montorsi ha scritto:
> Hi,
> 
> klaas.holwerda ha scritto:
>> Hi,
>>
>> I modified wxluacan a bit, it has now two types of luascript objects.
>> One that is fast, since it only load the script once and adds all 
>> drawing as childs objects to a group.
>> And the other use wxlua to draw the  object again and again.
>>
>> Here is a screenshot:
>>
>> http://www.xs4all.nl/~kholwerd/tmp/wxluacan.png
>>
>> I think it can be added like this?
> nice !
> I've added it to the screenshot page.
> I won't have time to take screenshots up to the end of this week... if 
> you want to take some others, just add them to the website/screenshots 
> folder adding a "_gtk2.png" or "_win.png" prefix...
I've added some other screenshots and updated screenshots page to use
thumbnails for faster loading.

Francesco

[Wxlua-users] Re: wxstedit and other link problems

[Francesco M. <f18...@ya...>]

[sending 2nd time - Gmane did not get the first message]

klaas.holwerda ha scritto:
> Hi,
> 
> I thought i do a last test with VC6 ( only debug and release multilib ).
> 
> I see with wxStEdit from wxCode CVS, still this problem, i think this is 
> the same as we had some time ago.
> If it is already introduced here, later on in wxLua the problem will 
> stay, and eventually in wxArt2D it became a real problem.
> Francesco how did you solve it that time? Better do it here too.
sincerely I don't remember how I solved it :(

However, looking at DSP files for both wxLua and wxStEdit, I see that
there are no /NODEFAULTLIB switches inside them.

I thought the problem last time was because of the *presence* of those
switches.

For me it's a problem solve these 'bugs' because I don't have easy
access to Windows now that I work on linux only...

I'll let you know,
Francesco

[Wxlua-users] Re: wxstedit and other link problems

[Francesco M. <f18...@ya...>]

klaas.holwerda ha scritto:
> John Labenski wrote:
>> On 3/4/06, klaas.holwerda 
>> <kho...@xs...> wrote:
>>  
>>> And indeed app_wxluaedit app crashes in the class RTTI initalization
>>> stuff again.
>>> This is for sure because of the warning below. It must be somewhere
>>> solved in bakefile.
>>>    
>>>> --------------------Configuration: wxstedit - Win32
>>>> Debug--------------------
>>>> Linking...
>>>> LINK : warning LNK4098: defaultlib "MSVCRTD" conflicts with use of
>>>> other libs; use /NODEFAULTLIB:library
>>>>       
>>
>> I think this is because you have compiled wxStEdit in RELEASE?
>> Unfortunately the wxStEdit build files only output to a single dir so
>> you have to completely! clean it out and rebuild it.
>>   
> No this should not be the case, i have a steditd.lib and a stedit.lib. 
> And i used batch build.
> BUT it looks there is something not right. Since if i just force the 
> active configuration to build in debug, and rebuild all,
> i can also run app_wxluaedit (after a rebuild) without problem.
> At least what i saw in wxLua is that stedit.lib is linked always, i 
> changed it by hand to use wxsteditd.lib.
> But looking at the size of wxsteditd.lib and wxstedit.lib they are eqaul 
> ( binary too ).
> I am confused.
I'm not sure how batch builds work but as John said, wxStEdit object 
files always go in the same folder so, unless MSVC does a 'clean 
project' command between two builds automatically, the batch builds are 
going to overlap...

I'll check it in MSVC asap!
Francesco

[Wxlua-users] Re: wxstedit and other link problems

[Francesco M. <f18...@ya...>]

John Labenski ha scritto:
> I'm just using the wxCode bakefiles and I don't think there's a way to
> separate the output of the build files? Francesco, is that right? I've
> used the bakefiles for your projects as a starting point, but maybe
> I've missed something.
it's possible but not that elegant:


   <set var="POSTFIX">
     <if cond="WX_SHARED=='0'">_lib</if>
     <if cond="WX_SHARED=='1'">_dll</if>
   </set>
   <if cond="FORMAT!='autoconf'">
     <set var="BUILDDIR">$(FORMAT)$(WXLIBPOSTFIX)$(POSTFIX)</set>
   </if>

I plan to revolutionate all wxCode bakefiles as soon as my patches are 
integrated in bakefile. Then, to setup a 'standard' component (i.e. a 
component using standard folders like src/ and include/) only few lines 
will be necessary in component's bakefiles to setup a powerful build 
system like the one we currently have in wxLua ;)

Francesco

[Wxlua-users] Re: Updated XXX_rules.lua files for clarity and consistency

[Francesco M. <f18...@ya...>]

John Labenski ha scritto:
> I have made some rather big changes to the rules files, but I hope
> everyone will agree that it's better to do it now than later. I think
> the variable names and comments make things a lot more clear. Let me
> know if anything is still not obvious or if something doesn't work.
now they look much easier to understand!
This will help indeed who is going to write his own rules.lua files !

Keep up the good work,
Francesco

[Wxlua-users] Re: wxstedit and other link problems

[Francesco M. <f18...@ya...>]

klaas.holwerda ha scritto:
> Hi,
> 
> I thought i do a last test with VC6 ( only debug and release multilib ).
> 
> I see with wxStEdit from wxCode CVS, still this problem, i think this is 
> the same as we had some time ago.
> If it is already introduced here, later on in wxLua the problem will 
> stay, and eventually in wxArt2D it became a real problem.
> Francesco how did you solve it that time? Better do it here too.
sincerely I don't remember how I solved it :(

However, looking at DSP files for both wxLua and wxStEdit, I see that 
there are no /NODEFAULTLIB switches inside them.

I thought the problem last time was because of the *presence* of those 
switches.

For me it's a problem solve these 'bugs' because I don't have easy 
access to Windows now that I work on linux only...

I'll let you know,
Francesco

[Wxlua-users] Re: screenshot wxluacan

[Francesco M. <f18...@ya...>]

Francesco Montorsi ha scritto:
> Hi,
> 
> klaas.holwerda ha scritto:
>> Hi,
>>
>> I modified wxluacan a bit, it has now two types of luascript objects.
>> One that is fast, since it only load the script once and adds all 
>> drawing as childs objects to a group.
>> And the other use wxlua to draw the  object again and again.
>>
>> Here is a screenshot:
>>
>> http://www.xs4all.nl/~kholwerd/tmp/wxluacan.png
>>
>> I think it can be added like this?
> nice !
> I've added it to the screenshot page.
> I won't have time to take screenshots up to the end of this week... if 
> you want to take some others, just add them to the website/screenshots 
> folder adding a "_gtk2.png" or "_win.png" prefix...
I've added some other screenshots and updated screenshots page to use 
thumbnails for faster loading.

Francesco