[sword-devel] Important things!

[Troy A. Griffitts]

I have added a task list to our sourceforge project.  You can get to it
from our development link on our main, public website.


> > Jody, our install shield expert has also expressed interest in this and
> > has worked on a few alternative pages.
> >
> > Anyone else interested, please put some prototype ideas together and
> > let's all look at them.
> 
> Ok, I'll try.

I didn't mean for you to do it! :)  You must pass school!


> > Don't be afraid of the direction we are going with search.  I'll try to
> > ease your conscience:
> >       o There are many people who have expression the desire to search in
> > MANY different ways.
> 
> But we shouldn't confuse them if we offer the different options. GUIs have to
> be simple, powerful and easy to use!

I agree.  I also feel that frameworks should be flexible and powerful. 
I believe it is the GUI writer's job to show their target user what they
want.  We should add functionality to the multiword search type to
include parsing of AND, OR, NOT, and ().  And if you don't want to show
your users the regex options or the future: 'find words within umpteen
chapters of eachother' feature, then that is your teams decision.  Also,
if you want to be sure all installed modules have the future: AND, OR,
NOT... multiword speedy framework built, and don't mind the extra disk
space, then that is your teams perogative.  Do you understand my
mindset?  I want to make you happy, and also allow others to do their
thing with the framework.


> >       o The framework will not hinder anyone from adding new search
> > capabilities.
> 
> I know, but imagine: In future we'll have 15 different search types with 5
> different speeds ;)

Maybe :)  But I would LOVE to have this 'problem' :)


> > > formats (GBF, ThML, RawText, RawFiles, RawCom, RawLD), this is confusing
> > > users and developers!
> >
> > Users should never know we have different module types.
> 
> Sure, they shouldn't. But they'll notice the difference.

Well, the only difference a user may see is if one source supports, say,
red letter, and one doesn't.  They should never have any idea what
markup the original source is in.


> > Developers should find it useful that we have the ability to support
> > many different module types seamlessly.  I'm not sure as to what the
> > issue is.
> 
> Yes, but sometimes it's hard to manage it. For example:
>         Under Linux we have different frontends. Every frontends provides an editor
> part for the personal commentary. But which format should we use? BibleTime
> uses HTML, GnomeSword uses now the same to be compatible with BibleTime, but
> what's with the windows frontend if you use the same modules in Linux and
> Windows?

Well, when we create the commentary, we need to specify the correct
'source' type so that the right filters will handle on display.  If I
had a good 'HTML' edit control to use in windows, I wouldn't have used
the RTF control that we currently use.


> We definitely need standards (e.g. the standard format you talked about some
> weeks ago).

Yes.  The 2 phase filter is on the task list.


> > Compressed drivers are in the source tree.  They were submitted months
> > back.  I integrated them into the source, but I think we lost our
> > submitter to other venture.  Anyone interested in picking this back up?
> 
> What's missing?

Well, I encorporated all the code that was submitted into the tree, but
I couldn't get the compressor tool that was submitted to make a module. 
Actually, I didn't spend much time trying to get it to work.  I was
hoping that someone else would champion the effort.


> Ok, which features does BibleTime not have? I'm talking about 1.0CVS :)
> The only thing I can think of is this nice "Range parsing" dialog of the
> search dialog.
> I got the Windows version now running in Wine, so I can comment better.

:)  We shouldn't try to say what our stuff has better than the other
one, but... :)

	Right-click verse list parsing, and verse list dialog windows
	Right-click autoselect of words and dictionary lookup
	Right-click copy as greek transliterated
	Netscape equiv. Bookmark support
		menu view
		tree view
			full drag and drop
		Sectional comments in bookmark hierchy
		Sharable bookmark file sets
	Autoparsing intuitive verse ranges with saved, named ranges
	Drag highlighted word to dictionary key (buggy, I think :)  )
	Really cool help system!
	Saved layouts.

Actually, there are many things I don't like about he Windows frontend,
so don't think I consider it 'really cool' or anything.  I would like
much more functionality, and when I add new things to the API teams like
you and gnomesword, I usually try to test it in the windows frontend.  I
really would like re revisit our prototype (that is now over a year
old).  I think it would be a very useful, novel, approach to a Bible
software UI.  I've had new ideas for it over time, but just haven't
revisited it.  I don't think Qt would support it's functionality,
though. (I despise tiled MDI windows, so this uses a 'frame' approach).
		
Anyway, all that to say.  I am planning on breaking out the windows
frontend from the API.  It should have been done a long time ago.  This
will eliminate an 'official' frontend concept.  I would love to offer
Bibletime to windows users!


> Hmm, Bible Works 4.0 was cool with it morphologic analysis and it's
> interlinear display.
> But who could add the tags?

There are modules with morph codes.  I'm sure that is what Bible Works
does.  I don't know of any pure language morph analyzer.  There are just
too many situations where context determines the declension.


> This remembers me that I have to buy a good C++ book to learn it better.

:)

Yeah, I need to get a new job and get out of this Java world! :)

	-Troy.