Good morning,
Just a couple quick comments about my messages from last night to clear up
possible misunderstandings.
>From the 2 responses from people who use the Bibletime wrappers, it sounds
>like there are many things which are useful for building At apps with SWORD.
>When I responded 'No' to Jaak's prompting to consider how bloated the library
>might get as we enhance the Qt integration, I meant the 'no' to mean that I
>wasn't planning on doing much more than the SWBuf, SWKey to QString.
Also regarding Greg's suggestion for bindings. I think this is a great place
for work to be done on this rich layer to provide assisted Qt development
components. It would be a great place for others to share in the work, as Greg
has mentioned.
My very modest additions were not meant to replace a rich layer of Qt
components, but merely to simplify development of them. It was the biggest bang
for the buck I could see which wasn't too intrusive into the engine.
I'm still willing to roll them back if they cause anyone problems or you
actually find that they don't save quite a bit of conversion syntax all over
the place.
Finally, Jaak, I've considered making SWKey more like an iterator, but while it
makes things conceptually more familiar at first, it loses much of the actual
usefulness of the abstraction. Consider the parsing and range features of
VerseKey, or the very much not iterator concepts of TreeKey. We've made these
all extend SWKey nicely and you can open a module and use it without knowing
the specifics of its key type, but if you need the more specific behavior of,
say, getting the children of a node in a TreeKey, then you can be specific
about it.
Also SWBuf was initially based on all the std::string functionality we used in
the engine before we replaced them with SWBuf. Often you can simply swap SWBuf
for std::string and your code will compile. Functionality beyond std::string
(which I feel is a very poorly thought out string object along with its wstring
counterpart) is taken nearly verbatim from Java's String class. So, I hope we
already do what you've suggested about modeling our string object on familiar
string object people might be familiar with.
Please still comment quickly. As soon as everyone is finished with their
ChangeLog entries, and we drop in a v11n for IBT for the Protestant Synodal
modules (which should be today or tomorrow) I will package up a release
candidate. If these small additions do not simplify your wrappers and make
programming for others without your wrappers much easier, we should drop them
back out.
Troy
"Troy A. Griffitts" <scr...@crosswire.org> wrote:
>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
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity._______________________________________________
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
