[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: wxLua at Sourceforge
- From: Chris Marrin <chris@...>
- Date: Wed, 30 Nov 2005 08:15:05 -0800
John Labenski wrote:
On 11/28/05, Chris Marrin <chris@marrin.com> wrote:
Can you point to (in your repository) what you had to do to get it to
work (in 5.0 for now) so we can duplicate it?
I started to get your sources, but there's a lot in there. Are these
the only two directories that involve wxLua?
http://emma3d.org/svn/emma/mainline/dependencies/wxLua/
- you made changes to the Library dir only it seems
http://emma3d.org/svn/emma/mainline/emma/runtime/wxgui/
Are these right?
Yes, those are the right locations, but we can just focus on wxLua for now.
I would suggest we just try to get my bug fixes/callback mechanism into
your source base for now. That would be pretty easy. There are a few
issues with the changes we made. First, we made a few changes and then
restructured our tree. So it is easiest to look at the changes before
restructuring and the changes after. Second, we added a few methods to
I don't see any restructuring? Maybe I'm looking in the wrong place?
No, we didn't restructure wxLua, just where it lives in the Emma tree.
You would only see it if you look at the subversion history. I just
mentioned it because if you look at that history, you would see a change
that might look confusing.
wxLuaWrap.cpp. Since this is a generated file, we should have made these
changes to the .lua file that generates it. But I don't understand how
to do that, so I added it directly to the wxLuaWrap.cpp file. We ended
up not using some of these, so I won't mention them below. Finally, you
will see one attempt at adding a callback mechanism to wxLua which used
a global function. I later replaced this with a more modular callback
class. I will not mention the first attempt below.
We don't use wxLuaWrap.cpp anymore. Instead, we use a more
sophisticated binding mechanism that generates cpp files that compile
in any platform and wxWidgets settings. It uses the same .i files and
there's been many updates to them.
That sounds good. I will send you all the bug fixes and additions we did
to wxLuaWrap.cpp as diffs. There is not much so hopefully it will be
clear. I will do that later this morning...
...
I'll try svn to see if I can get it to work. It seems like there's
only a couple dozen changes and all of them seem to make sense. As I
said I would rather just diff the final result of your changes than
try to track through them.
That's fine. I can send you the actual diffs from our original wxLua
version if that helps. Let me know...
Notes:
All updates to the bindings are, of course, welcome, I'll try to add them.
they all look pretty trivial, but why do this?
1970 and 2003 changed wxWindow:Move()
I assume it makes your life easier, but we should stick with the
wxWidgets functions
Yes, we can do that on our end. It just seemed to make sense to position
windows relative to their parent. This is not critical for us...
to save ourself the trouble of "gotchas" like these for other users.
We can always add an additional wxWindow::MoveRelative function
Yes, that might be useful. But again, we can do this outside wxLua, so
it is not critical.
wxLuaNativeCallback can be replaced by this I think
virtual void wxLuaCallback::CallFunction(wxEvent *pEvent);
I'm not sure how you mean. Doesn't CallFunction call a Lua function?
This is what we need to avoid because we are calling it in another
thread, so we can't use Lua at all (not even to call a Lua CFunction).
I don't get any warnings anymore. :) VC6/2003 & gcc in linux
Great!
It's a little disconcerting that lua_dostring and lua_dobuffer are
missing in 5.1. I hope there's a suitable replacement.
There is. I will look at our source and let you know how we did it.
Again, I will do that later this morning...
There's still a little more cleaning up to do with wxLua at SF, but
you can see the sources using the web CVS gui at SF. I'll try to write
some docs in the next few days.
I will look at it, thanks.
If we can get these changes into your version of wxLua (or determine
alternate ways of doing the same things), we can use that as our
dependency. Then I can build my WxGUI package on top of that. We can
either make WxGUI part of your wxLua distro, or I can keep it separate
as part of Emma. I have already split Fusion out of Emma, which is what
WxGUI depends on. Fusion is a Lua C++ wrapper library and I plan to make
is a separate distro for use by Lua developers.
It looks like WxGui depends on Fusion (I'm not sure what that is, a
lua game engine I gather). I think it should be separate. Could you
explain a little what WxGui is? What does the panel have as controls.
yes, I will respond to that later this morning...
So there are lots of ways to go - let me know what you think is best.
If you can confirm the source dirs you use, I'll update the bindings
and it seems like you'd be ready to go. The only problem is 5.1... I
want to wait just a little more to really be sure that things still
all work after my changes before I switch to 5.1. You can keep tabs on
it at the wxlua-users list on SF.
Sounds good. 5.1 is really crucial to us, so let me know if I can help
move that forward.
--
chris marrin ,""$, "As a general rule,don't solve puzzles
chris@marrin.com b` $ that open portals to Hell" ,,.
,.` ,b` ,` , 1$'
,|` mP ,` :$$' ,mm
,b" b" ,` ,mm m$$ ,m ,`P$$
m$` ,b` .` ,mm ,'|$P ,|"1$` ,b$P ,` :$1
b$` ,$: :,`` |$$ ,` $$` ,|` ,$$,,`"$$ .` :$|
b$| _m$`,:` :$1 ,` ,$Pm|` ` :$$,..;"' |$:
P$b, _;b$$b$1" |$$ ,` ,$$" ``' $$
```"```'" `"` `""` ""` ,P`