Some user feedback (mostly about the PA browser)

[Lamarque V. Souza]

Em Thursday 19 April 2012, Mario Fux escreveu:
> Am Dienstag 17 April 2012, 13.02:25 schrieb Thomas Pfeiffer:
> 
> Morning again
> 
> So I reinstalled (with 2012-04-10-10-15-basyskom-plasma-active-testing-mer-
> usb-live.iso) and right now we're playing with the browser. It is
> definitely much faster and zooms (with pinch) much faster as well.
> 
> > On 17.04.2012 12:14, Mario Fux wrote:
> > > Here the mentioned IRC log:
> > > [12:46]<unormal>  She tried to use mainly the browser to read some news
> > > sites (tagesschau.sf.tv and www.telepolis.de)
> > > [12:47]<unormal>  But first the browser was relatively slow (the
> > > website quite big) and thus took a while to load.
> > > [12:48]<unormal>  And then she had problems with zooming and clicking
> > > or tapping the links.
> > 
> > How did the pinch-to-zoom gesture work for her? I think the image you
> > used should already contain Marco's patch which greatly improves zooming
> > with the pinch gesture.
> 
> Now with the faster browser it works good. Before it was too unpredictable
> as it reacted just after a few seconds.
> 
> > > [12:48]<unormal>  I think the mousearea for links is just the link text
> > > and thus difficult tap with small fonts. Should probably be bigger.
> > 
> > I assume this won't be easy to do (especially since we'd also have to
> > avoid collisions between nearby links), but it would surely help. How is
> > e.g. the Android browser handling this issue?
> 
> No idea. But the link hitting problem is still there. Workaround. Zoom in
> and hit again. We had the problem that we weren't sure if the link was
> tapped or not but lamarque then told us on IRC:
> [18:44] <lamarque> unormal: if the "reload" button turns into a "X" that
> means the link was tapped.
> which helps but the urlbar doesn't always reappear instantly.
> 
> > > [12:50]<unormal>  sebas: Zoom triggered as she couldn't tap the link
> > > and tried several times.
> > 
> > So if we can make the links easier to hit, this should not happen
> > anymore, either.
> > 
> > > So I will try the mer image in the next days.
> > 
> > Would be great to see how big the difference between the images actually
> > is. I noticed the painfully slow loading on the Meego images as well.
> 
> Worlds.
> 
> > > And here some additional feedback. PA looks great, I like it!
> > 
> > Glad to hear! :)
> > 
> > > Another idea I had was to use QML news (RSS) thingie. What's the status
> > > here? It doesn't seem to be ready yet?
> > 
> > I've used it successfully on my device. Does it work at all on yours? And
> > if so, what's missing?
> 
> It works. But sometimes old feeds start to not work anymore and have
> something like "undefined" in the config. Will try again with this mer
> image.

	Maybe this is a problem with kded's networkstatus module not working 
with connman. Most KDE programs treats Solid::Networking::status() == 
Solid::Networking::Unknown as Solid::Networking::Connected (online), which is 
what happens with connman. But if the system is really offline then the 
program must recover by itself since there will be no statusChanged(Connected) 
signal. By what I could see in the rss dataengine it only fetches data if the 
statusChanged(Connected or Unknown) signal is received or when data source is 
requested.

	If we compile kde-runtime against QtNtrack then networkstatus should 
work with any network management software. But NTrack has a history of causing 
problems in kded (Ntrack 0.14 causes 100% CPU problems, Ntrack 0.16 force 
networkstatus to offline mode). Well, Ntrack 0.15 is also not perfect but 
seems to work. networkstatus includes a backend for NetworkManager and Wicd, 
so if we change to NM if will not need Ntrack.
 
-- 
Lamarque V. Souza
http://www.basyskom.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/active/attachments/20120419/0b08b9e5/attachment-0001.html>