[bt-devel] bt-devel Digest, Vol 53, Issue 14

Dylon Edwards integr8e at gmail.com
Tue Sep 16 10:50:42 MST 2008


>> 1) In the MDI, create an option that would allow the user to "anchor" the
>> windows together.  My idea would be to include a button along side the
>> minimize/maximize buttons that would allow the user to toggle each window
as
>> (un)anchored.  Once anchored, the user could modify the size and
arrangement
>> of the windows - much like they can now, only each would expand/contract
>> accordingly.  New windows would default to unanchored and would be placed
on
>> top the others.
>>
>>
>
> This needs some clarification, especially "much like they can now, only
> each would expand/contract accordingly".

I'll do my best - instead of having multiple windows floating around the MDI
that require you to resize each of them individually, implement a feature
that would allow them to be "anchored" together.  Once anchored, resizing
one causes any others connected to it, along the side being resized, to
resize as well; this would be similar to the drag handle on the
Mag/Bookshelf sidebar.  They would be placed on a grid with horizontal and
vertical axes, and each window could have a different size.  You could have
one window on one axis, while having 3 on another.  I would suggest either
having only one layer used for anchoring windows (which would be placed
behind all the others), or creating a feature, like the Slots and Signals
connector in Qt Designer, that would allow an arrow to be dragged from the
active module window to the one you wish to anchor it to.  Newly opened
module windows would default to being unanchored (in case you want to look
at a map or something, and don't want the sizes and positions of your
currently opened modules to be affected).

>> 5) In the search dialog, provide more options such as searching for a
string
>> as a whole, instead of only searching for substrings; also include
options
>> such as searching for an exact phrase (in one verse or continuing into
>> others) or verses containing all the words (in no specific order).  Also,
>> after performing a search, could we provide a window in the search dialog
>> that would allow the user to preview the reference and then switch to it
in
>> his open work(s) if he so chooses?
>>
>>
> The clucene syntax enables many of these already:
> his power (= his OR power)
> his AND power
> "his power"
> his AND po*
>
> We use verses as search documents so interverse searches are not
> possible, at least ATM.
>
> The reference can be opened in a Bible window by dragging and dropping
> it. This feature may be hard to find but I can't think of a better one.

I would imagine many people, such as myself previous to your last message,
don't know about Clucene's syntaxed searches.  Since Clucene already does
the hard work, it shouldn't be too dificult to implement radioboxes that
cause BT to perform certain types of searches by parsing the user's input
string and formatting it to the specified syntax before searching for it.
That would make things easier for everyone and spare the user from having to
enter extra words, such as "them AND in AND mind AND to AND be AND subject"
(Titus 3:1, KJV - a random verse I chose to make a point).  Don't you think
it would be much easier just to check a radiobox that searched for "them in
mind to be subject" than having to manually type AND between each word?

>> 7) When highlighting verses/paragraphs in open works, instead of
>> highlighting stuff from all the works, could we just highlight the
work(s)
>> currently under the cursor?  Say I have 2 bible works open, side-by-side,
>> and want to copy several verses from <one> of them to a separate
document.
>> Would it be too difficult to have BT only highlight the verses directly
>> under the cursor, similar to a rubber-band effect, and not highlight
those
>> of the other unless I drag the cursor to it?  BT already does this when
>> highlighting only one verse, but highlights them all if you try to do
more.
>>
>>
>
> Do you mean in parallel view? This depends on the html layout and the
> html renderer. The columns are implemented as a table. Maybe it's not an
> optimal solution but will not be changed for a while.

Yes, I mean in parallel view.

Well, I'm about to miss my chance to grab some lunch before my next class,
so I'm taking off.  BT IS AWESOME (and y'all are too)!!!

On Mon, Sep 15, 2008 at 3:00 PM, <bt-devel-request at crosswire.org> wrote:

> Send bt-devel mailing list submissions to
>        bt-devel at crosswire.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://www.crosswire.org/mailman/listinfo/bt-devel
> or, via email, send a message with subject or body 'help' to
>        bt-devel-request at crosswire.org
>
> You can reach the person managing the list at
>        bt-devel-owner at crosswire.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bt-devel digest..."
>
>
> Today's Topics:
>
>   1. Re: bt-devel Digest, Vol 53, Issue 12 (Eeli Kaikkonen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 15 Sep 2008 19:32:34 +0300
> From: Eeli Kaikkonen <eeli.kaikkonen at gmail.com>
> Subject: Re: [bt-devel] bt-devel Digest, Vol 53, Issue 12
> To: BibleTime development <bt-devel at crosswire.org>
> Message-ID: <48CE8E22.2080207 at mail.student.oulu.fi>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Dylon Edwards wrote:
> >> Packaging the svn head at a random date is not necessarily a good idea.
> >>
> >
> > OK, I won't make another such decision without first checking with you (I
> > can't remove it from the AUR without special permission from one of the
> TU's
> > - AUR admins).
> >
> >
>
> As far as I know the svn head has been in a stable state since beta1
> because we haven't done any feature changes, so your package should be
> OK. This will change of course, hopefully quite soon.
>
> > If you don't mind, I have some ideas I would like to submit for
> discussion:
> >
> > 1) In the MDI, create an option that would allow the user to "anchor" the
> > windows together.  My idea would be to include a button along side the
> > minimize/maximize buttons that would allow the user to toggle each window
> as
> > (un)anchored.  Once anchored, the user could modify the size and
> arrangement
> > of the windows - much like they can now, only each would expand/contract
> > accordingly.  New windows would default to unanchored and would be placed
> on
> > top the others.
> >
> >
>
> This needs some clarification, especially "much like they can now, only
> each would expand/contract accordingly".
>
> > 2) The new bookshelf manager is awesome!  I was wondering if maybe we
> could
> > include the extra repos by default - disabled at first - and display all
> the
> > available modules on one widget (with the option of exploring the content
> of
> > each repo individually - maybe by placing each repo in a listbox on the
> > side)?  We could also create a searchbox that would filter through the
> > modules according to specific search terms such as module name and
> > description.
> >
> >
>
> See http://devel.bibletime.info/wiki/Bookshelf_Manager_redesign for
> monologue which I used as a development plan. When designing the
> bookshelf manager it should be remembered that it's not usually the most
> frequent task for users to install modules. Because our resources are
> limited we can't implement every wanted detail. Also, the user interface
> should offer as much useful functionality as possible but still stay
> clean and simple. Extra widgets bring extra complexity.
>
> Therefore a filtering capability, for example, is not a feature I would
> implement. If you can point to a common use case where it would help
> tremendously I could reconsider.
>
> > 3) I kind of like the feature in e-Sword that causes each
> > commentary/dictionary/etc you have open to automatically search for a
> word
> > you click on - much like what the Mag does with Strong's numbers.  Could
> we
> > implement something like that in BT, along with a feature that would
> > automatically navigate to a bible passage whenever one clicks on a
> specific
> > reference in a commentary, as long as it is in a recognized format?
> > Something like this would be especially awesome when making notes in the
> > personal commentary, but would probably require some work.
> >
> >
>
> I think this is kind of functionality many users would find useful.
> There is still much to be automated in Bible study. But more than
> general ideas we need detailed analysis of possible user interface
> solutions. The bookshelf manager discussion page mentioned above is a
> good example. Or look at
> http://devel.bibletime.info/wiki/Talk:BibleTime2FrontendNavigator.
> Sometimes an idea is good but nobody finds a good UI for that.
>
> > 4) When one window includes >= 2 modules, instead of rendering it useless
> if
> > one module has something the other doesn't, maybe just display a "not
> found"
> > message in the one lacking.
> >
> >
>
> Not a bad idea. It's also quite stupid that you can choose for example
> an OT book in a translation where there's only NT, even if it's alone in
> a single window.
>
> > 5) In the search dialog, provide more options such as searching for a
> string
> > as a whole, instead of only searching for substrings; also include
> options
> > such as searching for an exact phrase (in one verse or continuing into
> > others) or verses containing all the words (in no specific order).  Also,
> > after performing a search, could we provide a window in the search dialog
> > that would allow the user to preview the reference and then switch to it
> in
> > his open work(s) if he so chooses?
> >
> >
> The clucene syntax enables many of these already:
> his power (= his OR power)
> his AND power
> "his power"
> his AND po*
>
> We use verses as search documents so interverse searches are not
> possible, at least ATM.
>
> The reference can be opened in a Bible window by dragging and dropping
> it. This feature may be hard to find but I can't think of a better one.
>
> > 6) GnomeSword's tabbed sessions idea is pretty cool (much like Dolphin's
> and
> > Konqueror's).  Could we do something like that, allowing multiple
> sessions
> > to be opened at the same time in different tabs?
> >
> >
>
> I have already thought this. Generally it's a good idea. It would give a
> very fast and visible access to several sessions simultaneously. Saving
> and opening sessions is now slow and clumsy.
>
> The problem is our window UI solution. The windows can be arranged
> manually or automatically. If manually, their sizes and placements must
> be exact. The bookshelf and mag are also part of the UI and the window
> sizes and the layout affect these, too. Therefore the whole UI should be
> inside a tab - but even then the windows depend on the size of the main
> window. When a session is opened all sizes and arrangements including
> the main window should be restored, and that makes tabs quite much
> unusable as a solution.
>
> > 7) When highlighting verses/paragraphs in open works, instead of
> > highlighting stuff from all the works, could we just highlight the
> work(s)
> > currently under the cursor?  Say I have 2 bible works open, side-by-side,
> > and want to copy several verses from <one> of them to a separate
> document.
> > Would it be too difficult to have BT only highlight the verses directly
> > under the cursor, similar to a rubber-band effect, and not highlight
> those
> > of the other unless I drag the cursor to it?  BT already does this when
> > highlighting only one verse, but highlights them all if you try to do
> more.
> >
> >
>
> Do you mean in parallel view? This depends on the html layout and the
> html renderer. The columns are implemented as a table. Maybe it's not an
> optimal solution but will not be changed for a while.
>
> > 8) I read in a forum where somebody had asked whether the Mag's font size
> > could be adjusted, could we allow different fontsizes to be set in each
> > module's window?  If so, when keyboard shortcuts are re-implemented, we
> > could assign shortcuts such as <Ctrl><+>, <Ctrl><->, <Ctrl><0>, and even
> > <Ctrl><mousewheel> to zooming in, out, and back to normal.  If I were to
> do
> > this, I wouldn't have a separate fontsize combobox in each window, but
> > rather would place a Zoom In, Out, and Back to Normal option in the View
> > menu that would affect only the active window.
> >
> >
>
> Ctrl+/- should work, they are a khtml feature. (Most other shortcuts
> should work, too, they just aren't configurable.) The font settings are
> now for each language but not for modules. Per module settings could be
> reasonable.
>
>
> > 9) Could we maybe implement a feature that would allow the Mag,
> Bookshelf,
> > and Bookmark toolbars to be (un)anchored and rearanged according to a
> user's
> > preference?  This goes along with idea 1.
> >
>
> That would be nice and has been thought already. It's just too much work
> for now.
>
>
> --Eeli
>
>
>
> ------------------------------
>
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel
>
>
> End of bt-devel Digest, Vol 53, Issue 14
> ****************************************
>



-- 
Dylon Edwards
SSWJ - Stay(ing) Strong With Jesus, Always!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.crosswire.org/pipermail/bt-devel/attachments/20080916/72a371be/attachment-0001.html 


More information about the bt-devel mailing list