Dependence on Windows

[willfurnass]

Looks like at present giswater is Windows only as in Utils.java it checks in the Windows Registry whether the .qgs file extension is associated with a default application.

Can this dependency be removed to allow giswater to run on other platforms?

[xtorret]

I think there are more dependences into the code.
As Giswater runs using JRE, it's possible to run on other platforms, not only windows, but this capability is not allowed yet.

[willfurnass]

Would it be worth enumerating these dependencies on the project wiki?

A second set of dependencies relate to the use of windows binaries (./models/bin/*.exe and ./epa/*.exe); I imagine it would be trivial to include the equilvalent UNIX-compatible binaries in these directories and include a case statement for using those on UNIX-like OSs.

[xtorret]

Thank you Will for your suggestion.

Now we are on holidays. Next september we will study your suggestion in order to incorporate it into the route book of Giswater. The project wiki is a pending task and we must to start.

On the other hand,
We would like to develop Giswater UNIX-compatible, but this is a task we can't do yet. May be in the future we will have opportunities to develop it.

Thank you

[vicente-medina]

Dear Will, from the beginning GISWATER was planed as multi platform application. The core of the software is based on JAVA and PostgreSQL. As you know both are released for multiple platforms.

On the other hand there are some weakness in our approach:

1. The installer and the file structure is adapted to Windows architecture (user folder, program files...). To overcome these difficulties is simply, just coping the files to a equivalent structure in your OS is enough.

2. The second issue are the applications exe's. GISWATER is devoted to interact with hydraulic tools (SWMM, EPANET, HEC-RAS). All of them are released as Windows binaries. Being open source, for SWMM and EPANET it is possible to recompile the computational engine to different OS but for HEC-RAS it is more difficult. The whole GUI could run in a emulator framework (like Wine) o perhaps just the engine (SNET.exe, UNET.exe...)

As a final remark we could say that we are really close to be multi platform and we plan to do it the future, but it requires a final effort and we don't have a clear idea about the real impact of this migration in the community, therefore it is in the TODO list, but not in the pole position ;-)

Vicente
.