<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 21-01-16 16:48, Dirk Hohndel wrote:<br>
</div>
<blockquote cite="mid:20160121154844.GA2894@rrmbpvm.gr8dns.org"
type="cite">
<pre wrap="">On Thu, Jan 21, 2016 at 11:11:52AM +0100, Jan Mulder wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
After the mysterious crash of yesterday (version 683) first a little focus
on the most recent changes with that respect. First, running on the desktop,
I can easily crash the app by pulling the divedetails slider. Difficult to
</pre>
</blockquote>
<pre wrap="">
Can you explain in a bit more detail what exactly you mean by "pulling the
divedetails slider"? Do you mean the horizontal bar at the bottom of the
screen?</pre>
</blockquote>
<br>
Yes, the horizontal bar at the bottom. I mean with "pulling the
slider". Focus with the mouse and hold it while sliding to the
right. Basically, this overfloods the
<meta name="qrichtext" content="1">
<span style=" color:#000000;"> call of setDiveId, as in very quick
selecting different dives.<br>
</span>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;"><!--EndFragment--></p>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css">
p, li { white-space: pre-wrap; }
</style><br>
<blockquote cite="mid:20160121154844.GA2894@rrmbpvm.gr8dns.org"
type="cite">
<pre wrap="">Which OS are you running? Which version of Qt are you running with (btw,
that's in the log display that you can get to from the left drawer under
Developer)?</pre>
</blockquote>
Arch Linux, latest pacman -Syu, and the Qt stuff from the Arch
repository. Version 5.5.1. <br>
<blockquote cite="mid:20160121154844.GA2894@rrmbpvm.gr8dns.org"
type="cite"><br>
<blockquote type="cite">
<pre wrap="">Back to other functionality:
Editing of dive details. Ok, it works, and I can press save. When the save
button is hit there is no feedback that the save button is actually pressed
(in hindsight I think that that is true for all button hits throughout the
app).
</pre>
</blockquote>
<pre wrap="">
I thought that was implemented in Rick's change to abstract out the
SubsurfaceButton.qml but didn't pay much attention to that detail. Yes,
the button should change when pressed - different color or something. Jan,
would you like to try to play with this? This is a really nice and simple
way to get your feet wet with QML (and you clearly are already building
your own on the desktop).</pre>
</blockquote>
Ok, I will give this a go. I already did Henriks simple "back to
divelist" (but I see something I still do not like and I do not want
to spoil the fun :-)<br>
<br>
<blockquote cite="mid:20160121154844.GA2894@rrmbpvm.gr8dns.org"
type="cite">
<blockquote type="cite">
<pre wrap="">This is confusing because saving takes multiple seconds to complete.
In addition. what is the dive-edit save actually doing? It doesn't save to
the actual cloud, but (I assume, did not check the source) but only to the
local cache.
</pre>
</blockquote>
<pre wrap="">
Yes - I discussed this on the mailing list a while back. On the desktop
app save just marks the dive list as changed and then prompts you to save
on exit; that doesn't make sense on mobile. So instead we save to the
local cache when we save. But we only save to the cloud if you do so
explicitly from the left drawer menu.</pre>
</blockquote>
Yes, that is what I thought as well, so was surprised by the "save
at start" as discussed below.<br>
<br>
<blockquote cite="mid:20160121154844.GA2894@rrmbpvm.gr8dns.org"
type="cite">
<blockquote type="cite">
<pre wrap="">So, exited the app, checked the cloud data from my desktop. The
latest save (from the divedetails edit page) is not in the cloud. Opened on
the device again, and the last edit shows. Now, reopen the cloud on the
desktop. And yes, the last save is now also in the true cloud. So: on start
of the app, the local cloud is synced to the true cloud. I am not sure that
that is what a mobile user expects. This all said, it edited and saved
correctly.
</pre>
</blockquote>
<pre wrap="">
Yes. that is kinda strange, now that you mention it. Maybe we should save
to the local cache and return to the execution thread and in separate
thread try to sync with the cloud. I just want to make sure that the UI
doesn't get stalled by this.</pre>
</blockquote>
Yes, that sounds like a solid approach.<br>
<br>
<blockquote cite="mid:20160121154844.GA2894@rrmbpvm.gr8dns.org"
type="cite">
<blockquote type="cite">
<pre wrap="">The editing itself. The notes box is bigger than the screen. So when
starting to enter text, you run out of screen and do not see what you type.
</pre>
</blockquote>
<pre wrap="">
Really? What device? What screen resolution?</pre>
</blockquote>
5" screen portrait orientation. 720x1280 pixels. <br>
<br>
<blockquote cite="mid:20160121154844.GA2894@rrmbpvm.gr8dns.org"
type="cite">
<blockquote type="cite">
<pre wrap="">Re-positioning of the edit screen does not work (it slides back when
swiped). Basically, re-styling the edit screen would solve this (labels on
top instead of in front).
</pre>
</blockquote>
<pre wrap="">
But that uses a lot more vertical space overall. I'll play around with the
options there to optimize. Maybe do this just for the notes..</pre>
</blockquote>
I agree that the main "problem" here is the notes.<br>
<br>
<blockquote cite="mid:20160121154844.GA2894@rrmbpvm.gr8dns.org"
type="cite">
<blockquote type="cite">
<pre wrap="">Then the situation that the cloud is newer than the local cache. The app is
opened, splash screen follows, and after that the divelist is shown. Hit any
dive, but nothing happens. Ok, the app is busy refreshing the divelist and
local cache data. It is visual feedback that is missing here.
</pre>
</blockquote>
<pre wrap="">
Yes and I have no idea what to do in that case. I want to show the dive
list from cache right away. That's just a much better user experience. But
then after the sync from the cloud is completed, what do we do if there's
a change?</pre>
</blockquote>
I agree that this is a dilemma. Is is just the lack of visual
feedback here that causes me to click some more times before
realizing that it is just busy. I am not really into UI design, but
"greyed out" or "wait cursor" spring to mind. <br>
<br>
<blockquote cite="mid:20160121154844.GA2894@rrmbpvm.gr8dns.org"
type="cite"><br>
<blockquote type="cite">
<pre wrap="">Some functionality that I really would like to be it a useful tool:
- the auto complete edit things from the desktop app (for example buddy
names, and divesite names).
</pre>
</blockquote>
<pre wrap="">
Oh no. No no no no no. Maybe in version 2. But we will not add that
nightmare of complexity to the first version of the mobile app.
</pre>
<blockquote type="cite">
<pre wrap="">- some way to filter dives. For example, when on a trip, I like to check for
previous dives on that site. The cloud web interface is currently perfect
for that.
</pre>
</blockquote>
<pre wrap="">
Again, great for version 2. Not for the initial version.
Please file these as "enhancement" requests on the bug tracker so they
don't get lost.</pre>
</blockquote>
Agreed and I file these as enhancements. However, i think the
especially the first one (autocomplete) will result in not using the
app for real. Entering at the divesite correctly (proper spelling of
names) will not happen for me, and just trying results in lot of
work later to correct it. But again, version 2 stuff.<br>
<br>
best,<br>
<br>
--jan<br>
</body>
</html>