John Labenski wrote: >> I could try the bleeding edge wxwidgets and wxstedit, of course. >> But I would prefer if it worked OK with 2.8.4 and 1.2.5 as well. > > Ok, I have been using the svn of wxWidgets 2.8 since it seems like OSX > is still being worked on quite a bit.
Sure, but both wxWidgets 2.6.4 and 2.8.4 are fully operational... >> What I have done is taken the "wxLua" directory, and then added the >> binaries to "apps" and "bin" by combining the PPC and X86 builds... > > I saw that, but didn't have time to understand how or where you put > the "magic" files/dirs to make it work in OSX. By magic, I mean the > ones that allow the program to work and not ignore the keyboard and > mouse input, i.e. what happens if you compile a binary and try to run > that all by itself without the extras. I'll look into that when I get > back. There is a system call* that you can do on start, so Mac OS X notices that a Carbon program is running. wxWidgets has chosen not to call this, which means that you either need to add a resource fork or bundle up your application before it will receive any events (second choice suggested) So as long as you run the bundle, it should be OK. The script called "copydylibs" includes a copy of all the dynamic libraries and repoints the "install_name" of the apps to point to them (compare with rpath), but that's optional and it is _not_ used by the MacPorts port/package. > I think it may also be nice to make it easy to pull out wxLuaFreeze > since that's supposed to be the "lean" wxLua executable that you can > use to run your own programs. The "freezing" part isn't too great > since it only works on a single file, but I've been meaning to write > in the docs/FAQ that people with multiple lua parts should feel > welcome to rename wxLuaFreeze to the name of their program and create > a script to run it as "MySuperProgram mysuperprogram.wx.lua" Anyway, > if wxLuaFreeze was a separate dir in the mac binary they could just > copy it, rename it, add their lua scripts and done - they've got a > "binary". Or, am I missing something. Well, I just packaged what it built and didn't remove anything :-) According to wxWidgets practices, wxLuaFreeze on Mac OS X either needs to add a resource fork or build a bundle directory instead. Considering as how the resource fork normally ends up in a separate file called "._foo" (for file "foo"), there are *no* one-file exes... I guess it could be educated to build a Mac OS X disk image, but. >> Think "About" has a similar issue, it's also moved away from Help ? > > Oops, yeah I meant wxID_ABOUT. I tried a whole bunch of combinations > of having >1 items in the help menu (containing wxID_ABOUT), adding > items later, adding a whole new menu (Help2) and adding items, but in > every case there was something funny about it. It seemed like the menu > with wxID_ABOUT in it was hidden even for multiple items and adding a > menu or menuitem after setting the menu to the frame caused problems. > I think the worst case was adding a whole extra menu (Help2) which > caused the handler function to be called multiple times. I'll have to > revisit that since I just don't remember anymore. I think the menu briefly disappears (since there are no items), and then it suddenly remembers it and it reappears when you mouse over it. Either way it looks funny. But "About" does belong in the app menu... That it is hidden when it had more than one sounds like a bug, though. --anders * http://article.gmane.org/gmane.comp.lib.wxwidgets.devel/83092 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ wxlua-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wxlua-users
