wxlua-users — wxLua list for users and developers

Re: [Wxlua-users] Re: bin2c.c doesn't compile in MSVC, do we even want it?

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

Francesco Montorsi wrote:
> John Labenski ha scritto:
>> In util/bin2c there is a program bin2c.c that can convert a file into
>> a const unsigned char* string to be loaded in a C program. I have
>> written a replacement bin2c.lua that is a lot more powerful, flexible,
>> and doesn't need to be compiled. I suggest that we remove bin2c.c and
>> the build files for it and keep only bin2c.lua in the util/bin2c
>> directory.
>>
>> Any objections?
No, never used sofar.

Klaas

[Wxlua-users] Re: bin2c.c doesn't compile in MSVC, do we even want it?

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

John Labenski ha scritto:
> In util/bin2c there is a program bin2c.c that can convert a file into
> a const unsigned char* string to be loaded in a C program. I have
> written a replacement bin2c.lua that is a lot more powerful, flexible,
> and doesn't need to be compiled. I suggest that we remove bin2c.c and
> the build files for it and keep only bin2c.lua in the util/bin2c
> directory.
> 
> Any objections?
No, any.

BTW maybe this should go in the changelog...
Francesco

[Wxlua-users] bin2c.c doesn't compile in MSVC, do we even want it?

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

In util/bin2c there is a program bin2c.c that can convert a file into
a const unsigned char* string to be loaded in a C program. I have
written a replacement bin2c.lua that is a lot more powerful, flexible,
and doesn't need to be compiled. I suggest that we remove bin2c.c and
the build files for it and keep only bin2c.lua in the util/bin2c
directory.

Any objections?

Regards,
    John Labenski

Re: [Wxlua-users] some notes

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

On 3/7/06, klaas.holwerda <kho...@xs...> wrote:
> John Labenski wrote:
> >
> > The plot.i file should also go into it's own directory. I see messages
> > on wx-users that people seem to use the plot widget every once in a
> > while. Maybe we should keep that, if nothing else it shows how easy it
> > is to make a binding for a outside library.
> > bindings/wxplot
> > modules/wxbindplot
> >
> I also like this idea, it sets the right approach for things to come,
> when more  modules  from e.g.  wxCode  get wrapped.

I was thinking about wrapping some of my things in wxCode, but I think
the best solution is to put the binding in the wxCode project. If we
start to have bindings for projects not maintained by anyone using
wxLua or the wxCode project regularly we can get out of sync and it'd
be burden on the wxLua maintainers to keep things up to date. Take for
example the FL stuff, I've never used it and have no way to test or do
anything with it, so it just languishes.

It may be more troublesome for people who want to build wxLua
themselves to have to get the other bindings running, but they'll have
to already have the wxCode c++ code anyway.

Regards,
    John Labenski

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

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

On 3/7/06, Francesco Montorsi <f18...@ya...> wrote:
> John Labenski ha scritto:
> > Francesco,  are there any other things that need to be fixed that you
> > haven't done yet?
> no; now wxLua should compile & work also on wxMac.
> We just need wxMac screenshots and packaging stuff :)

Great! That'd be pretty nice to get it going there too.

-John Labenski

[Wxlua-users] Re: wxLua for wxMac

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

John Labenski ha scritto:
> On 3/7/06, Francesco Montorsi <f18...@ya...> wrote:
>> Anders F Björklund ha scritto:
>>> Francesco Montorsi wrote:
>>>
>>>> I've checked in the __WXMAC__ changes and the inclusion of internal.h
>>>> but not these changes:
>>>>
>>>> +#ifndef __WXMAC__
>>>>      // call constructor
>>>>      returns = new wxDropSource(win, *iconCopy, *iconMove, *iconStop);
>>>> +#else
>>>> +    returns = new wxDropSource(win);
>>>> +#endif
>>>>
>>>> they affect automatically-generated files rather than their generators
>>>> and thus should be changed.
>>>> Why does Mac need this asimmetry ?
>>> Someone declared the Mac constructor with the wrong type arguments...
>>> The icons aren't being used anyway, so it's a pretty silly error :-)
>>>
>>>     // ctors: if you use default ctor you must call SetData() later!
>>>     //
>>>     // NB: the "wxWindow *win" parameter is unused and is here only for
>>> wxGTK
>>>     //     compatibility, as well as both icon parameters
>>>     wxDropSource( wxWindow *win = (wxWindow *)NULL,
>>>                  const wxCursor &cursorCopy = wxNullCursor,
>>>                  const wxCursor &cursorMove = wxNullCursor,
>>>                  const wxCursor &cursorStop = wxNullCursor);
>>>
>>> I thought it would be easiest to just *not* supply the icons on wxMac ?
>>> (BTW; You can peek at the Mac stuff for wxWidgets, it's in "mac/carbon")
>> This really looks as a bug in wxWidgets itself.
>> I think it would be difficult to handle this case nicely in wxLua
>> binding wrappers... it's probably better to submit a patch to wx devs
>> and ask them to apply it before 2.6.3...
>> if those icons aren't really used it should not be a big issue just
>> replacing wxCursor->wxIcon...
> 
> I did a fix for it in the binding files. Hopefully it'll work now.
> 
>     %win|%mac wxDropSource(wxWindow* win = NULL, const wxCursor&
> iconCopy = wxNullCursor, const wxCursor& iconMove = wxNullCursor,
> const wxCursor& iconStop = wxNullCursor)
> 
>     %gtk wxDropSource(wxWindow* win = NULL, const wxIcon& iconCopy =
> wxNullIcon, const wxIcon& iconMove = wxNullIcon, const wxIcon&
> iconStop = wxNullIcon)
very nice workaround but I'll send a mail to wxdev anyway.

> 
> Francesco,  are there any other things that need to be fixed that you
> haven't done yet?
no; now wxLua should compile & work also on wxMac.
We just need wxMac screenshots and packaging stuff :)

Francesco

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

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

On 3/7/06, Francesco Montorsi <f18...@ya...> wrote:
> Anders F Bj=F6rklund ha scritto:
> > Francesco Montorsi wrote:
> >
> >> I've checked in the __WXMAC__ changes and the inclusion of internal.h
> >> but not these changes:
> >>
> >> +#ifndef __WXMAC__
> >>      // call constructor
> >>      returns =3D new wxDropSource(win, *iconCopy, *iconMove, *iconStop=
);
> >> +#else
> >> +    returns =3D new wxDropSource(win);
> >> +#endif
> >>
> >> they affect automatically-generated files rather than their generators
> >> and thus should be changed.
> >> Why does Mac need this asimmetry ?
> >
> > Someone declared the Mac constructor with the wrong type arguments...
> > The icons aren't being used anyway, so it's a pretty silly error :-)
> >
> >     // ctors: if you use default ctor you must call SetData() later!
> >     //
> >     // NB: the "wxWindow *win" parameter is unused and is here only for
> > wxGTK
> >     //     compatibility, as well as both icon parameters
> >     wxDropSource( wxWindow *win =3D (wxWindow *)NULL,
> >                  const wxCursor &cursorCopy =3D wxNullCursor,
> >                  const wxCursor &cursorMove =3D wxNullCursor,
> >                  const wxCursor &cursorStop =3D wxNullCursor);
> >
> > I thought it would be easiest to just *not* supply the icons on wxMac ?
> > (BTW; You can peek at the Mac stuff for wxWidgets, it's in "mac/carbon"=
)
> This really looks as a bug in wxWidgets itself.
> I think it would be difficult to handle this case nicely in wxLua
> binding wrappers... it's probably better to submit a patch to wx devs
> and ask them to apply it before 2.6.3...
> if those icons aren't really used it should not be a big issue just
> replacing wxCursor->wxIcon...

I did a fix for it in the binding files. Hopefully it'll work now.

    %win|%mac wxDropSource(wxWindow* win =3D NULL, const wxCursor&
iconCopy =3D wxNullCursor, const wxCursor& iconMove =3D wxNullCursor,
const wxCursor& iconStop =3D wxNullCursor)

    %gtk wxDropSource(wxWindow* win =3D NULL, const wxIcon& iconCopy =3D
wxNullIcon, const wxIcon& iconMove =3D wxNullIcon, const wxIcon&
iconStop =3D wxNullIcon)


Francesco,  are there any other things that need to be fixed that you
haven't done yet?

Regards,
    John Labenski

[Wxlua-users] Re: wxluasudoku not running

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

John Labenski ha scritto:
> On 3/7/06, Francesco Montorsi <f18...@ya...> wrote:
>> Hi John,
>>     I see you added that very nice example and also a screenshot for
>> it... unfortunately it doesn't run on my linux with latest wxLua
>> compiled & installed:
>>
>> frm@genius:~/work/wxLua/samples$ wxlua wxluasudoku.wx.lua
>> wxLua: Syntax error during pre-compilation
>> wxluasudoku.wx.lua:193: malformed number near `9.1'
>> wxLua: Syntax error during pre-compilation
>>
>> Maybe the dot must be replaced with a comma ?
>> Doing the replace in line 193 makes wxLua complain for next occurrences
>> .... probably if I'd solve them all, it would just run.
>> What I do not understand is why it works with you ?
> 
> It works fine here, I want to divide by the number 9.1 = 91E-1.
> 
>> Could it be a locale problem ?
> 
> It seems like it is, I don't know how to solve it for you. Change you
> system locale to "C" maybe? I think that's what I use.
Changing locale it works.

there is something at bottom of
    http://www.lua.org/pil/22.2.html
but I've tried to run just 'lua' and not 'wxlua' and it accepts also 
dots as decimals... so the problem seems to be in wxLua or wxWidgets.
Searching for locale in wxLua gives few results and it looks like a 
wxLocale is never created in wxLua. Maybe it's some initialization stuff 
done by wx...

I'll try to dig in this problem..

Francesco

Re: [Wxlua-users] wxluasudoku not running

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

On 3/7/06, Francesco Montorsi <f18...@ya...> wrote:
> Hi John,
>     I see you added that very nice example and also a screenshot for
> it... unfortunately it doesn't run on my linux with latest wxLua
> compiled & installed:
>
> frm@genius:~/work/wxLua/samples$ wxlua wxluasudoku.wx.lua
> wxLua: Syntax error during pre-compilation
> wxluasudoku.wx.lua:193: malformed number near `9.1'
> wxLua: Syntax error during pre-compilation
>
> Maybe the dot must be replaced with a comma ?
> Doing the replace in line 193 makes wxLua complain for next occurrences
> .... probably if I'd solve them all, it would just run.
> What I do not understand is why it works with you ?

It works fine here, I want to divide by the number 9.1 =3D 91E-1.

> Could it be a locale problem ?

It seems like it is, I don't know how to solve it for you. Change you
system locale to "C" maybe? I think that's what I use.

Regards,
    John Labenski

[Wxlua-users] Re: wxLua for wxMac

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

Anders F Björklund ha scritto:
> Francesco Montorsi wrote:
> 
>> I've checked in the __WXMAC__ changes and the inclusion of internal.h 
>> but not these changes:
>>
>> +#ifndef __WXMAC__
>>      // call constructor
>>      returns = new wxDropSource(win, *iconCopy, *iconMove, *iconStop);
>> +#else
>> +    returns = new wxDropSource(win);
>> +#endif
>>
>> they affect automatically-generated files rather than their generators 
>> and thus should be changed.
>> Why does Mac need this asimmetry ?
> 
> Someone declared the Mac constructor with the wrong type arguments...
> The icons aren't being used anyway, so it's a pretty silly error :-)
> 
>     // ctors: if you use default ctor you must call SetData() later!
>     //
>     // NB: the "wxWindow *win" parameter is unused and is here only for 
> wxGTK
>     //     compatibility, as well as both icon parameters
>     wxDropSource( wxWindow *win = (wxWindow *)NULL,
>                  const wxCursor &cursorCopy = wxNullCursor,
>                  const wxCursor &cursorMove = wxNullCursor,
>                  const wxCursor &cursorStop = wxNullCursor);
> 
> I thought it would be easiest to just *not* supply the icons on wxMac ?
> (BTW; You can peek at the Mac stuff for wxWidgets, it's in "mac/carbon")
This really looks as a bug in wxWidgets itself.
I think it would be difficult to handle this case nicely in wxLua 
binding wrappers... it's probably better to submit a patch to wx devs 
and ask them to apply it before 2.6.3...
if those icons aren't really used it should not be a big issue just 
replacing wxCursor->wxIcon...

am I right ?

Francesco

[Wxlua-users] Re: wxLua icon

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

Anders F Björklund ha scritto:
> PS. If you tell me what files and demos to run,
>     I can make some Mac screenshots to match...
Great!

Just go to the screenshots page and try to reproduce the same screens:

1) run wxLuaCan and choose ModifyObjects->Run 
Script->wxLua/apps/wxluacan/scripts/incircles.lua

2) run samples/scribble.wx.lua

3) run samples/calculator/calculator.wx.lua, samples/htmlwin.wx.lua

Then mail me the resulting screenshots, possibly in the .PNG format.

Thanks,
Francesco

[Wxlua-users] wxluasudoku not running

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

Hi John,
    I see you added that very nice example and also a screenshot for 
it... unfortunately it doesn't run on my linux with latest wxLua 
compiled & installed:

frm@genius:~/work/wxLua/samples$ wxlua wxluasudoku.wx.lua
wxLua: Syntax error during pre-compilation
wxluasudoku.wx.lua:193: malformed number near `9.1'
wxLua: Syntax error during pre-compilation

Maybe the dot must be replaced with a comma ?
Doing the replace in line 193 makes wxLua complain for next occurrences 
.... probably if I'd solve them all, it would just run.
What I do not understand is why it works with you ?
Could it be a locale problem ?

Francesco

Re: [Wxlua-users] some notes

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

John Labenski wrote:
>
> The plot.i file should also go into it's own directory. I see messages
> on wx-users that people seem to use the plot widget every once in a
> while. Maybe we should keep that, if nothing else it shows how easy it
> is to make a binding for a outside library.
> bindings/wxplot
> modules/wxbindplot
>   
I also like this idea, it sets the right approach for things to come,  
when more  modules  from e.g.  wxCode  get wrapped.

Klaas
 

Re: [Wxlua-users] Re: wxLua icon

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

Francesco Montorsi wrote:
>>
>>
>> Do you want to use this new "yellow moon", instead of Luas ?
> Klaas suggested the yellow colour and it looks nice in the website...
> however we can change it... John, Klaas, which logo would you prefer ?
In case of a black background this:

http://www.xs4all.nl/~kholwerd/tmp/lualogo/wxlua13.gif

else

http://www.xs4all.nl/~kholwerd/tmp/lualogo/wxlua11.gif

Maybe with the moon stroke black like in 
http://www.xs4all.nl/~kholwerd/tmp/lualogo/wxlua6.gif,
(needs modified with ring on blue removed.

I think using the lua icon as moon, is becoming to complex already.
It also contains the orbit idea in itself, so one to much.

Klaas

Re: [Wxlua-users] Re: wxLua icon

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

Francesco Montorsi wrote:

> I'm experimenting with it but it's not well-suited for a small website 
> logo... specially with a black background..
>
>> http://www.xs4all.nl/~kholwerd/tmp/lualogo/wxlua6.gif
>> is probably better than the one I have now, I think...
>> Do you want to use this new "yellow moon", instead of Luas ?
> Klaas suggested the yellow colour and it looks nice in the website...
> however we can change it... John, Klaas, which logo would you prefer ?

Here are some ideas (not suitable for black bg yet, though)

Current logo, with a "change of moons":
http://www.algonet.se/~afb/wx/wxLua1.png

Old logo, redone with new wxWidgets/Lua:
http://www.algonet.se/~afb/wx/wxLua2.png

And I agree, I think the new wxLua site looks very nice!

--anders


PS. If you tell me what files and demos to run,
     I can make some Mac screenshots to match...

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

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

Francesco Montorsi wrote:

> I've checked in the __WXMAC__ changes and the inclusion of internal.h 
> but not these changes:
>
> +#ifndef __WXMAC__
>      // call constructor
>      returns = new wxDropSource(win, *iconCopy, *iconMove, *iconStop);
> +#else
> +    returns = new wxDropSource(win);
> +#endif
>
> they affect automatically-generated files rather than their generators 
> and thus should be changed.
> Why does Mac need this asimmetry ?

Someone declared the Mac constructor with the wrong type arguments...
The icons aren't being used anyway, so it's a pretty silly error :-)

     // ctors: if you use default ctor you must call SetData() later!
     //
     // NB: the "wxWindow *win" parameter is unused and is here only for 
wxGTK
     //     compatibility, as well as both icon parameters
     wxDropSource( wxWindow *win = (wxWindow *)NULL,
                  const wxCursor &cursorCopy = wxNullCursor,
                  const wxCursor &cursorMove = wxNullCursor,
                  const wxCursor &cursorStop = wxNullCursor);

I thought it would be easiest to just *not* supply the icons on wxMac ?
(BTW; You can peek at the Mac stuff for wxWidgets, it's in "mac/carbon")

--anders

[Wxlua-users] Re: wxLua for wxMac

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

Hi,

Anders F Björklund ha scritto:
> Francesco Montorsi wrote:
>> the inclusion of lua internal.h is strange - we don't need it on win 
>> or unix.
> 
> Well, the reason I needed to add it was that I got missing symbols
> for lua2wx and wx2lua. It is supposed to inline those calls, but...
I've checked in the __WXMAC__ changes and the inclusion of internal.h 
but not these changes:

+#ifndef __WXMAC__
      // call constructor
      returns = new wxDropSource(win, *iconCopy, *iconMove, *iconStop);
+#else
+    returns = new wxDropSource(win);
+#endif

they affect automatically-generated files rather than their generators 
and thus should be changed.
Why does Mac need this asimmetry ?


> 
>> Last the addition of the wxSTENotebook is probably not required using 
>> the latest wxStEdit from CVS...
> 
> Okey dokey, will check the CVS then (SourceForge CVS lags a *lot*
> for anonymous access, it's only live when you are using SSH...)
I know :(

> 
>> 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...
> 
> configure script worked like a charm, that "config" was in error
good

> 
>> I think adding a folder like build\macbundle containing all required 
>> files could be enough ?
> 
> Yes, or just a few extra steps before packaging it up for the end user.
> The current Makefile does all things needed for a UNIX-type installation
ok; then just send me the files to put there once you've prepared them...

> 
>> Would you require any change in build system (i.e. Makefiles)?
>> We manage them using Bakefile so I can help with it...
> 
> Not to just compile it, no. And the Installer packages are easiest
> done with Apple's PackageMaker.app, not sure it needs a Makefile ?
if it needs a Makefile I could just create a small target "macbundle" in 
wxLua makefile which just calls it...


Thanks,
Francesco

[Wxlua-users] Re: wxLua icon

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

Anders F Björklund ha scritto:
> Francesco Montorsi wrote:
> 
>>> Since the icon of the running application shows up
>>> in the Dock, it could probably need a "clean-up" ?
>> how many pixels are the icons in the "dock" of a Mac ?
> 
> They are all 128x128, in full 32-bits of color (RGBA)
> 
>> If you say the icon looks too smaller or confused, I think we could 
>> stress the moon and the 3 wx blocks and remove the ring...
> 
> Well, I just thought that it looked a bit blocky... :-)
> Compare http://www.algonet.se/~afb/wx/codeblocks-icon.png
you're right; it doesn't look so much clear...

> 
>> Klaas has still some drafts at
>> http://www.xs4all.nl/~kholwerd/tmp/lualogo/
>> you could look at it and choose/edit the best one...
> 
> Q: What happened to the old wxLua logo, with the Lua logo,
> e.g. http://www.erix.it/progutil/gpeddler2/help/wxLua.png
> 
> It seems to still be used in the current release, in XPM ?
ooooooops
I never noticed that the icon had been saved from the shutdown of the 
old wxLua website right in our art\ folder...

I'm experimenting with it but it's not well-suited for a small website 
logo... specially with a black background..

> 
> 
> http://www.xs4all.nl/~kholwerd/tmp/lualogo/wxlua6.gif
> is probably better than the one I have now, I think...
> 
> Do you want to use this new "yellow moon", instead of Luas ?
Klaas suggested the yellow colour and it looks nice in the website...
however we can change it... John, Klaas, which logo would you prefer ?

Francesco

Re: [Wxlua-users] Re: wxLua icon

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

Francesco Montorsi wrote:

>> Since the icon of the running application shows up
>> in the Dock, it could probably need a "clean-up" ?
> how many pixels are the icons in the "dock" of a Mac ?

They are all 128x128, in full 32-bits of color (RGBA)

> If you say the icon looks too smaller or confused, I think we could 
> stress the moon and the 3 wx blocks and remove the ring...

Well, I just thought that it looked a bit blocky... :-)
Compare http://www.algonet.se/~afb/wx/codeblocks-icon.png

> Klaas has still some drafts at
> http://www.xs4all.nl/~kholwerd/tmp/lualogo/
> you could look at it and choose/edit the best one...

Q: What happened to the old wxLua logo, with the Lua logo,
e.g. http://www.erix.it/progutil/gpeddler2/help/wxLua.png

It seems to still be used in the current release, in XPM ?


http://www.xs4all.nl/~kholwerd/tmp/lualogo/wxlua6.gif
is probably better than the one I have now, I think...

Do you want to use this new "yellow moon", instead of Luas ?

--anders

[Wxlua-users] Re: wxLua icon

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

Anders F Björklund ha scritto:
> I made a (placeholder) Mac OS X app icon available at:
> http://www.algonet.se/~afb/wx/wxLua.icns [new format]
> http://www.algonet.se/~afb/wx/wxLua.r.gz [old format]
> 
> I took it from the website, looks like this:
> http://www.algonet.se/~afb/wx/wxLua.png  [128x128x32]
> adapted from:
> http://wxlua.sourceforge.net/images/wxlualogo.gif
Thanks!

> 
> Since the icon of the running application shows up
> in the Dock, it could probably need a "clean-up" ?
how many pixels are the icons in the "dock" of a Mac ?
If you say the icon looks too smaller or confused, I think we could 
stress the moon and the 3 wx blocks and remove the ring...

Klaas has still some drafts at

http://www.xs4all.nl/~kholwerd/tmp/lualogo/

you could look at it and choose/edit the best one...


> Could have used the Lua one again, but didn't:
> http://www.algonet.se/~afb/lua/Lua.png
> 
> Since I had already used that for the regular
> Lua interpreter, for the MacLua packaging...
I agree: it's best to use another icon rather than the regular Lua one...

Francesco

[Wxlua-users] Re: some notes

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

John Labenski ha scritto:
> On 3/6/06, Francesco Montorsi <f18...@ya...> wrote:
>> 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
> 
> No it would work just like wxstc before we separated it, it's turned
> off using wxLUA_USE_FL 0. So if you turned it back on in wxluasetup.h
> you'd get linker errors if you didn't link to wxfl.lib or whatever
> it's called.
yes: when I said it doesn't work I meant that putting wxLUA_USE_FL to 1 
yields to linking errors...

> 
>> it's best to just remove it...
> 
> You're probably right. I hate to remove stuff like that since it's a
> lot of work to put it back, but the FL has been dead for some time
> now. I keep seeing messages of something new on wx-dev, but I haven't
> checked to see if that's materialized yet.
wxAUI is pretty good and there are also wxIFM and wxDockIt.
wx developers have put the wxIFM patch in pending status: they want to 
see which library (wxAUI or wxIFM) is more used and then they will 
integrate the winning one...

> 
> The plot.i file should also go into it's own directory. I see messages
> on wx-users that people seem to use the plot widget every once in a
> while. Maybe we should keep that, if nothing else it shows how easy it
> is to make a binding for a outside library.
> bindings/wxplot
> modules/wxbindplot
yes, I agree

> 
> I can do both of these things tonight, I can just clear out the files
> (so it'll still compile) like I did before and when you rebake you'll
> just have to remove the empty files.
ok, sure. Just a tip: you can cvs remove -f the files directly instead 
of just empting them.
Then I'll just update bakefiles and run bakefile_gen...

Francesco

[Wxlua-users] wxLua icon

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

I made a (placeholder) Mac OS X app icon available at:
http://www.algonet.se/~afb/wx/wxLua.icns [new format]
http://www.algonet.se/~afb/wx/wxLua.r.gz [old format]

I took it from the website, looks like this:
http://www.algonet.se/~afb/wx/wxLua.png  [128x128x32]
adapted from:
http://wxlua.sourceforge.net/images/wxlualogo.gif

Since the icon of the running application shows up
in the Dock, it could probably need a "clean-up" ?


Could have used the Lua one again, but didn't:
http://www.algonet.se/~afb/lua/Lua.png

Since I had already used that for the regular
Lua interpreter, for the MacLua packaging...

--anders

Re: [Wxlua-users] some notes

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

On 3/6/06, Francesco Montorsi <f18...@ya...> wrote:
> 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

No it would work just like wxstc before we separated it, it's turned
off using wxLUA_USE_FL 0. So if you turned it back on in wxluasetup.h
you'd get linker errors if you didn't link to wxfl.lib or whatever
it's called.

> it's best to just remove it...

You're probably right. I hate to remove stuff like that since it's a
lot of work to put it back, but the FL has been dead for some time
now. I keep seeing messages of something new on wx-dev, but I haven't
checked to see if that's materialized yet.

The plot.i file should also go into it's own directory. I see messages
on wx-users that people seem to use the plot widget every once in a
while. Maybe we should keep that, if nothing else it shows how easy it
is to make a binding for a outside library.
bindings/wxplot
modules/wxbindplot

I can do both of these things tonight, I can just clear out the files
(so it'll still compile) like I did before and when you rebake you'll
just have to remove the empty files.

-John Labenski

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

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

On 3/6/06, Francesco Montorsi <f18...@ya...> wrote:
> klaas.holwerda ha scritto:
> > Francesco Montorsi wrote:
> >> it's possible but not that elegant:
> >>
> >>
> >>   <set var=3D"POSTFIX">
> >>     <if cond=3D"WX_SHARED=3D=3D'0'">_lib</if>
> >>     <if cond=3D"WX_SHARED=3D=3D'1'">_dll</if>
> >>   </set>
> >>   <if cond=3D"FORMAT!=3D'autoconf'">
> >>     <set var=3D"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 ?

Yes, I was going to do a release last week, good thing I didn't. :)

Thanks,
    John Labenski

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

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

Francesco Montorsi wrote:

> the absence of __WXMAC__ symbols can only be noticed when compiling on 
> Mac :)

Yeah, those I'll worry about so no need to check on Windows/Linux :-)

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

Well, the reason I needed to add it was that I got missing symbols
for lua2wx and wx2lua. It is supposed to inline those calls, but...

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

Okey dokey, will check the CVS then (SourceForge CVS lags a *lot*
for anonymous access, it's only live when you are using SSH...)

> 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...

configure script worked like a charm, that "config" was in error

> I think adding a folder like build\macbundle containing all required 
> files could be enough ?

Yes, or just a few extra steps before packaging it up for the end user.
The current Makefile does all things needed for a UNIX-type installation

> Would you require any change in build system (i.e. Makefiles)?
> We manage them using Bakefile so I can help with it...

Not to just compile it, no. And the Installer packages are easiest
done with Apple's PackageMaker.app, not sure it needs a Makefile ?

--anders