On 07/28/2013 09:29 PM, Greg Hellings wrote:
On Sun, Jul 28, 2013 at 2:07 PM, Jaak Ristioja <j...@ristioja.ee
<mailto:j...@ristioja.ee>> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi!
On 28.07.2013 20:36, Troy A. Griffitts wrote:
> Hey guys. I spent today to try to add a few methods into 1.7.0
> before we push it out the door to ease your (those building Qt
> frontends) integration with SWORD.
I'm sorry, but this doesn't seem like a good idea. First of all, if
1.7.0 is just about to be released then adding experimental features
is not good.
See response to Karl.
Secondly, if you have support for Qt, why not for Gtk+ and others?
Maybe we can add support for Gtk+. I haven't heard that Gtk+ makes it
difficult to integrate with SWORD as I have heard from the Qt crowd.
For the above two reasons, I wonder if it's not better to put this
sort of compatibility into the bindings world rather than strapping it
directly into the engine.
It's difficult to do this.
A simple extension of the primary classes that support QString and
QArray typed methods would keep it out of the way of all the other
front-ends and prevent unnecessary changes. I had begun down this
route, but got stalled when I had difficulty unraveling the exact
nature of the inheritance hierarchy between SWModule and its specific
implementations. I never returned to it, because there didn't seem to
be a pressing desire to have it.
The SWORD engine returns SWBuf and SWKey objects all over the place
(among other things). Creating a class SWBufWithQTSupport : public
SWBuf {} subclass doesn't help. All the internal methods still return
SWBuf-- not your subclasses. If you have a look at the added methods,
they are simply to allow SWBuf to cast itself to QString and for SWKey
to be constructed with a QString.
Finally, have you thought about how much effort must be put into Sword
over time to develop good Qt interfaces for everything in Sword? Have
you considered how much code bloat this would involve?
No, I don't believe this is true. SWORD exclusively uses SWBuf and
const char * for strings. The additions allow SWBuf and QString to
better flow back and forth. This should be sufficient to allow many
interfaces in SWORD to work nicely with Qt.
Putting it into the bindings would permit more people to help. I've
already got privileges in that folder and Troy could open commit
rights to more. It also mirrors the behavior of the ObjC bindings
shared between Eloquent and PocketSword.
I'm certainly open to this if you have a working example that gets as
much bang for that the SWBuf and SWKey to QString conversion methods
give up.
I also am certainly open to removing what I just added if there is a
detriment. But please have a look at the simply Qt example. This is
completely natural interaction between the engine and Qt, and these are
the major access points of the engine. I believe these minor additions
should simplify quite a bit of code for Qt projects.
Troy
--Greg
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
