libwm - Project Hosting on Google Code

Last 30 days Nov 28, 2009 6 new revisions pushed by maililistaalterego - 43627a17d2:Fixed GCC compiler warnings, Win32 implementation should be checked for warnings later cd7c634d40:Vsync for GLX using GLX_SGI_swap_control, WIP 6c468887b9:Configuration::Capabilities, API docs for swapInterval 43e0a27c72:Removed (void)event; from the event handling functions used to get rid of GCC warnings. Will cause spectacular compile failure on MSVC. Another workaround is needed to satisfy GCC, MSVC and Doxygen. 76797b5355:Swap control for Win32 using WGL_EXT_swap_control. cd4e8c1ec9:Moved EventHandler::handle definitions outside of the class declaration as inline functions to work around unused parameter warnings 43627a17d2:Fixed GCC compiler warnings, Win32 implementation should be checked for warnings later cd7c634d40:Vsync for GLX using GLX_SGI_swap_control, WIP 6c468887b9:Configuration::Capabilities, API docs for swapInterval 43e0a27c72:Removed (void)event; from the event handling functions used to get rid of GCC warnings. Will cause spectacular compile failure on MSVC. Another workaround is needed to satisfy GCC, MSVC and Doxygen. 76797b5355:Swap control for Win32 using WGL_EXT_swap_control. cd4e8c1ec9:Moved EventHandler::handle definitions outside of the class declaration as inline functions to work around unused parameter warnings Nov 25, 2009 2 new revisions pushed by maililistaalterego - e1177ff8a1:Removed makeCurrent in favor of RAII-based CurrentContext class, Win32 broken 7de47e27a4:CurrentContext for Win32. e1177ff8a1:Removed makeCurrent in favor of RAII-based CurrentContext class, Win32 broken 7de47e27a4:CurrentContext for Win32. Earlier this year Sep 17, 2009 Revision 007d9cb5a0 (Workarounds to fix build issues on FreeBSD.) pushed by maililistaalterego - Workarounds to fix build issues on FreeBSD. Workarounds to fix build issues on FreeBSD. Sep 13, 2009 issue 27 (add memory managment via boost::shared_ptr) commented on by maililistaalterego - Also, our current design does not require Libwm-applications to have boost installed at compile time, because there are no references to boost in the public interface. Also, our current design does not require Libwm-applications to have boost installed at compile time, because there are no references to boost in the public interface. Sep 13, 2009 issue 28 (build breaks on vs 2005) changed by maililistaalterego - TRACKMOUSEEVENT is located in the WinUser.h header inside the Microsoft Platform SDK. Does the compiler find WinUser.h or are the include paths missing something? If the header is found, is there some weird macro that makes TRACKMOUSEEVENT behave funny? I don't have Visual Studio 2005 or the time to fix this problem. Please send CMakeFiles.txt patches, preferably as Mercurial Bundles. Status: Accepted Labels: Priority-Low −Priority-Medium TRACKMOUSEEVENT is located in the WinUser.h header inside the Microsoft Platform SDK. Does the compiler find WinUser.h or are the include paths missing something? If the header is found, is there some weird macro that makes TRACKMOUSEEVENT behave funny? I don't have Visual Studio 2005 or the time to fix this problem. Please send CMakeFiles.txt patches, preferably as Mercurial Bundles. Status: Accepted Labels: Priority-Low −Priority-Medium Sep 13, 2009 issue 27 (add memory managment via boost::shared_ptr) changed by maililistaalterego - Thanks for posting the issue/enhancement/issue request. When I designed libwm I considered various smart pointers to handle the pimpl idiom opaque pointers, but I ended up with raw pointers. Shared pointers cannot be used with forward declared types and that makes using the pimpl idiom worthless, since you'd have to include the platform-dependent implementation headers to the public headers. Shared ptr's have inconvinient side effects, especially when it comes to multi threading. I initially used boost::scoped_ptr's, which can be used with the pimpl idiom, but I ended up having difficulties when I wanted to build .dll's/shared libs. The problems were related to __delcspec(dllexport/dllimport) and apparently it wasn't easy to use the boost templates as member variables in WM_EXPORT/__declspec'd classes so I ended up using raw pointers. I did a small hack with std::auto_ptr's to ensure clean destruction in case of exceptions in constructors. Using smart pointers to store libwm objects may not be a smart option to start with. Libwm expects some objects to out-live others and reference counted garbage collection may mess up the object lifetimes and make things go wrong. A better solution would be not to have Libwm objects behind shared pointers but rather use the object values directly. (in the class Pipeline above, all wmWindowPtr's etc would be just a plain wm::Window and a shared_ptr<Pipeline> would be used elsewhere if reference counting is required). Libwm also expects EventHandlers to be disconnected before the associated window is created. This can be done with wm::Connections ctor/dtor to a limited extent, but in many cases it is better to use .connect() and .disconnect() for explicit control over event handler connections. Maybe the tutorial and the doxygen docs could be improved in this aspect. Status: WontFix Labels: Type-Enhancement −Type-Defect Thanks for posting the issue/enhancement/issue request. When I designed libwm I considered various smart pointers to handle the pimpl idiom opaque pointers, but I ended up with raw pointers. Shared pointers cannot be used with forward declared types and that makes using the pimpl idiom worthless, since you'd have to include the platform-dependent implementation headers to the public headers. Shared ptr's have inconvinient side effects, especially when it comes to multi threading. I initially used boost::scoped_ptr's, which can be used with the pimpl idiom, but I ended up having difficulties when I wanted to build .dll's/shared libs. The problems were related to __delcspec(dllexport/dllimport) and apparently it wasn't easy to use the boost templates as member variables in WM_EXPORT/__declspec'd classes so I ended up using raw pointers. I did a small hack with std::auto_ptr's to ensure clean destruction in case of exceptions in constructors. Using smart pointers to store libwm objects may not be a smart option to start with. Libwm expects some objects to out-live others and reference counted garbage collection may mess up the object lifetimes and make things go wrong. A better solution would be not to have Libwm objects behind shared pointers but rather use the object values directly. (in the class Pipeline above, all wmWindowPtr's etc would be just a plain wm::Window and a shared_ptr<Pipeline> would be used elsewhere if reference counting is required). Libwm also expects EventHandlers to be disconnected before the associated window is created. This can be done with wm::Connections ctor/dtor to a limited extent, but in many cases it is better to use .connect() and .disconnect() for explicit control over event handler connections. Maybe the tutorial and the doxygen docs could be improved in this aspect. Status: WontFix Labels: Type-Enhancement −Type-Defect Sep 10, 2009 issue 28 (build breaks on vs 2005) reported by bobkuehne - What steps will reproduce the problem? 1. download trunk libwm 2. cmake (2.6.4) and use 'visual studio 8 2005' as the generator 3. build the resultant libwm.sln What is the expected output? What do you see instead? expect a clean build, see: ... 1>window.cpp 1>..\..\..\libwm\src\win32\window.cpp(95) : error C2065: 'TRACKMOUSEEVENT' : undeclared identifier 1>..\..\..\libwm\src\win32\window.cpp(95) : error C2146: syntax error : missing ';' before identifier 'tme' 1>..\..\..\libwm\src\win32\window.cpp(95) : error C2065: 'tme' : undeclared identifier 1>..\..\..\libwm\src\win32\window.cpp(96) : error C2228: left of '.cbSize' must have class/struct/union 1> type is ''unknown-type'' 1>..\..\..\libwm\src\win32\window.cpp(96) : error C2070: ''unknown-type'': illegal sizeof operand 1>..\..\..\libwm\src\win32\window.cpp(97) : error C2228: left of '.dwFlags' must have class/struct/union ... What version of the product are you using? On what operating system? * libwm trunk * windows xp * visual studio 8 / 2005 What steps will reproduce the problem? 1. download trunk libwm 2. cmake (2.6.4) and use 'visual studio 8 2005' as the generator 3. build the resultant libwm.sln What is the expected output? What do you see instead? expect a clean build, see: ... 1>window.cpp 1>..\..\..\libwm\src\win32\window.cpp(95) : error C2065: 'TRACKMOUSEEVENT' : undeclared identifier 1>..\..\..\libwm\src\win32\window.cpp(95) : error C2146: syntax error : missing ';' before identifier 'tme' 1>..\..\..\libwm\src\win32\window.cpp(95) : error C2065: 'tme' : undeclared identifier 1>..\..\..\libwm\src\win32\window.cpp(96) : error C2228: left of '.cbSize' must have class/struct/union 1> type is ''unknown-type'' 1>..\..\..\libwm\src\win32\window.cpp(96) : error C2070: ''unknown-type'': illegal sizeof operand 1>..\..\..\libwm\src\win32\window.cpp(97) : error C2228: left of '.dwFlags' must have class/struct/union ... What version of the product are you using? On what operating system? * libwm trunk * windows xp * visual studio 8 / 2005 Sep 09, 2009 issue 27 (add memory managment via boost::shared_ptr) commented on by bobkuehne - i figured out that my crash was due to event handlers not being disconnected at window destruction. this too, i suspect could be improved with non-raw pointer handling, but for now, i'm happy to table my request. i figured out that my crash was due to event handlers not being disconnected at window destruction. this too, i suspect could be improved with non-raw pointer handling, but for now, i'm happy to table my request. Sep 09, 2009 issue 27 (add memory managment via boost::shared_ptr) commented on by bobkuehne - meant to mark this as a feature request... meant to mark this as a feature request... Sep 09, 2009 issue 27 (add memory managment via boost::shared_ptr) reported by bobkuehne - i'm trying to integrate libwm in an app we produce, and we use boost shared_ptrs throughout to allow clean cross-referencing of related objets. i notice that none of the internal objects use anything except raw pointers, and this is actually causing me a problem on app shutdown. in my app, i package up the objects together in a class, creating display, window, surface, and context together in the destructor, storing them in shared_ptrs, and then letting automatic cleanup occur on class destruction. example code below. the problem occurs when this class goes away, and the objects are destroyed in an order which seemingly has some dependency. i consistently get a crash on exit in wm::Display::impl_t::Registry::remove, where another component has already been deleted, but this remove is relying on it. at any rate, if objects were managed internally as shared_ptrs, then i suspect some of this pain could be mitigated. you already have a boost dependency for the examples, and shared_ptr is a header-only dependency. i'd be happy to do the work... class Pipeline { public: Pipeline() { // setup windows/displays display_ = wmDisplayPtr( new wm::Display ); config_ = wmConfigurationPtr( new wm::Configuration( display_ ) ); window_ = wmWindowPtr( new wm::Window( display_, 1024, 768, wm::choose( config_, 8, 8, 8, 8, 16, 0 ) ) ); surface_ = wmSurfacePtr( new wm::Surface( window_ ) ); context_ = wmContextPtr( new wm::Context( window_->pixelformat(), 3, 1, true, true ) ); } protected: wmWindowPtr window_; wmContextPtr context_; wmSurfacePtr surface_; wmConfigurationPtr config_; wmDisplayPtr display_; }; i'm trying to integrate libwm in an app we produce, and we use boost shared_ptrs throughout to allow clean cross-referencing of related objets. i notice that none of the internal objects use anything except raw pointers, and this is actually causing me a problem on app shutdown. in my app, i package up the objects together in a class, creating display, window, surface, and context together in the destructor, storing them in shared_ptrs, and then letting automatic cleanup occur on class destruction. example code below. the problem occurs when this class goes away, and the objects are destroyed in an order which seemingly has some dependency. i consistently get a crash on exit in wm::Display::impl_t::Registry::remove, where another component has already been deleted, but this remove is relying on it. at any rate, if objects were managed internally as shared_ptrs, then i suspect some of this pain could be mitigated. you already have a boost dependency for the examples, and shared_ptr is a header-only dependency. i'd be happy to do the work... class Pipeline { public: Pipeline() { // setup windows/displays display_ = wmDisplayPtr( new wm::Display ); config_ = wmConfigurationPtr( new wm::Configuration( display_ ) ); window_ = wmWindowPtr( new wm::Window( display_, 1024, 768, wm::choose( config_, 8, 8, 8, 8, 16, 0 ) ) ); surface_ = wmSurfacePtr( new wm::Surface( window_ ) ); context_ = wmContextPtr( new wm::Context( window_->pixelformat(), 3, 1, true, true ) ); } protected: wmWindowPtr window_; wmContextPtr context_; wmSurfacePtr surface_; wmConfigurationPtr config_; wmDisplayPtr display_; }; Sep 07, 2009 Revision 386fd89880 (Changed PROJECT_VERSION to 0.2.1 in CMakeLists.txt) pushed by maililistaalterego - Changed PROJECT_VERSION to 0.2.1 in CMakeLists.txt Changed PROJECT_VERSION to 0.2.1 in CMakeLists.txt Aug 29, 2009 2 new revisions pushed by maililistaalterego - Revision 8e2a10e2f9:Changed PROJECT_VERSION to 0.2.0 in CMakeLists.txt Revision 827ad516a4:Tagged version 0.2.0 Revision 8e2a10e2f9:Changed PROJECT_VERSION to 0.2.0 in CMakeLists.txt Revision 827ad516a4:Tagged version 0.2.0 Aug 29, 2009 issue 26 (Add support for vsync) reported by maililistaalterego - Add support for vsync extensions like GLX_SGIX_swap_control. Add support for vsync extensions like GLX_SGIX_swap_control. Aug 28, 2009 libwm-0.2.0-Doc.zip (Libwm 0.2.0 API documentation) file uploaded by maililistaalterego - Labels: Type-Docs OpSys-All Labels: Type-Docs OpSys-All Aug 28, 2009 libwm-0.2.0-Darwin.tar.bz2 (Libwm 0.2.0 binaries for Mac OS X Darwin) file uploaded by maililistaalterego - Labels: Type-Archive OpSys-OSX Labels: Type-Archive OpSys-OSX Aug 28, 2009 libwm-0.2.0-win32.zip (Libwm 0.2.0 binaries for Windows / MSVC++) file uploaded by maililistaalterego - Labels: Type-Archive OpSys-Windows Labels: Type-Archive OpSys-Windows Aug 28, 2009 libwm-0.2.0-Source.tar.bz2 (Libwm 0.2.0 source code) file uploaded by maililistaalterego - Labels: Type-Source OpSys-All Labels: Type-Source OpSys-All Aug 28, 2009 issue 18 (Floating point pixel formats) changed by maililistaalterego - Added support for floating point and packed float pixel formats. Status: Fixed Labels: OpSys-All Added support for floating point and packed float pixel formats. Status: Fixed Labels: OpSys-All Aug 28, 2009 issue 17 (Shared-exponent (SRGB) pixel formats) Status changed by maililistaalterego - Added support for {WGL,GLX}_{EXT,ARB}_framebuffer_sRGB. Status: Fixed Added support for {WGL,GLX}_{EXT,ARB}_framebuffer_sRGB. Status: Fixed Aug 27, 2009 7 new revisions pushed by maililistaalterego - Revision eb853b3b8d:Added support for WGL_{EXT,ARB}_framebuffer_sRGB Revision 0d978e6ac9:Support for WGL_ARB_pixel_format_float and WGL_EXT_pixel_format_packed_float Revision 91af974944:Detect slow/software pixel formats on WGL Revision f20813e6f2:Added Configuration::getProcAddress wrapper for wglGetProcAddress Revision 08a33ee68d:Use GLX_CONFIG_CAVEAT on GLX 1.3 and GLX_EXT_visual_rating on GLX 1.2 to detect slow pixel formats Revision 53cab430df:Added Configuration::getProcAddress for GLX Revision a8454c893e:Changed incorrect references to GLX_EXT_packed_float to GLX_EXT_fbconfig_packed_float Revision eb853b3b8d:Added support for WGL_{EXT,ARB}_framebuffer_sRGB Revision 0d978e6ac9:Support for WGL_ARB_pixel_format_float and WGL_EXT_pixel_format_packed_float Revision 91af974944:Detect slow/software pixel formats on WGL Revision f20813e6f2:Added Configuration::getProcAddress wrapper for wglGetProcAddress Revision 08a33ee68d:Use GLX_CONFIG_CAVEAT on GLX 1.3 and GLX_EXT_visual_rating on GLX 1.2 to detect slow pixel formats Revision 53cab430df:Added Configuration::getProcAddress for GLX Revision a8454c893e:Changed incorrect references to GLX_EXT_packed_float to GLX_EXT_fbconfig_packed_float Aug 26, 2009 Revision 640fa6683e (Added support for GLX_{EXT,ARB}_framebuffer_sRGB, GLX_ARB_fb...) pushed by maililistaalterego - Added support for GLX_{EXT,ARB}_framebuffer_sRGB, GLX_ARB_fbconfig_float and GLX_EXT_packed_float Added support for GLX_{EXT,ARB}_framebuffer_sRGB, GLX_ARB_fbconfig_float and GLX_EXT_packed_float Aug 25, 2009 Revision 6edf61fa80 (Added missing doxygen comment annotations for wm::choose par...) pushed by maililistaalterego - Added missing doxygen comment annotations for wm::choose parameters Added missing doxygen comment annotations for wm::choose parameters Aug 25, 2009 Building Wiki page commented on by maililistaalterego - Nope, it's not a typo. I put ccmake (the console/curses gui) instead of the command line cmake intentionally there so users would find the compile time configuration options easier. You could also use cmake-gui. Nope, it's not a typo. I put ccmake (the console/curses gui) instead of the command line cmake intentionally there so users would find the compile time configuration options easier. You could also use cmake-gui. Aug 25, 2009 issue 16 (Multisampling support) Status changed by maililistaalterego - Added support for {WGL,GLX}_ARB_multisample and GLX 1.3 multisampling. Status: Fixed Added support for {WGL,GLX}_ARB_multisample and GLX 1.3 multisampling. Status: Fixed Aug 25, 2009 issue 25 (Support separate read and draw surfaces on Win32 (WGL_ARB_ma...) Status changed by maililistaalterego - Added support for WGL_ARB_make_current_read. Status: Fixed Added support for WGL_ARB_make_current_read. Status: Fixed Aug 25, 2009 issue 24 (Handle indirect rendering with GLX) Status changed by maililistaalterego - Added a constructor parameter for direct/indirect rendering and Context::direct as a wrapper for glXIsDirect. Status: Fixed Added a constructor parameter for direct/indirect rendering and Context::direct as a wrapper for glXIsDirect. Status: Fixed Aug 25, 2009 4 new revisions pushed by maililistaalterego - Revision 9244760bcf:Added multisampling support for GLX 1.3 Revision de95865145:Support for GLX_ARB_multisample for GLX 1.2 multisampling, moved PixelFormatBuilder to Configuration::impl to fix a segfaulting problem Revision 6db83e8907:WGL_ARB_multisample support Revision 9c19dd3111:WGL_ARB_make_current_read support Revision 9244760bcf:Added multisampling support for GLX 1.3 Revision de95865145:Support for GLX_ARB_multisample for GLX 1.2 multisampling, moved PixelFormatBuilder to Configuration::impl to fix a segfaulting problem Revision 6db83e8907:WGL_ARB_multisample support Revision 9c19dd3111:WGL_ARB_make_current_read support Aug 22, 2009 Building Wiki page commented on by sschuberth - Minor typo, I believe it should be "cmake" instead of "ccmake" under "Configuring the build". Minor typo, I believe it should be "cmake" instead of "ccmake" under "Configuring the build". Aug 21, 2009 issue 14 (Multi screen support) commented on by tuan.kuranes - multiscreen, if possible multi GPU supports on platform that have support for it. (where GPU affinity extension in nvidia/ati drivers) Both support are heavily bonded, as you may want to attach a specific render context/window to a GPU. multiscreen, if possible multi GPU supports on platform that have support for it. (where GPU affinity extension in nvidia/ati drivers) Both support are heavily bonded, as you may want to attach a specific render context/window to a GPU. Aug 19, 2009 issue 25 (Support separate read and draw surfaces on Win32 (WGL_ARB_ma...) reported by maililistaalterego - Add support for [http://www.opengl.org/registry/specs/ARB/wgl_make_current_read.txt WGL_ARB_make_current_read] extension. Add support for [http://www.opengl.org/registry/specs/ARB/wgl_make_current_read.txt WGL_ARB_make_current_read] extension. Aug 19, 2009 Revision a0a6483bef (Added OpenGL/glu.h to wm/opengl/opengl.hpp for OSX) pushed by maililistaalterego - Added OpenGL/glu.h to wm/opengl/opengl.hpp for OSX Added OpenGL/glu.h to wm/opengl/opengl.hpp for OSX Aug 19, 2009 issue 15 (OpenGL 3.x / ARB_create_context support) Status changed by maililistaalterego - Added support for {WGL,GLX}_ARB_create_context. Status: Fixed Added support for {WGL,GLX}_ARB_create_context. Status: Fixed Aug 19, 2009 4 new revisions pushed by maililistaalterego - Revision 80087bdaea:WGL_ARB_create_context support, Xlib broken Revision b42e518ef3:Added dummy parameters and Context::direct for Xlib Revision 984b9cf1bf:GLX_ARB_create_context support Revision 9ad8abc9cd:Added OpenGL version checking to test application Revision 80087bdaea:WGL_ARB_create_context support, Xlib broken Revision b42e518ef3:Added dummy parameters and Context::direct for Xlib Revision 984b9cf1bf:GLX_ARB_create_context support Revision 9ad8abc9cd:Added OpenGL version checking to test application Aug 18, 2009 Revision 52ff340821 (GLX extension query and loading functions) pushed by maililistaalterego - GLX extension query and loading functions GLX extension query and loading functions Aug 17, 2009 2 new revisions pushed by maililistaalterego - Revision 423b52182d:Added Surface::getSize for GLX/Xlib Revision 5cd642e947:Surface::getSize for Win32 Revision 423b52182d:Added Surface::getSize for GLX/Xlib Revision 5cd642e947:Surface::getSize for Win32 Aug 13, 2009 libwm-0.1.0-Doc.tar.bz2 (Libwm 0.1.0 API documentation) file uploaded by maililistaalterego - Labels: Type-Docs OpSys-All Labels: Type-Docs OpSys-All Aug 13, 2009 libwm-0.1.0-Darwin.tar.bz2 (Libwm 0.1.0 binaries for Mac OS X Darwin) file uploaded by maililistaalterego - Labels: OpSys-OSX Type-Archive Labels: OpSys-OSX Type-Archive Aug 13, 2009 libwm-0.1.0-win32.zip (Libwm 0.1.0 binaries for Windows) file uploaded by maililistaalterego - Labels: Type-Archive OpSys-Windows Labels: Type-Archive OpSys-Windows Aug 13, 2009 libwm-0.1.0-Source.tar.bz2 (Libwm 0.1.0 source code) file uploaded by maililistaalterego - Labels: Type-Source OpSys-All Labels: Type-Source OpSys-All Aug 13, 2009 2 new revisions pushed by maililistaalterego - Revision ca06eccfc4:Set PROJECT_VERSION to 0.1.0 in CMakeLists.txt Revision 556cf316bc:Added tag v0.1.0 for changeset ca06eccfc40f Revision ca06eccfc4:Set PROJECT_VERSION to 0.1.0 in CMakeLists.txt Revision 556cf316bc:Added tag v0.1.0 for changeset ca06eccfc40f Aug 13, 2009 2 new revisions pushed by maililistaalterego - Revision e905315b1b:Set CPack to build .zip packages on Win32 Revision 42dc12a06f:Added LGPL License text to doc/ Revision e905315b1b:Set CPack to build .zip packages on Win32 Revision 42dc12a06f:Added LGPL License text to doc/ Aug 13, 2009 issue 24 (Handle indirect rendering with GLX) reported by maililistaalterego - Currently the Context constructor is hard-coded to create direct rendering contexts. This will cause an Xlib error handler to be invoked if direct rendering is not possible the specified pixel format (Visual/GLXFBConfig). Try to detect pixel formats that can be used with direct rendering, perhaps by creating a dummy context with direct rendering = false and glXIsDirect to see if the context is actually direct. Although indirect rendering is slow, supporting software rendering and over the network rendering is a nice feature. Also, the Xlib error handler crashes are very ugly. Currently the Context constructor is hard-coded to create direct rendering contexts. This will cause an Xlib error handler to be invoked if direct rendering is not possible the specified pixel format (Visual/GLXFBConfig). Try to detect pixel formats that can be used with direct rendering, perhaps by creating a dummy context with direct rendering = false and glXIsDirect to see if the context is actually direct. Although indirect rendering is slow, supporting software rendering and over the network rendering is a nice feature. Also, the Xlib error handler crashes are very ugly. Aug 12, 2009 6 new revisions pushed by maililistaalterego - Revision f3f6534508:Disabled generating Doxygen/GraphViz/Dot diagrams Revision 0ee7b58faf:Changed Win32 to use window class atoms instead of classname, simplified name generation Revision a08d96df7e:Use FormatMessageA instead of FormatMessageW for error message formatting on Win32 Revision 92b447a6d4:Added a few error checks in win32 window.cpp Revision ad246e5a54:Small cleanups in WGL code Revision a90329eb42:Try to build test/application only if boost date_time and thread are found Revision f3f6534508:Disabled generating Doxygen/GraphViz/Dot diagrams Revision 0ee7b58faf:Changed Win32 to use window class atoms instead of classname, simplified name generation Revision a08d96df7e:Use FormatMessageA instead of FormatMessageW for error message formatting on Win32 Revision 92b447a6d4:Added a few error checks in win32 window.cpp Revision ad246e5a54:Small cleanups in WGL code Revision a90329eb42:Try to build test/application only if boost date_time and thread are found Aug 12, 2009 Revision 8ec6a30ca9 (Moved GLX pixel format builder stuff from Configuration::imp...) pushed by maililistaalterego - Moved GLX pixel format builder stuff from Configuration::impl_t to constructor local variables Moved GLX pixel format builder stuff from Configuration::impl_t to constructor local variables Aug 12, 2009 2 new revisions pushed by maililistaalterego - Revision a2a46627e2:Added a new utility function for choosing pixel formats Revision 7cb0cf7a4a:Moved Display and Configuration implementation details from Wiki to API docs. Revision a2a46627e2:Added a new utility function for choosing pixel formats Revision 7cb0cf7a4a:Moved Display and Configuration implementation details from Wiki to API docs. Aug 10, 2009 2 new revisions pushed by maililistaalterego - Revision 4ae691a750:Fixed a few uninitialized members in win32 event reader Revision 90c238f165:Changed from using boost::uint32_t to unsigned int Revision 4ae691a750:Fixed a few uninitialized members in win32 event reader Revision 90c238f165:Changed from using boost::uint32_t to unsigned int Aug 06, 2009 Revision c9a4b427e3 (Fixed a bug in Win32 WM_PAINT message handling that caused a...) pushed by maililistaalterego - Fixed a bug in Win32 WM_PAINT message handling that caused an infinite loop when Window::resize changed the window not to fit on the screen Fixed a bug in Win32 WM_PAINT message handling that caused an infinite loop when Window::resize changed the window not to fit on the screen Aug 06, 2009 Revision 20e4567929 (Win32 Window::setFullscreen restores previous window size wh...) pushed by maililistaalterego - Win32 Window::setFullscreen restores previous window size when going back to windowed Win32 Window::setFullscreen restores previous window size when going back to windowed Aug 06, 2009 2 new revisions pushed by maililistaalterego - Revision 1360f9a3ca:Configured cmake, doxygen and latex to build pdf api docs Revision 0c47f33e10:Fixed a typo that caused a syntax error Revision 1360f9a3ca:Configured cmake, doxygen and latex to build pdf api docs Revision 0c47f33e10:Fixed a typo that caused a syntax error Aug 05, 2009 4 new revisions pushed by maililistaalterego - Revision 0af0156099:Window::repaint for Xlib Revision 9cfd757c0d:Window::repaint for Win32, got rid of some double->float truncation MSVC++ warnings in test applications Revision 33b4b717ac:Changed Window:: and Display::dispatch to Display::wait, ::poll, Window::wait and ::dispatch, Xlib broken Revision 41e8c09ef5:Display::wait, ::poll, Window::wait and ::dispatch for Xlib Revision 0af0156099:Window::repaint for Xlib Revision 9cfd757c0d:Window::repaint for Win32, got rid of some double->float truncation MSVC++ warnings in test applications Revision 33b4b717ac:Changed Window:: and Display::dispatch to Display::wait, ::poll, Window::wait and ::dispatch, Xlib broken Revision 41e8c09ef5:Display::wait, ::poll, Window::wait and ::dispatch for Xlib

issue 27 (add memory managment via boost::shared_ptr) changed by maililistaalterego - Thanks for posting the issue/enhancement/issue request. When I designed libwm I considered various smart pointers to handle the pimpl idiom opaque pointers, but I ended up with raw pointers. Shared pointers cannot be used with forward declared types and that makes using the pimpl idiom worthless, since you'd have to include the platform-dependent implementation headers to the public headers. Shared ptr's have inconvinient side effects, especially when it comes to multi threading. I initially used boost::scoped_ptr's, which can be used with the pimpl idiom, but I ended up having difficulties when I wanted to build .dll's/shared libs. The problems were related to __delcspec(dllexport/dllimport) and apparently it wasn't easy to use the boost templates as member variables in WM_EXPORT/__declspec'd classes so I ended up using raw pointers. I did a small hack with std::auto_ptr's to ensure clean destruction in case of exceptions in constructors. Using smart pointers to store libwm objects may not be a smart option to start with. Libwm expects some objects to out-live others and reference counted garbage collection may mess up the object lifetimes and make things go wrong. A better solution would be not to have Libwm objects behind shared pointers but rather use the object values directly. (in the class Pipeline above, all wmWindowPtr's etc would be just a plain wm::Window and a shared_ptr<Pipeline> would be used elsewhere if reference counting is required). Libwm also expects EventHandlers to be disconnected before the associated window is created. This can be done with wm::Connections ctor/dtor to a limited extent, but in many cases it is better to use .connect() and .disconnect() for explicit control over event handler connections. Maybe the tutorial and the doxygen docs could be improved in this aspect.

Status: WontFix

Labels: Type-Enhancement −Type-Defect

Thanks for posting the issue/enhancement/issue request. When I designed libwm I considered various smart pointers to handle the pimpl idiom opaque pointers, but I ended up with raw pointers. Shared pointers cannot be used with forward declared types and that makes using the pimpl idiom worthless, since you'd have to include the platform-dependent implementation headers to the public headers. Shared ptr's have inconvinient side effects, especially when it comes to multi threading. I initially used boost::scoped_ptr's, which can be used with the pimpl idiom, but I ended up having difficulties when I wanted to build .dll's/shared libs. The problems were related to __delcspec(dllexport/dllimport) and apparently it wasn't easy to use the boost templates as member variables in WM_EXPORT/__declspec'd classes so I ended up using raw pointers. I did a small hack with std::auto_ptr's to ensure clean destruction in case of exceptions in constructors. Using smart pointers to store libwm objects may not be a smart option to start with. Libwm expects some objects to out-live others and reference counted garbage collection may mess up the object lifetimes and make things go wrong. A better solution would be not to have Libwm objects behind shared pointers but rather use the object values directly. (in the class Pipeline above, all wmWindowPtr's etc would be just a plain wm::Window and a shared_ptr<Pipeline> would be used elsewhere if reference counting is required). Libwm also expects EventHandlers to be disconnected before the associated window is created. This can be done with wm::Connections ctor/dtor to a limited extent, but in many cases it is better to use .connect() and .disconnect() for explicit control over event handler connections. Maybe the tutorial and the doxygen docs could be improved in this aspect.

Status: WontFix

Labels: Type-Enhancement −Type-Defect

Last 30 days

Earlier this year