Hi John, wxwidgets team is getting ready to release v3.1.0 in about two weeks and it would be great to refresh the API in wxlua, fix some outstanding issues, and release the next version of wxlua. The upgrade will also include the latest Scintilla version (3.6.3), so it would be ideal to include added events/API calls as well. I tried to add some of them myself, but ran into issues even with simple methods like GetLibraryVersionInfo (it returns wxVersionInfo, which wxlua doesn't know about). Here are some of the recent discussions that may be relevant for the upgrade: 1. Memory leak in wxlua: http://sourceforge.net/p/wxlua/mailman/message/34430092/ 2. MacOpenFiles and related methods: http://sourceforge.net/p/wxlua/mailman/message/34559782/ 3. wxButton class is missing all the methods from wxAnyButton class it's inherited from (http://docs.wxwidgets.org/trunk/classwx_button.html). This affects methods like GetBitmap* and SetBitmap* as those are not present in wxButton (but rather inherited from wxAnyButton). 4. Several other methods missing: http://sourceforge.net/p/wxlua/mailman/message/32988247/ There are likely to be more methods not in the bindings and I'm not sure what the best way to deal with those. Are you usually adding them manually? The more wxlua lags behind, the more difficult it becomes to add them. I've tried to go through 5k+ lines of stc.h to identify updated constants and methods, but there are just too many changes to do it manually; I considered writing a script, but there are also too many version-specific manual changes to make the script to work. I'm open to suggestions on how to proceed with these changes. In general, are you up for making some of these changes over the next 2-3 weeks? If not, I'll probably try to apply some of them myself (I have a clone of current wxlua code on github), but I have not been able to figure out how to fix the memory leak or how to support Mac* classes, so would welcome your assistance. Paul.
Hi All, For those interested in wxwidgets upgrades, I pulled the current version of wxlua into a github repository and applied wxSTC changes in the current wxwidgets master branch to wxlua; all these changes are available in wxwidgets31 branch: https://github.com/pkulchenko/wxlua/tree/wxwidgets31 I wrote a couple of scripts to merge stc.h constants/methods with wxlua interface descriptions, but since the earlier changes have been done manually, I've tried to reconcile the differences keeping the manual changes intact when possible. All the constants/methods/events have been updated and should be up-to-date with wxwidgets31 and Scintilla 3.6.3. John, I also fixed an earlier change that removed CoffeeScript lexer instead of removing just one constant in wxwidgets 3.1; the change is here: https://github.com/pkulchenko/wxlua/commit/0cb663ecd05dd1aabe9dcd12a7053f524dc336d5 I've tested this with my application on Windows and would appreciate you letting me know if you notice any issues with the updated binding. Paul. On Tue, Feb 2, 2016 at 11:29 AM, Paul K <pau...@ya...> wrote: > Hi John, > > wxwidgets team is getting ready to release v3.1.0 in about two weeks > and it would be great to refresh the API in wxlua, fix some > outstanding issues, and release the next version of wxlua. The upgrade > will also include the latest Scintilla version (3.6.3), so it would be > ideal to include added events/API calls as well. I tried to add some > of them myself, but ran into issues even with simple methods like > GetLibraryVersionInfo (it returns wxVersionInfo, which wxlua doesn't > know about). > > Here are some of the recent discussions that may be relevant for the upgrade: > > 1. Memory leak in wxlua: > http://sourceforge.net/p/wxlua/mailman/message/34430092/ > 2. MacOpenFiles and related methods: > http://sourceforge.net/p/wxlua/mailman/message/34559782/ > 3. wxButton class is missing all the methods from wxAnyButton class > it's inherited from > (http://docs.wxwidgets.org/trunk/classwx_button.html). This affects > methods like GetBitmap* and SetBitmap* as those are not present in > wxButton (but rather inherited from wxAnyButton). > 4. Several other methods missing: > http://sourceforge.net/p/wxlua/mailman/message/32988247/ > > There are likely to be more methods not in the bindings and I'm not > sure what the best way to deal with those. Are you usually adding them > manually? The more wxlua lags behind, the more difficult it becomes to > add them. I've tried to go through 5k+ lines of stc.h to identify > updated constants and methods, but there are just too many changes to > do it manually; I considered writing a script, but there are also too > many version-specific manual changes to make the script to work. I'm > open to suggestions on how to proceed with these changes. > > In general, are you up for making some of these changes over the next > 2-3 weeks? If not, I'll probably try to apply some of them myself (I > have a clone of current wxlua code on github), but I have not been > able to figure out how to fix the memory leak or how to support Mac* > classes, so would welcome your assistance. > > Paul.
Hi All, > manual changes intact when possible. All the constants/methods/events > have been updated and should be up-to-date with wxwidgets31 and > Scintilla 3.6.3. It turned out that my patch for Scintilla 3.6.3 was not merged into 3.1.0 that was recently released, but has been merged into 3.1.1 (the current master branch), so I split the patch I had into two branches/patches: wxwidgets310 (https://github.com/pkulchenko/wxlua/tree/wxwidgets310), which is updated for Scintilla 3.5.5 that was included with 3.1.0 and wxwidgets311 (https://github.com/pkulchenko/wxlua/tree/wxwidgets311), which includes Scintilla 3.6.3. I plan on adding more missing methods/constants to 3.1.0 branch (and rebasing 3.1.1 branch to include Scintilla changes). Please let me know if you notice any issues with the bindings. Paul. On Tue, Feb 9, 2016 at 2:39 PM, Paul K <pau...@ya...> wrote: > Hi All, > > For those interested in wxwidgets upgrades, I pulled the current > version of wxlua into a github repository and applied wxSTC changes in > the current wxwidgets master branch to wxlua; all these changes are > available in wxwidgets31 branch: > https://github.com/pkulchenko/wxlua/tree/wxwidgets31 > > I wrote a couple of scripts to merge stc.h constants/methods with > wxlua interface descriptions, but since the earlier changes have been > done manually, I've tried to reconcile the differences keeping the > manual changes intact when possible. All the constants/methods/events > have been updated and should be up-to-date with wxwidgets31 and > Scintilla 3.6.3. > > John, I also fixed an earlier change that removed CoffeeScript lexer > instead of removing just one constant in wxwidgets 3.1; the change is > here: https://github.com/pkulchenko/wxlua/commit/0cb663ecd05dd1aabe9dcd12a7053f524dc336d5 > > I've tested this with my application on Windows and would appreciate > you letting me know if you notice any issues with the updated binding. > > Paul.
Hi All, I pushed more changes to the wxwidgets311 branch in wxlua: https://github.com/pkulchenko/wxlua/commits/wxwidgets311 These changes cover the updated API for the following classes: wxMenu, wxMenuItem, wxTreeCtrl, wxTextEntry, wxTextCtrl, wxButton, wxAnyButton, wxBitmapButton, wxToggleButton, wxBitmapToggleButton, wxDir, wxWindow, wxTopLevelWindow, and wxFrame. I realize that the selection may look strange, but I started from those classes that I needed new methods from and also those classes that I could test with my application. The changes have been tested on Windows and OSX using the latest wxwidgets code. I have not tested running any older version of wxwidgets, so if anyone runs into issues, please let me know. I tried to preserve all the methods that were working before, but since the updates were done with scripts based on the current wxwidgets interface files, it's possible that there are some issues with the results. I plan to add wxFont, wxConfig, wxImage and possible couple of other classes, as these are the classes that are used in my application, so I can make sure that the changes are working. I'll include include the scripts I used for processing, so you should be able to update the API for other classes you may need. The main issue I ran into is with wxApp and its Mac* methods, which I covered in another email in this thread. John, if you have a bit of time, I'd appreciate your help as I feel stuck as to have to handle those methods. Thanks. Paul.
Hi Paul, I'm interested to moving to wxwidgets310 or higher because of support for vc14. I try to use your fork, but I'm not able to compile some projects because of lack of compatibility with old wxWidget classes like wxProperty. I tryed to set to 1 the define WXWIN_COMPATIBILITY_2_8 which is set to 0 since wxWidget 3.1.0 but I have encountered lot of others problems. Have you override some others define to be able to compile ? Did I miss something ? Laurent. -----Message d'origine----- De : Paul K [mailto:pau...@ya...] Envoyé : samedi 5 mars 2016 23:27 À : wxl...@li... Objet : Re: [wxlua-users] wxlua upgrade and outstanding issues Hi All, > manual changes intact when possible. All the constants/methods/events > have been updated and should be up-to-date with wxwidgets31 and > Scintilla 3.6.3. It turned out that my patch for Scintilla 3.6.3 was not merged into 3.1.0 that was recently released, but has been merged into 3.1.1 (the current master branch), so I split the patch I had into two branches/patches: wxwidgets310 (https://github.com/pkulchenko/wxlua/tree/wxwidgets310), which is updated for Scintilla 3.5.5 that was included with 3.1.0 and wxwidgets311 (https://github.com/pkulchenko/wxlua/tree/wxwidgets311), which includes Scintilla 3.6.3. I plan on adding more missing methods/constants to 3.1.0 branch (and rebasing 3.1.1 branch to include Scintilla changes). Please let me know if you notice any issues with the bindings. Paul. On Tue, Feb 9, 2016 at 2:39 PM, Paul K <pau...@ya...> wrote: > Hi All, > > For those interested in wxwidgets upgrades, I pulled the current > version of wxlua into a github repository and applied wxSTC changes in > the current wxwidgets master branch to wxlua; all these changes are > available in wxwidgets31 branch: > https://github.com/pkulchenko/wxlua/tree/wxwidgets31 > > I wrote a couple of scripts to merge stc.h constants/methods with > wxlua interface descriptions, but since the earlier changes have been > done manually, I've tried to reconcile the differences keeping the > manual changes intact when possible. All the constants/methods/events > have been updated and should be up-to-date with wxwidgets31 and > Scintilla 3.6.3. > > John, I also fixed an earlier change that removed CoffeeScript lexer > instead of removing just one constant in wxwidgets 3.1; the change is > here: > https://github.com/pkulchenko/wxlua/commit/0cb663ecd05dd1aabe9dcd12a70 > 53f524dc336d5 > > I've tested this with my application on Windows and would appreciate > you letting me know if you notice any issues with the updated binding. > > Paul. ------------------------------------------------------------------------------ _______________________________________________ wxlua-users mailing list wxl...@li... https://lists.sourceforge.net/lists/listinfo/wxlua-users
Hi, friends. Also interested in "update" wxLua. I can help by writing some changes as indicated.
Hi Laurent, > I'm not able to compile some projects because of lack of compatibility with old wxWidget classes like wxProperty. I'm not sure how wxProperty is involved, but my fork shouldn't *add* any issues as it's based on John's code and I only added updated wxSTC binding (with all the methods updated for wxwidgets 3.1.0 and 3.1.1) > I tryed to set to 1 the define WXWIN_COMPATIBILITY_2_8 which is set to 0 since wxWidget 3.1.0 but I have encountered lot of others problems. Have you override some others define to be able to compile ? Did I miss something ? I use the same setting; here is my configure line: ./configure --prefix="$INSTALL_DIR" $WXWIDGETSDEBUG --disable-shared --enable-unicode \ --enable-compat28 \ --with-libjpeg=builtin --with-libpng=builtin --with-libtiff=no --with-expat=no \ --with-zlib=builtin --disable-richtext \ CFLAGS="-Os -fno-keep-inline-dllexport" CXXFLAGS="-Os -fno-keep-inline-dllexport" I build using my own scripts without issues on Windows/OSX/Linux, but I'm using my fork of wxwidgets that is little bit behind their master branch (but I don't have any changes to their version, just lagging a bit behind). You can find all the build scripts for various platforms here: https://github.com/pkulchenko/ZeroBraneStudio/tree/master/build; just search for BUILD_WXWIDGETS. Paul.
Hi John, > 1. Memory leak in wxlua: http://sourceforge.net/p/wxlua/mailman/message/34430092/ > 2. MacOpenFiles and related methods: http://sourceforge.net/p/wxlua/mailman/message/34559782/ > 3. wxButton class is missing all the methods from wxAnyButton class > 4. Several other methods missing: http://sourceforge.net/p/wxlua/mailman/message/32988247/ I've been making good progress updating wxlua API for wxwidgets 3.1.x and have processed about dozen or so classes, so adding all the missing methods is much less of a priority for me. I tried to add MacOpenFiles processing and ran into an issue with getting access to the current Lua state. Here is what I currently have: %override wxLua_wxApp_MacOpenFiles void wxApp::MacOpenFiles(const wxArrayString& filenames) { wxLuaState m_wxlState = s_wxlState // <== not sure what to put here if (m_wxlState.Ok() && !m_wxlState.GetCallBaseClassFunction() && m_wxlState.HasDerivedMethod(this, "MacOpenFiles", true)) { int nOldTop = m_wxlState.lua_GetTop(); m_wxlState.wxluaT_PushUserDataType(this, wxluatype_wxApp, true); m_wxlState.PushwxArrayStringTable(filenames); m_wxlState.LuaPCall(2, 0); m_wxlState.lua_SetTop(nOldTop-1); // -1 to remove pushed derived method func too } m_wxlState.SetCallBaseClassFunction(false); // clear flag always } %end I would have used s_wxlState, but it's "static" in the Lua module, so not available outside of that file. It doesn't solve all the problems, but it could set me on the right track. When I make s_wxlState non-static, I do get a linker error about duplicate wxApp::MacOpenFiles method, so any ideas on how to avoid this, would be useful too. Paul.
Hi John, It seems like I'll need to create a derived class for wxLuaApp (similar to wxLuaPrintout) and add those Mac* methods to that class. Then the app can be set using wxGetApp::SetInstance() method, which should trigger those Mac* methods as expected. This also eliminates the issue with getting the Lua state, but I still need to figure out how to initialize the application fields properly... Or is there a better way? Paul. On Thu, May 5, 2016 at 10:59 PM, Paul K <pau...@ya...> wrote: > Hi John, > >> 1. Memory leak in wxlua: http://sourceforge.net/p/wxlua/mailman/message/34430092/ >> 2. MacOpenFiles and related methods: http://sourceforge.net/p/wxlua/mailman/message/34559782/ >> 3. wxButton class is missing all the methods from wxAnyButton class >> 4. Several other methods missing: http://sourceforge.net/p/wxlua/mailman/message/32988247/ > > I've been making good progress updating wxlua API for wxwidgets 3.1.x > and have processed about dozen or so classes, so adding all the > missing methods is much less of a priority for me. > > I tried to add MacOpenFiles processing and ran into an issue with > getting access to the current Lua state. Here is what I currently > have: > > %override wxLua_wxApp_MacOpenFiles > void wxApp::MacOpenFiles(const wxArrayString& filenames) > { > wxLuaState m_wxlState = s_wxlState // <== not sure what to put here > > if (m_wxlState.Ok() && !m_wxlState.GetCallBaseClassFunction() && > m_wxlState.HasDerivedMethod(this, "MacOpenFiles", true)) > { > int nOldTop = m_wxlState.lua_GetTop(); > m_wxlState.wxluaT_PushUserDataType(this, wxluatype_wxApp, true); > m_wxlState.PushwxArrayStringTable(filenames); > > m_wxlState.LuaPCall(2, 0); > m_wxlState.lua_SetTop(nOldTop-1); // -1 to remove pushed > derived method func too > } > m_wxlState.SetCallBaseClassFunction(false); // clear flag always > } > %end > > I would have used s_wxlState, but it's "static" in the Lua module, so > not available outside of that file. It doesn't solve all the problems, > but it could set me on the right track. When I make s_wxlState > non-static, I do get a linker error about duplicate > wxApp::MacOpenFiles method, so any ideas on how to avoid this, would > be useful too. > > Paul.