[sword-devel] SWORD + Qt better support
jaak at ristioja.ee
Mon Jul 29 02:21:10 MST 2013
-----BEGIN PGP SIGNED MESSAGE-----
On 29.07.2013 11:08, Troy A. Griffitts wrote:
> 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.
> 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.
Personally I'd still remove the Qt stuff and keep the Sword interface
as simple as possible. This would make it a bit easier for anybody to
the comprehend the header files, and simplify code maintenance efforts
for Sword developers. In my opinion the overhead for using Sword with
Qt stuff is not that big. On the contrary, I think this would make
Sword biased towards Qt-based projects.
Additionally it seems that in Qt conversion operators are frowned
upon. For example, QString doesn't define conversion operators to and
from std::string but uses explicit methods for that.
> 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.
I think it is still possible to change them to fulfill standard
iterator requirements without sacrificing these features. Iterators
can still have other methods besides the ones listed in the
requirements. Of course for tree iterators the order of traversal is
somewhat an issue.
> 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.
If we expect C++ programmers to be familiar with Java's String object,
then yes. I can only speak for myself and I'm not familiar with it.
Personally I would first have considered subclassing SWBuf from
> 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.
Regardless of the advantages and disadvantages of this move towards
Qt, at this point such commits should not go into the branch from
which you plan to release stable version 1.7.0 from. For Sword 1.8.0
this still needs more consideration, but please let's have a STABLE
1.7 series (branch).
PS: Why does Sword release from trunk instead of having a different
branch for 1.7?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the sword-devel