(0027479)
Marcus D. Hanwell (developer)
2011-09-15 13:12

How does it break even the simplest VTK project - very few should be including vtkXOpenGLRenderWindow.h directly, we take care of returning that class and most code should not be including system specific derived classes like that. I could take a look at modifying the use file to bring these things in the default case.

I would like a little more detail on what exactly is breaking as a consequence of this change.

(0027486)
Pietro Cerutti (reporter)
2011-09-16 05:26

I don't completely see why one should not be including system derived classes like vtkXOpenGLRenderWindow.

Anyway, I think that all vtk include files should be compilable by just using the VTK_USE_FILE.

Either that, or hide away all X11 specific things in the .cxx implementation..

What do you think about it?

(0027487)
Marcus D. Hanwell (developer)
2011-09-16 10:08

Back to my original question - what simple VTK projects does this change break?

The VTK object factories will make sure you get the correct derived form or a class, so it is a rare thing to include the header you refer to. I am very interested in what simple VTK projects are impacted by this change.

(0027488)
Pietro Cerutti (reporter)
2011-09-16 10:19

Any simple project that explicitly includes vtkXOpenGLRenderWindow.

If it is intended that client code does not use those objects directly, then the flaw is probably to install unusable include files.

(0027489)
Marcus D. Hanwell (developer)
2011-09-16 10:27

That would not be a simple project, the project should be using the vtkRenderWindow class, and will get the correct one returned based upon the OS. Including that class directly means that you will have to do that on Unix, Cocoa/Carbon on Mac, Win32 on Windows. The headers need to be there, for the occasions where you must do something platform specific but in any normal VTK program you would never include that header.

(0027490)
Pietro Cerutti (reporter)
2011-09-16 10:36

I see your point, and I don't necessarily disagree. However, I still think that it is inconvenient that - even if I am working on a slightly more complex project - I have to INCLUDE_DIRECTORIES myself to bring in X11 headers when I'm already including vtkXOpenGLRenderWindow.

(0031271)
Dave DeMarle (administrator)
2013-07-22 20:03

moving all "tabled" bugs into "backlog" category since "tabled" is no longer used.

(0033439)
Marcus D. Hanwell (developer)
2014-10-02 10:32

We might consider adding a new config variable with system headers, but I think the standard includes work well as they are. Most standard programs should avoid including the X specific classes - the object factory takes care of that for them.

Issue History
Date Modified	Username	Field	Change
2011-09-15 03:36	Pietro Cerutti	New Issue
2011-09-15 13:12	Marcus D. Hanwell	Note Added: 0027479
2011-09-15 13:13	Marcus D. Hanwell	Assigned To	=> Marcus D. Hanwell
2011-09-15 13:13	Marcus D. Hanwell	Status	backlog => tabled
2011-09-16 05:26	Pietro Cerutti	Note Added: 0027486
2011-09-16 10:08	Marcus D. Hanwell	Note Added: 0027487
2011-09-16 10:19	Pietro Cerutti	Note Added: 0027488
2011-09-16 10:27	Marcus D. Hanwell	Note Added: 0027489
2011-09-16 10:36	Pietro Cerutti	Note Added: 0027490
2013-07-22 20:03	Dave DeMarle	Status	tabled => backlog
2013-07-22 20:03	Dave DeMarle	Note Added: 0031271
2014-10-02 10:32	Marcus D. Hanwell	Note Added: 0033439
2014-10-02 10:32	Marcus D. Hanwell	Status	backlog => closed
2014-10-02 10:32	Marcus D. Hanwell	Resolution	open => fixed

Notes
(0027479) Marcus D. Hanwell (developer) 2011-09-15 13:12	How does it break even the simplest VTK project - very few should be including vtkXOpenGLRenderWindow.h directly, we take care of returning that class and most code should not be including system specific derived classes like that. I could take a look at modifying the use file to bring these things in the default case. I would like a little more detail on what exactly is breaking as a consequence of this change.

(0027486) Pietro Cerutti (reporter) 2011-09-16 05:26	I don't completely see why one should not be including system derived classes like vtkXOpenGLRenderWindow. Anyway, I think that all vtk include files should be compilable by just using the VTK_USE_FILE. Either that, or hide away all X11 specific things in the .cxx implementation.. What do you think about it?

(0027487) Marcus D. Hanwell (developer) 2011-09-16 10:08	Back to my original question - what simple VTK projects does this change break? The VTK object factories will make sure you get the correct derived form or a class, so it is a rare thing to include the header you refer to. I am very interested in what simple VTK projects are impacted by this change.

(0027488) Pietro Cerutti (reporter) 2011-09-16 10:19	Any simple project that explicitly includes vtkXOpenGLRenderWindow. If it is intended that client code does not use those objects directly, then the flaw is probably to install unusable include files.

(0027489) Marcus D. Hanwell (developer) 2011-09-16 10:27	That would not be a simple project, the project should be using the vtkRenderWindow class, and will get the correct one returned based upon the OS. Including that class directly means that you will have to do that on Unix, Cocoa/Carbon on Mac, Win32 on Windows. The headers need to be there, for the occasions where you must do something platform specific but in any normal VTK program you would never include that header.

(0027490) Pietro Cerutti (reporter) 2011-09-16 10:36	I see your point, and I don't necessarily disagree. However, I still think that it is inconvenient that - even if I am working on a slightly more complex project - I have to INCLUDE_DIRECTORIES myself to bring in X11 headers when I'm already including vtkXOpenGLRenderWindow.

(0031271) Dave DeMarle (administrator) 2013-07-22 20:03	moving all "tabled" bugs into "backlog" category since "tabled" is no longer used.

(0033439) Marcus D. Hanwell (developer) 2014-10-02 10:32	We might consider adding a new config variable with system headers, but I think the standard includes work well as they are. Most standard programs should avoid including the X specific classes - the object factory takes care of that for them.

Relationships