<html><head></head><body>Just a quick comment. I say this once every 3 years or so, but...<br>
<br>
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.<br>
<br>
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.,<br>
BTStringMgr to use Qt Unicode functions instead of ICU<br>
Replacement for CurlFTPTransport to use Qt instead of curl<br>
Your own lucene impl instead of the builtin SWORD search engine.<br>
Reimplementations of all the HTML filters in SWORD.<br>
<br>
Are you partners in software development with CrossWire or just using SWORD to get access to our module library?<br>
<br>
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?<br>
<br>
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?<br>
<br>
;) Just wanted to rile up conversation. :)<br>
<br>
Troy<br>
-- <br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.<br><br><div class="gmail_quote">Jaak Ristioja <jaak@ristioja.ee> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif">-----BEGIN PGP SIGNED MESSAGE-----<br />Hash: SHA1<br /><br />On 19.04.2012 22:22, Patrick Zimmermann wrote:<br />>> 1) When exactly does the search (proposals) screen appear? Is it<br />>> that when I click on a specific a part of the key<br />>> (book/chapter/verse) then it jumps to the selection screen. How<br />>> do I start searching for regular text? This was a bit vaguely<br />>> described.<br />> <br />> The GUI can operate in two modes, auto search switching and forced<br />> search mode.<br />> <br />> In auto search switching mode it will open the search screen as<br />> soon as there are no more possible proposals left, or said<br />> differently, when the entered text does not seem to be a passage<br />> name. The search button should change color/shape or something to<br />> indicate this. While typing the number of passages shown
in the<br />> button selector at the bottom will shrink until there is none left<br />> and then the search screen is shown (or the "SEARCH" overlay,<br />> depending on what proves to be better).<br />> <br />> When in forced search mode (entered by pushing the search button),<br />> no attempt is made to resolving the search term to a passage. This<br />> should mostly not be needed, but in case I want to search for<br />> "john" or something that could be resolved to a passage it is<br />> necessary.<br />> <br />> I'm thought about making the parts of the key clickable too. The<br />> problem I see with this approach is, that the area to click on is<br />> quite small (in worst case the space of a "1"). I thought about<br />> overlaying three buttons: book, chapter, verse when hovering over<br />> the text box, but that would collide with selecting the text.<br />> Something like this is in fact needed to quickly switch chapters.
<br />> But I don't have any ideas at the moment. I thought I'd leave it<br />> out for later. Any ideas welcome.<br /><br />What still puzzles me, is this: Let's imagine we have opened Matthew<br />chapter 1 and can see the scripture on the screen. Which options do I<br />have to reach<br /> 1) the screen displaying key selection proposals, or<br /> 2) the screen displaying the search suggestions?<br /><br />>> 4) I didn't quite understand the Add/Replace menu. Please clarify<br />>> how it works.<br />> <br />> The idea is to combine the currently existing two buttons "add<br />> work" and "replace work" buttons into a single button. That button<br />> should, as it does now, open a dropdown menu. The distinction<br />> whether I want to add or replace is done by having all two<br />> "headings" in the menu list "add" and "replace". Below them are the<br />> normal entries that are known from the current buttons. This is not<br />> touch
friendly and might/should be changed into a selector that <br />> shows up in the central area, but I would leave that for later,<br />> since selecting works is not on the "hot path", at least not for<br />> me. And I would like to take an iterative aproach, at least to some<br />> extent.<br /><br />Suppose I have 3 works open: W1, W2 and W3. How do I replace W2 using<br />this menu?<br /><br />I think the current solution is somewhat better in this respect at the<br />moment. Maybe we should instead have a button which displays a special<br />work selection screen where one can interactively add, replace or<br />reorder the works. Perhaps a neat solution were to implement this work<br />organization screen as an overlay on top of the display screen using<br />some neat HTML/CSS/JavaScript hackery.<br /><br />>> 5) Why double-click on the search results? Can't this be done in <br />>> single click, i.e. something like <a
href="http://google.com">google.com</a> does that the<br />>> search result item title is single-clickable, and the match is<br />>> shown below the search result item and is not clickable?<br />> <br />> Hm, the reason I said double click is because the single click was<br />> already reserved to show the result in the search window. Changing<br />> the searchwindow to directly show search results seems like a good<br />> idea. For now I would like to keep the search window the way it is.<br />> Redesigning that window can be done later on. Again, I want to take<br />> an iterative approach.<br /><br />Iterative approach is good. However in the future a google-like search<br />UI with previews might also be a very cool feature.<br /><br />>> 7) Does adding/replacing works in the search screen or the<br />>> regular display screen constitute a new history item in the<br />>> back/forward chain?<br />> <br />> Didn't think
about that. Sounds like a good idea. Again, I would<br />> favor the iterative approach and leave that for later.<br /><br />Once we get there, the back/forward chain logic must be done very well<br />or users will complain for sure.<br /><br />> I must confess that I already started implementing a bit.<br /><br />Cool! :)<br /><br />> -Either base that model on plain sword or use the CSwordKey as<br />> basis. Only do a rough, single module implementation for testing.<br /><br />I think that Sword types/classes/objects should never be directly used<br />in front-end code. We should abstract it all away.<br /><br />> -Either subclass CDisplayWindow and put the selectors and model<br />> class in there or start off with a new MDI window and only copy the<br />> code for the actual display window over<br /><br />The architecture of CDisplayWindow and related classes is very<br />lacking. I'm afraid all that logic needs to be rethought and rewritten<br />from
scratch.<br /><br />> -Port my code over to use the bibletime backend. The connection<br />> points should be few, since it's only about retrieving available<br />> books/chapters/verses and selecting them.<br /><br />It should, but it isn't currently this simple :| It is rather obscure<br />and ambigious what the interface provided by the backend is. In simple<br />words the "backend" does not have a well-defined interface and does<br />not fully resemble a layer.<br /><br />> So the only connection points to existing code are the<br />> CDisplayWindow, if I choose to subclass from that, and the<br />> interface between my selector model and the selection logic there<br />> currently is in bibletime.<br />> <br />> I don't have a deep insight into bibletime code. So please correct<br />> me if this approach can't work or you think it's better done<br />> differently.<br /><br />The best solution would be to first draw a lot of (UML) diagrams<br
/>detailing BibleTime's architecture, the components and their<br />interfaces. Then refactor a lot. Negative side-effects may include<br />death by frustration about existing code.<br /><br /><br />> In principle the same selector model could also be used for books,<br />> commentaries and lexicons. But taking the iterative approach means<br />> leaving them for now. They can either stay the way they are or<br />> later on be migrated to also make use of the new selector model and<br />> get their own selector widgets. (The text selector works badly for<br />> normal books, the dropdown boxes as they currently have are be<br />> better suited I guess, but implementing a drop down box selector<br />> should be possible).<br />> <br />> If this approach works out I don't have to touch existing code<br />> much.<br />> <br />> <br />> Do you mean the following bug? <br />> <a
href="https://sourceforge.net/tracker/index.php?func=detail&aid=2993283&group_id=954&atid=100954">https://sourceforge.net/tracker/index.php?func=detail&aid=2993283&group_id=954&atid=100954</a><br />><br />> <br />Yes, I will probably bump into it. But I don't think I have to solve it,<br />do I?<br /><br />Yes, I think its the bug I meant. We will try not to force you. :)<br /><br />Blessings,<br />Jaak<br />-----BEGIN PGP SIGNATURE-----<br />Version: GnuPG v2.0.18 (GNU/Linux)<br /><br />iQgcBAEBAgAGBQJPkIyPAAoJELeXyoqzFNdNugA//24H8FIZajqWJ3CPqPvPrWFN<br />ed3Ep3EYTb2yYva3qxIHFmAiJyvsgnkomMhv3PI4qEgG+quH3z3ei9SpjcygJ5WK<br />UMHNFaWY1+hcgOsF5dt+V0iPGBkowRzvC2duPBCcjjA9O0WmwRyaqame7juOF4Gh<br />UY3vYG9WkWOWtSuAfkJtUr0w51uiuQzVKMNhkfdP3GQM4k3yajL9zgh2VU7W/jad<br />OP6iJrn2b4G6bEUjILvzqFhTvlJTRSOveWJKlhUIAbQklybbqoOmb5wcjSMQ4A56<br />tg1j9q6BqS/NaSCzMFWuKNP4KNvCYjHj9mi7rnqPxo2NhwsSCLYfprXzS+eRVAiN<br
/>TG5VKEGAcRi8V1nfXQzI7STjpQIUGhET5flZeqkkotKwQPTkwieZsN7rG2C9lQwS<br />85B4rSX5Zs046+ba7Jr0RxdZqP39ZBdJXbe92v1FQAdCDITh+XjQAfJ2LkGdmpyg<br />nWOPSP2w//WhaFrnmGnnkJjC8afp8BEnOyX7K7OD0qSk5PdqmbIFO8jp/NSaGhbE<br />v+UnsEwYBCkUqvKAe93vKituKXFRArAhTMOKoEBRaOz70hNAsa3Qm/lN2V+mFEgM<br />gVNPK4/lHQwKgUbhL9QLPV0njWWZ1IpetP+6N0ZPuUdXx6l16A/YpkxGw4nOQNc3<br />cmfnEkiFYChfNO6qSIgEb2b6gNCsIBdM7xq99+h/v8J377PXOgdBFY9bpt2FCjmQ<br />Fcd46e2fBF7qAvpm9Oak7ppmhL+N7+AVC0ulUNM8yQbkcpzdEV1L45pBfspsRNmA<br />zwewVFDN1hULF4BiUEpGx0XLsunfoEPH7tTenxAMp/CTvP9AUElzRr+cpXTqpb4z<br />w01By026ch0HKoQTbLCNrk1+pI7Chg00JFbE7F9k1YO5g6liI7JynFqQ/XUUGnP/<br />CsSrUEQpYq1eAKaBU0IBzNaJ6lkupVjMQQzwnSEw9mGPB7z+sxosQu/oBBeYQDvD<br />/YDvztlhqkkkM2+cj6y+Bdu5By0PSgrlaln/qgLlydwT+I0nBWBJb0kAG8mRtbpj<br />If+Kf4mWn2EmnO+zZdpsTVGXGZ/i4OL8LCVIivwKpz9I0jC+ik3SvrGZ1gI+/rro<br />ukaug1EDYrMmhpfjlMfQGpja4sPnLV09pU0Rojur3TDUAKFqw0Xw2uv7J2qBMV7U<br />UD6ecbBA1cMgRseJdPqirBmYbWkEzUKBsrfuAQ7iCEMZFHaSudn0ceej9e/5+n4T<br
/>p4kLxcp89bGIBEtgYiH1tsh89w4+v7o7r8/mJ8BrLqBtpiJRQXPAR+8fTJyBnu1K<br />NQuk8wCqUxFj7jGiAeKxHrQJxuWHrO+pCNAP0qHkpX6j+l3rZkcrhPkE6QDwzv+w<br />rbQbl4xAFWJiY183h511ogaHMb01DppyvJ52ZXJ3SEKD367T4xOy4Ufx7XxTygAj<br />mcK3RWCxPTictmMThiAY/zT/CNkpR0gC/i26aWI1UNFd3RK0r2EMfti0CnR3nzZw<br />rfRFE/hHx8EK8VTjOWtaoTvRYL9dzvQWwGao9qaE0Jmd0DtBrUPv1QKNvkhz9dxg<br />2bW4Csdc+8L3km9ejaPgRrbb1eryAbThZvvWc9HCQF/ZTRob3SJ3K/KbbKTD95Rl<br />Aus5BDEEF+v+Q6z7o6BYmtoDg7AYJF6C/1LH9iOQkV+z1GihEQuYKZv+2rRBU1zl<br />ykFdRGBwtIUpUOppitEzJ0l3gwzPqkQUlE1OF0PK+cZCXCym36UnKMXjEtXcDk+D<br />ptO7JG+7F+4N4LJLB7leOdVjQisKprjEvx2lgmIaj9rqOgaCm7loYmTvRV+k1UMN<br />Rd1jJtKZWNVDxjxDf9P0W32J5xBBYx7VcfB1lMF/FjZ3uXUs5XlZVyY5pAtEmii1<br />fD8mmavN1qRJiv8wihXutyRy/XynFjJ5+aN1TajmBXsXz9FlNec08Ap1poIKQRF9<br />3NKsVKdUtvXbKCI6ozs+S8ZvqnCeQbuMSK+qUPV/fXgBCP64KmTWDEVFI6fMXx32<br />GSRcZwHcK/fee1pboz54dcTrQdzVUnHKdw8Imht1TMWKsBbhTDbfyM3sps9JYRWM<br />Y9GW79UdsAE8Dv8lcXLuKCiQ3RzMXUzrz3rj6CYlVpoDqxfkz7IJvcSW8kky7chV<br
/>OcsaVKwOU5RP+bU9VnIMyFIJXrUrESrilA4HNf1v4WsA1xx9o4G3zyF/QVdbzr9E<br />cmku3ZxFSU6yMZ9TLZ43phEKiwra4b2Q1w0XqyzYP+XV6/djJzQn/+63rBpBq4Xg<br />wyp9hMrJBdW2iApLjpPwW2+mFs22xdr/KEW5+Mvs2PSVTWoHxElqLyYj62sW+jM8<br />koe8Fo8sdwLJQ0weIyDqLmZYFHiaFtwn03xFsb8zJZK+QJ58PL1Srp861KVl6cL9<br />hRykjDb//ph1OvK/bEp4TyUWdtCfesTef7SSxgNABgnIGD5sIy3jLuW+n3kyTlvc<br />+CG/wVNEo6XUEyamNKPmh2xfElInkO/GDZG9Ks9VazP1MRlo4TCRczUUEeJaeobB<br />CM6e4oWYS9cnPDJUNSYvgzM2N/J1QGx9EdVqzfgKIEuIIb385GyMPbvWChCuNxjg<br />lSFO9A4q5bR4QDymHyzj3zD9G3042ALl2J7/oxnkxEQKZQEXvPWc7JyneU1xORdG<br />ZeNDcXwrP5kmkGfRLmWGrbDL1IguRPAjXX5N5aErYq9Qp3mNbP17v3j+NnutKN5A<br />2pRUWFBkS2FaB99pnPIC<br />=eHWr<br />-----END PGP SIGNATURE-----<br /><br /><hr /><br />bt-devel mailing list<br />bt-devel@crosswire.org<br /><a href="http://www.crosswire.org/mailman/listinfo/bt-devel">http://www.crosswire.org/mailman/listinfo/bt-devel</a><br /></pre></blockquote></div></body></html>