OpenSimulationInterface / osi-visualizer

**This repository is abandoned and looking for a maintainer.** A tool to visualize OSI data from two different sources. Data can be stored in files and replayed afterwards, or validated using a Python interface.
Other
39 stars 25 forks source link

Feature/win32 support #33

Closed pmai closed 6 years ago

pmai commented 6 years ago

This PR merges win32 support enhancements made by @MEpping.

pmai commented 6 years ago

This is a cleaned-up version of PR #31 without git breakage, please review if this works on Win32 for you @MEpping, @monishgogri . I have not tested on Win32, but at least the linux CI build works again.

monishgogri commented 6 years ago

@pmai @CarloVanDriestenBMW Thank you for cleaning and approving. The code runs just like the last time (#31 ) @MEpping I was trying to Debug, why it the "example_sensorview.txt" is not working. It turns out that the following line 301 in osireader.cpp must be changed to: `std::ifstream inputFile (osiFileName.toStdString().c_str(), std::ios::binary);` Now, I am getting the Pause button, the seek slider is also activating and it is showing me 14 secs on the timer, but I still see nothing on the GUI. Here is the screen shot: image I also noticed that during this, osi-visualizer.exe consumes 35%+ of my CPU! Which I believe is a lot since it didn't consume so much when I ran it on Linux. Update: the header file (.txth) is also getting correctly generated.

pmai commented 6 years ago

@monishgogri I've separated out the binary fix, since that applies to this branch.

The resource directory fix seems to me to be not fully thought out: If this is changed, it should likely either try to get the CMAKE install target path, so that the visualizer works when installed, or, even better, resources should be localized relative to the executable on all platforms. In any case this should be fixed not only for Win32.

The other cmake changes seem ill-advised: Paths that are likely to only work on your system should not be included as hints; rather when building using cmake, these should be provided as cmake options and/or using a file to prepopulate the cmake cache (see e.g. the -C option to cmake).