About c-functions that make UI calls. [qt-rewrite]

[Dirk Hohndel]

On Apr 3, 2013, at 5:50 AM, Tomaz Canabrava wrote:

> People,
> 
> I'v managed to integrate my files to the Makefile (yey), so now I'm trying to detach the GTK code and put the Qt code in the old place.
> 
> in dive.h there's quite a bunch function definitions of interface related things, that are being called in a lot of places on the code, and basically they creates an ui, process things then close the ui.
> 
> How this is going to be managed?
> 
> 1 - Continue the way that it is, port the code *inside* the function calls to Qt.
> 
> This will create a code that's not easily understandable from people with Qt experience, since we are used to a more 'class-methods' thinking, and Qt callback system ( Signals / Slots ) needs the callback to be a class member, so for this one to work a good amount of boilerplate code is needed.
> 
> 2 - Remove the interface calls from the non-interface code ( there's a few in main.c for instance ), adapt the code and use it on the interface by calling a few methods, basically transforming all the logic of the subsurface in a library, then using the library on the interface.
> 
> This will create a code that's easily understandable by qt-people, and can also have some benefits, like an future Android-based version of subsurface using QtQuick.
> 
> I need to know what you guys prefer before digging more into the code.

I may be a little slow this morning (I swear I already had a latte), but I'm not 100% sure I understand what you are asking…

Right now the C code and UI code are a muddled connected mess. Worse in some parts of the code than in others. This has been a major pain in my rear for a while (and if you go WAY back in the git history you'll see two valiant efforts of mine to reduce that intermingling). So that far I am with you.

What I don't quite understand is what you mean by "transforming all the logic of the subsurface[sic] in a library". Can you elaborate on this, please?

/D