[sword-devel] frontend features, their applicability -- consistency?
niccarter at mac.com
Wed Apr 14 09:50:17 MST 2010
Ok, I'll keep this brief cause it's 2:30am & I'm on my phone, but I
pretty much agree with Karl.
Re: bookmarks: PocketSword has a 2 min worth of effort implementation
in there atm. This WILL change soon, as with loads of other features.
I get to play catchup with all you big boys, cause I've only been
working on PS for such a short period of time...
But perhaps this is the time for me to say I'm considering cutting
support for the GenBook format? The iPhone has the kindle app, has a
very cool CCEL app & is about to get the iBooks app (from Apple), so I
can't see much point.
If there are other features the team here at CrossWire believe are
extremely high priority for PS (or any other front-end, for that
matter), speak up & I'll look into it. Unlocking of modules will be in
the next release, due in a week or 2... :)
ps: I reckon that bookmarks sync between PS and a desktop would be a
manual process (in that you need to hit a button to do it, rather than
it all being automagic cloud-based syncing), so it would be something
you could opt out of, for the persecuted country situation. &
bookmarks might be something that happens between PS & MacSword, cause
we can share all the same Obj-C code (says Nic, without talking it
over with Manfred!). And is also a feature that would, of course, be
part of the iPad version of PS... :)
Ok, bed time, can't wait to read other replies to this in the morning :)
(sent from my iPhone, hence this email is brief!)
On 15/04/2010, at 2:24, Peter von Kaehne <refdoc at gmx.net> wrote:
> Thanks Karl, this is brilliant!
> Karl Kleinpaste wrote:
>> This brings a couple problems. First, we have the necessity of the
>> interaction: Does the user allow this to occur? If the user
>> declines --
>> for now, or forever -- then we are left with an application that
>> must provide bookmark storage. That means that we must create 2
>> methods for bookmarks, and that complexifies the bookmark subsystem
>> in the
> Would this be required? I would think that every application stores
> folders of internal settings +/- may provide a import/export/sync
> capability. Does this need to be amalgamated functionality? I would
> think so.
>> The result is that, regardless of whether network-sync'able
>> bookmarks ever
>> get implemented, every application must still provide its own
>> method for
>> doing so locally. That will be OS-, language-, toolkit-, and
>> filesystem-dependent, thus usually not portable. I'm simply not yet
>> excited about having to expand this in Xiphos, because the value
>> from doing so likely won't offset the anguish of its development.
>> But why do I say that? Because sometimes we have warped ideas of
>> important. Generally speaking, we are often not like our users.
>> In a related discussion in the Xiphos devel list, it was pointed
>> out that
>> we as developers sometimes have an odd perspective about
>> because we keep multiple applications installed in order to test our
>> features and our modules, and so we think "everyone" must want
>> "everything" to work together. On its face...um, yeah, sure, and
>> we're at it, we love baseball, motherhood, and apple pie, too. In
>> reality, how many Joe Averages are there, who particularly care
>> bookmarks can be sync'd among Xiphos, BPBible, BibleTime,
>> Bible Desktop, and BibleCS? Do you (does anyone) actually do
>> remotely the
>> same kind of study in 2 different applications? Do you care
>> whether your
>> tightly-managed bookmarks in Xiphos are directly usable in
>> which doesn't yet provide bookmark titles, has no hierarchy, and no
>> verse support? For facially similar applications (say, Xiphos and
>> BibleTime, or BPBible and BibleCS, or...pick any pair), does Joe
>> actually use 2 such applications, so that sync rises to the level of
>> interest, or in fact does he look over a couple of the available
>> possibilities, and then come down in favor of using just one?
>> Can we even claim to know? If so, how?
>> A prime, on-point example: Since the Dawn Of Net.Time, there has
>> been code
>> in GnomeSword/Xiphos to import BibleTime bookmarks. But the code
>> to do so
>> was so unsupported that it simply stopped working well over a year
>> when BT left behind its KDE specificity.
> Part of the reason is probably general direction of user mobility.
> People move Windows->Apple or Windows-> Linux, but after a bit of
> messing around, few move Gnome->KDE or vice versa.
>> Xiphos uses the exact same bookmark storage format as BT.
> Is it not also the same format as BibleCS? I think so.
>> I didn't know that until this time. I didn't know because I had
>> never had
>> cause to want BT bookmarks in the first place, because Xiphos is my
>> application of choice, and I do my study in Xiphos, where my
>> bookmarks are
>> extensive, featureful, titled, commented. Apparently, Terry simply
>> inhaled BT's format whole when he first implemented them for
>> _In practice_ no one cares about that beneficial compatibility,
>> even when
>> compatibility comes literally for free.
> See above. KDE to Gnome (or back) is not a common move in established
> users. Last time I used KDE is 8 years ago.
>> The practical use case for bookmark sync is undoubtedly desktop -vs-
>> handheld device, and not for different applications that run in the
>> (physical) environment, that is, desktops. And so where we would be
>> concerned with sync is between, say, Xiphos and PocketSword...whose
>> respective metaphors for bookmarks are virtually unrelated. What
>> "sync bookmarks from Xiphos to PocketSword" mean, when my titles, my
>> hierarchy, and my multi-verse references will simply vanish during
>> operation? Would I ever want to sync back the other way? No, never,
>> because too much information would be lost.
> I would think that this is the main place where syncing has a role to
> play. And the order of the day is clearly for mobile application
> developers to become equally featureful as desktop frontends.
>> Now please let me generalize and extrapolate: This in turn makes me
>> about baseline capability, and what "should" be part of any Sword
>> application. Certainly there are obvious qualifiers on which we
>> agree about the bottommost bare minimums: Show selected Bible text,
>> generally on a per-chapter basis; provide for module installation;
>> search somehow; provide commentaries along with or alongside Bible
>> support UTF-8 to get correct display. We could create a list of
>> kinds of real bare minimums. (We wouldn't /entirely/ agree on the
>> of course. But we could probably come close.)
>> How far beyond these bare minimums should we expect any (all) apps
>> to go?
> We had some time ago a debate of what we would consider a "fully
> featured frontend" - and large part of this was what was considered
> necessary functionality.
> In essence it meant that every module could be displayed fully in all
> its features and then some. The canon and versification problematic
> of course thrown a major spanner into the works, making at this moment
> exactly none of the frontends truly "fully featured". But that aside,
> the debate took place about a year and a half or so ago around my
> of the website and discussions which applications may
>> I'm asking because, when I think about some of the capability that
>> brought to Xiphos in the last couple years, I realize that a lot of
>> it has
>> no analogue or counterpart in any other Sword application.
> Again, the feature comparison page on the wiki was meant to create
> impetus towards standardisation and mutual convergence. I think it
> One of the really fascinating outcomes (for me at least) was how
> compiling the comparison lists slowly a picture emerged of
> developing in parallel and ignorance of each other, calling
> the same feature different names
>> Along comes Jane Random, who desperately wants Critical Feature XYZ
>> in her
>> Bible study application. She hears about The Sword Project, finds an
>> application, tries it out, and sees that XYZ isn't there. And so she
>> concludes erroneously that The Sword Project isn't worth her time,
>> worst of all, she tells her friends about her search for XYZ and
>> how The
>> Sword Project didn't measure up.
> I think part of the answer would be to move the comparison page out of
> teh wiki into the general website and link + refer to it from various
> frontends. At the moment it is meant mostly for developers.
>> And to think that we have PR problems on our best days...
>> As to those Critical Features:
> beyond complete module support this is for me: user content, image
> support, rtol, syncable bookmarking + commenting (sometimes called
> tagging), text comparison (see jsword), decent parallel display,
> integration of commentary in parallel views (see jsword), zip install,
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel