Re: [osg-users] osgWidget 0.1.8 (pre-merge)
Hi, Jeremy. I've tried to compile your code on my Gentoo just for now, and I have linker errors while building examples: Linking CXX executable osgwidgetlabel /var/tmp/portage/media-libs/osgwidget-/work/osgwidget-/build/libosgWidget.so: undefined reference to `forkpty' /var/tmp/portage/media-libs/osgwidget-/work/osgwidget-/build/libosgWidget.so: undefined reference to `openpty' libosgWidget.so itself was built properly. It is right for version 0.1.8 and last version from SVN. I haven't installed LUA but have Python (OSGWIDGET_USEPYTHON is TRUE in my CMakeCache.txt). And there are another pair of strings from CMakeCache.txt for information: //Path to a file. PYTHON_INCLUDE_PATH:PATH=/usr/include/python2.4 //Path to a library. PYTHON_LIBRARY:FILEPATH=/usr/lib/python2.4/config/libpython2.4.a Best regards, Valery ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
Hi Jeremy
Window* parent = wl-back()-getParent(); // wl is declared as 'const
WidgetList* wl'
Was this the only line you needed to change? Were there others? :)
If it had only been as easy as modifying 1 line, I would have sent you
a patch rather than complaining :)
I could not get the beast compiling because in so many places the same
programming logic is used. If I remove constness from somewhere, it
propagates upwards from caller to caller until everything becomes non
const ...
I still don't understand how it can work with you guys ... Typical
things that seem wrong to me are:
in src/UIObjectParent:54
object_type* _getByName(const std::string name) const {
for(ConstIterator i = begin(); i != end(); i++) {
if(i-valid() i-get()-getName() == name) return
i-get();
}
return 0;
}
A const method doing a const-iteration on a container cannot return a
non const pointer to an element of that container, can it ?
Somewhere else:
void Window::_setFocused(Widget* widget) {
[...]
}
bool Window::setFocused(const Widget* widget) {
ConstIterator i = std::find(begin(), end(), widget);
_setFocused(i-get());
}
// i-get() returns a const Widget* that cannot be passed as argument
to _setFocused(), can it ?
I'm starting to feel strange, as if I had seen an alien and the FBI in
my garden and the government had told me that nothing had happened.
Nothing. So would have had my neighbours, making me feel alone and not
so sure that I had actually seen anything. :)
Regards
Thibault
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
On Wed, 2008-05-14 at 08:57 +0200, Thibault Genessay wrote:
Hi Jeremy
Window* parent = wl-back()-getParent(); // wl is declared as 'const
WidgetList* wl'
Was this the only line you needed to change? Were there others? :)
If it had only been as easy as modifying 1 line, I would have sent you
a patch rather than complaining :)
I could not get the beast compiling because in so many places the same
programming logic is used. If I remove constness from somewhere, it
propagates upwards from caller to caller until everything becomes non
const ...
I still don't understand how it can work with you guys ... Typical
things that seem wrong to me are:
in src/UIObjectParent:54
object_type* _getByName(const std::string name) const {
for(ConstIterator i = begin(); i != end(); i++) {
if(i-valid() i-get()-getName() == name) return
i-get();
}
return 0;
}
A const method doing a const-iteration on a container cannot return a
non const pointer to an element of that container, can it ?
The prototype for ref_ptr::get looks like this:
T* get() const { return _ptr; }
It's a const method that returns a non-const pointer. I've done a bit of
research, and this does appear to be something some compilers catch and
some don't, so I'm not sure how OSG builds for any of us if we really
adhering to some strict checking.
In the above example, I imagine it works because while ref_ptr::get()
returns a non-const pointer, the ConstIterator never calls a non-const
method of the ref_ptr class.
Perhaps a real C++ guru can shed some light here...
Somewhere else:
void Window::_setFocused(Widget* widget) {
[...]
}
bool Window::setFocused(const Widget* widget) {
ConstIterator i = std::find(begin(), end(), widget);
_setFocused(i-get());
}
// i-get() returns a const Widget* that cannot be passed as argument
to _setFocused(), can it ?
I'm starting to feel strange, as if I had seen an alien and the FBI in
my garden and the government had told me that nothing had happened.
Nothing. So would have had my neighbours, making me feel alone and not
so sure that I had actually seen anything. :)
I am as well. :)
I'm going to install Fedora 9 (which will give me GCC4.2), and I'm going
to google for some additional strict-checking options for GCC. Perhaps I
can find a way to reproduce this and get it squashed...
I've got VC++9 installed on my Windows partition, I've just never been
able to get OSG to build at all there. However, there have been lots of
threads recently on the subject, so perhaps now is the time to spend an
afternoon doing it...
At any rate, thanks for the info!
Regards
Thibault
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
Jeremy,
Just to keep you informed: the code compiles well for the 0.1.7 tag on
both machines, but fails for both on the trunk.
The prototype for ref_ptr::get looks like this:
T* get() const { return _ptr; }
After reviewing the 0.1.7 code, this makes perfect sense. It is legal
to get a non const reference from a const list of ref_ptrs.
But the trunk uses observer_ptr instead. And this observer_ptr
does *not* define the const method returning a non const pointer.
I really don't know why it is this way - I had actually never noticed
that ref_ptr had this feature. It makes more sense to me how the
observer_ptr is implemented because ref_ptr and observer_ptr are
just proxies that should IMHO behave like ordinary references or
pointers when we call operator*() or operator-(). (I'm sure a C++
guru could slap me for what I've said, but I'd enjoy it if it came
with an explanation :)
It's a const method that returns a non-const pointer. I've done a bit of
research, and this does appear to be something some compilers catch and
some don't, so I'm not sure how OSG builds for any of us if we really
adhering to some strict checking.
OSG does compile well with VS 9.0 and my (weird?) GCC 4.1.2 ...
To be continued I guess.
Thibault
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
Hi Thibault,
On Wed, May 14, 2008 at 4:02 PM, Thibault Genessay [EMAIL PROTECTED] wrote:
I really don't know why it is this way - I had actually never noticed
that ref_ptr had this feature. It makes more sense to me how the
observer_ptr is implemented because ref_ptr and observer_ptr are
just proxies that should IMHO behave like ordinary references or
pointers when we call operator*() or operator-(). (I'm sure a C++
guru could slap me for what I've said, but I'd enjoy it if it came
with an explanation :)
Which version of the OSG are you using? In 2.4 the observer_ptr is
consistent with
ref_ptr i.e.
inline T operator*() const { return *_ptr; }
inline T* operator-() const { return _ptr; }
inline T* get() const { return _ptr; }
The next question is this wacky world is why does ref_ptr and
observer_ptr do this trick?
Try:
typedef std::set osg::ref_ptrNode MySet;
Then try to access members of it, and you'll find out they are in fact
now a const ref_ptr and you
can't access any non const methods of Node. What the const method
here is const of the ref_ptr
not const of what its pointing to. If you meant this then you'd have
osg::ref_ptrconst Node.
However, it all can get a bit sticky, as sometimes you intend const
osg::ref_ptrNode to be const osg::ref_ptrconst Node in which case
the relaxation of the the above accessors misses this.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
Hi Robert, Jeremy
Okay I have spotted the alien and the FBI. I was using 2.3.4 and
updated to 2.4 - how I could forget that the version of the OSG I was
using was something to investigate is beyond me.
The observer_ptr is now defined correctly and all my errors
automagically went away.
I am sorry for the noise.
Thank you Robert for the little lesson :)
Regards
Thibault
On Wed, May 14, 2008 at 5:19 PM, Robert Osfield
[EMAIL PROTECTED] wrote:
Hi Thibault,
On Wed, May 14, 2008 at 4:02 PM, Thibault Genessay [EMAIL PROTECTED] wrote:
I really don't know why it is this way - I had actually never noticed
that ref_ptr had this feature. It makes more sense to me how the
observer_ptr is implemented because ref_ptr and observer_ptr are
just proxies that should IMHO behave like ordinary references or
pointers when we call operator*() or operator-(). (I'm sure a C++
guru could slap me for what I've said, but I'd enjoy it if it came
with an explanation :)
Which version of the OSG are you using? In 2.4 the observer_ptr is
consistent with
ref_ptr i.e.
inline T operator*() const { return *_ptr; }
inline T* operator-() const { return _ptr; }
inline T* get() const { return _ptr; }
The next question is this wacky world is why does ref_ptr and
observer_ptr do this trick?
Try:
typedef std::set osg::ref_ptrNode MySet;
Then try to access members of it, and you'll find out they are in fact
now a const ref_ptr and you
can't access any non const methods of Node. What the const method
here is const of the ref_ptr
not const of what its pointing to. If you meant this then you'd have
osg::ref_ptrconst Node.
However, it all can get a bit sticky, as sometimes you intend const
osg::ref_ptrNode to be const osg::ref_ptrconst Node in which case
the relaxation of the the above accessors misses this.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
Thanks Jeremy for your work! Trying osgwidgetinput I receive the following warnings on Linux with latest SVN. At least one of them could be stopped if you could provide the missing font Calibri1.ttf . Is it possible? Ciao! mario isone /local/OSG/osgwidget-read-only/examples/osgwidgetinput ./osgwidgetinput Warning: font file fonts/Calibri1.ttf not found. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Widget [Label_Row0] was asked to set it's width to 50, but the minimum width is 80. Warning: font file fonts/Calibri1.ttf not found. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Widget [Label_Row1] was asked to set it's width to 50, but the minimum width is 80. Warning: font file fonts/Calibri1.ttf not found. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Widget [Label_Row2] was asked to set it's width to 50, but the minimum width is 80. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Widget [Widget_1] was asked to set it's height to 18, but the minimum height is 44. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: Input is disabled until someone can help me understand how to use osgText; sorry... osgWidget: Input is disabled until someone can help me understand how to use osgText; sorry... osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: MousePush @ Window: table osgWidget: MousePush @ Window: table osgWidget: MousePush @ Window: table osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: x: y: z: osgWidget: Window [frame] couldn't find the Widget [Widget_2] in it's object list. osgWidget: x: y: z: osgWidget: Window [frame] couldn't find the Widget [Widget_2] in it's object list. Jeremy Moles wrote: I've put the (hopefully!) final version of a separate osgWidget up on the googlecode site: http://osgwidget.googlecode.com This means that I feel like I'm getting closer to the point where it would make sense to submit osgWidget to Robert to see how he feels about inclusion into the main trunk, with ongoing development there instead. This will expose far more eyeballs to osgWidget's codebase, which can only be good as development continues. The next version (I'll call 0.2.0 for now) will be the one I submit, and I'm going to construct a serious TODO list of items on the website project page of things I want to accomplish prior to this. I can't say how long this will take, but hopefully no longer than about two weeks or so... This also means I'll probably make a few posts within the next two weeks asking questions regarding some outstanding issues, soliciting design opinions, etc. I only even mention this so that folks don't think I'm spamming the lists. :) Keep in mind that even if Robert is feeling brave enough to allow this code to sneak in, it won't nearly be feature complete. The goal, however, isn't to provide a final version but to expose more people and hopefully expose more bugs/flaws. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ing. Mario Valle Data Analysis and Visualization Services | http://www.cscs.ch/~mvalle Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60 v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
On Tue, 2008-05-13 at 17:26 +0200, Mario Valle wrote: Thanks Jeremy for your work! Trying osgwidgetinput I receive the following warnings on Linux with latest SVN. At least one of them could be stopped if you could provide the missing font Calibri1.ttf . Is it possible? Ciao! mario This is a Microsoft font. :( Perhaps I should consolidate all of these examples to use a Linux front that I CAN distribute or perhaps just the arial font included in the OpenSceneGraph-Data project. At any rate, my rampant and unpredictable use of fonts is just a way for me to try and mix things up; please feel free to change that font/arial.ttf... Obviously, issues such as these can't exist when I do the submission, so it's good to bring up! I'll add it on the TODO on the website... isone /local/OSG/osgwidget-read-only/examples/osgwidgetinput ./osgwidgetinput Warning: font file fonts/Calibri1.ttf not found. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Widget [Label_Row0] was asked to set it's width to 50, but the minimum width is 80. Warning: font file fonts/Calibri1.ttf not found. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Widget [Label_Row1] was asked to set it's width to 50, but the minimum width is 80. Warning: font file fonts/Calibri1.ttf not found. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Widget [Label_Row2] was asked to set it's width to 50, but the minimum width is 80. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Widget [Widget_1] was asked to set it's height to 18, but the minimum height is 44. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: Input is disabled until someone can help me understand how to use osgText; sorry... osgWidget: Input is disabled until someone can help me understand how to use osgText; sorry... osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: MousePush @ Window: table osgWidget: MousePush @ Window: table osgWidget: MousePush @ Window: table osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: x: y: z: osgWidget: Window [frame] couldn't find the Widget [Widget_2] in it's object list. osgWidget: x: y: z: osgWidget: Window [frame] couldn't find the Widget [Widget_2] in it's object list. Jeremy Moles wrote: I've put the (hopefully!) final version of a separate osgWidget up on the googlecode site: http://osgwidget.googlecode.com This means that I feel like I'm getting closer to the point where it would make sense to submit osgWidget to Robert to see how he feels about inclusion into the main trunk, with ongoing development there instead. This will expose far more eyeballs to osgWidget's codebase, which can only be good as development continues. The next version (I'll call 0.2.0 for now) will be the one I submit, and I'm going to construct a serious TODO list of items on the website project page of things I want to accomplish prior to this. I can't say how long this will take, but hopefully no longer than about two weeks or so... This also means I'll probably make a few posts within the next two weeks asking questions regarding some outstanding issues, soliciting design opinions, etc. I only even mention this so that folks don't think I'm spamming the lists. :) Keep in mind that even if Robert is feeling brave enough to allow this code to sneak in, it won't nearly be feature complete. The goal, however, isn't to provide a final version but to expose more people and hopefully expose more bugs/flaws. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
Hi Jeremy I've just tried to compile your code using Visual Studio 9.0 and got lots of errors that are almost all related to 'const' usage. I am sometime suspicious about Redmond compilers so I also tried to compile the code on Debian 4.0, and the errors are (hopefully) similar. Here is the output from the Linux build: [EMAIL PROTECTED]:~/prog/osgWidget-0.1.8$ make Scanning dependencies of target osgWidget [ 2%] Building CXX object CMakeFiles/osgWidget.dir/src/Box.o [ 5%] Building CXX object CMakeFiles/osgWidget.dir/src/Canvas.o [ 8%] Building CXX object CMakeFiles/osgWidget.dir/src/Frame.o /home/tibo/prog/osgWidget-0.1.8/include/osgWidget/UIObjectParent: In member function 'T* osgWidget::UIObjectParentT::_getByName(const std::string) const [with T = osgWidget::Widget]': /home/tibo/prog/osgWidget-0.1.8/include/osgWidget/UIObjectParent:76: instantiated from 'const T* osgWidget::UIObjectParentT::getByName(const std::string) const [with T = osgWidget::Widget]' /home/tibo/prog/osgWidget-0.1.8/src/Frame.cpp:109: instantiated from here /home/tibo/prog/osgWidget-0.1.8/include/osgWidget/UIObjectParent:56: error: invalid conversion from 'const osgWidget::Widget*' to 'osgWidget::Widget*' make[2]: *** [CMakeFiles/osgWidget.dir/src/Frame.o] Error 1 make[1]: *** [CMakeFiles/osgWidget.dir/all] Error 2 make: *** [all] Error 2 And Windows build: 3-- Build started: Project: osgWidget, Configuration: Debug Win32 -- 3Compiling... 3WindowManager.cpp 3.\src\WindowManager.cpp(191) : error C2440: 'initializing' : cannot convert from 'const osgWidget::Window *' to 'osgWidget::Window *' 3Conversion loses qualifiers 3.\src\WindowManager.cpp(203) : error C2440: 'initializing' : cannot convert from 'const osgWidget::Widget *' to 'osgWidget::Widget *' 3Conversion loses qualifiers 3.\src\WindowManager.cpp(333) : error C2440: 'initializing' : cannot convert from 'const osgWidget::Window *' to 'osgWidget::Window *' 3Conversion loses qualifiers [...] Thibault On Tue, May 13, 2008 at 5:03 PM, Jeremy Moles [EMAIL PROTECTED] wrote: I've put the (hopefully!) final version of a separate osgWidget up on the googlecode site: http://osgwidget.googlecode.com This means that I feel like I'm getting closer to the point where it would make sense to submit osgWidget to Robert to see how he feels about inclusion into the main trunk, with ongoing development there instead. This will expose far more eyeballs to osgWidget's codebase, which can only be good as development continues. The next version (I'll call 0.2.0 for now) will be the one I submit, and I'm going to construct a serious TODO list of items on the website project page of things I want to accomplish prior to this. I can't say how long this will take, but hopefully no longer than about two weeks or so... This also means I'll probably make a few posts within the next two weeks asking questions regarding some outstanding issues, soliciting design opinions, etc. I only even mention this so that folks don't think I'm spamming the lists. :) Keep in mind that even if Robert is feeling brave enough to allow this code to sneak in, it won't nearly be feature complete. The goal, however, isn't to provide a final version but to expose more people and hopefully expose more bugs/flaws. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
On Tue, 2008-05-13 at 17:49 +0200, Thibault Genessay wrote: Hi Jeremy I've just tried to compile your code using Visual Studio 9.0 and got lots of errors that are almost all related to 'const' usage. I am sometime suspicious about Redmond compilers so I also tried to compile the code on Debian 4.0, and the errors are (hopefully) similar. Here is the output from the Linux build: [EMAIL PROTECTED]:~/prog/osgWidget-0.1.8$ make Scanning dependencies of target osgWidget [ 2%] Building CXX object CMakeFiles/osgWidget.dir/src/Box.o [ 5%] Building CXX object CMakeFiles/osgWidget.dir/src/Canvas.o [ 8%] Building CXX object CMakeFiles/osgWidget.dir/src/Frame.o /home/tibo/prog/osgWidget-0.1.8/include/osgWidget/UIObjectParent: In member function 'T* osgWidget::UIObjectParentT::_getByName(const std::string) const [with T = osgWidget::Widget]': /home/tibo/prog/osgWidget-0.1.8/include/osgWidget/UIObjectParent:76: instantiated from 'const T* osgWidget::UIObjectParentT::getByName(const std::string) const [with T = osgWidget::Widget]' /home/tibo/prog/osgWidget-0.1.8/src/Frame.cpp:109: instantiated from here /home/tibo/prog/osgWidget-0.1.8/include/osgWidget/UIObjectParent:56: error: invalid conversion from 'const osgWidget::Widget*' to 'osgWidget::Widget*' make[2]: *** [CMakeFiles/osgWidget.dir/src/Frame.o] Error 1 make[1]: *** [CMakeFiles/osgWidget.dir/all] Error 2 make: *** [all] Error 2 I'd be real interested to know what version of GCC is complaining about this. I don't see this error on Fedora 8/GCC4.1, and I've never had an e-mail about it or antyhing. The code, as far as I can tell, is perfectly valid C++. Perhaps I can come up with a workaround for this, as I really do believe it's valid C++... And Windows build: 3-- Build started: Project: osgWidget, Configuration: Debug Win32 -- 3Compiling... 3WindowManager.cpp 3.\src\WindowManager.cpp(191) : error C2440: 'initializing' : cannot convert from 'const osgWidget::Window *' to 'osgWidget::Window *' 3Conversion loses qualifiers 3.\src\WindowManager.cpp(203) : error C2440: 'initializing' : cannot convert from 'const osgWidget::Widget *' to 'osgWidget::Widget *' 3Conversion loses qualifiers 3.\src\WindowManager.cpp(333) : error C2440: 'initializing' : cannot convert from 'const osgWidget::Window *' to 'osgWidget::Window *' 3Conversion loses qualifiers [...] This is the exact same problem as above. I can definitely come up with a workaround, but if possible I'd like to see your version of GCC first if possible. :) Thibault On Tue, May 13, 2008 at 5:03 PM, Jeremy Moles [EMAIL PROTECTED] wrote: I've put the (hopefully!) final version of a separate osgWidget up on the googlecode site: http://osgwidget.googlecode.com This means that I feel like I'm getting closer to the point where it would make sense to submit osgWidget to Robert to see how he feels about inclusion into the main trunk, with ongoing development there instead. This will expose far more eyeballs to osgWidget's codebase, which can only be good as development continues. The next version (I'll call 0.2.0 for now) will be the one I submit, and I'm going to construct a serious TODO list of items on the website project page of things I want to accomplish prior to this. I can't say how long this will take, but hopefully no longer than about two weeks or so... This also means I'll probably make a few posts within the next two weeks asking questions regarding some outstanding issues, soliciting design opinions, etc. I only even mention this so that folks don't think I'm spamming the lists. :) Keep in mind that even if Robert is feeling brave enough to allow this code to sneak in, it won't nearly be feature complete. The goal, however, isn't to provide a final version but to expose more people and hopefully expose more bugs/flaws. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
Hi Jeremy On Tue, May 13, 2008 at 6:16 PM, Jeremy Moles [EMAIL PROTECTED] wrote: On Tue, 2008-05-13 at 17:49 +0200, Thibault Genessay wrote: Hi Jeremy I've just tried to compile your code using Visual Studio 9.0 and got lots of errors that are almost all related to 'const' usage. I am sometime suspicious about Redmond compilers so I also tried to compile the code on Debian 4.0, and the errors are (hopefully) similar. Here is the output from the Linux build: [EMAIL PROTECTED]:~/prog/osgWidget-0.1.8$ make Scanning dependencies of target osgWidget [ 2%] Building CXX object CMakeFiles/osgWidget.dir/src/Box.o [ 5%] Building CXX object CMakeFiles/osgWidget.dir/src/Canvas.o [ 8%] Building CXX object CMakeFiles/osgWidget.dir/src/Frame.o /home/tibo/prog/osgWidget-0.1.8/include/osgWidget/UIObjectParent: In member function 'T* osgWidget::UIObjectParentT::_getByName(const std::string) const [with T = osgWidget::Widget]': /home/tibo/prog/osgWidget-0.1.8/include/osgWidget/UIObjectParent:76: instantiated from 'const T* osgWidget::UIObjectParentT::getByName(const std::string) const [with T = osgWidget::Widget]' /home/tibo/prog/osgWidget-0.1.8/src/Frame.cpp:109: instantiated from here /home/tibo/prog/osgWidget-0.1.8/include/osgWidget/UIObjectParent:56: error: invalid conversion from 'const osgWidget::Widget*' to 'osgWidget::Widget*' make[2]: *** [CMakeFiles/osgWidget.dir/src/Frame.o] Error 1 make[1]: *** [CMakeFiles/osgWidget.dir/all] Error 2 make: *** [all] Error 2 I'd be real interested to know what version of GCC is complaining about this. I don't see this error on Fedora 8/GCC4.1, and I've never had an e-mail about it or antyhing. The code, as far as I can tell, is perfectly valid C++. Perhaps I can come up with a workaround for this, as I really do believe it's valid C++... And Windows build: 3-- Build started: Project: osgWidget, Configuration: Debug Win32 -- 3Compiling... 3WindowManager.cpp 3.\src\WindowManager.cpp(191) : error C2440: 'initializing' : cannot convert from 'const osgWidget::Window *' to 'osgWidget::Window *' 3Conversion loses qualifiers 3.\src\WindowManager.cpp(203) : error C2440: 'initializing' : cannot convert from 'const osgWidget::Widget *' to 'osgWidget::Widget *' 3Conversion loses qualifiers 3.\src\WindowManager.cpp(333) : error C2440: 'initializing' : cannot convert from 'const osgWidget::Window *' to 'osgWidget::Window *' 3Conversion loses qualifiers [...] This is the exact same problem as above. I can definitely come up with a workaround, but if possible I'd like to see your version of GCC first if possible. :) Strange ... I have 4.1 as well: [EMAIL PROTECTED]:~$ g++ --version g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) However, on the C++ side, I feel that there is a problem somewhere. At line 191 of WindowManager.cpp, you write Window* parent = wl-back()-getParent(); // wl is declared as 'const WidgetList* wl' Which does not seem valid to me. wl is a const list that holds const pointers, which can't be casted to non-const Window*. I have tried to replace line 191 by const Window* parent = ... under Visual C++ and the error for that line went away. As far as I have looked in the sources to find the errors, both compilers seemed to be right. The fact that two completely different environments (XP SP2 + VC 9 + CMake 2.5, Debian 4 + GCC 4.1.2 + CMake 2.6) give the same errors do not look like a coincidence. But ... I'm really puzzled by this because I had successfully compiled osgWidgets-0.17 previously and I doubt all of these errors were introduced in the meantime. Regards Thibault Thibault On Tue, May 13, 2008 at 5:03 PM, Jeremy Moles [EMAIL PROTECTED] wrote: I've put the (hopefully!) final version of a separate osgWidget up on the googlecode site: http://osgwidget.googlecode.com This means that I feel like I'm getting closer to the point where it would make sense to submit osgWidget to Robert to see how he feels about inclusion into the main trunk, with ongoing development there instead. This will expose far more eyeballs to osgWidget's codebase, which can only be good as development continues. The next version (I'll call 0.2.0 for now) will be the one I submit, and I'm going to construct a serious TODO list of items on the website project page of things I want to accomplish prior to this. I can't say how long this will take, but hopefully no longer than about two weeks or so... This also means I'll probably make a few posts within the next two weeks asking questions regarding some outstanding issues, soliciting design opinions, etc. I only even mention this so that folks don't think I'm spamming the lists. :) Keep in mind that even if Robert is feeling
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
hi, fwiw, there are at least two high-quality fonts intended as freely-distributable replacements for common MS burdened fonts. Give them a shot, see how they work for you: http://en.wikipedia.org/wiki/Liberation_fonts http://en.wikipedia.org/wiki/Bitstream_Vera seems these might be a great addition to the OSG data collection (if not, I prob put them in the osgToy data collection) -- mew On Tue, May 13, 2008 at 10:28 AM, Jeremy Moles [EMAIL PROTECTED] wrote: On Tue, 2008-05-13 at 17:26 +0200, Mario Valle wrote: Thanks Jeremy for your work! Trying osgwidgetinput I receive the following warnings on Linux with latest SVN. At least one of them could be stopped if you could provide the missing font Calibri1.ttf . Is it possible? Ciao! mario This is a Microsoft font. :( Perhaps I should consolidate all of these examples to use a Linux front that I CAN distribute or perhaps just the arial font included in the OpenSceneGraph-Data project. At any rate, my rampant and unpredictable use of fonts is just a way for me to try and mix things up; please feel free to change that font/arial.ttf... Obviously, issues such as these can't exist when I do the submission, so it's good to bring up! I'll add it on the TODO on the website... isone /local/OSG/osgwidget-read-only/examples/osgwidgetinput ./osgwidgetinput Warning: font file fonts/Calibri1.ttf not found. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Widget [Label_Row0] was asked to set it's width to 50, but the minimum width is 80. Warning: font file fonts/Calibri1.ttf not found. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Widget [Label_Row1] was asked to set it's width to 50, but the minimum width is 80. Warning: font file fonts/Calibri1.ttf not found. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Widget [Label_Row2] was asked to set it's width to 50, but the minimum width is 80. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Widget [Widget_1] was asked to set it's height to 18, but the minimum height is 44. Warning: font file fonts/Calibri1.ttf not found. osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: Input is disabled until someone can help me understand how to use osgText; sorry... osgWidget: Input is disabled until someone can help me understand how to use osgText; sorry... osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: MousePush @ Window: table osgWidget: MousePush @ Window: table osgWidget: MousePush @ Window: table osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: Window [frame] couldn't find the Widget [Input_Row0] in it's object list. osgWidget: x: y: z: osgWidget: Window [frame] couldn't find the Widget [Widget_2] in it's object list. osgWidget: x: y: z: osgWidget: Window [frame] couldn't find the Widget [Widget_2] in it's object list. Jeremy Moles wrote: I've put the (hopefully!) final version of a separate osgWidget up on the googlecode site: http://osgwidget.googlecode.com This means that I feel like I'm getting closer to the point where it would make sense to submit osgWidget to Robert to see how he feels about inclusion into the main trunk, with ongoing development there instead. This will expose far more eyeballs to osgWidget's codebase, which can only be good as development continues. The next version (I'll call 0.2.0 for now) will be the one I submit, and I'm going to construct a serious TODO list of items on the website project page of things I want to accomplish prior to this. I can't say how long this will take, but hopefully no longer than about two weeks or so... This also means I'll probably make a few posts within the next two weeks asking questions regarding some outstanding issues, soliciting design opinions, etc. I only even mention this so that folks don't think I'm spamming the lists. :) Keep in mind that even if Robert is feeling brave enough to allow this code to sneak in, it won't nearly be feature complete. The goal, however, isn't to provide a final version but to expose more people and hopefully expose more bugs/flaws. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Mike Weiblen -- Austin Texas USA --
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
Hello Jeremy, I'd be real interested to know what version of GCC is complaining about this. I don't see this error on Fedora 8/GCC4.1, and I've never had an e-mail about it or antyhing. The code, as far as I can tell, is perfectly valid C++. Perhaps I can come up with a workaround for this, as I really do believe it's valid C++... I just updated and compiled on Visual Studio 2005 (8.0), zero errors and zero warnings. Just another data point... Perhaps you already added your workarounds, or perhaps VC8 is less finicky than VC9? J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
Hi Jeremy, I wanted to try out your lib, but I have problems regarding to the cmake build system. First problem is, if you have osg installed not under standard directory. I have then manually to specify the cmake_include and cmake_lib paths. maybe you could take a look into CMake build system of osgPPU, which I have tried to improve for simpler use. Examples do compiles, however I have seg faults and cannot run them. The gdb says it is somewhere on the osg side (osg::Node::setNodeMask). However since osg works fine, I assume that there are somewhere zero pointers in use.;( I am now compiling osg in debug mode, to find out what happens. Maybe I let you know later, what is the status. Best regards, Art P.S. Change the line with ccmake .. in README to cmake .., because this is actually what one has to call ;) --- Jeremy Moles [EMAIL PROTECTED] schrieb: I've put the (hopefully!) final version of a separate osgWidget up on the googlecode site: http://osgwidget.googlecode.com This means that I feel like I'm getting closer to the point where it would make sense to submit osgWidget to Robert to see how he feels about inclusion into the main trunk, with ongoing development there instead. This will expose far more eyeballs to osgWidget's codebase, which can only be good as development continues. The next version (I'll call 0.2.0 for now) will be the one I submit, and I'm going to construct a serious TODO list of items on the website project page of things I want to accomplish prior to this. I can't say how long this will take, but hopefully no longer than about two weeks or so... This also means I'll probably make a few posts within the next two weeks asking questions regarding some outstanding issues, soliciting design opinions, etc. I only even mention this so that folks don't think I'm spamming the lists. :) Keep in mind that even if Robert is feeling brave enough to allow this code to sneak in, it won't nearly be feature complete. The goal, however, isn't to provide a final version but to expose more people and hopefully expose more bugs/flaws. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
On Tue, 2008-05-13 at 20:28 +0200, Art Tevs wrote: Hi Jeremy, I wanted to try out your lib, but I have problems regarding to the cmake build system. First problem is, if you have osg installed not under standard directory. I have then manually to specify the cmake_include and cmake_lib paths. Yeah, this is why I recommend ccmake, because I always do this myself. Since I had intentions of this going into OSG all things going according to plan, I never really went too in-depth with making that process easier. :( maybe you could take a look into CMake build system of osgPPU, which I have tried to improve for simpler use. Examples do compiles, however I have seg faults and cannot run them. The gdb says it is somewhere on the osg side (osg::Node::setNodeMask). However since osg works fine, I assume that there are somewhere zero pointers in use.;( I am now compiling osg in debug mode, to find out what happens. Maybe I let you know later, what is the status. Yes, please! :) Even a hint might be enough... Best regards, Art P.S. Change the line with ccmake .. in README to cmake .., because this is actually what one has to call ;) --- Jeremy Moles [EMAIL PROTECTED] schrieb: I've put the (hopefully!) final version of a separate osgWidget up on the googlecode site: http://osgwidget.googlecode.com This means that I feel like I'm getting closer to the point where it would make sense to submit osgWidget to Robert to see how he feels about inclusion into the main trunk, with ongoing development there instead. This will expose far more eyeballs to osgWidget's codebase, which can only be good as development continues. The next version (I'll call 0.2.0 for now) will be the one I submit, and I'm going to construct a serious TODO list of items on the website project page of things I want to accomplish prior to this. I can't say how long this will take, but hopefully no longer than about two weeks or so... This also means I'll probably make a few posts within the next two weeks asking questions regarding some outstanding issues, soliciting design opinions, etc. I only even mention this so that folks don't think I'm spamming the lists. :) Keep in mind that even if Robert is feeling brave enough to allow this code to sneak in, it won't nearly be feature complete. The goal, however, isn't to provide a final version but to expose more people and hopefully expose more bugs/flaws. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget 0.1.8 (pre-merge)
On Tue, 2008-05-13 at 18:44 +0200, Thibault Genessay wrote: Hi Jeremy On Tue, May 13, 2008 at 6:16 PM, Jeremy Moles [EMAIL PROTECTED] wrote: On Tue, 2008-05-13 at 17:49 +0200, Thibault Genessay wrote: Hi Jeremy I've just tried to compile your code using Visual Studio 9.0 and got lots of errors that are almost all related to 'const' usage. I am sometime suspicious about Redmond compilers so I also tried to compile the code on Debian 4.0, and the errors are (hopefully) similar. Here is the output from the Linux build: [EMAIL PROTECTED]:~/prog/osgWidget-0.1.8$ make Scanning dependencies of target osgWidget [ 2%] Building CXX object CMakeFiles/osgWidget.dir/src/Box.o [ 5%] Building CXX object CMakeFiles/osgWidget.dir/src/Canvas.o [ 8%] Building CXX object CMakeFiles/osgWidget.dir/src/Frame.o /home/tibo/prog/osgWidget-0.1.8/include/osgWidget/UIObjectParent: In member function 'T* osgWidget::UIObjectParentT::_getByName(const std::string) const [with T = osgWidget::Widget]': /home/tibo/prog/osgWidget-0.1.8/include/osgWidget/UIObjectParent:76: instantiated from 'const T* osgWidget::UIObjectParentT::getByName(const std::string) const [with T = osgWidget::Widget]' /home/tibo/prog/osgWidget-0.1.8/src/Frame.cpp:109: instantiated from here /home/tibo/prog/osgWidget-0.1.8/include/osgWidget/UIObjectParent:56: error: invalid conversion from 'const osgWidget::Widget*' to 'osgWidget::Widget*' make[2]: *** [CMakeFiles/osgWidget.dir/src/Frame.o] Error 1 make[1]: *** [CMakeFiles/osgWidget.dir/all] Error 2 make: *** [all] Error 2 I'd be real interested to know what version of GCC is complaining about this. I don't see this error on Fedora 8/GCC4.1, and I've never had an e-mail about it or antyhing. The code, as far as I can tell, is perfectly valid C++. Perhaps I can come up with a workaround for this, as I really do believe it's valid C++... And Windows build: 3-- Build started: Project: osgWidget, Configuration: Debug Win32 -- 3Compiling... 3WindowManager.cpp 3.\src\WindowManager.cpp(191) : error C2440: 'initializing' : cannot convert from 'const osgWidget::Window *' to 'osgWidget::Window *' 3Conversion loses qualifiers 3.\src\WindowManager.cpp(203) : error C2440: 'initializing' : cannot convert from 'const osgWidget::Widget *' to 'osgWidget::Widget *' 3Conversion loses qualifiers 3.\src\WindowManager.cpp(333) : error C2440: 'initializing' : cannot convert from 'const osgWidget::Window *' to 'osgWidget::Window *' 3Conversion loses qualifiers [...] This is the exact same problem as above. I can definitely come up with a workaround, but if possible I'd like to see your version of GCC first if possible. :) Strange ... I have 4.1 as well: [EMAIL PROTECTED]:~$ g++ --version g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) However, on the C++ side, I feel that there is a problem somewhere. At line 191 of WindowManager.cpp, you write Window* parent = wl-back()-getParent(); // wl is declared as 'const WidgetList* wl' Was this the only line you needed to change? Were there others? :) Which does not seem valid to me. wl is a const list that holds const pointers, which can't be casted to non-const Window*. I have tried to replace line 191 by const Window* parent = ... under Visual C++ and the error for that line went away. As far as I have looked in the sources to find the errors, both compilers seemed to be right. The fact that two completely different environments (XP SP2 + VC 9 + CMake 2.5, Debian 4 + GCC 4.1.2 + CMake 2.6) give the same errors do not look like a coincidence. But ... I'm really puzzled by this because I had successfully compiled osgWidgets-0.17 previously and I doubt all of these errors were introduced in the meantime. Regards Thibault Thibault On Tue, May 13, 2008 at 5:03 PM, Jeremy Moles [EMAIL PROTECTED] wrote: I've put the (hopefully!) final version of a separate osgWidget up on the googlecode site: http://osgwidget.googlecode.com This means that I feel like I'm getting closer to the point where it would make sense to submit osgWidget to Robert to see how he feels about inclusion into the main trunk, with ongoing development there instead. This will expose far more eyeballs to osgWidget's codebase, which can only be good as development continues. The next version (I'll call 0.2.0 for now) will be the one I submit, and I'm going to construct a serious TODO list of items on the website project page of things I want to accomplish prior to this. I can't say how long this will take, but hopefully no longer than about two weeks or so... This also means I'll probably make a few posts
