[sword-devel] SWORD + Qt better support

[Troy A. Griffitts]

On 07/28/2013 09:29 PM, Greg Hellings wrote:
>
> On Sun, Jul 28, 2013 at 2:07 PM, Jaak Ristioja <jaak at ristioja.ee 
> <mailto:jaak at 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 at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20130728/d3eb9632/attachment-0001.html>