[sword-devel] Ubuntu Touch Bible app
Troy A. Griffitts
scribe at crosswire.org
Thu Jul 4 14:27:21 MST 2013
On 07/04/2013 08:45 PM, Greg Hellings wrote:
>
>
>
> On Thu, Jul 4, 2013 at 1:28 PM, Troy A. Griffitts
> <scribe at crosswire.org <mailto:scribe at crosswire.org>> wrote:
>
> Not to insult anyone-- please don't feel insulted...
>
> But what exactly does basing code off of Bibletime instead of
> SWORD give you? Are any of these things worth having in the
> engine itself?
>
>
> Primarily:
> 1) Translation between char*/SWBuf and QString, plus adding QObject
> and additional helpers that Qt offers. This is quite possibly worth
> having in the engine, but every time I've asked the BibleTime guys if
> they want a minimal Qt-Sword binding in the engine they have decided
> that it is unnecessary for BT's specific purposes. I'd still be happy
> to help get this much functionality into the engine if we're going to
> have now 3 frontends leveraging Qt.
I'm happy to ifdef QT some stuff like:
SWKey::SWKey(const QString &other) : SWKey((const char *)other.toUtf8()) {}
SWBuf::SWBuf(const QString &other) : SWBuf((const char *)other.toUtf8()) {}
These two should make things flow mostly transparently Qt and the SWORD
engine, since SWBuf and SWKey can already cast themselves to a const
char * and QString can be constructed from a const char *. It was
simply the const temporaries we count on which would have needed these
casts, for example:
QString key = "John.3.16";
kjv->setText(key);
This last line would not have worked because setKey takes a const SWKey
&. It works seamlessly with a const char * because a temporary can be
constructed because of the SWKey(const char *) c-tor, but there is not
currently a SWKey(const QString &) to allow a temporary to be
constructed from a QString.
>
> 2) An improved CLucene search has long been something that BibleTime
> touts - the index covers more fields and metadata than Sword's CLucene
> index.
Yes, I've seen the ability to search on 'footnotes' and 'headings', but
didn't feel those were worth adding right now, but tried to convince the
BT developers to help me modularize the search framework to allow a
'search field' plugin mechanism-- probably simply a new filter type, and
set of filters which could pull the desired field data from the buffer,
then they could add plugins for their footnotes and headings and
anything else they wanted and frontend could choose which fields they
wanted to include when building indexes. There was no success in that,
but they simply wanted to re-write basically the exact same code we have
for building CLucene indexes, but including their additional fields.
> This is probably worth having, but has been summarily rejected by you
> in the past because there would be no way of detecting Old Index vs
> New Index as current indexes are unversioned (why that itself couldn't
> serve as the flag for old vs new following the addition of an index
> version field, I'm not sure).
You are mistaken.
> You've also given the impression that the CLucene indexes are not a
> high priority for you since you have the brute force search available.
I use the CLucene indexes all the time. They are great for some
things. I have tried to convince people that they aren't necessary for
90% of searches because our unindexed search of an entire Bible is
optimized to return results in under a few seconds on most hardware
(probably including most mobile handsets these days).
>
> 3) An entirely rewritten set of OSIS filters, at the very least.
> Whether these are better or not, I have no opinion of, although I have
> found BibleTime's filters more understandable.
Yes, but re-written isn't necessarily a feature. We add support for new
things all the time in our filters. Are the Bibletime filters updated
as well? Again, this is important to me: I would love for all the
projects which render to HTML to agree on what they would like to see as
the HTML output from the filters and work together on the new XHTML
filter set in the engine so we can all share in each other's improvements.
> 4) Potentially reusable widgets in some places, for common
> functionality like the Install Manager, where a redesign may or may
> not be necessary for some of it.
>
Yes, resusable GUI components are useful but not something I think we
would put into the engine. Maybe a 'contrib/qt folder?
On 07/04/2013 09:35 PM, Gary Holmlund wrote:
> I am definitely leveraging BibleTime backend code to install works
So, a Qt UI using the SWORD InstallMgr facility? This is good but falls
under #4 from Greg, above.
> and the config system for dealing with user preferences.
Is this different than SWConfig? Probably using a QSettings? How is
this different than just using stock SWConfig or QSettings? Does it
remember common things the user might store for SWORD, like which option
filters are turned on? and then reset them when the app starts back up?
This could possibly be useful in the engine, though I would guess most
frontend developers would want to micromanage this and also have more
than what we might decide to track in the engine. Not sure we could
come to some consensus for a useful implementation projects would adopt.
> The filters also provide parallel viewing of passages in a single window.
This would be nice to have: a display class which could produce parallel
HTML for multiple modules.
> The fact that the BibleTime backend converts to QString, etc. is a big
> savings for a Qt app.
Greg also mentioned this above. Would the additions I mention help?
Thanks for the comments Greg and Gary!
Troy
Troy
>
> Those are just some of the things I know of that could be leveraged,
> in addition to having the differences of opinion and strategy you talk
> about below.
>
> --Greg
>
>
> I have looked at the backend 'wrappers' in Bibletime around SWORD
> a few years back and I was disappointed for a number of reasons--
> and so as not to insult anyone-- primarily because they didn't add
> any value at all, but only 'shielded' developers from using the
> engine directly.
>
> I have no idea if this is still the case. I get the impression
> that Bibletime, itself, has been re-written a number of times and
> I'm guessing this includes the 'backend' wrappers as well.
>
> My hope is that if there are any features that are usable by
> multiple frontend, then we should add these into the engine, if it
> makes sense. Again, in an attempt to stop this thread from
> becoming a defense of the Bibletime code or a defense of a
> 'methodology for an API interface (e.g., stateful vs. stateless
> container classes) and from degrading into insulting each other, I
> have not commented on the quality of the Bibletime code. I am
> simply stating that I don't know what
>
> * solid, additional features *
>
> are gained from using the Bibletime base for starting a new
> frontend instead of the SWORD code directly, and if there are any,
> can we add these into the engine?
>
>
> Troy
>
>
>
>
> On 07/04/2013 08:17 PM, Israel wrote:
>
> Great!! I will post the git page (to the uBible Developers)
> if you want me too, or you can head over to
> https://github.com/uBible/uBible/issues/1
> and post the info yourself if you want.
> We have been discussing using Bible Time's backend because
> @Mark Trompell suggested it.
> You can e-mail me off list if you'd like, or post on the
> Github page...
>
>
> On Thu, 04 Jul 2013 09:22:17 -0700
> Gary Holmlund <gary.holmlund at gmail.com
> <mailto:gary.holmlund at gmail.com>> wrote:
>
> I am currently working on a second frontend for BibleTime
> that uses QML.
> It is a work in progress and I have some basic features up
> and working.
> Bibles, Commentaries, and Books can be read in multiple
> windows. The
> windows can be tabbed or split views of the screen. The
> install process
> for bibles, etc. is working.
>
> It requires Qt 5.1 and compiles on linux (ubuntu, fedora,
> etc.). I am
> looking into cross compiling onto android right now. Qt is
> not making
> this easy because they don't support cmake builds for android.
>
> I have it in a private git repository right now, but
> expect to put it
> into the main BibleTime git repository soon. Help with
> this would be
> welcome.
>
> Gary Holmlund
> gary.holmlund at gmail.com <mailto:gary.holmlund at gmail.com>
>
>
> On 07/04/2013 06:25 AM, Israel wrote:
>
> It uses QML, so it is part of Qt. I will bring this
> up to the others
> and see what they think about it all.
> It may be a good idea. Anyhow we are designing an
> interface at the
> moment to get the features we want, using what
> capabilities QML has,
> and designing it to be fully integrated with the
> Ubuntu Touch
> ecosystem. There are some things about using Bible
> Time that may make
> this
> hard, but there very well may be some things we might
> be able to utilize.
> Thanks!
>
> On 07/04/2013 12:15 AM, Mark Trompell wrote:
>
> On Thu, Jul 4, 2013 at 2:04 AM, Israel
> <israeldahl at gmail.com
> <mailto:israeldahl at gmail.com>> wrote:
>
> Hi everyone,
> There are a few of us who have banded together
> to start work on a
> Ubuntu
> Touch SWORD app. Is anyone else working on one?
>
> AFAIK Ubuntu touch uses qt, so maybe just another
> UI Frontent to
> bibletime would do fine,
> with the advantage of being easily portable to
> mer/nemo/sailfish(jolla).
>
> If anyone is interested please join us on github.
> https://github.com/uBible
> We are currently in the process of working out
> the beginning
> details, such
> as UI setup, features, etc....
> May the Lord Jesus bless you all!
>
> --
> Regards
>
>
> _______________________________________________
> sword-devel mailing list:
> sword-devel at crosswire.org
> <mailto:sword-devel at 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 at crosswire.org
> <mailto:sword-devel at 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 at crosswire.org
> <mailto:sword-devel at 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 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/20130704/ea3d0b08/attachment-0001.html>
More information about the sword-devel
mailing list