> Not because of disrespect of devels efforts, no. Good. :)
> Python is not suited for a desktop application: it's too slow, uses > too much resources, the legibility of the code is worse than c++, it > has no good library for reading dive computers, it's hard to package > it on osx Windows and Linux regarding libraries, bindings to another > languages are a pain to be made. You don't see c or c++ apps going to > python, but the opposite : once the python app stops scalling, it > must go to either c or c++. I would respectfully disagree on several of these points: the GUI is not appreciably slower than in C (granted, I only compared gtk and pygtk, and have no experience with qt), and any speed loss is certainly offset by convenience; the legibility ultimately depends on the programmer (and the programmer's affinity to document code) in both languages; and C APIs can be wrapped more-or-less easily. Packaging might indeed be an issue for windows and osx, I don't know enough to comment because I am ignorantly exclusive to linux. I would never suggest C or C++ number crunching code to be ported to python, but I would advocate for porting the (G)UI into python. Mixing C and python (not sure about C++, never tried it) is really not that much of a pain once you get used to it. I am an astrophysicist by day and I can tell you that most of our field is rapidly migrating all of the UI stuff to python. Our own code (phoebe) runs C for number-crunching under the hood, but all UI is done in python, and we never regretted the move. Your mileage may vary, of course, I just figured I'd ask because, if subsurface UI was in python, I'd be much better positioned to contribute to the code -- for whatever that's worth. Cheers, Andrej _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
