[bt-devel] New passage selector proposal

Thu Apr 19 15:07:16 MST 2012

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 19.04.2012 22:22, Patrick Zimmermann wrote:
>> 1) When exactly does the search (proposals) screen appear? Is it
>> that when I click on a specific a part of the key
>> (book/chapter/verse) then it jumps to the selection screen. How
>> do I start searching for regular text? This was a bit vaguely
>> described.
> 
> The GUI can operate in two modes, auto search switching and forced
> search mode.
> 
> In auto search switching mode it will open the search screen as
> soon as there are no more possible proposals left, or said
> differently, when the entered text does not seem to be a passage
> name. The search button should change color/shape or something to
> indicate this. While typing the number of passages shown in the
> button selector at the bottom will shrink until there is none left
> and then the search screen is shown (or the "SEARCH" overlay,
> depending on what proves to be better).
> 
> When in forced search mode (entered by pushing the search button),
> no attempt is made to resolving the search term to a passage. This
> should mostly not be needed, but in case I want to search for
> "john" or something that could be resolved to a passage it is
> necessary.
> 
> I'm thought about making the parts of the key clickable too. The
> problem I see with this approach is, that the area to click on is
> quite small (in worst case the space of a "1"). I thought about
> overlaying three buttons: book, chapter, verse when hovering over
> the text box, but that would collide with selecting the text.
> Something like this is in fact needed to quickly switch chapters. 
> But I don't have any ideas at the moment. I thought I'd leave it
> out for later. Any ideas welcome.

What still puzzles me, is this: Let's imagine we have opened Matthew
chapter 1 and can see the scripture on the screen. Which options do I
have to reach
  1) the screen displaying key selection proposals, or
  2) the screen displaying the search suggestions?

>> 4) I didn't quite understand the Add/Replace menu. Please clarify
>> how it works.
> 
> The idea is to combine the currently existing two buttons "add
> work" and "replace work" buttons into a single button. That button
> should, as it does now, open a dropdown menu. The distinction
> whether I want to add or replace is done by having all two
> "headings" in the menu list "add" and "replace". Below them are the
> normal entries that are known from the current buttons. This is not
> touch friendly and might/should be changed into a selector that 
> shows up in the central area, but I would leave that for later,
> since selecting works is not on the "hot path", at least not for
> me. And I would like to take an iterative aproach, at least to some
> extent.

Suppose I have 3 works open: W1, W2 and W3. How do I replace W2 using
this menu?

I think the current solution is somewhat better in this respect at the
moment. Maybe we should instead have a button which displays a special
work selection screen where one can interactively add, replace or
reorder the works. Perhaps a neat solution were to implement this work
organization screen as an overlay on top of the display screen using
some neat HTML/CSS/JavaScript hackery.

>> 5) Why double-click on the search results? Can't this be done in 
>> single click, i.e. something like google.com does that the
>> search result item title is single-clickable, and the match is
>> shown below the search result item and is not clickable?
> 
> Hm, the reason I said double click is because the single click was
> already reserved to show the result in the search window. Changing
> the searchwindow to directly show search results seems like a good
> idea. For now I would like to keep the search window the way it is.
> Redesigning that window can be done later on. Again, I want to take
> an iterative approach.

Iterative approach is good. However in the future a google-like search
UI with previews might also be a very cool feature.

>> 7) Does adding/replacing works in the search screen or the
>> regular display screen constitute a new history item in the
>> back/forward chain?
> 
> Didn't think about that. Sounds like a good idea. Again, I would
> favor the iterative approach and leave that for later.

Once we get there, the back/forward chain logic must be done very well
or users will complain for sure.

> I must confess that I already started implementing a bit.

Cool! :)

> -Either base that model on plain sword or use the CSwordKey as
> basis. Only do a rough, single module implementation for testing.

I think that Sword types/classes/objects should never be directly used
in front-end code. We should abstract it all away.

> -Either subclass CDisplayWindow and put the selectors and model
> class in there or start off with a new MDI window and only copy the
> code for the actual display window over

The architecture of CDisplayWindow and related classes is very
lacking. I'm afraid all that logic needs to be rethought and rewritten
from scratch.

> -Port my code over to use the bibletime backend. The connection
> points should be few, since it's only about retrieving available
> books/chapters/verses and selecting them.

It should, but it isn't currently this simple :| It is rather obscure
and ambigious what the interface provided by the backend is. In simple
words the "backend" does not have a well-defined interface and does
not fully resemble a layer.

> So the only connection points to existing code are the
> CDisplayWindow, if I choose to subclass from that, and the
> interface between my selector model and the selection logic there
> currently is in bibletime.
> 
> I don't have a deep insight into bibletime code. So please correct
> me if this approach can't work or you think it's better done
> differently.

The best solution would be to first draw a lot of (UML) diagrams
detailing BibleTime's architecture, the components and their
interfaces. Then refactor a lot. Negative side-effects may include
death by frustration about existing code.

> In principle the same selector model could also be used for books,
>  commentaries and lexicons. But taking the iterative approach means
> leaving them for now. They can either stay the way they are or
> later on be migrated to also make use of the new selector model and
> get their own selector widgets. (The text selector works badly for
> normal books, the dropdown boxes as they currently have are be
> better suited I guess, but implementing a drop down box selector
> should be possible).
> 
> If this approach works out I don't have to touch existing code
> much.
> 
> 
> Do you mean the following bug? 
> https://sourceforge.net/tracker/index.php?func=detail&aid=2993283&group_id=954&atid=100954
>
> 
Yes, I will probably bump into it. But I don't think I have to solve it,
do I?

Yes, I think its the bug I meant. We will try not to force you. :)

Blessings,
Jaak
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQgcBAEBAgAGBQJPkIyPAAoJELeXyoqzFNdNugA//24H8FIZajqWJ3CPqPvPrWFN
ed3Ep3EYTb2yYva3qxIHFmAiJyvsgnkomMhv3PI4qEgG+quH3z3ei9SpjcygJ5WK
UMHNFaWY1+hcgOsF5dt+V0iPGBkowRzvC2duPBCcjjA9O0WmwRyaqame7juOF4Gh
UY3vYG9WkWOWtSuAfkJtUr0w51uiuQzVKMNhkfdP3GQM4k3yajL9zgh2VU7W/jad
OP6iJrn2b4G6bEUjILvzqFhTvlJTRSOveWJKlhUIAbQklybbqoOmb5wcjSMQ4A56
tg1j9q6BqS/NaSCzMFWuKNP4KNvCYjHj9mi7rnqPxo2NhwsSCLYfprXzS+eRVAiN
TG5VKEGAcRi8V1nfXQzI7STjpQIUGhET5flZeqkkotKwQPTkwieZsN7rG2C9lQwS
85B4rSX5Zs046+ba7Jr0RxdZqP39ZBdJXbe92v1FQAdCDITh+XjQAfJ2LkGdmpyg
nWOPSP2w//WhaFrnmGnnkJjC8afp8BEnOyX7K7OD0qSk5PdqmbIFO8jp/NSaGhbE
v+UnsEwYBCkUqvKAe93vKituKXFRArAhTMOKoEBRaOz70hNAsa3Qm/lN2V+mFEgM
gVNPK4/lHQwKgUbhL9QLPV0njWWZ1IpetP+6N0ZPuUdXx6l16A/YpkxGw4nOQNc3
cmfnEkiFYChfNO6qSIgEb2b6gNCsIBdM7xq99+h/v8J377PXOgdBFY9bpt2FCjmQ
Fcd46e2fBF7qAvpm9Oak7ppmhL+N7+AVC0ulUNM8yQbkcpzdEV1L45pBfspsRNmA
zwewVFDN1hULF4BiUEpGx0XLsunfoEPH7tTenxAMp/CTvP9AUElzRr+cpXTqpb4z
w01By026ch0HKoQTbLCNrk1+pI7Chg00JFbE7F9k1YO5g6liI7JynFqQ/XUUGnP/
CsSrUEQpYq1eAKaBU0IBzNaJ6lkupVjMQQzwnSEw9mGPB7z+sxosQu/oBBeYQDvD
/YDvztlhqkkkM2+cj6y+Bdu5By0PSgrlaln/qgLlydwT+I0nBWBJb0kAG8mRtbpj
If+Kf4mWn2EmnO+zZdpsTVGXGZ/i4OL8LCVIivwKpz9I0jC+ik3SvrGZ1gI+/rro
ukaug1EDYrMmhpfjlMfQGpja4sPnLV09pU0Rojur3TDUAKFqw0Xw2uv7J2qBMV7U
UD6ecbBA1cMgRseJdPqirBmYbWkEzUKBsrfuAQ7iCEMZFHaSudn0ceej9e/5+n4T
p4kLxcp89bGIBEtgYiH1tsh89w4+v7o7r8/mJ8BrLqBtpiJRQXPAR+8fTJyBnu1K
NQuk8wCqUxFj7jGiAeKxHrQJxuWHrO+pCNAP0qHkpX6j+l3rZkcrhPkE6QDwzv+w
rbQbl4xAFWJiY183h511ogaHMb01DppyvJ52ZXJ3SEKD367T4xOy4Ufx7XxTygAj
mcK3RWCxPTictmMThiAY/zT/CNkpR0gC/i26aWI1UNFd3RK0r2EMfti0CnR3nzZw
rfRFE/hHx8EK8VTjOWtaoTvRYL9dzvQWwGao9qaE0Jmd0DtBrUPv1QKNvkhz9dxg
2bW4Csdc+8L3km9ejaPgRrbb1eryAbThZvvWc9HCQF/ZTRob3SJ3K/KbbKTD95Rl
Aus5BDEEF+v+Q6z7o6BYmtoDg7AYJF6C/1LH9iOQkV+z1GihEQuYKZv+2rRBU1zl
ykFdRGBwtIUpUOppitEzJ0l3gwzPqkQUlE1OF0PK+cZCXCym36UnKMXjEtXcDk+D
ptO7JG+7F+4N4LJLB7leOdVjQisKprjEvx2lgmIaj9rqOgaCm7loYmTvRV+k1UMN
Rd1jJtKZWNVDxjxDf9P0W32J5xBBYx7VcfB1lMF/FjZ3uXUs5XlZVyY5pAtEmii1
fD8mmavN1qRJiv8wihXutyRy/XynFjJ5+aN1TajmBXsXz9FlNec08Ap1poIKQRF9
3NKsVKdUtvXbKCI6ozs+S8ZvqnCeQbuMSK+qUPV/fXgBCP64KmTWDEVFI6fMXx32
GSRcZwHcK/fee1pboz54dcTrQdzVUnHKdw8Imht1TMWKsBbhTDbfyM3sps9JYRWM
Y9GW79UdsAE8Dv8lcXLuKCiQ3RzMXUzrz3rj6CYlVpoDqxfkz7IJvcSW8kky7chV
OcsaVKwOU5RP+bU9VnIMyFIJXrUrESrilA4HNf1v4WsA1xx9o4G3zyF/QVdbzr9E
cmku3ZxFSU6yMZ9TLZ43phEKiwra4b2Q1w0XqyzYP+XV6/djJzQn/+63rBpBq4Xg
wyp9hMrJBdW2iApLjpPwW2+mFs22xdr/KEW5+Mvs2PSVTWoHxElqLyYj62sW+jM8
koe8Fo8sdwLJQ0weIyDqLmZYFHiaFtwn03xFsb8zJZK+QJ58PL1Srp861KVl6cL9
hRykjDb//ph1OvK/bEp4TyUWdtCfesTef7SSxgNABgnIGD5sIy3jLuW+n3kyTlvc
+CG/wVNEo6XUEyamNKPmh2xfElInkO/GDZG9Ks9VazP1MRlo4TCRczUUEeJaeobB
CM6e4oWYS9cnPDJUNSYvgzM2N/J1QGx9EdVqzfgKIEuIIb385GyMPbvWChCuNxjg
lSFO9A4q5bR4QDymHyzj3zD9G3042ALl2J7/oxnkxEQKZQEXvPWc7JyneU1xORdG
ZeNDcXwrP5kmkGfRLmWGrbDL1IguRPAjXX5N5aErYq9Qp3mNbP17v3j+NnutKN5A
2pRUWFBkS2FaB99pnPIC
=eHWr
-----END PGP SIGNATURE-----