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
<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.
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.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
_______________________________________________
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
