[jsword-devel] Future Direction for BibleDesktop

[Adam Thomas]

DM Smith wrote:
>
> 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 Sun JRE can be downloaded and used by anyone for free. I know some
Linux distros have a very pure definition of free and they sometimes see
Sun's JRE as proprietary. However the Sun JDK and VM have been opened,
but some distros (Debian I think) still view the licenses as not open
enough. It really depends how far we want to go with the whole software
openness concept. Personally I don't have a problem using Sun's JRE since
it is Open Source, free, and readily available on every major current
platform.
>
>>
>>>
>>> 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.

I understand the "just works" concept well. Unfortunately Ubuntu still
doesn't make it easy for Java applications out of the box, maybe someday.

First, before we start defining what OSes we are targeting, we need to
understand our user base and what we are trying to accomplish.
Especially with the recent Windows Vista flop, Microsoft has been
loosing user base primarily to Intel-based Macs and some users are also
switching to Linux. I have no idea what percentage of Mac users use
Intel-based Macs, but it certainly seems to be the current and future
trend to move away from PowerPC-based machines.

As such, are we trying to be an application that can reach the user who
is running a 5 year old or older Mac with very low system specs or are
we targeting mainstream systems worldwide with this ministry? Obviously
we don't want to consciously exclude people from using the application,
but quite honestly there are plenty of very nice web-based Bible
applications already that someone with a text-based browser could use
while running only a Linux console. The biggest question I will ask in
this email is this: What are we trying to be?

My vision is an application that targets current (not bleeding edge)
systems and OSes and moves to at least Java 5. I also see BibleDesktop 
as becoming a lightweight-feeling desktop application that brings the 
Bible to your desktop while using open and cross-platform software.
>
>>
>>>
>>> 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/>

I'm not quite sure how to respond. I think I understand what you are
suggesting and it sound like the type of rework and maintenance that I
am trying to get away from with the re-architecture. I'm gonna hold off
on developing anything for the new architecture and JRE 5 or 6 until we
have a clear plan in place.
>>
>>>>
>>>>
>>>> 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!

First we need a solid product with a crystal clear mission and target
audience. I'll be glad to help with that!
>
>>
>>>
>>> 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.)
>

Glad to hear you are interested.
> 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.

I am quite familiar with "rich" HTML rendering in desktop applications,
however if a user wants a web application, they will use one. Check out:
http://www.ebible.com/ for an example of what I am trying to say. There
are tons and tons of web-based applications to read the Bible. With Web
2.0 and 3.0 and AJAX, etc etc etc they can feel just like desktop
applications complete with persistence. Why bother creating a desktop
Bible application simply to embed web technologies? I personally don't
see the benefit.

The new architecture can be designed to support existing projects such
as FireBible if desired. However, I do not advocate embedding native
browsers into desktop applications of this nature. Have you ever seen or
used Google's Picasa 3 Photo Viewer? It's lightweight, does it's job 
with minimal
fuss, very clean interface, etc. I kinda see BibleDesktop like that. You
can publish photos with Picasa to your blog, email photos, and much
more. The trick is making your desktop application web-aware, not
embedding browsers to replicate rich content via Javascript and DHTML,
and AJAX. If you really wanna write HTML and Javascript go develop for
FireBible, but if you want to build a modern desktop Bible study
application do it with BibleDesktop. My 2 cents...

Maybe I am simply not aware of some very compelling arguments for
embedding a native browser that you have uncovered by years of
experience in developing this product?
>
> 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.

I definitely want to see a robust plugin capability in BibleDesktop!
>
> 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.

Based on my review of Alkitab it is based on the NetBeans RCP, runs on 
JRE 5 or better, and it
looks like a BibleDesktop clone. Not saying that is bad in any way, just
stating my observation.

We could certainly consider Alkitab as a starting
point, but both Eclipse RCP and NetBeans RCP are a little "heavier"
than I would have liked. Again, all of the tabs, buttons, and search 
boxes need to "melt away" and allow the real content, The Bible, be the 
star of the show. Netbeans and Eclipse are great for development IDEs 
and their RCPs are great for certain types of applications, however my 
vision is for something that reduces anything that takes the user's 
focus away from the Bible content, including search boxes, tabs, and 
menu items.

As previously stated, these items are a description of what I would like 
to see BibleDesktop become. You may not share the same vision.

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

That would be great! Let me know if I can do anything to help.

Regards,
Adam
>
> In Him,
>     DM
>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>