Re: Some user feedback (mostly about the PA browser)
Em Friday 20 April 2012, Thomas Pfeiffer escreveu: > > 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. > > Wait, why should we start implementing workarounds for conman? I thought > the plan was to use networkmanager in the long run? We have found that > conman sucks with Plasma Active, and it will always do so. So I don't > think we should invest any more time in it. QtNtrack is not a workaround, it has been supported by networkstatus for years. If it worked without problems we could even remove the NetworkManager and Wicd backends from networkstatus and stay only with QtNtrack. -- Lamarque V. Souza http://www.basyskom.com/ ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Some user feedback (mostly about the PA browser)
Am Donnerstag 19 April 2012, 22.57:38 schrieb Lamarque V. Souza: Morning > Em Thursday 19 April 2012, Sebastian Kügler escreveu: > > On Thursday, April 19, 2012 18:57:09 Mario Fux wrote: > > > One last thing about the browser. She told me that the videos on the > > > news side "work" now. At least the play button and co are visible but > > > she didn't manage to get one loading. > > > > Flash? If so, it just doesn't work. > > > > But ... we do support Flash in principle, meaning you can switch it on in > > the browser's settings, and then it'll work as horrible as flash works > > everywhere else, and your browser will feel slow while flash is enabled. > > And you also need to install the Shockwave flash plugin since we do not > ship it in any image. I see. Interestingly the (most probably flash) videoplayer seems to start/load but the videos is loading and loading and ... Thx Mario ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Some user feedback (mostly about the PA browser)
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. Wait, why should we start implementing workarounds for conman? I thought the plan was to use networkmanager in the long run? We have found that conman sucks with Plasma Active, and it will always do so. So I don't think we should invest any more time in it. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Some user feedback (mostly about the PA browser)
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] She tried to use mainly the browser to read some news > > > sites (tagesschau.sf.tv and www.telepolis.de) > > > [12:47] But first the browser was relatively slow (the > > > website quite big) and thus took a while to load. > > > [12:48] 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] 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] 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] 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/ ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Some user feedback (mostly about the PA browser)
On Thursday 19 April 2012, Lamarque V. Souza wrote: > > > > But ... we do support Flash in principle, meaning you can switch it on in > > the browser's settings, and then it'll work as horrible as flash works > > everywhere else, and your browser will feel slow while flash is enabled. > > And you also need to install the Shockwave flash plugin since we do not > ship it in any image. and in case of html5 would also mean of course missing h264 codec as well. all of this suck but we can't legally distribute them -- Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Some user feedback (mostly about the PA browser)
Em Thursday 19 April 2012, Sebastian Kügler escreveu: > On Thursday, April 19, 2012 18:57:09 Mario Fux wrote: > > One last thing about the browser. She told me that the videos on the news > > side "work" now. At least the play button and co are visible but she > > didn't manage to get one loading. > > Flash? If so, it just doesn't work. > > But ... we do support Flash in principle, meaning you can switch it on in > the browser's settings, and then it'll work as horrible as flash works > everywhere else, and your browser will feel slow while flash is enabled. And you also need to install the Shockwave flash plugin since we do not ship it in any image. -- Lamarque V. Souza http://www.basyskom.com/ ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Some user feedback (mostly about the PA browser)
On Thursday, April 19, 2012 18:57:09 Mario Fux wrote: > One last thing about the browser. She told me that the videos on the news > side "work" now. At least the play button and co are visible but she > didn't manage to get one loading. Flash? If so, it just doesn't work. But ... we do support Flash in principle, meaning you can switch it on in the browser's settings, and then it'll work as horrible as flash works everywhere else, and your browser will feel slow while flash is enabled. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Some user feedback (mostly about the PA browser)
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] She tried to use mainly the browser to read some news > > sites (tagesschau.sf.tv and www.telepolis.de) > > [12:47] But first the browser was relatively slow (the website > > quite big) and thus took a while to load. > > [12:48] 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] 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] 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] 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. > > Oh and I like the new "file" browser (I still think "file" is not the > > right term as IIRC you want to get rid of the file hierarchy paradigm > > which IMHO goes in the right direction and brings KDE software (together > > with Nepomuk) in a pole position). > > Yes, this will definitely be renamed before the PA3 release. It's actually > more of a proof of concept at its current state, since it does not support > any operation other than "open" yet. And it will also support browsing any > type of resource in the future, not just files. So the current name would > not make any sense then, anyway. > Glad that you like our direction of replacing the file hierarchy with > semantic data. Oh I liked it from the start of Nepomuk on ;-). One last thing about the browser. She told me that the videos on the news side "work" now. At least the play button and co are visible but she didn't manage to get one loading. Thx Mario & Betty ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Some user feedback (mostly about the PA browser)
On Tuesday 17 April 2012, Marco Martin wrote: > i would have to check if technically possible having a dnd event active > while the menu is open tough, or rather close it and be actually sure is > closed before the drag event starts, the two things are quite notorious to > make the X server explode badly when used together byy the way, to give a quick idea about what the hell we are talking about to who didn't try it ;) http://www.youtube.com/watch?v=xZhevJRkuxs -- Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Some user feedback (mostly about the PA browser)
On Tuesday, April 17, 2012 13:54:16 Marco Martin wrote: > On Tuesday 17 April 2012, Mario Fux wrote: > > So I will try the mer image in the next days. > > > > And here some additional feedback. PA looks great, I like it! > > > > Another idea I had was to use QML news (RSS) thingie. What's the status > > here? It doesn't seem to be ready yet? > > doesn't have offline caching but online browsing should work fine. > it should probably become a real app with at least the models taken from > akgregator to work more reliably. > > at the moment nobody has time to work on it, but as usual, volunteers > welcome One thing that is already possible to get more feeds into the RSS Reader is while browsing websites, the webbrowser's dashboard will show an RSS icon for pages that have associated feeds. Tapping that icon will copy it to the clipboard, then you can paste it into the RSS Readers config dialog, using the press-and-hold mechanism. It's not overly intuitive though, what I'd like is to have some sort of system-wide or per-activity bookmarks of RSS feeds, but I don't know if we have the ontologies to store this in Nepomuk in a meaningful way. Does anybody know? Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Some user feedback (mostly about the PA browser)
On Tuesday 17 April 2012, Thomas Pfeiffer wrote: > On 17.04.2012 15:01, Marco Martin wrote: > > hmm, could work, but as in the activity screen right now long tap is the > > same context slc menu. > > I know, but does it not highlight/mark it as well? At least it did the last > time I checked ;) > > But even if the context menu appears, dragging the icon could still be > enabled (the menu should disappear opon dragging, of course). hmm, another problem... at the moment the behaviour is that moving the fingler while pressed and menu open it selects menu items, so the events are completely managed by the menu, to make possible to press, move finger over an item, like the stars, release, the item gets activated, so all done in a single gesture (just like the desktop menubar behaves) this is kinda mututally exclusive with enabling drag and drop while the menu is open, i think is nice because makes using the menu a bit faster, if is decided to drop that feature both here and in the activity screen fine, should be the same tough. i would have to check if technically possible having a dnd event active while the menu is open tough, or rather close it and be actually sure is closed before the drag event starts, the two things are quite notorious to make the X server explode badly when used together -- Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Some user feedback (mostly about the PA browser)
On 17.04.2012 15:01, Marco Martin wrote: hmm, could work, but as in the activity screen right now long tap is the same context slc menu. I know, but does it not highlight/mark it as well? At least it did the last time I checked ;) But even if the context menu appears, dragging the icon could still be enabled (the menu should disappear opon dragging, of course). it can select the icon as well making the marker appear tough Yes. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Some user feedback (mostly about the PA browser)
On Tuesday 17 April 2012, Thomas Pfeiffer wrote: > On 17.04.2012 14:42, Marco Martin wrote: > > probably just well hidden, one of the things that really has to be > > learned vs something that clutters the ui forever (like the top pulling > > panel) > > I'm all for not cluttering, as long as users can still learn how to do > things > > > two finger gesture to select files, then drag and drop over the trashcan, > > the device icons or the tags > > What about long-tap to select as on the Activity screen? That way both > would be consistent (Short tap to open, long tap to select). Plus, a > two-finger gesture would only work on multitouch-devices, right? > I'm still not totally happy with the long-tap on the Activity screen, but > anyways we should definitely make the two consistent. That way at least the hmm, could work, but as in the activity screen right now long tap is the same context slc menu. it can select the icon as well making the marker appear tough -- Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Some user feedback (mostly about the PA browser)
On 17.04.2012 14:42, Marco Martin wrote: probably just well hidden, one of the things that really has to be learned vs something that clutters the ui forever (like the top pulling panel) I'm all for not cluttering, as long as users can still learn how to do things two finger gesture to select files, then drag and drop over the trashcan, the device icons or the tags What about long-tap to select as on the Activity screen? That way both would be consistent (Short tap to open, long tap to select). Plus, a two-finger gesture would only work on multitouch-devices, right? I'm still not totally happy with the long-tap on the Activity screen, but anyways we should definitely make the two consistent. That way at least the user has to find out only once and can transfer the knowledge to the other. We don't want them to learn two unintuitive actions for the same thing in different places ;) However, the user should not have to lift the finger between long-tapping to select and actually dragging the resource. So it should be: - Finger down - Wait for the tapped resource to be highlighted - Drag The two-finger gesture is great for selecting multiple resources, but not for selecting a single resources. but indeed needs a very recent devel image and is still in development, so only partly tested Ok. Will have a look at it as soon as I get a devel image on my device again. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Some user feedback (mostly about the PA browser)
On Tuesday 17 April 2012, Thomas Pfeiffer wrote: > On 17.04.2012 13:16, Marco Martin wrote: > > supports open, either by an external application or internal viewer if > > supported (only an internal viewer for images exists right now, i would > > like calligra and the ebook reader getting ported to it) > > Definitely, yes. Every resource type for which we currently have a default > viewing application should be opened by it. > > > delete, copy between internal memory and removables, browse by date, by > > tag and tagging of resources. as features go, i think it should really > > be it. > > Since when does it support delete and copy? Was this implemented just > recently and I haven't noticed it yet, or has it been there for a longer > time and is just hidden so well that I missed it? ;) probably just well hidden, one of the things that really has to be learned vs something that clutters the ui forever (like the top pulling panel) two finger gesture to select files, then drag and drop over the trashcan, the device icons or the tags but indeed needs a very recent devel image and is still in development, so only partly tested -- Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Some user feedback (mostly about the PA browser)
On 17.04.2012 13:16, Marco Martin wrote: supports open, either by an external application or internal viewer if supported (only an internal viewer for images exists right now, i would like calligra and the ebook reader getting ported to it) Definitely, yes. Every resource type for which we currently have a default viewing application should be opened by it. delete, copy between internal memory and removables, browse by date, by tag and tagging of resources. as features go, i think it should really be it. Since when does it support delete and copy? Was this implemented just recently and I haven't noticed it yet, or has it been there for a longer time and is just hidden so well that I missed it? ;) as the name, i'm still on the fence, making it support way different things like contacts is quite a mine field, risks to become a broken version of an addressbook or whatever, while it would still need the "real" one at least for a very long time Everything that can be added to an Activity should also be browseable via the resource browser. We don't need addressbook functionality like editing contacts or initiating actions like writing an email. Of course things like moving a contact to an external medium would be more difficult (ideally, this would create a vcs on the medium, but that is not high priority), but these could be disabled if not available. Deleting should work, but even that is not strictly a must right from the start. Finding and opening (and SLC stuff) is a must, everything else is nice-to-have for anything but files. One of the central innovations of Activities vs. folders is that an Activity treats any sort of resources the same, be it files, contacts, mails, places or whatnot. Therefore, we want our users to treat them the same as well. So if we break this paradigm already at the browser, this is not good. We throw them back at the distinction between files and "other things", telling them "If you are looking for a file, use the file browser. If you're looking for a contact, use Contacts". Suddenly, the user has to distinguish these things again in order to know which application to open. We do not want that. If the user wants to edit a contact, she should 1. Open the resource browser 2. Search for it (using all the criteria we offer) 3. Tap it to open it in Contacts 4. Edit it I sometimes have a hard time explaining the advantages of our Activity concept vs. good ol' folders, because people say "When I want to collect files related to a project, I put them in a folder". It's usually when I say "Yes, but can you collect other things there as well, like contacts or events?" that they get it. This is what Plasma Active is about. "Forget about files and folders and applications. It's about the resources you need to accomplish your task!" A browser that's only for files totally breaks that. For example, we should not create a separate bookmark management UI in PA. The resource browser should replace it, because it's the central component for resource handling. Maybe this needs a larger discussion, but for me, restricting the resource browser to files is clearly not an option, because it touches such a central concept. Cheers, Thomas ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Some user feedback (mostly about the PA browser)
On Tuesday 17 April 2012, Mario Fux wrote: > > So I will try the mer image in the next days. > > And here some additional feedback. PA looks great, I like it! > > Another idea I had was to use QML news (RSS) thingie. What's the status > here? It doesn't seem to be ready yet? > doesn't have offline caching but online browsing should work fine. it should probably become a real app with at least the models taken from akgregator to work more reliably. at the moment nobody has time to work on it, but as usual, volunteers welcome -- Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Some user feedback (mostly about the PA browser)
On Tuesday 17 April 2012, Thomas Pfeiffer wrote: > On 17.04.2012 12:14, Mario Fux wrote: > > Here the mentioned IRC log: > > [12:46] She tried to use mainly the browser to read some news > > sites (tagesschau.sf.tv and www.telepolis.de) > > [12:47] But first the browser was relatively slow (the website > > quite big) and thus took a while to load. > > [12:48] 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. > > > [12:48] 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? > > > [12:50] 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. > > > 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? > > > Oh and I like the new "file" browser (I still think "file" is not the > > right term as IIRC you want to get rid of the file hierarchy paradigm > > which IMHO goes in the right direction and brings KDE software (together > > with Nepomuk) in a pole position). > > Yes, this will definitely be renamed before the PA3 release. It's actually > more of a proof of concept at its current state, since it does not support > any operation other than "open" yet. And it will also support browsing any > type of resource in the future, not just files. So the current name would > not make any sense then, anyway. supports open, either by an external application or internal viewer if supported (only an internal viewer for images exists right now, i would like calligra and the ebook reader getting ported to it) delete, copy between internal memory and removables, browse by date, by tag and tagging of resources. as features go, i think it should really be it. as the name, i'm still on the fence, making it support way different things like contacts is quite a mine field, risks to become a broken version of an addressbook or whatever, while it would still need the "real" one at least for a very long time -- Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Some user feedback (mostly about the PA browser)
On 17.04.2012 12:14, Mario Fux wrote: Here the mentioned IRC log: [12:46] She tried to use mainly the browser to read some news sites (tagesschau.sf.tv and www.telepolis.de) [12:47] But first the browser was relatively slow (the website quite big) and thus took a while to load. [12:48] 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. [12:48] 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? [12:50] 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. 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? Oh and I like the new "file" browser (I still think "file" is not the right term as IIRC you want to get rid of the file hierarchy paradigm which IMHO goes in the right direction and brings KDE software (together with Nepomuk) in a pole position). Yes, this will definitely be renamed before the PA3 release. It's actually more of a proof of concept at its current state, since it does not support any operation other than "open" yet. And it will also support browsing any type of resource in the future, not just files. So the current name would not make any sense then, anyway. Glad that you like our direction of replacing the file hierarchy with semantic data. That's it for the moment. Thank you very much for your feedback! Keep it coming! Best regards Mario Best, Thomas ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Some user feedback (mostly about the PA browser)
Good PA team Some days ago I installed the following PA meego image on the Intel ExoPC from BDS: 2012-04-10-10-37-basyskom-plasma-active-testing-meego-usb-live.iso The reason that my wife wanted to have a device to read the news in the morning (at mainly the two German websites tagesschau.sf.tv and www.telepolis.de). So I got some feedback from a new PA user and wanted to share this with you. I already did it on IRC (see below) and was asked to mail it to this list as well. Here the mentioned IRC log: [12:46] She tried to use mainly the browser to read some news sites (tagesschau.sf.tv and www.telepolis.de) [12:47] But first the browser was relatively slow (the website quite big) and thus took a while to load. [12:48] And then she had problems with zooming and clicking or tapping the links. [12:48] I think the mousearea for links is just the link text and thus difficult tap with small fonts. Should probably be bigger. [12:49] And then she sometimes tapped several times the link (or at least attempted) and then, when she tapped to fast, it zoomed. [12:49] Hm, zoom should not trigger when links have been tapped [12:49] This are the main annoyances for now. Will post this to the list as well. And it's about Meego testing image from 10th of April. [12:50] slow browser is difficult to fix... [12:50] slow loading: not sure what we can do about it, which image is that? [12:50] sebas: Zoom triggered as she couldn't tap the link and tried several times. [12:50] the meego images loaded webpages very slow, no idea why [12:50] unormal: "couldn't tap" means? [12:50] (didn't hit, it didn't react, it wasn't there, ... ?) [12:50] "her arms were too short" ;) [12:50] The link text was e.g "Mehr..." and she tried to tap and didn't hit (nicht getroffen). [12:52] unormal: could you check if with the Mer images or the Balsam images, page loading is faster? [12:53] I found meego images to be very slow when loading webpages, it didn't seem a browser problem So I will try the mer image in the next days. And here some additional feedback. PA looks great, I like it! Another idea I had was to use QML news (RSS) thingie. What's the status here? It doesn't seem to be ready yet? Oh and I like the new "file" browser (I still think "file" is not the right term as IIRC you want to get rid of the file hierarchy paradigm which IMHO goes in the right direction and brings KDE software (together with Nepomuk) in a pole position ). That's it for the moment. Best regards Mario ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
