ubuntu-phone team mailing list archive

[Rodney Dawes <rodney.dawes@xxxxxxxxxxxxx>]

On Mon, 2014-11-03 at 16:29 -0500, Robert Schroll wrote:
> On Mon, Nov 3, 2014 at 3:49 PM, Rodney Dawes 
> <rodney.dawes@xxxxxxxxxxxxx> wrote:
> > There should be a short delay (~100ms) already, after the last key was
> > pressed, before the query is sent. Maybe this needs to be closer to
> > 300ms or so, as typing on the phone can be pretty slow, unlike typing
> > with a real keyboard. If you are finding the current delay is not long
> > enough, please file a bug that the queries are happening too fast.
> 
> I'm testing on an emulator, where typing is *really* slow, so I'm not 
> in any position to judge this empirically.  But 100ms is roughly 100 
> wpm, which is a rather fast clip!
> 
> Is this something that could be made a setting in the .ini file?  If 
> you're typing a mathematical expression, as in my case, you're probably 
> going to be moving significantly slower than if you're typing a buddy's 
> handle.

I do think 100ms is probably to fast, personally. 300ms would be much
better, and on par with average users. I don't even want to imagine
typing a math expression in as a query, with the phone keyboard. :)

I don't think having it be a setting in the .ini file is the right
solution. It should be a static value, but 300ms would feel more
appropriate to me, at least. It's the common delay for a11y keyboard
features, with the repeat delay being 500ms.

> > However, when a new query is sent to the scope, the old query has
> > cancel() called on it. You may need to add additional code to close 
> > the
> > connection to the server, or similar, when you receive the cancel 
> > call.
> 
> Presumably a scope could set up a timeout and only send out the HTTP 
> request if it doesn't get a cancel() in that time.  Any gotchas with 
> that approach?

You could indeed add additional timeouts here, but it should remain a
reasonable delay. Too long and it seems like things are broken. You will
also need to block in your Query::run, in the same way as if you were
doing async (as you would basically be doing async at this point).

> >>  2) Is it possible to display images without any rescaling or 
> >> cropping?
> > 
> > I don't think so. The card size and aspect ratio you specify in the
> > scope, tells the dash how to draw the images. To fit properly, the 
> > dash
> > will scale and may crop, the images.
> 
> This is a problem.  Some responses will be mathematical formulae.  They 
> can be formatted as MathML or LaTeX, but unless I'm mistaken, the scope 
> can only display plain text.  The server can also respond with these 
> rendered as images, but these look ugly if a short formula is scaled to 
> stretch all the way across the screen.

Yeah. MathML/LeTeX is hard. I'm not sure if there is a good solution for
that case, unfortunately.

> > It is basically up to the developer of the scope to decide how to do
> > that. You will need to block in the Query::run, hold the reference to
> > the Reply pointer, and manage asynchronous calls in the background, 
> > via
> > additional threads or event loops.
> 
> Am I correct in understanding that the results show up in the scope 
> each time reply->push is called?  If so, I could probably get nearly 
> the same result by making a series of synchronous requests with pushes 
> in between.  Presumably we'd also need to be checking if cancel had 
> been called anywhere in there.

Yes, each result should show up basically as soon as you call push for
it, with the exception of the slight delay as a result of IPC to
actually send the data to the shell. It might be hard to notice in the
emulator though, if you're on a fast network connection. When I search
in the store scope for example, everything shows up pretty fast, and
there is no noticeable delay between each result.

Yes, if cancel was called, and run is still running, you should stop
pushing, and exit run, as additional push requests will be ignored (and
should be returning false as well). You should also stop pushing if push
returns false, as further pushes will be ignored.