On 07/04/2013 08:45 PM, Greg Hellings wrote:
On Thu, Jul 4, 2013 at 1:28 PM, Troy A. Griffitts
<scr...@crosswire.org <mailto:scr...@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.holml...@gmail.com
<mailto:gary.holml...@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.holml...@gmail.com <mailto:gary.holml...@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
<israeld...@gmail.com
<mailto:israeld...@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@crosswire.org
<mailto: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
<mailto: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
<mailto: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
_______________________________________________
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
