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

[Tomaz Canabrava]

Sure.

My idea was to separate all the code logic code into a static library (
core.a ),  with no call to the interface at all. Right now there's a file
named 'dive.h' that has quite a few interface-defined functions there, and
it's used everywhere, like in main.c ( why the main.c file calls a function
that's interface-related, I don't know ).

So, moving all of the interface-code ( putting a lot of //WARNINGS: in the
code explaining what's broken and such ) from the sources, making it a
static-library ( doesn't need to be shared, since the only purpose of this
move is to be able to create more than one ui, for mobile and desktop
platforms )

then all of the interface - related code whould be acessible only from the
interface sources, but this one will talk to the corelib  that whould be
linked together making the binary.

T.




2013/4/3 Dirk Hohndel <dirk at hohndel.org>

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130403/621c88dc/attachment.html>