Re: Updating Project:KDE:Trunk project on build.pub.meego.com
Hi, On April 17, 2012 at 1:02 AM Lamarque V. Souza lamarque.souza@basyskom.com wrote: Em Monday 16 April 2012, Thomas Pfeiffer escreveu: On Tuesday 03 April 2012 18:22:00 Maurice de la Ferte wrote: Hi all, at the moment we have a well tested and improved state of Plasma Active 2 in our 'Project:KDE:Trunk:Testing' project. We like to ship this state into the 'Project:KDE:Trunk project' asap which is the package feed of our MeeGo/Mer end-user like images. This state is represented by several 'testing' marked images with '2012-03-27' timestamp prefix. Today, I put myself in an end-user position again: I installed the plasma active two stable meego image (basyskom-plasma-active- two-meego-usb-live.iso) and - without changing anything beforehand - ran zypper ref and zypper up (maybe that's not what an end-user is supposed to do, but it's possible and does not come with a warning, and I don't know of a safer way to update). This left my system in a pretty buggy state: The task switcher does not display thumbnails (i.e. it does not work), the top bar is black with a grey border and I could not add Berlin_Routes.pdf to an activity. This is not what I call well tested and improved. Great thanks for testing this scenario and congratulations to find this update issue. It would be very nice if you could also file a bug for this. The problem with task switcher happens probably because the ~/.kde/share/config/kwinrc is configured with a different tabbox layout. The one we use now is: [TabBox] LayoutName=window_strip PA2 uses LayoutName=thumbnails in ~/kde/share/config/kwinrc, we need to edit that file to fix this problem. I will see if we can use kconf_update for that. The other problem is still an open issue: https://bugs.kde.org/show_bug.cgi?id=292820 . Today I've added a patch to kdelibs that seems to workaround the problem (needs more testing). Maybe the code works if compiled as a testing image, but that's not the realistic use-case. What has to actually work is that an end-user who installed the latest stable image available (which currently is PA 2) can update her system in order to receive bug fixes. Maybe we can't get that in PA2 anymore, but this should definitely be our aim for PA3: If a user updates her stable system from the stable repositories, it has to have fewer bugs afterwards, not more. Sorry for the rant. I don't have a problem with a buggy system personally, but once we have actual end-users using and updating their devices and they get what I got today, they ain't gonna be happy. We need more people testing the upgrade process and reporting bugs. I'm not happy about this situation too and this might be just the peak of an iceberg, but this is the why we need people testing different kind of scenarios. I would really like to see a kind of public test checklist and more people who get involved into testing. Thanks for your feedback! Cheers Maurice -- Lamarque V. Souza http://www.basyskom.com/ ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Updating Project:KDE:Trunk project on build.pub.meego.com
On 17.04.2012 01:02, Lamarque V. Souza wrote: The problem with task switcher happens probably because the ~/.kde/share/config/kwinrc is configured with a different tabbox layout. The one we use now is: [TabBox] LayoutName=window_strip Ah yes, I remember. That thing. PA2 uses LayoutName=thumbnails in ~/kde/share/config/kwinrc, we need to edit that file to fix this problem. I will see if we can use kconf_update for that. Yes, we definitely need a process to automatically update config files (while offering the user a chance to keep her modified version, ideally) if we offer updated packages that need changed config files to work correctly. Alternatively, we need to provide a working config file (like e.g. pacman does with .pacnew files) along with instructions that the user must replace the file in order for the system to work correctly. I'd strongly recommend the automatic update, though, at least for config files which users shouldn't mess with in PA anyways. The other problem is still an open issue: https://bugs.kde.org/show_bug.cgi?id=292820 . Today I've added a patch to kdelibs that seems to workaround the problem (needs more testing). If this only affects the demo files, it's a minor problem. We need more people testing the upgrade process and reporting bugs. Definitely. And for that, we need a process for testing the upgrade process _before_ end-users can gain access to the updated packages. Would installing the the last stable image, switching to the Testing repository and then updating be the correct way? Cheers, Thomas ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Updating Project:KDE:Trunk project on build.pub.meego.com
Definitely. And for that, we need a process for testing the upgrade process _before_ end-users can gain access to the updated packages. Would installing the the last stable image, switching to the Testing repository and then updating be the correct way? This seems to be a good work-flow to test the update process. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Updating Project:KDE:Trunk project on build.pub.meego.com
On 17.04.2012 10:29, Maurice de la Ferte wrote: Great thanks for testing this scenario and congratulations to find this update issue. It would be very nice if you could also file a bug for this. Thanks for not taking my little rant personally :) Sorry if my mail sounded harsh. Yes, filing a bug would have been better. I will do that now and next time I will do it before or directly after posting anything to the mailing list. We need more people testing the upgrade process and reporting bugs. I'm not happy about this situation too and this might be just the peak of an iceberg, but this is the why we need people testing different kind of scenarios. I would really like to see a kind of public test checklist and more people who get involved into testing. Thanks for your feedback! Agreed. We definitely need to do upgrade tests every time we plan to merge anything into the stable repository. Ideally we would test a scenario of a user who updates regularly (i.e. has the previous updates installed) as well as one of a user who has just downloaded the latest stable image and then upgrades. And checklists would definitely help. Structured testing will become more and more important as soon as actual paying customers use their PA devices and expect them to just work. Yes, the first Vivaldi buyers are probably mostly tech-savvy friendly users, but even they probably have higher quality expectations towards a tablet than towards a desktop. If I receive advance notice (a few days should suffice) of a planned update of the repository, I'm willing to do an upgrade test from the stable image, if it's possible to do it using a live image instead of installing. I only have one device and I use it for testing the development status as well as for daily tasks, so I can't afford to completely reinstall regularly. But unless a reboot is required, updating on the live image and then just restarting X or plasma-device should work just fine. Cheers, 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] 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. [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. [12:49] unormal And then she sometimes tapped several times the link (or at least attempted) and then, when she tapped to fast, it zoomed. [12:49] sebas Hm, zoom should not trigger when links have been tapped [12:49] unormal 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] ingwa slow browser is difficult to fix... [12:50] sebas slow loading: not sure what we can do about it, which image is that? [12:50] unormal sebas: Zoom triggered as she couldn't tap the link and tried several times. [12:50] sebas the meego images loaded webpages very slow, no idea why [12:50] sebas unormal: couldn't tap means? [12:50] sebas (didn't hit, it didn't react, it wasn't there, ... ?) [12:50] sebas her arms were too short ;) [12:50] unormal The link text was e.g Mehr... and she tried to tap and didn't hit (nicht getroffen). [12:52] sebas unormal: could you check if with the Mer images or the Balsam images, page loading is faster? [12:53] sebas 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 /endOfLongSideTrack). That's it for the moment. Best regards Mario ___ 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]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. [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? [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. 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/endOfLongSideTrack). 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: Updating Project:KDE:Trunk project on build.pub.meego.com
Em Tuesday 17 April 2012, Thomas Pfeiffer escreveu: On 17.04.2012 01:02, Lamarque V. Souza wrote: The problem with task switcher happens probably because the ~/.kde/share/config/kwinrc is configured with a different tabbox layout. The one we use now is: [TabBox] LayoutName=window_strip Ah yes, I remember. That thing. PA2 uses LayoutName=thumbnails in ~/kde/share/config/kwinrc, we need to edit that file to fix this problem. I will see if we can use kconf_update for that. Yes, we definitely need a process to automatically update config files (while offering the user a chance to keep her modified version, ideally) if we offer updated packages that need changed config files to work correctly. Alternatively, we need to provide a working config file (like e.g. pacman does with .pacnew files) along with instructions that the user must replace the file in order for the system to work correctly. I'd strongly recommend the automatic update, though, at least for config files which users shouldn't mess with in PA anyways. Well, I took a look at kwin's kconf_update files and it is disabled (not compiled) in obs. I think Marco disabled it weeks ago to prevent it from changing the LayoutName to thumbnails. We can re-enable it and make it set LayoutName to window_strip instead of thumbnails. The other problem is still an open issue: https://bugs.kde.org/show_bug.cgi?id=292820 . Today I've added a patch to kdelibs that seems to workaround the problem (needs more testing). If this only affects the demo files, it's a minor problem. No, it can affect any file. I do not know exactly why it happens and why it happens only sometimes yet. By what I could figure out when the problem happens kactivitymanagerd tries to set the url property of the resource before setting the is related to property. When setting the url property nepomuk tries to update it and for that it queries soprano to check if the property exists. Soprano returns an empty answer and nepomuk thinks the url property does not exist and creates a new url property and a bogus resource pointed by that url property. The resource now has two url properties when only one should exist. When nepomuk finally set the is related to property it set it to the bogus resource instead of the real one. We need more people testing the upgrade process and reporting bugs. Definitely. And for that, we need a process for testing the upgrade process _before_ end-users can gain access to the updated packages. Would installing the the last stable image, switching to the Testing repository and then updating be the correct way? Yes, as far as I know. According to Maurice the Testing repository is already configured in PA2 image, so the second step is not needed. One problem is that we are in the process of migrating to Mer, when that is finished everybody will have to re-install their tablets. -- 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 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: Updating Project:KDE:Trunk project on build.pub.meego.com
On Tuesday 17 April 2012, Lamarque V. Souza wrote: Well, I took a look at kwin's kconf_update files and it is disabled (not compiled) in obs. I think Marco disabled it weeks ago to prevent it from changing the LayoutName to thumbnails. We can re-enable it and make it set LayoutName to window_strip instead of thumbnails. yeah, that and most of the script were quite old and not relevant to active.. what about having a different folder for active update scripts? so would categorize things a bit better (btw, we'll need shortly one to convert kwinrc-kwinactiverc when the rename will be done) -- 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, 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 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 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: Updating Project:KDE:Trunk project on build.pub.meego.com
On Tuesday, April 17, 2012 14:01:14 Marco Martin wrote: On Tuesday 17 April 2012, Lamarque V. Souza wrote: Well, I took a look at kwin's kconf_update files and it is disabled (not compiled) in obs. I think Marco disabled it weeks ago to prevent it from changing the LayoutName to thumbnails. We can re-enable it and make it set LayoutName to window_strip instead of thumbnails. yeah, that and most of the script were quite old and not relevant to active.. what about having a different folder for active update scripts? so would categorize things a bit better (btw, we'll need shortly one to convert kwinrc-kwinactiverc when the rename will be done) Nasty idea: We can fold them into one. :) If we just ship a correct kwinactiverc, with the right tabstrip, the user's kwinrc will just be ignored, and we get the default config (what we want). Horrible idea, isn't it? ;) -- 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: Updating Project:KDE:Trunk project on build.pub.meego.com
Em Tuesday 17 April 2012, Sebastian Kügler escreveu: On Tuesday, April 17, 2012 14:01:14 Marco Martin wrote: On Tuesday 17 April 2012, Lamarque V. Souza wrote: Well, I took a look at kwin's kconf_update files and it is disabled (not compiled) in obs. I think Marco disabled it weeks ago to prevent it from changing the LayoutName to thumbnails. We can re-enable it and make it set LayoutName to window_strip instead of thumbnails. yeah, that and most of the script were quite old and not relevant to active.. what about having a different folder for active update scripts? so would categorize things a bit better (btw, we'll need shortly one to convert kwinrc-kwinactiverc when the rename will be done) Nasty idea: We can fold them into one. :) If we just ship a correct kwinactiverc, with the right tabstrip, the user's kwinrc will just be ignored, and we get the default config (what we want). Horrible idea, isn't it? ;) Well, what we used to want is the opposite: the old kconf_update is used only in plasma desktop, so we disabled in it in plasma active. Now we need one kconf_update configuration for plasma desktop and one for plasma active. -- Lamarque V. Souza http://www.basyskom.com/ ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Updating Project:KDE:Trunk project on build.pub.meego.com
On Tuesday 17 April 2012, Sebastian Kügler wrote: Nasty idea: We can fold them into one. :) If we just ship a correct kwinactiverc, with the right tabstrip, the user's kwinrc will just be ignored, and we get the default config (what we want). Horrible idea, isn't it? ;) yeah, that one may be skipped indeed. ie if someone hand edited his kwinrc (since is the only way to change kwin config here) he'll know how to take care anyways, while the usual case is the default config anyways -- 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, 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
[Bug 297068] When shutting down via Lock Screen, the sleep countdown runs first
https://bugs.kde.org/show_bug.cgi?id=297068 Lamarque V. Souza lamar...@kde.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Lamarque V. Souza lamar...@kde.org --- Ok, I moved screenlocker to ksmserver: https://build.pub.meego.com/package/rdiff?linkrev=basepackage=kde-workspaceproject=Project%3AKDE%3ADevelrev=302 Now there is one less executable in kde-workspace (kscreenlocker is now a static library linked against libkdeinit4_ksmserver.so), there is still another executable (kscreenlocker_greet) that is responsible for drawing the QML unlock screen (the one with the clock). I changed ksmserver to close screenlocker right before closing the window manager, that is needed to prevent kwin from becoming a zoombie. Because of that sometimes you will still be able to see the home screen before the computer finally shuts down. We could move the greeter into ksmserver to prevent that but that would increase the memory used by ksmserver since now the greeter is running only when the screen is locked. -- You are receiving this mail because: You are the assignee for the bug. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
