[bt-devel] New passage selector proposal

Thu Apr 19 21:12:09 MST 2012

Just a quick comment. I say this once every 3 years or so, but...

Of course my opinion is that you are making a huge mistake trying to abstract the SWORD code away and not use the classes directly in your frontend.

The classes in SWORD were written to facilitate quick and easy frontend development. As Jaak notes, your abstractions are not well organize. BT seems to chronically reimplement SWORD functionality for no real benefit, e.g.,
BTStringMgr to use Qt Unicode functions instead of ICU
Replacement for CurlFTPTransport to use Qt instead of curl
Your own lucene impl instead of the builtin SWORD search engine.
Reimplementations of all the HTML filters in SWORD.

Are you partners in software development with CrossWire or just using SWORD to get access to our module library?

If you really feel you have a need which isn't handled by the engine, wouldn't you rather like to contribute code back to the engine for other frontend projects to use, and take advantage of the numerous improvements other projects have contributed to these things?

I always hear the argument that you want to add other data sources in the future, or completely replace SWORD in the future. Why? Are we a body working together, building common tools, sharing together, or do you only take what we're offering?

;) Just wanted to rile up conversation. :)

Troy
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Jaak Ristioja <jaak at ristioja.ee> wrote:

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

_____________________________________________

bt-devel mailing list
bt-devel at crosswire.org
http://www.crosswire.org/mailman/listinfo/bt-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/bt-devel/attachments/20120420/bb44d730/attachment.html>