[jsword-devel] Future Direction for BibleDesktop

[DM Smith]

On Mar 2, 2009, at 8:01 AM, Adam Thomas wrote:

> My comments are below...
>
> DM Smith wrote:
>>
>> On Mar 1, 2009, at 9:33 AM, Adam Thomas wrote:
>>
>>>
<snip/>
>>>
>>>
>>> The Future Direction page has statements such as "Able to use any  
>>> 1.4.2 Java runtime, with GJC being a specific target". Really,  
>>> even with the release of OpenJDK and newer Open Source platforms  
>>> that are supported on Mac, you still want to mess with GJC?
>>
>> This goal statement is outdated. Joe and I wanted to have BD/JSword  
>> be completely free and open. It would have been better to state that.
> I'm assuming based on your statements that "completely free" means  
> doesn't require Sun's JRE to run?

Yes, that is what I mean. Though if Sun's JRE, as delivered by them,  
is completely free then that would be included.

>
>>
>> The statement regarding gjc was that it was the only free/open  
>> implementation. But it suffered that it did not support Swing and  
>> thus Bible Desktop. Now that OpenJDK is available, this a lot less  
>> important. JSword/BibleDesktop run well with it. But it has only  
>> been available for a short period of time.
>>
>> It's not that I want to "mess" with GJC. But, if gjc ever gets to  
>> the point that it has a full Swing implementation, then I'd like to  
>> support it as well.
>>
> Sure, GCJ could be targeted, but for now I would recommend focusing  
> on OpenJDK as the "open" alternative to Sun's JRE.

I agree.

>
>
>>
>>>
>>>
>>> I also understand the current or old reasons for using JDK 1.4.x,  
>>> but especially since Sun has moved that version into its effective  
>>> end-of-life phase wouldn't it be wise to attempt migration? Sun  
>>> made me register on their site simply because I was attempting to  
>>> download an outdated JDK. I think they made me register so they  
>>> could track how many people are still actively using the outdated  
>>> JDK. Regardless of their reason, do we really want to be hanging  
>>> on to that platform? I'm not advocating bleeding-edge, or even  
>>> leading-edge, simply somewhat current would be nice and still  
>>> allow the maximum number of users to take advantage of BibleDesktop.
>>
>> There are only one reason to hang on to JDK 1.4.2: MacOSX 10.3.
>>
>> Our stated goal is that after Bookmarks are implemented, we'll move  
>> to Java 1.5. Again the reason not to move to Java 1.6 is MacOS 10.4.
> Did you mean to say MacOS 10.3 or 10.4 in both comments above?  
> Again, I've heard that OpenJDK has ports for Mac, just not certain  
> which versions. Need to investigate further.

Mac OSX 10.3 does not have Java 1.5
Mac OSX 10.4 does not have Java 1.6

Most Mac users expect things to just work, so a separate download for  
Java would not be appropriate. Also, the OpenJDK won't have a Mac look  
and feel. And that's bad.

>
>>
>> Basically, I see the addition of Bookmarks as making BibleDesktop  
>> as fairly feature complete. At that time, it would have enough  
>> features that I would have not qualms about leaving it as a legacy  
>> implementation for legacy OS users.
> Makes sense.
>>
>> At one point I updated JSword, Common, Bible Desktop, ... fully to  
>> Java 1.5. I found that there was no performance improvement. The  
>> features of Java 1.5 were syntactic sugar that slightly improved  
>> code quality. (It did spot some bugs!) If I had replace  
>> StringBuffer, I might have seen some.
> JRE 1.5 and 1.6 have been proven faster than previous  
> implementations, however simply moving to an updated JRE oviously  
> doesn't mean noticeable speed improvements. The whole issue of  
> moving to a newer platform is not specifically an issue of  
> performance anyway. Sure, there are tons of syntactic sugar in 1.5  
> and newer, but I see three main benefits. First you can take  
> advantage of new JRE features such as the concurrency utils and  
> other powerful enhancements. Second, development is theoretically  
> made faster/easier/safer via the syntactic sugar you refer to (ie.  
> Generics). Third, I am certainly not opposed to running outdated  
> JREs and realize many companies across the globe are stuck on 1.4,  
> however going out of our way to obtain and develop to an outdated  
> platform doesn't make sense from a modernization and usability  
> perspective. I like your idea of keeping the current version once it  
> has bookmarks, then lets move along into the current century with  
> the main trunk of development using 1.5 or 1.6.

For my setup, I have Java 1.4.2, 5 and 6 installed. I compile with  
Java 1.4, but test against Java 5 or Java 6. If you wish, you can  
develop with either and I'll adjust any patches to compile against  
1.4.2 (i.e. try not to use language features not present in Java 1.4.2).

Regarding Java 5 features, we can put them in using reflection. For  
example, the StringBuffer class could be wrapped by a class in Common  
and if Java 5+ is present it would use StringBuilder. This would use  
reflection.

We do this for ICU. If it is present, we delegate to it.

<snip/>
>
>>>
>>>
>>> Maybe I am totally out of place saying this and nobody else agrees  
>>> with me? Maybe I should go off and start my own project that meets  
>>> my vision? However, I would really like to contribute to THIS  
>>> project since you guys have already done so much great work and I  
>>> don't think that building a new car is the solution when an oil  
>>> change and tire rotation is all that is required.
>>
>> What is your vision? To make BD more visible? Then go for it! Is it  
>> to improve BD by adding new features? Then go for it!
> My vision is to make BibleDesktop a modern and sought after Bible  
> application. It will be the reference implementation to JSword. It  
> will have packages for most major Linux distros that are available  
> on our download site and via the official repos. I would like to  
> begin "going for it" however my efforts need to be coordinated with  
> yours and others if we want to succeed. Finishing the current  
> implementation would be a first step toward moving forward.

Sounds good. Part of this is PR work, which I am not good at;) When we  
get the Linux distributions going, then we need to shout it!

>
>>
>> Let's use this list as a place to discuss your ideas.
> I have some ideas about what I would like to see from BibleDesktop  
> in a future version. Most Bible software does exactly what has been  
> done by BibleDesktop. The texts are presented inside the GUI in a  
> vertical scroll browser window with panels on the left, right, and  
> above that expose functionality such as searching and bookmarking.  
> What if there were a Bible application that felt like an actual  
> Bible, complete with page flipping. Imagine an application where the  
> user interface disappears and is secondary to the content being  
> presented. Imagine an electronic Bible sitting on your computer  
> screen that allows you to open it and flip to the page of your  
> choice or bookmark of your choice. Searches and all other  
> functionality is intuitively built into and hidden from the user  
> until needed. No clutter on the screen, simply content until you  
> need functionality. And for heavens sake, no more vertical  
> scrolling, instead we use digital page flipping to make it feel like  
> are real book.
>
> Here's some very rough examples of page flipping technology with non- 
> cluttered user interfaces, similar to what I have in mind for the  
> future version of BibleDesktop: http://www.flipviewer.com/flipbook/apfinovdec07/ 
>  and another example http://www.turnpagepro.com/doc/Turn-Page/LuxuryReportOpt/2008120202/
>
> Think about it, an electronic Bible sitting on your virtual desktop.  
> BibleDesktop would certainly live up to its name if the application  
> looked and behaved more like I am describing.
>
> This is simply one idea and by no means represents that path we must  
> take. I kinda like the idea of making a Bible reading application  
> that feels like a real book. The vertical scrolling Bible with  
> massive user interface idea have been overdone. Just a thought!

This would be great!

Right now we have the notion of a page consisting of x verses, where x  
is configurable in the options/preferences. It is very clumsy.

It used to be 50, but I think I upped it to 250. When the page is over  
250, we add bottom tabs (which users often fail to notice) as a page  
navigation feature. Give it a try by going into options and setting it  
to a small number.

The biggest problem with this is that it does not take chapter  
boundaries into account. So if there are x + 3 verses in a chapter, it  
probably should show the entire chapter. (When we had it at 50, there  
was a chapter with 51 verses that people reported as being incomplete.)

I'd like to stick with HTML for rendering. Some reasons:
It makes it easier to repurpose JSword to the web. (FireBible  
capitalizes on this as well as some other JSword apps)
When we replace Java's anemic HTML renderer with a native browser,  
we'll get true CSS and JavaScript, which will allow us to make the  
pages come alive.

The other thought we've had is to re-engineer it using SWT/JFace/RCP.  
This seemed like the best path to get a real, native HTML browser. But  
it also would bring a plugin model and flexible layout to Bible Desktop.

Each Bible application has a particular "work flow" or presentation.  
It's great when it resonates with the user. But when it doesn't the  
user is (somewhat) frustrated. (We have several user requests to show/ 
hide various parts of BibleDesktop. We've implemented it for the  
Passage Sidebar.) By having a flexible layout, the user can add/remove  
and reposition each part of the view. By having plugins, developers  
can create new ways to view the books and make them available to others.

This re-engineering is the 2.0 effort.

BTW, AlKitab has the plugin model and a flexible layout. It largely  
replicates the BibleDesktop interface. When we start the 2.0 effort,  
we should evaluate whether it is the appropriate starting point.

>
>>
>> The way it works here is that after you have submitted enough  
>> quality patches, you'd be given commit privs.
>>
>>>
>>>
>>> Let's make BibleDesktop a well known reference implementation and  
>>> further more let's make it a well known application to end users!  
>>> I'll certainly help, but it won't work if I am the only one with  
>>> this vision.
>>
>> I share this vision, but I have not pursued it.
>>
>> The road map reflects my interests and how I would address the Jira  
>> issues. Part of the road map is that after adding Bookmarks, we'll  
>> revisit the GUI to replace the HTML renderer with a native browser.  
>> This is critical for RtoL texts and many other things. That means  
>> that we might replace Swing with SWT/JFace/RCP.
>>
>> The other wish I have is that JSword could be used on a mobile  
>> device. I'm not sure if this is realistic.
>>
>>
>>>
>>>
>>> Warm Regards,
>>> Adam Thomas
>>
>> Thank you so much!
> Let's get the troops rallied, get some more participants, and get  
> this thing going. Are there specific Jira ticket numbers I could  
> help you with to rapidly get the current version stabilized for  
> freeze? I'd like to get the current version done and locked down  
> ASAP and then start planning for our move to the new 1.5/1.6  
> platform and also start discussing what we want BibleDesktop to look  
> like in the future versions.

I'll see about updating Jira to specify a 1.7 release and for 2.0 or  
later. When done, look for the 1.7 issues.

In the meantime, we should do frequent point releases. Hopefully, I'll  
have 1.6.1 out by month's end.

In Him,
	DM