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