[sword-devel] Ubuntu Touch Bible app

Gary Holmlund gary.holmlund at gmail.com
Thu Jul 4 15:26:52 MST 2013

On 07/04/2013 02:27 PM, Troy A. Griffitts wrote:
> 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.
I am not using the Qt install UI from BibleTime. I am using the Qt 
Models that essentially wrap the installation information up so it can 
be used by various Qt UI widgets or QML. There is also thread management 
I am using during the install.
>> 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.
I am talking about a layer above QSettings. It manages sessions which 
include things like opening windows to the same locations and references 
as when BibleTime was last used. The user can also save or restore 
sessions. It also handles fonts and fonts sizes for each language and is 
integrated with the filters that render the html. It also handles 
keyboard shortcuts, previous search terms, etc. It would be to specific 
for sword functionality.
>> 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?
Greg has more experience with the interface to sword. Perhaps he will 
comment on this.
> 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
> _______________________________________________
> 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/01ea0ed0/attachment-0001.html>

More information about the sword-devel mailing list