http://blog.gmane.org/gmane.comp.lib.wxwidgets.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149258 <pre>Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15268&gt; #15268: Intel c++ compiler build error -------------------------+-------------------------------------------------- Reporter: fr0ster | Owner: Type: build error | Status: new Priority: low | Milestone: Component: build | Version: 2.9-svn Keywords: | Blockedby: Patch: 1 | Blocking: -------------------------+-------------------------------------------------- When using the Intel c + + compiler will see the error "/home/alex/prj/gcc/wxWidgets_fr_01/Debug/bk-deps icc -c -o basedll_extended.o -pch-use ./.pch/wxprec_basedll/wx/wxprec.h.gch -DWXGTK -DWXBUILDING -I/home/alex/prj/gcc/wxWidgets_fr_01/Debug/src/tiff/libtiff -I../src/tiff/libtiff -I../src/jpeg -I../src/regex -DwxUSE_GUI=0 -DWXMAKINGDLL_BASE -DwxUSE_BASE=1 -fPIC -DPIC -D_FILE_OFFSET_BITS=64 -I/home/alex/prj/gcc/wxWidgets_fr_01/Debug/lib/wx/include/gtk3-unicode-2.9 -I../include -pthread -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 -I/usr/include /gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/libpng12 -pthread -Wall -wd810,869,981,1418,1572,1684,2259 -g -O0 -pthread -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 -I/usr/include /gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux- gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/home/alex/opt/intellib/include/SDL2 -D_REENTRANT -D_GNU_SOURCE -fvisibility=hidden ../src/common/extended.c Catastrophic error: the language mode (C or C++) must match mode used when precompiled header file "./.pch/wxprec_basedll/wx/wxprec.h.gch" was created compilation aborted for ../src/common/extended.c (code 4) make: *** [basedll_extended.o] Ошибка 4" The patch corrects the error attached -- Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15268&gt; </pre> wxTrac 2013-06-20T07:01:22 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149257 <pre>Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15267#comment:2&gt; #15267: Intel c++ compiler build error --------------------------+------------------------------------------------- Reporter: fr0ster | Owner: Type: build error | Status: closed Priority: normal | Milestone: Component: build | Version: 2.9-svn Resolution: invalid | Keywords: intel c++ Blockedby: | Patch: 1 Blocking: | --------------------------+------------------------------------------------- Changes (by fr0ster): * status: new =&gt; closed * resolution: =&gt; invalid -- Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15267#comment:2&gt; </pre> wxTrac 2013-06-20T06:59:59 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149256 <pre>Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15267#comment:1&gt; #15267: Intel c++ compiler build error -------------------------+-------------------------------------------------- Reporter: fr0ster | Owner: Type: build error | Status: new Priority: normal | Milestone: Component: build | Version: 2.9-svn Keywords: intel c++ | Blockedby: Patch: 1 | Blocking: -------------------------+-------------------------------------------------- Comment(by fr0ster): When using the Intel c + + compiler will see the error "/home/alex/prj/gcc/wxWidgets_fr_01/Debug/bk-deps icc -c -o basedll_extended.o -pch-use ./.pch/wxprec_basedll/wx/wxprec.h.gch -D__WXGTK__ -DWXBUILDING -I/home/alex/prj/gcc/wxWidgets_fr_01/Debug/src/tiff/libtiff -I../src/tiff/libtiff -I../src/jpeg -I../src/regex -DwxUSE_GUI=0 -DWXMAKINGDLL_BASE -DwxUSE_BASE=1 -fPIC -DPIC -D_FILE_OFFSET_BITS=64 -I/home/alex/prj/gcc/wxWidgets_fr_01/Debug/lib/wx/include/gtk3-unicode-2.9 -I../include -pthread -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 -I/usr/include /gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/libpng12 -pthread -Wall -wd810,869,981,1418,1572,1684,2259 -g -O0 -pthread -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 -I/usr/include /gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux- gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/home/alex/opt/intellib/include/SDL2 -D_REENTRANT -D_GNU_SOURCE -fvisibility=hidden ../src/common/extended.c Catastrophic error: the language mode (C or C++) must match mode used when precompiled header file "./.pch/wxprec_basedll/wx/wxprec.h.gch" was created compilation aborted for ../src/common/extended.c (code 4) make: *** [basedll_extended.o] Ошибка 4" The patch corrects the error attached -- Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15267#comment:1&gt; </pre> wxTrac 2013-06-20T06:58:44 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149255 <pre>Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15267&gt; #15267: Intel c++ compiler build error -------------------------+-------------------------------------------------- Reporter: fr0ster | Owner: Type: build error | Status: new Priority: normal | Milestone: Component: build | Version: 2.9-svn Keywords: intel c++ | Blockedby: Patch: 1 | Blocking: -------------------------+-------------------------------------------------- When using the Intel c + + compiler will see the error "Catastrophic error: the language mode (C or C++) must match mode used when precompiled header file "./.pch/wxprec_basedll/wx/wxprec.h.gch" was created compilation aborted for ../src/common/any.cpp (code 4)" The patch corrects the error attached -- Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15267&gt; </pre> wxTrac 2013-06-20T06:40:43 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149254 <pre>Hi Vadim: I have working versions (passing the tests) for GTK, Cocoa, Carbon and unix console using your wxEventLoopFactory proposal (with some changes detailed below). I've also incorporated your comments in the review - and responded back to some of them. One thing is still a little unclear - about the handling of HUP condition in GTK - see the comments in the review. I still need to clean up what I have done before submitting a new patch/review for you to look at. Hopefully I will have time for that tomorrow night. Here are some responses to your previous mail: I don't think 'CreateLoop' is required for this patch. Its probably a nice to have. I want to avoid doing it because it could impact more than the Unix ports. It could be added on top of my addition of wxEventLoopFactory. This is also not required for this patch, and I will avoid doing it. It could be added later to the library. I'll keep the old version of this function for now. For GTK, I was able to successfully implement this in evtloop.cpp instead of utilsgtk.cpp. But it is a different story for OSX port. In OSX, the evtloop_cf.cpp is compiled with -DwxUSE_GUI=0 -DwxUSE_BASE=1'. This makes it impossible to reference the wxGUIAppTraits, I get compile errors that wxGUIAppTraits is unrecognized. Therefore in OSX port, I had to put this code into utilsexc_cf.cpp, which is compiled with '-DwxUSE_BASE=0'. Then it compiles and passes the tests. I think you made a mistake here. The static function should only be wxEventLoopBase::AddSourceForFD(), and not in wxGUIEventLoop. And I think it needs a traits pointer. I have a working/compiled implementation of this static function (inside src/common/evtloopcmn.cpp) and it looks like this: #if wxUSE_EVENTLOOP_SOURCE wxEventLoopSource* wxEventLoopBase::AddSourceForFD(int fd, wxEventLoopSourceHandler *handler, int flags) { wxConsoleAppTraits traitsConsole; wxAppTraits *traits = wxTheApp ? wxTheApp-&gt;GetTraits() : NULL; if ( !traits ) traits = &amp;traitsConsole; return traits-&gt;GetEventLoopFactory()-&gt;AddSourceForFD(fd,handler,flags); } #endif Regards, Rob </pre> Rob Bresalier 2013-06-20T04:44:51 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149253 <pre>Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15253#comment:14&gt; #15253: No translation in osx trunk --------------------------+------------------------------------------------- Reporter: raananc | Owner: vaclavslavik Type: defect | Status: accepted Priority: normal | Milestone: 2.9.5 Component: translations | Version: Keywords: | Blockedby: Patch: 0 | Blocking: --------------------------+------------------------------------------------- Comment(by raananc): Replying to [comment:12 vaclavslavik]: I do not use locale to set any language, as you can see from my code. I need to know the currentLanguage (which I now get from locale-&gt;GetSystemLanguage() or locale-&gt;GetLanguage() ) for my application. If locale-&gt;[http://trac.wxwidgets.org/search?q=wiki%3AGetSystemLanguage GetSystemLanguage]() is prohibited, is GetLanguage() any better ? If not, then what else is available? Replying to [comment:10 raananc]: &gt; &gt; do not provide translation when the mo file is in applicationPath/fr/translations.mo, &gt; It's possible the bug fixed in r74253 caused this. In any case, `AddCatalogLookupPathPrefix` looks into subdirs named after the language (and is documented to), so there's really no point in add per-language directory explicitly. You don't need to add `applicationPath/fr`, you only need to add `applicationPath` -- and it works for ''all'' languages. This is not specific to any platform. &gt; &gt; As for locale-&gt;GetSystemLanguage(), the discussion over what gives the user language in [http://trac.wxwidgets.org/ticket/15257 #15257] is too unconclusive &gt; There's nothing inconclusive about it. You should never ever under any circumstances use the default ''locale'' to set the UI ''language''. &gt; &gt; Can you be more specific as to what should be used? &gt; Nothing. Use `wxLANGUAGE_DEFAULT` when initializing and that's it. Add language-agnostic(!) paths with `AddCatalogLookupPathPrefix` if needed. But this breakage should still be fixed, of course, I'll have a look. -- Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15253#comment:14&gt; </pre> wxTrac 2013-06-19T21:35:23 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149252 <pre>Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15253#comment:13&gt; #15253: No translation in osx trunk --------------------------+------------------------------------------------- Reporter: raananc | Owner: vaclavslavik Type: defect | Status: accepted Priority: normal | Milestone: 2.9.5 Component: translations | Version: Keywords: | Blockedby: Patch: 0 | Blocking: --------------------------+------------------------------------------------- Comment(by raananc): Replying to [comment:11 vaclavslavik]: Up to now it was in gestioncomptes.app/Contents/MacOS/fr/gestioncomptes.mo Looking at the implementation of DialogBlocks, language specific files are stored in folders de_DE, and en_US. Theres folders are located next to the executable: in Windows &amp; Linux these folders are in the !DialogBlocks folder; in OSX they are under MacOS folder (not in the Resources folder). Is that where `AddCatalogLookupPathPrefix` looks for them? If the answer is Yes, then I would modify my folders to suit this specification. I would have appreciated if the wxWidgets documentation of Internationalisation was more explicit on this point. &gt; Replying to [comment:3 raananc]: &gt; &gt; The relevant code in my application is: &gt; And what is the exact location (relative to `applicatoinPath`) of your `gestioncomptes.mo` file? -- Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15253#comment:13&gt; </pre> wxTrac 2013-06-19T21:19:51 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149251 <pre>Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15264#comment:2&gt; #15264: Ctrl+Enter can't be used for wxGrid cell editing when parent is a wxPanel --------------------+------------------------------------------------------- Reporter: HelgeB | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: wxGrid | Version: 2.9.1 Keywords: | Blockedby: Patch: 0 | Blocking: --------------------+------------------------------------------------------- Comment(by HelgeB): I attached files for short check. This code doesn't contain additional event handler to capture the Ctrl- Enter. I tried this and tried some exapmples (workarounds from internet) which are not implemented. The events and workaround doesn' work. Sadly I put all different samples and tries into the trash. Type a text in the Grid in the second column and second row (B2). Press ctrl-enter and the text is broken into next line of the cell (working example). If you do this in the non working examples (when wxPanel is used) after ctrl-enter the cursor is jump to the next control (text control). -- Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15264#comment:2&gt; </pre> wxTrac 2013-06-19T16:35:00 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149250 <pre>Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15253#comment:12&gt; #15253: No translation in osx trunk --------------------------+------------------------------------------------- Reporter: raananc | Owner: vaclavslavik Type: defect | Status: accepted Priority: normal | Milestone: 2.9.5 Component: translations | Version: Keywords: | Blockedby: Patch: 0 | Blocking: --------------------------+------------------------------------------------- Comment(by vaclavslavik): Replying to [comment:10 raananc]: &gt; do not provide translation when the mo file is in applicationPath/fr/translations.mo, It's possible the bug fixed in r74253 caused this. In any case, `AddCatalogLookupPathPrefix` looks into subdirs named after the language (and is documented to), so there's really no point in add per-language directory explicitly. You don't need to add `applicationPath/fr`, you only need to add `applicationPath` -- and it works for ''all'' languages. This is not specific to any platform. &gt; As for locale-&gt;GetSystemLanguage(), the discussion over what gives the user language in [http://trac.wxwidgets.org/ticket/15257 #15257] is too unconclusive There's nothing inconclusive about it. You should never ever under any circumstances use the default ''locale'' to set the UI ''language''. &gt; Can you be more specific as to what should be used? Nothing. Use `wxLANGUAGE_DEFAULT` when initializing and that's it. Add language-agnostic(!) paths with `AddCatalogLookupPathPrefix` if needed. But this breakage should still be fixed, of course, I'll have a look. -- Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15253#comment:12&gt; </pre> wxTrac 2013-06-19T16:27:28 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149249 <pre>Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15253#comment:11&gt; #15253: No translation in osx trunk --------------------------+------------------------------------------------- Reporter: raananc | Owner: vaclavslavik Type: defect | Status: accepted Priority: normal | Milestone: 2.9.5 Component: translations | Version: Keywords: | Blockedby: Patch: 0 | Blocking: --------------------------+------------------------------------------------- Changes (by vaclavslavik): * owner: =&gt; vaclavslavik * status: new =&gt; accepted Comment: Replying to [comment:3 raananc]: &gt; The relevant code in my application is: And what is the exact location (relative to `applicatoinPath`) of your `gestioncomptes.mo` file? -- Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15253#comment:11&gt; </pre> wxTrac 2013-06-19T16:01:37 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149248 <pre>Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15266&gt; #15266: Add support for horizontal mouse wheel scrolling to wxStyledTextCtrl ---------------------------------------------------------------+------------ Reporter: toiffel | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: wxStyledText | Version: 2.9-svn Keywords: wxStyledTextCtrl wxSTC horizontal scrolling wheel | Blockedby: Patch: 1 | Blocking: ---------------------------------------------------------------+------------ This patch does exactly what the title says - enables the horizontal scrolling using wxMouseEvent::GetColumnsPerAction() introduced in #15239. The current implementation doesn't distinguish between vertical and horizontal axes so the horizontal scrolling behaves as vertical one. In order to make things work I've added ''axis'' and ''columnsPerAction'' parameters to ScintillaWX::DoMouseWheel(). Note that unlike line-by-line vertical scrolling, Scintilla allows us to perform smooth horizontal scrolling on a pixel-by-pixel basis. Also ''wheelRotation'' accumulator is now splitted up to ''wheelVRotation'' and ''wheelHRotation'' members for vertical and horizontal axes respectively. -- Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15266&gt; </pre> wxTrac 2013-06-19T15:15:33 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149247 <pre>I was thinking that for the next patch I give you, with the wxEventLoopFactory (if we go that way, still need to look at that tonight, outside my day job), will be against the WIP commit, as we just discussed. I also plan to have the OS X API change to sockets in that commit as I've already done it, and it impacts only 1 file and is pretty localized. But then, when I do the refactoring to merge the data structures - I will start where I left off, but then I can make the patch be a diff against the commit just before the WIP commit. Then, it may be easier for you to understand, as you won't see code that is ripped out and replaced, you'll just see all the wxExecute stuff as new code. </pre> Rob Bresalier 2013-06-19T15:01:35 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149246 <pre> RB&gt; I used this commit of yours because it is a fully working version, so I can RB&gt; use it to verify changes work. OK, I didn't even realize this, sorry. As usual, ideal would be to have small obviously correct changes, e.g. the first one adding wxEventLoopFactory (if we go that way), then others building on top of it. But I can do the rebasing myself once we have the final version of the patch. Thanks, VZ </pre> Vadim Zeitlin 2013-06-19T14:32:25 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149245 <pre>I used this commit of yours because it is a fully working version, so I can use it to verify changes work. I know you want more refactoring, such as joining wxExecuteData, wxUnixProcess, wxEndProcess (may not be the exact names), so I'll do that in a later commit and remove code from your WIP commit to do it. This way, I can start with something that passes all tests, refactor that, and know if I broke anything. </pre> Rob Bresalier 2013-06-19T14:29:09 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149244 <pre>Hi Vadim: I need to digest the details in your mail, but want to comment on one item quickly while our time zones overlap. I think quite a few things are going to change compared to the last patch, No, I mean your WIP commit, not the one before it. There is much code that you put in there that is needed (many things unrelated to how fds are monitored). To be precise, I'm referring to all the changes you have in here: https://github.com/vadz/wxWidgets/commit/5f951773390b38a0347c601f01ee8277c7935ba9 My changes are built on top of the changes in this commit, this is where I branched off from you in my local git repository. Maybe you have 1 extra commit in your local repository that you never pushed to github? Regards, Rob </pre> Rob Bresalier 2013-06-19T14:26:13 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149243 <pre>Ticket URL: &lt;http://trac.wxwidgets.org/ticket/14314#comment:31&gt; #14314: Menu event routing problem ----------------------+----------------------------------------------------- Reporter: troelsk | Owner: vadz Type: defect | Status: accepted Priority: normal | Milestone: 2.9.5 Component: GUI-all | Version: 2.9-svn Resolution: | Keywords: mdi event Blockedby: | Patch: 0 Blocking: | ----------------------+----------------------------------------------------- Comment(by troelsk): &gt;would you have some simple test for this by chance? Added a little more to the sample, menuevent-problem.3.patch (includes the original patch, menuevent-problem.patch) -- Ticket URL: &lt;http://trac.wxwidgets.org/ticket/14314#comment:31&gt; </pre> wxTrac 2013-06-19T14:14:36 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149242 <pre> RB&gt; For my next patch, do you want it to be a diff against my previous RB&gt; submission or a diff against your WIP commit? Hi, I think quite a few things are going to change compared to the last patch, so perhaps a new diff against the commit before the WIP one (I think this is what you meant, but just wanted to be precise) would be easier for both of us. RB&gt; Based on your suggestion, I did some searching around, and I did find usage RB&gt; of the Socket API in the Qt library for precisely the same function RB&gt; (monitoring file descriptors) OK, very good, thanks for checking. RB&gt; &gt; RB&gt; AddSourceForFd() method into static methods. RB&gt; &gt; RB&gt; &gt; OK, let's do it, I think I already agreed to this in a previous RB&gt; &gt; discussion. RB&gt; &gt; RB&gt; I started this work and ran into a complication. Right now, there is a RB&gt; wxEventLoopBase::AddSourceForFd(), but there are also overloaded versions RB&gt; of these in the derived classes. For static functions, there is no such RB&gt; thing as 'virtual static', so I needed to rename all of the versions in the RB&gt; derived classes (GUI, Console, and CF (OSX)) to new names (such as RB&gt; wxGUIEventLoop::AddSourceForFdGUI(), RB&gt; wxConsoleEventLoop::AddSourceForFdConsole(), and RB&gt; wxCFEventLoop::AddSourceForFdCF()). To be honest I don't like these names very much. If we're going to use wxAppTraits anyhow to virtualize these calls, why not just put the code directly in wxAppTraits then? RB&gt; Next is the problem of being able to call the right version based on RB&gt; whether we are a console or GUI application. This is what wxAppTraits is for, so it has to be used. The only question is whether this should be done directly (as you are doing now, I think) or indirectly, via another class, as it was done before with the concrete wxEventLoop being created by wxAppTraits and then all the event loop stuff done in this derived wxEventLoop class. RB&gt; But I'm not sure if this is the best way to do it, and wanted to ask you RB&gt; how you would do it. If we do it like this, I'd just prefer to keep the real implementation in wxAppTraits itself and make wxEventLoopBase::AddSourceForFD() just a trivial wrapper. This is not very elegant, it would probably be nicer to do it indirectly by adding some new wxEventLoopFactory class which would actually represent the class of wxEventLoop, thus making it possible to have "virtual static": wxEventLoop methods which would be simple virtual methods of this class. I.e., in pseudo code: // New class in wx/private/eventloopfactory.h class wxEventLoopFactoryBase { public: virtual wxEventLoopBase* CreateLoop() = 0; #if wxUSE_EVENTLOOP_SOURCE virtual wxEventLoopSource* AddSourceForFD(int fd, wxEventLoopSourceHandler *handler, int flags) = 0; #endif }; // Changed code in wx/apptrait.h class wxAppTraitsBase { public: ... // This replaces the old CreateEventLoop(). virtual wxEventLoopFactoryBase *GetEventLoopFactory() = 0; // We may keep this one for convenience and to avoid // updating the existing code inside wx itself. virtual wxEventLoopBase *CreateEventLoop() { // This shouldn't be inline as we don't have // full wxEventLoopFactoryBase declaration // here, but in src/common/appbase.cpp return GetEventLoopFactory()-&gt;CreateLoop(); } }; // Implementation in e.g. src/gtk/evtloop.cpp (moved from // src/gtk/utilsgtk.cpp), will be similar for the other ports class wxGTKEventLoopFactory : public wxEventLoopFactoryBase { public: virtual wxEventLoopBase *CreateEventLoop() { return new wxGUIEventLoop(); } virtual wxEventLoopSource* AddSourceForFD(int fd, wxEventLoopSourceHandler *handler, int flagsint fd, wxEventLoopSourceHandler *handler, int flagsint fd, wxEventLoopSourceHandler *handler, int flags) { ... real code using g_io_add_watch() goes here ... } }; // This can be just a global object, there doesn't seem to be // any benefit in allocating it on the heap. static wxGTKEventLoopFactory gs_eventLoopFactory; wxEventLoopFactoryBase *wxGUIAppTraits::GetEventLoopFactory() { return &amp;gs_eventLoopFactory; } /* static */ wxEventLoopSource* wxGUIEventLoop::AddSourceForFD(int fd, wxEventLoopSourceHandler *handler, int flags) { return gs_eventLoopFactory.AddSourceForFD(fd, handler, flags); } Having written this just now, it doesn't seem that bad actually and looks nicer than just stuffing all this into wxAppTraits. So I think it would be nicer to do it like this. What do you think? RB&gt; &gt; I've left a few remarks concerning some of the changed of the patch but I RB&gt; &gt; think all of them could be fixed rather easily/quickly. Please let me know RB&gt; &gt; if you disagree or if you have any questions about what exactly did I RB&gt; &gt; mean. RB&gt; &gt; RB&gt; I glanced over your remarks and I will start tackling them tonight. Thanks again! VZ </pre> Vadim Zeitlin 2013-06-19T14:12:36 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149241 <pre>Hi Vadim: Thanks! Just a minor remark: it would probably be better to open a new Yes, I will create a new review. For my next patch, do you want it to be a diff against my previous submission or a diff against your WIP commit? I would think you want a diff against my last patch so it is a smaller package for you to consume, so you don't need to re-review code? When we are done I can give you a patch that covers all the changes since your "WIP" commit. RB&gt; The socket based method used in my last wxExecute patch did not have Based on your suggestion, I did some searching around, and I did find usage of the Socket API in the Qt library for precisely the same function (monitoring file descriptors) In Qt, there is the 'QSocketNotifier', which is used for monitoring file descriptors (not just sockets, but also pipes), see: http://qt-project.org/doc/qt-4.8/qsocketnotifier.html http://www.qtcentre.org/threads/18016-Watching-a-UNIX-file-descriptor I looked into the source code for OSX, and it is using the OS X socket API: See line 324 for the 'void QEventDispatcherMac::registerSocketNotifier(QSocketNotifier *notifier)' at this link: https://qt.gitorious.org/+qt-s60-developers/qt/qt-s60/blobs/5356d3717a9355830a13dfa0c8726f86a5f1c522/src/gui/kernel/qeventdispatcher_mac.mm I also found the API is used by google in the "Google toolbox for Mac", see: http://google-toolbox-for-mac.googlecode.com/svn-history/r41/trunk/Foundation/GTMSignalHandler.m So I think it is safe to use it. In fact, I have coded it last night and it passes all the wxExecute tests on Cocoa, GTK, and Carbon. And I was able to get rid of the hack code that I put in for demo purposes in order to get the code working with the old API! RB&gt; Also - I really think that we should change all implementations of the I started this work and ran into a complication. Right now, there is a wxEventLoopBase::AddSourceForFd(), but there are also overloaded versions of these in the derived classes. For static functions, there is no such thing as 'virtual static', so I needed to rename all of the versions in the derived classes (GUI, Console, and CF (OSX)) to new names (such as wxGUIEventLoop::AddSourceForFdGUI(), wxConsoleEventLoop::AddSourceForFdConsole(), and wxCFEventLoop::AddSourceForFdCF()). Next is the problem of being able to call the right version based on whether we are a console or GUI application. To do this, inside the body of the new static wxEventLoopBase::AddSourceForFd(), I get a pointer to the traits object (in the same way as wxExecute code), and then call a new function traits-&gt;AddSourceForFd(). I created GUI and console versions of wxAppTraits::AddSourceForFd(), and inside the appropriate version I call either the GUI (or CF for OSX) or console version. But I'm not sure if this is the best way to do it, and wanted to ask you how you would do it. I already have this coded and working, but it can be easily changed. I glanced over your remarks and I will start tackling them tonight. Regards, Rob </pre> Rob Bresalier 2013-06-19T13:47:57 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149240 <pre>Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15265&gt; #15265: wxListCtrl::AppendColumn detail -------------------------+-------------------------------------------------- Reporter: troelsk | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: GUI-all | Version: 2.9-svn Keywords: wxListCtrl | Blockedby: Patch: 1 | Blocking: -------------------------+-------------------------------------------------- This method is new, there is no reason not to make it type safe. Also, use AppendColumn() in 3 samples -- Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15265&gt; </pre> wxTrac 2013-06-19T13:22:26 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149239 <pre> SC&gt; ok, so you would rather set the max height to be GetBestSize().y than SC&gt; overriding this in SetSize ? Yes, but if setting smaller height doesn't work neither, then it probably doesn't really matter in practice... Regards, VZ </pre> Vadim Zeitlin 2013-06-19T13:04:47 http://permalink.gmane.org/gmane.comp.lib.wxwidgets.devel/149238 <pre>Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15264#comment:1&gt; #15264: Ctrl+Enter can't be used for wxGrid cell editing when parent is a wxPanel --------------------+------------------------------------------------------- Reporter: HelgeB | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: wxGrid | Version: 2.9.1 Keywords: | Blockedby: Patch: 0 | Blocking: --------------------+------------------------------------------------------- Comment(by vadz): As always, it would be very useful to have an as small as possible [HowToSubmitPatches patch] to the grid sample allowing to reproduce the problem. Could you please make one? -- Ticket URL: &lt;http://trac.wxwidgets.org/ticket/15264#comment:1&gt; </pre> wxTrac 2013-06-19T12:58:52 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.wxwidgets.devel