nvidia-widgets - Project Hosting on Google Code

Earlier this year Aug 31, 2009 issue 9 (It doesn't compile on 64-bit Mac OS X Snow Leopard) Status changed by castano - This bug has been fixed already. Status: Fixed This bug has been fixed already. Status: Fixed Aug 31, 2009 issue 9 (It doesn't compile on 64-bit Mac OS X Snow Leopard) reported by Huahang.Liu - What steps will reproduce the problem? 1. Try to compile this library. What is the expected output? What do you see instead? It should compile but it doesn't... The error is in the 3rd line of the this function void GLUIPainter::drawTextureView() This line doesn't compile. Because GLunit is 32-bit but texID is a const void* which is 64-bit on a 64-bit machine. And the compiler will report an error here. GLuint lTexID = reinterpret_cast<GLuint> ( texID ); What version of the product are you using? On what operating system? Snow Leopard Please provide any additional information below. N/A What steps will reproduce the problem? 1. Try to compile this library. What is the expected output? What do you see instead? It should compile but it doesn't... The error is in the 3rd line of the this function void GLUIPainter::drawTextureView() This line doesn't compile. Because GLunit is 32-bit but texID is a const void* which is 64-bit on a 64-bit machine. And the compiler will report an error here. GLuint lTexID = reinterpret_cast<GLuint> ( texID ); What version of the product are you using? On what operating system? Snow Leopard Please provide any additional information below. N/A Aug 03, 2009 issue 8 (LineEdit Bug) commented on by cheng.clei - Never mind. I solved this issue by adding a checking to see if the returned code of function translateKey is not 0. If yes, then ignore. Never mind. I solved this issue by adding a checking to see if the returned code of function translateKey is not 0. If yes, then ignore. Aug 03, 2009 issue 8 (LineEdit Bug) reported by cheng.clei - What steps will reproduce the problem? 1. Enter a capitalized letter in a LineEdit widget (pushing Shift key) What is the expected output? What do you see instead? Crash. seems due to wrong m_focusCaretPos value What version of the product are you using? On what operating system? 1.0.0 Please provide any additional information below. What steps will reproduce the problem? 1. Enter a capitalized letter in a LineEdit widget (pushing Shift key) What is the expected output? What do you see instead? Crash. seems due to wrong m_focusCaretPos value What version of the product are you using? On what operating system? 1.0.0 Please provide any additional information below. Jun 10, 2009 issue 7 (UIContext Class not as open as it could be...) changed by castano - Thanks for the request. Similar functionality has been requested by multiple users already. I agree there's a risk of breaking users code if we expose too much and change the inner workings later. So, we have be careful with that. BTW, if you have any patches that add support for other input devices I'd be happy to integrate them. Status: Accepted Labels: Type-Enhancement −Type-Defect Thanks for the request. Similar functionality has been requested by multiple users already. I agree there's a risk of breaking users code if we expose too much and change the inner workings later. So, we have be careful with that. BTW, if you have any patches that add support for other input devices I'd be happy to integrate them. Status: Accepted Labels: Type-Enhancement −Type-Defect Jun 10, 2009 issue 7 (UIContext Class not as open as it could be...) reported by Dudymas - This is an enhancement/feature request. Since this is an open library, I'd like the ability to extend the widgets of the UIContext class in nvwidgets.h without having to necessarily rewrite some of the current private functions. That is, change some of the private functions to be protected: static bool UIContext::overlap(const Rect & rect, const Point & p); bool UIContext::hasFocus(const Rect & rect); bool UIContext::isHover(const Rect & rect); Just so that if a user of the library only wants to add a couple widgets or recombine them... rewriting the mouse calls and duplicating mouse data wouldn't be necessary. You'd have to move some of the mouse data from private to protected as well. Other functions are more intricately laced with the class and understandably should be rewritten in the case that an inherited context is being used... Also, I understand that if I start adding to the classes, I have to be ready for these functions to totally be changed or removed, and possibly it will hurt development if someone wants to change them and a lot of people use an older class interface. Soooooo..... this is just a request. See what you guys think about it. As an example, I want to add tablet support to the library... and then make a couple redo's of the widgets to make them support pressure and tilt changes. Perhaps that gives you an idea of what would be done... and what might need to be added. This is an enhancement/feature request. Since this is an open library, I'd like the ability to extend the widgets of the UIContext class in nvwidgets.h without having to necessarily rewrite some of the current private functions. That is, change some of the private functions to be protected: static bool UIContext::overlap(const Rect & rect, const Point & p); bool UIContext::hasFocus(const Rect & rect); bool UIContext::isHover(const Rect & rect); Just so that if a user of the library only wants to add a couple widgets or recombine them... rewriting the mouse calls and duplicating mouse data wouldn't be necessary. You'd have to move some of the mouse data from private to protected as well. Other functions are more intricately laced with the class and understandably should be rewritten in the case that an inherited context is being used... Also, I understand that if I start adding to the classes, I have to be ready for these functions to totally be changed or removed, and possibly it will hurt development if someone wants to change them and a lot of people use an older class interface. Soooooo..... this is just a request. See what you guys think about it. As an example, I want to add tablet support to the library... and then make a couple redo's of the widgets to make them support pressure and tilt changes. Perhaps that gives you an idea of what would be done... and what might need to be added. Jun 07, 2009 r15 (Fix gl error, set window extents at init. Fix default argume...) committed by castano - Fix gl error, set window extents at init. Fix default argument of doTextureView. Change doTextureView API to take pointer to GLuint. Update example to show how to use doTextureView. Fix gl error, set window extents at init. Fix default argument of doTextureView. Change doTextureView API to take pointer to GLuint. Update example to show how to use doTextureView. Jun 07, 2009 r14 (Fix gcc warnings. ) committed by castano - Fix gcc warnings. Fix gcc warnings. May 03, 2009 issue 6 (Example fails on GLEW) commented on by Dudymas - I get the following output: GLEW Error: GLX 1.2 and up are not supported Looking in to how to fix this... I get the following output: GLEW Error: GLX 1.2 and up are not supported Looking in to how to fix this... May 01, 2009 issue 6 (Example fails on GLEW) commented on by castano - You should check the error code of glewInit to understand what's going on. Ideally, the example should do something like: GLenum err = glewInit(); if (GLEW_OK != err) { fprintf(stderr, "GLEW Error: %s\n", glewGetErrorString(err)); return 0; } You should check the error code of glewInit to understand what's going on. Ideally, the example should do something like: GLenum err = glewInit(); if (GLEW_OK != err) { fprintf(stderr, "GLEW Error: %s\n", glewGetErrorString(err)); return 0; } May 01, 2009 issue 6 (Example fails on GLEW) commented on by Dudymas - commenting out lines 163 and 169 within example.cpp resolves the issue and the fellow runs just fine. I think. I'm not sure how it is supposed to run, but it DOES run. Hooray. GLEW is evil. commenting out lines 163 and 169 within example.cpp resolves the issue and the fellow runs just fine. I think. I'm not sure how it is supposed to run, but it DOES run. Hooray. GLEW is evil. May 01, 2009 issue 6 (Example fails on GLEW) commented on by castano - Sounds like a problem with your setup. Can you run other glew applications? Sounds like a problem with your setup. Can you run other glew applications? May 01, 2009 issue 6 (Example fails on GLEW) reported by Dudymas - What steps will reproduce the problem? 1. Downloaded latest SVN on OSX leopard 2. Configure and Make 3. execute 'example' from build/src/nvwidgets/examples/example What is the expected output? What do you see instead? The fellow should pop up a GL window and show stuff happening. The console reports back to me "GLEW initialization failed" What version of the product are you using? On what operating system? Latest SVN. OSX 10.5 leopard. Please provide any additional information below. Is it just me? What steps will reproduce the problem? 1. Downloaded latest SVN on OSX leopard 2. Configure and Make 3. execute 'example' from build/src/nvwidgets/examples/example What is the expected output? What do you see instead? The fellow should pop up a GL window and show stuff happening. The console reports back to me "GLEW initialization failed" What version of the product are you using? On what operating system? Latest SVN. OSX 10.5 leopard. Please provide any additional information below. Is it just me? Apr 23, 2009 issue 1 (IMGUI requires constant redraw) commented on by castano - A simple workaround is not to refresh the screen constantly, but limit it to 60 or 30 Hz. That can be achieved with WaitableTimers. See the comment section of the following article: http://cbloomrants.blogspot.com/2009/03/03-02-09-sleep-sucks-and-vsync-woes.html A simple workaround is not to refresh the screen constantly, but limit it to 60 or 30 Hz. That can be achieved with WaitableTimers. See the comment section of the following article: http://cbloomrants.blogspot.com/2009/03/03-02-09-sleep-sucks-and-vsync-woes.html Jan 23, 2009 issue 4 (unbalanced grouping & panels) commented on by tbptbp - Ok, i wasn't thinking straight. It indeed does the trick. On top of a bit of documentation, a feedback mechanism of some sort (in debug builds) about whether the stack is clear or not on end() would definitely help the end-user to catch such mistakes. Ok, i wasn't thinking straight. It indeed does the trick. On top of a bit of documentation, a feedback mechanism of some sort (in debug builds) about whether the stack is clear or not on end() would definitely help the end-user to catch such mistakes. Jan 23, 2009 issue 4 (unbalanced grouping & panels) commented on by tbptbp - Samuel, that's also what i first thought, but that doesn't cut it. As you can see http://code.google.com/p/nvidia-widgets/source/browse/trunk/src/nvwidgets/nvWidgets.cpp#335 a group starts no matter what's the folding status. Then a frame may also starts. When beginPanel returns there's 1 group + (unfold ? 1 frame) on the stack; endPanel pops 2. Whether you conditionalize endPanel call on the unfold status or not, there's always an unbalanced path. // unfold = false if (beginPanel()) // +1 endPanel(); // // +1 PS: i think a run-time feedback mechanism of some sort, for debug builds, checking if the group stack is clear would definitely help the end-user; it's easy to miss ending a group or something. Samuel, that's also what i first thought, but that doesn't cut it. As you can see http://code.google.com/p/nvidia-widgets/source/browse/trunk/src/nvwidgets/nvWidgets.cpp#335 a group starts no matter what's the folding status. Then a frame may also starts. When beginPanel returns there's 1 group + (unfold ? 1 frame) on the stack; endPanel pops 2. Whether you conditionalize endPanel call on the unfold status or not, there's always an unbalanced path. // unfold = false if (beginPanel()) // +1 endPanel(); // // +1 PS: i think a run-time feedback mechanism of some sort, for debug builds, checking if the group stack is clear would definitely help the end-user; it's easy to miss ending a group or something. Jan 23, 2009 issue 4 (unbalanced grouping & panels) changed by samuel.gateau - Hi Thierry, Thanks for the catch. After looking at the issue closer, I think it's just a problem of documentation for the Panel. This is the way I designed the panel calls: static bool isUnfold = true; if ( ui.beginPanel( Rect, "The panel Name", &isUnfold ) ) { // Do some stuff in the unfold panel // End the panel since it is unfold ui.endPanel(); } // if the Panel is not unfold, there is nothing to do And then it works just fine. I suspect you are doing always the calls beginPanel / endPanel no matter the panel is unfold or not. I agree that there is a naming issue here, a good documentation would be a minimum What's your opinion ? Thanks, Sam Status: Started Owner: samuel.gateau Cc: castano den.kovacs Hi Thierry, Thanks for the catch. After looking at the issue closer, I think it's just a problem of documentation for the Panel. This is the way I designed the panel calls: static bool isUnfold = true; if ( ui.beginPanel( Rect, "The panel Name", &isUnfold ) ) { // Do some stuff in the unfold panel // End the panel since it is unfold ui.endPanel(); } // if the Panel is not unfold, there is nothing to do And then it works just fine. I suspect you are doing always the calls beginPanel / endPanel no matter the panel is unfold or not. I agree that there is a naming issue here, a good documentation would be a minimum What's your opinion ? Thanks, Sam Status: Started Owner: samuel.gateau Cc: castano den.kovacs Jan 19, 2009 issue 5 (LineEdit widget, memory corruption) Status changed by castano - I've applied the patch you provided. This is not fixed in revision 13: http://code.google.com/p/nvidia-widgets/source/detail?r=13 Status: Fixed I've applied the patch you provided. This is not fixed in revision 13: http://code.google.com/p/nvidia-widgets/source/detail?r=13 Status: Fixed Jan 19, 2009 r13 (Fix buffer overrun, patch provided by tbp. Fixes issue 5. ) committed by castano - Fix buffer overrun, patch provided by tbp. Fixes issue 5 . Fix buffer overrun, patch provided by tbp. Fixes issue 5 . Jan 13, 2009 issue 5 (LineEdit widget, memory corruption) Owner changed by castano - Sam, this one is for you. http://code.google.com/p/nvidia-widgets/source/browse/trunk/src/nvwidgets/nvWidgets.cpp#757 http://code.google.com/p/nvidia-widgets/source/browse/trunk/src/nvwidgets/nvWidgets.cpp#768 Owner: samuel.gateau Sam, this one is for you. http://code.google.com/p/nvidia-widgets/source/browse/trunk/src/nvwidgets/nvWidgets.cpp#757 http://code.google.com/p/nvidia-widgets/source/browse/trunk/src/nvwidgets/nvWidgets.cpp#768 Owner: samuel.gateau Jan 13, 2009 issue 5 (LineEdit widget, memory corruption) reported by tbptbp - (excuse my fuzzy memory, i should have reported earlier, and that code is a tad too baroque for what it does) In doLineEdit at line 757 and 768, memmoves are incorrectly guarded and if m_focusCaretPos > textLength bad karma ensues. (excuse my fuzzy memory, i should have reported earlier, and that code is a tad too baroque for what it does) In doLineEdit at line 757 and 768, memmoves are incorrectly guarded and if m_focusCaretPos > textLength bad karma ensues. Jan 13, 2009 issue 4 (unbalanced grouping & panels) reported by tbptbp - Because void UIContext::endPanel() { endFrame(); endGroup(); } assumes both are on stack but UIContext::beginPanel does if (isUnfold && isUnfold) { beginFrame( flags, Rect(0, 0, r.w, r.h) ); return true; } else { endGroup(); return false; } said stack is smashed. My simple solution was to define GroupFlags_InternalSkipFrame = 0x10000, if (isUnfold && isUnfold) { beginFrame(flags, Rect(0, 0, r.w, r.h)); return true; } else { beginFrame(flags \| GroupFlags_InternalSkipFrame, Rect(0, 0, 0, 0)); return false; } then have that flag propagated through UIContext::beginGroup and finally void UIContext::endFrame() { endGroup(); if (!(m_groupStack[m_groupIndex + 1].flags & GroupFlags_InternalSkipFrame)) m_painter->drawFrame( m_groupStack[m_groupIndex + 1].bounds, m_groupStack[m_groupIndex + 1].margin, 0); } so that no residual frame would get drawn when panel is collapsed. Because void UIContext::endPanel() { endFrame(); endGroup(); } assumes both are on stack but UIContext::beginPanel does if (isUnfold && isUnfold) { beginFrame( flags, Rect(0, 0, r.w, r.h) ); return true; } else { endGroup(); return false; } said stack is smashed. My simple solution was to define GroupFlags_InternalSkipFrame = 0x10000, if (isUnfold && isUnfold) { beginFrame(flags, Rect(0, 0, r.w, r.h)); return true; } else { beginFrame(flags \| GroupFlags_InternalSkipFrame, Rect(0, 0, 0, 0)); return false; } then have that flag propagated through UIContext::beginGroup and finally void UIContext::endFrame() { endGroup(); if (!(m_groupStack[m_groupIndex + 1].flags & GroupFlags_InternalSkipFrame)) m_painter->drawFrame( m_groupStack[m_groupIndex + 1].bounds, m_groupStack[m_groupIndex + 1].margin, 0); } so that no residual frame would get drawn when panel is collapsed. Older Aug 25, 2008 r12 (Replace tabs with spaces. Add NVSDKENTRY to classes, remove ...) committed by castano - Replace tabs with spaces. Add NVSDKENTRY to classes, remove from methods. Replace tabs with spaces. Add NVSDKENTRY to classes, remove from methods. Aug 24, 2008 issue 2 (Remove GLEW dependency) Status changed by castano - Status: New Status: New Aug 24, 2008 issue 3 (Do not use GLUT for font rendering) reported by castano - Provide our own font rendering code instead of relying on GLUT. Provide our own font rendering code instead of relying on GLUT. Aug 24, 2008 issue 2 (Remove GLEW dependency) reported by castano - nvWidgets.dll should not depend on GLEW. nvWidgets.dll should not depend on GLEW. Aug 24, 2008 r11 (Create 1.0.0 release. ) committed by castano - Create 1.0.0 release. Create 1.0.0 release. Aug 24, 2008 r10 (Create 1.0 branch. ) committed by castano - Create 1.0 branch. Create 1.0 branch. Aug 24, 2008 r9 (Fix buildpkg script. ) committed by castano - Fix buildpkg script. Fix buildpkg script. Aug 22, 2008 r8 (Fix win32 build under vc8. Remove vc8 warnings. ) committed by castano - Fix win32 build under vc8. Remove vc8 warnings. Fix win32 build under vc8. Remove vc8 warnings. Aug 21, 2008 r7 (Fix compilation errors on OSX. ) committed by castano - Fix compilation errors on OSX. Fix compilation errors on OSX. Aug 21, 2008 issue 1 (IMGUI requires constant redraw) reported by den.kovacs - What steps will reproduce the problem? run the example What is the expected output? What do you see instead? it redraws all the time. This drains laptop battery life. What version of the product are you using? On what operating system? osx. Latest svn version. Please provide any additional information below. Maybe one could implement a version that is only redrawing when the mouse button is pressed. Of course hovering effects are not possible with this, or one would have to work with a timer. What steps will reproduce the problem? run the example What is the expected output? What do you see instead? it redraws all the time. This drains laptop battery life. What version of the product are you using? On what operating system? osx. Latest svn version. Please provide any additional information below. Maybe one could implement a version that is only redrawing when the mouse button is pressed. Of course hovering effects are not possible with this, or one would have to work with a timer. Aug 20, 2008 r6 (Include ogl headers and libs. ) committed by castano - Include ogl headers and libs. Include ogl headers and libs. Aug 20, 2008 r5 (More cleanup. Add simple example. ) committed by castano - More cleanup. Add simple example. More cleanup. Add simple example. Aug 19, 2008 r4 (Fix gcc warnings and errors. ) committed by castano - Fix gcc warnings and errors. Fix gcc warnings and errors. Aug 18, 2008 r3 (Add glew and glut. Fix build errors. ) committed by castano - Add glew and glut. Fix build errors. Add glew and glut. Fix build errors. Aug 18, 2008 r2 (Import first version. Cleanup for public release. ) committed by castano - Import first version. Cleanup for public release. Import first version. Cleanup for public release.

issue 7 (UIContext Class not as open as it could be...) reported by Dudymas - This is an enhancement/feature request. Since this is an open library, I'd like the ability to extend the widgets of the UIContext class in nvwidgets.h without having to necessarily rewrite some of the current private functions. That is, change some of the private functions to be protected: static bool UIContext::overlap(const Rect & rect, const Point & p); bool UIContext::hasFocus(const Rect & rect); bool UIContext::isHover(const Rect & rect); Just so that if a user of the library only wants to add a couple widgets or recombine them... rewriting the mouse calls and duplicating mouse data wouldn't be necessary. You'd have to move some of the mouse data from private to protected as well. Other functions are more intricately laced with the class and understandably should be rewritten in the case that an inherited context is being used... Also, I understand that if I start adding to the classes, I have to be ready for these functions to totally be changed or removed, and possibly it will hurt development if someone wants to change them and a lot of people use an older class interface. Soooooo..... this is just a request. See what you guys think about it. As an example, I want to add tablet support to the library... and then make a couple redo's of the widgets to make them support pressure and tilt changes. Perhaps that gives you an idea of what would be done... and what might need to be added.

This is an enhancement/feature request. Since this is an open library, I'd like the ability to extend the widgets of the UIContext class in nvwidgets.h without having to necessarily rewrite some of the current private functions. That is, change some of the private functions to be protected: static bool UIContext::overlap(const Rect & rect, const Point & p); bool UIContext::hasFocus(const Rect & rect); bool UIContext::isHover(const Rect & rect); Just so that if a user of the library only wants to add a couple widgets or recombine them... rewriting the mouse calls and duplicating mouse data wouldn't be necessary. You'd have to move some of the mouse data from private to protected as well. Other functions are more intricately laced with the class and understandably should be rewritten in the case that an inherited context is being used... Also, I understand that if I start adding to the classes, I have to be ready for these functions to totally be changed or removed, and possibly it will hurt development if someone wants to change them and a lot of people use an older class interface. Soooooo..... this is just a request. See what you guys think about it. As an example, I want to add tablet support to the library... and then make a couple redo's of the widgets to make them support pressure and tilt changes. Perhaps that gives you an idea of what would be done... and what might need to be added.

Earlier this year

Older