<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
> I will try to build Mobile under Android, currently without cmake<br>
> scripts but pro.<br>
> Install manager is that what i would make. I think utility for<br>
> managing background tasks should be prior.<br>
</div>The current install manager is installing in the background in one<br>
thread. This is all done at the end after modules to install are<br>
selected. The progress is shown as it installs.<br>
<div class="im"><br></div></blockquote><div>this is what i wrote in my todo on this matter:<br> centralized parallel processing:<br> get data from sword<br> install a module<br> refresh remote sources<br>
build search index<br> maybe backend reloading</div><div> ability for blocking execution (e.g. first text entry)</div><div> make this suitable for main repo<br> should know what is current view (text/install), current text, probably via signals/slots<br>
i'd prefer to make it in c++ layer<br><br></div><div>I decide to maximally unload main thread, and keep it from blocking as much as possible. Your opinion is very valuable here of course. <br><br></div><div>Here would be different solutions: leave it decentralized as it is, use QtConcurency - but las time i implemented it i found it not enough functional as there is no priority control and (not sure) queue management.<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
<br>
><br>
> For interface design i would like to avoid overlapping and hanging<br>
> elements, it just makes feeling of some kind of a heap, overloads<br>
> interface. Its better to make sliding panels, shifting and snapping of<br>
> interface elements, those in my opinion makes feel order and logic.<br>
> Just a mention, i understand that it is early variant of interface.<br>
</div>Please give a more complete description of each user interface before<br>
implementing them. I think we should agree on them before implementation.<br>
<div class="im"><br></div></blockquote><div>Complete description is difficult task. For the final implementation we should agree on each element, but this should not be braking factor for development.<br><br></div><div>Talking of your Install manager, i'd better fill whole screen with it. Pop-up menu - would be, but i realize that there should be something more serious, maybe side navigation (like facebook/evernote). And avoid folding because it makes user's way longer to desired function (for tiling i'd placed items on menu top level grouped as square tiles with icons).<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
> I plan to merge prototype i will made and Mobile code, so i able to<br>
> make this task also. You will need to test this on your devices as well.<br>
><br>
><br>
> Recently i got success with my Bible model in QML. Model with 32000<br>
> heavy text elements been layout almost smoothly on Android device. If<br>
> there will be threader data acquisition it will be smooth at all.<br>
> It would be layout with Chapters instead of verses, what mode do you<br>
> prefer (continuous reading per chapter, continuous reading per verses,<br>
> single chapter mode)?<br>
</div>Does "continuous reading per chapter" mean that multiple chapters are<br>
loaded at once?</blockquote><div><br></div><div>Yes, user would see two chapters at time, at the joint.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Would the entire book be loaded?</blockquote><div><br></div><div>With Qml ListView it is difficult, because without scroll bar it optimizes display and loads first list entry, <br>entries you actually see and some entries behind visible area (amount equal to ListView::<span style="color:rgb(26,26,26);font-family:Arial,Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:100;letter-spacing:normal;line-height:20px;text-align:justify;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(246,246,246);display:inline!important;float:none">cacheBuffer </span>property)<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think this is<br>
preferred as long as it is not a performance problem. I do worry about<br>
the performance?<br>
<div class="im"><br></div></blockquote><div> "?" => "." I do as well.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
><br>
> Also i'm interested in how would be realized BibleTime Magnifier tool<br>
> on mobile device, will method with JS object work?<br>
</div>This concerns me. I know how the current desktop version works and the<br>
QML WebView won't work this way. Javascript can be loaded and ran in the<br>
WebView, but I don't know how to communicate back to the c++ code. I am<br>
continuing to look for this answer.<br>
<div class=""><div class="h5"><br>
Gary<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>
</div></div></blockquote></div><br></div></div>