<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 17, 2015 at 9:42 PM, Andrej Prsa <span dir="ltr"><<a href="mailto:aprsa09@gmail.com" target="_blank">aprsa09@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> Not because of disrespect of devels efforts, no.<br>
<br>
</span>Good. :)<br>
<span class=""><br>
> Python is not suited for a desktop application: it's too slow, uses<br>
> too much resources, the legibility of the code is worse than c++,  it<br>
> has no good library for reading dive computers, it's hard to package<br>
> it on osx Windows and Linux regarding libraries, bindings to another<br>
> languages are a pain to be made. You don't see c or c++ apps going to<br>
> python, but the opposite : once the python app stops scalling, it<br>
> must go to either c or c++.<br>
<br>
</span>I would respectfully disagree on several of these points:</blockquote><div><br></div><div>And that`s how good conversations starts :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> the GUI is<br>
not appreciably slower than in C (granted, I only compared gtk and<br>
pygtk, and have no experience with qt), and any speed loss is<br>
certainly offset by convenience;</blockquote><div><br></div><div>That`s true if you are comparing only the UI speed - but when you asked why it was not in python I understood "the whole code", for only the interface my point about speed is moot.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> the legibility ultimately depends on<br>
the programmer (and the programmer's affinity to document code) in both<br>
languages;</blockquote><div><br></div><div>not really - and I say that having worked in a insanely large app both in C++ and in Python, two different apps for two different companies that did the same thing: earth simulations to find oil, both softwares had a LOC count of around 5 Million lines. in Python I didn't know what types I should send to a random class method, in C or C++ you dont need to document that, in python people tend to forget to document that.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> and C APIs can be wrapped more-or-less easily. Packaging<br>
might indeed be an issue for windows and osx, I don't know enough to<br>
comment because I am ignorantly exclusive to linux. I would never<br>
suggest C or C++ number crunching code to be ported to python, but I<br>
would advocate for porting the (G)UI into python. </blockquote><div><br></div><div>there is a Qt for python bundle already made, it's PyQt, but there's a few libraries that we use that do not have that part done so this would be yet another hassle: port external libraries to python. also, the Subsurface project already uses a few languages: json, xstl, c, c++ - C++ was choosed for the interface because I'm the interface developer and I'm proeficient with it ( it was C with GTK before it was ported to C++, and you just read how much linus hates c++, why on earth he allowed me to port away from C/GTK to C++/Qt you can watch a few videos on why this was made.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Mixing C and python<br>
(not sure about C++, never tried it) is really not that much of a pain<br>
once you get used to it.</blockquote><div><br></div><div>Since both languages ( c and c++ ) are fairly similar, the learning curve is small.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> I am an astrophysicist by day and I can tell<br>
you that most of our field is rapidly migrating all of the UI stuff to<br>
python. Our own code (phoebe) runs C for number-crunching under the<br>
hood, but all UI is done in python, and we never regretted the move.<br>
Your mileage may vary, of course, I just figured I'd ask because, if<br>
subsurface UI was in python, I'd be much better positioned to<br>
contribute to the code -- for whatever that's worth.<br></blockquote><div><br></div><div>If I may say a thing or two: GTK is a terrible UI library - currently tons of applications are shifting away from it, I can say about: whireshark, gcompris, lxde, subsurface, even Ubuntu And that's maybe why Python code in GTK is better than C code in GTK - it unsuck it a bit.</div><div><br></div><div>If you know how to handle python, then C++ won't be that much of a pain, if you really wanna try to help on subsurface you can :)</div><div><br></div><div>I surely can stop what I'm doing to help you get your first bits of Qt. And maybe you would like to try to port your app from PyGTK to PyQT. </div><div><br></div><div>(<a href="https://www.reddit.com/r/linux/comments/2dxik3/future_of_gnome_and_gtk_when_whole_world_is/">https://www.reddit.com/r/linux/comments/2dxik3/future_of_gnome_and_gtk_when_whole_world_is/</a>)</div><div><br></div><div>Cheers, </div><div>Tomaz Canabrava</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Cheers,<br>
Andrej<br>
</blockquote></div><br></div></div>