[Bug 296941] imageviewer: search doesnt return results for some words; or doesnt recognize word-fragments
https://bugs.kde.org/show_bug.cgi?id=296941 --- Comment #5 from Lamarque V. Souza --- Git commit 6d36741809fba9c408179f9d29b0a47aea3e4e6f by Lamarque V. Souza. Committed on 31/03/2012 at 02:42. Pushed by lvsouza into branch 'master'. Revert "remove regexp as nepomuk anyway does a substring match using contains()" Nepomuk does not do substring match with contains. Active image-browser now shows results for any subtring (even for one character). This reverts commit b789c94de9c3d88e88809099b27126e30d1dde5c. (cherry picked from commit 6947cfa0b8b6a12788741e10bc4116400d09079d) M +2-1components/metadatamodel/metadatamodel.cpp http://commits.kde.org/plasma-mobile/6d36741809fba9c408179f9d29b0a47aea3e4e6f -- 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
[Bug 296941] imageviewer: search doesnt return results for some words; or doesnt recognize word-fragments
https://bugs.kde.org/show_bug.cgi?id=296941 --- Comment #4 from Lamarque V. Souza --- Git commit 6947cfa0b8b6a12788741e10bc4116400d09079d by Lamarque V. Souza. Committed on 31/03/2012 at 02:42. Pushed by lvsouza into branch 'mart/useFullScreenSheet'. Revert "remove regexp as nepomuk anyway does a substring match using contains()" Nepomuk does not do substring match with contains. Active image-browser now shows results for any subtring (even for one character). This reverts commit b789c94de9c3d88e88809099b27126e30d1dde5c. M +2-1components/metadatamodel/metadatamodel.cpp http://commits.kde.org/plasma-mobile/6947cfa0b8b6a12788741e10bc4116400d09079d -- 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
[Bug 296943] copy/paste feature is great, but are the icons intuitive?
https://bugs.kde.org/show_bug.cgi?id=296943 --- Comment #3 from Lamarque V. Souza --- Git commit c5f0b815230057cf8a5a8be0ce48a9e647208d77 by Lamarque V. Souza. Committed on 31/03/2012 at 01:08. Pushed by lvsouza into branch 'master'. EditBubble.qml: put buttons in the order "copy" and then "paste", double buttons' MouseArea sizeto make it easier to tap on them, and add space between the buttons. M +21 -17 plasma/declarativeimports/plasmacomponents/platformcomponents/touch/EditBubble.qml M +1-1 plasma/declarativeimports/plasmacomponents/platformcomponents/touch/TextField.qml http://commits.kde.org/kde-runtime/c5f0b815230057cf8a5a8be0ce48a9e647208d77 -- 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
Re: Creating pre-filled Activities
On Friday 30 March 2012 22:26:56 Aaron J. Seigo wrote: > this sounds cool. will it get used? in this manner? > > would a more common use case be that when "Anne receives an email asking her > to prepare a presentation for a meeting on very short notice." she wants to > pull together all information related to that topic that already exists? > or an activity that reflects / is based on / is the activity related to that > task of the person who sent it to her? If the system already has enough data to "know" the related information then yes, sure, that would be even better. Btw, that's what I meant by "activities based on semantic connection". But this is the highest - and probably hardest to achieve - level of machine knowledge. If we have it, all the better. If not, creating an activity based on the resources used within a specific context ex post is still better than nothing. > i don't have enough usage data to know. i doubt any of us do because this > kind of data will only come through people using it. right now it is > speculative: it could be a feature lots of people use fairly frequently, > one that is used by a few people lots, or used by lots of people rarely. or > by "no one". Of course we don't know that, and we can hardly predict it because no user will tell you "I want that" without even knowing it's possible. > my concern is that implementing this kind of feature (including Ivan's > expansion of it into activity clone-and-reduce) increases the UI load for > all users of activities. if it ends up not being a common use case, we'll > have degraded the experience. I don't see users creating new activities very frequently as long as filling them with resources is done all manually (which is pretty tedious even with the best UI). So why make the creation of new empty activities as fast as possible if actually filling them with content is much more work anyway? > honestly: i really do not think we should be doing much more work on the > shell right now. it will likely only make it more complex before we have a > strong user base that has learned what we have already (which already comes > with some learning curve, but an approachable one right now), and we have > tons of things that actually do need doing elsewhere in the user > experience. The thing is: We have (or, to be exact, mostly Ivan has) invested quite some work into the recommendation system. It can already do quite some fancy stuff technically, but the practical usefulness is currently close to zero. So we sat together and thought "Hey, how can this system actually serve the user?" The current recommendations layer obviously isn't the answer. And that's because it offers recommendations proactively, mostly without the user needing them at that moment. So we asked ourselves "Okay, so when _will_ the user need - or benefit from - recommendations?" And one of the situations that came to our mind was "When she creates a new Activity". It wasn't the only one, but we'll tell more about the other situations when we have fleshed out the concepts further. I don't say that we should make the pre-filled Activities a top priority for PA 3 (besides, it looks like Ivan does not find it any realistic soon anyway). However, it is important to keep possible future developments in mind when talking about current changes, if only to make sure that we won't make them harder to implement later. I'm not sure what priority the Activity creation wizard has for Fania. For me, the priority is not very high, though I think it's very likely that we'll need one eventually, in the future. I only wanted to put her suggestion into context. > example: i have received _numerous_ requests for shared and/or synchronized > activities, based on actual not-made-up use cases. implementing that would > be guaranteed to grow out user base. it may not sound as sexy, but it's > completely practical and desired and could probably be done without > impacting the shell itself. Actually, I find that _very_ sexy! In fact, I even think I was the one who put it in the "business user" scenario we created during the PA sprint last fall! And I'd be totally fine with giving this a higher priority than the pre-filled Activities. I completely agree that right now, we still need many things to make Plasma Active really useful for the end-user, and that is our top priority. Remember, I am an end-user myself, using PA every day, so of course I'm highly interested in getting a product that is as useful as possible. But imo it's the more unusual stuff - for example the recommendations, but also shared Activities - that offer the chance to really set us apart from anything else on the market in the future. So I want us to keep these in mind, even when their realization is still a thing of the future. In the end, it's all a matter of communication. It may seem like our goals are very different at first, but in the end they're the same, only maybe with s
Re: findings on networkmanager/polkit/consolekit/arm
Em Friday 30 March 2012, Marco Martin escreveu: > Hi all, Hi, > so, today i tried to figure out a why networkmanager is not working on arm > and only arm. > > turns out the problem is polkit. so not only networkmanager doesn't work, > but anything that requires authentication > apparently polkit depends from consolekit to identify who belongs to the > same session and who doesn't, except that now doesn't use consolekit > anymore but systemd. > > in kde, not exactly sure in what part of the stack, systemd is still not > supported (or better, is not supported the act to telling to systemd a what > is the currently running session) Usuallly it is kdm that talks to console-kit, since we do not use kdm then uxlaunch should do that role. Distributions seem to launch desktop sessions like this: ck-launch-session dbus-launch startactive I tried that in a x86 Meego image it the kde agent simply stopped working (could not authenticate). I wonder why everybody on the Internet suggests doing that, maybe uxlaunch does not support console-kit. > what happens is that the kde polkit authentication agent fails with this > message > polkit_agent_listener_register: assertion `POLKIT_IS_SUBJECT (subject) > failed > > so, i tried to rebuild the polkit package making it still use consolekit > (could even be used until a real solution is found?) > > the status i have now is: > if i manually launch ck-launch-session, then from the same terminal > relaunch the authentication agent it does connect. > > if now i launch an application that uses polkit, like the time settings > dialog it works correctly and i can actually change the time. > i still didn't manage at all to make polkit authenticate for networkmanager > (reued to restart kded, plasma-device but nothing) > > > so, that's basically how far i could push it, > this session registration part has to be fixed. > > it's still misterious why this happens only on arm and not on x86, so... > ideas? ;) Have you tested downgrading polkit from 0.104 to 0.103? -- Lamarque V. Souza http://www.basyskom.com/ ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
findings on networkmanager/polkit/consolekit/arm
Hi all, so, today i tried to figure out a why networkmanager is not working on arm and only arm. turns out the problem is polkit. so not only networkmanager doesn't work, but anything that requires authentication apparently polkit depends from consolekit to identify who belongs to the same session and who doesn't, except that now doesn't use consolekit anymore but systemd. in kde, not exactly sure in what part of the stack, systemd is still not supported (or better, is not supported the act to telling to systemd a what is the currently running session) what happens is that the kde polkit authentication agent fails with this message polkit_agent_listener_register: assertion `POLKIT_IS_SUBJECT (subject) failed so, i tried to rebuild the polkit package making it still use consolekit (could even be used until a real solution is found?) the status i have now is: if i manually launch ck-launch-session, then from the same terminal relaunch the authentication agent it does connect. if now i launch an application that uses polkit, like the time settings dialog it works correctly and i can actually change the time. i still didn't manage at all to make polkit authenticate for networkmanager (reued to restart kded, plasma-device but nothing) so, that's basically how far i could push it, this session registration part has to be fixed. it's still misterious why this happens only on arm and not on x86, so... ideas? ;) Cheers, Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Workflow and integration
Em Friday 30 March 2012, Aaron J. Seigo escreveu: > On Friday, March 30, 2012 11:19:32 Lamarque V. Souza wrote: > > Em Friday 30 March 2012, Marco Martin escreveu: > > > * when a feature is almost ready is merged into integration, people > > > test it, fixes are done in the feature branch, then re-merged > > > > What happened if a feature from on repo depends on a feature from > > > > another repo's integration branch? > > if you are doing devel, you probably want to be running the integration > branch(es). I am asking this because I use obs to compile packages and it removes all dependencies from the build directory when compiling a new package. How can I prevent it from doing that? > > I use obs to compile packages and test > > features here. In my case I would need to hack obs to compile two (or > > more) packages whose .tar.bz2 are not in obs. > > obviously we need to have one of the obs projects tracking the integration > branches. it makes no sense otherwise. > > > more complicated because of the dependencies. People who use Mer SDK > > would have the same problem too. > > no, because they'd be tracking one of: > > * master > * integration > * a device specific target > > > > * when tested enough, it gets merged into master > > > * Device specific (Archos, vivaldi, whatever) releases are branches of > > > master called like Device/Vivaldi (only a stable state needed? or > > > integration/stable for that too?) > > > > > > This reflects in obs in the following way > > > * integration project points to integration branch, (or devel can be > > > repurposed to it) > > > * testing project points to master: master became a stable branch now > > > * Each device specific git branch has an own obs project > > > > Why use a git branches instead of sub-directories? > > because these branches need to track the existing code from a "known good" > point and stabilize around that. that is precisely what branches are for. > > > With sub-directories > > > > we can use only one obs project to build all rpm packages for all devices > > and minimize the burden of maintaining different copies of the same > > files. > > so we'd have a complete copy of all the source code in each subdirectory? > and then manually merge diffs between the sub-directories? that makes no > sense :) No, you copy only the files that need changes. I am not talking about diffs, you copy the whole file, not diffs. > > For instance, we can create a "shared" sub-directory which contains all > > configuration files, > > this has nothing to do with configuration files. this is the code: the > shell, the applications, etc. Ok then, forget my suggestion. > > if a device needs a different configuration file we > > create a sub-directory for that device and copy only the files that it > > needs. > > and when changes are made to the original files that are globally > applicable? we just copy those changes by hand? how long do we keep those > subdirectories? With branches we will have to apply them by hand using git anyway. The difference is that if the change affects affect a file that has never been compiled to a sub-directory then we need to apply it only once. If we use branches for configuration files we will need to apply the change to all branches. > this also ignore the reality that each device target will end up having its > own OBS project anyways, so nothing is really to be gained here. If you say so. > > Then we configure the .spec to, during installation phase, copy the > > shared directory to the BUILD_ROOT and then override the files there with > > the ones from the device's sub-directory. > > and what about files specific to the device? right: you'll need a different > .spec file. .spec supports sub-packages. > and again: this is not about configuration. this is about changes in the > source code in plasma-mobile and stabilization for specific device > targets. Again: forget my suggestion then. -- Lamarque V. Souza http://www.basyskom.com/ ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Creating pre-filled Activities
On Friday, March 30, 2012 11:51:02 Thomas Pfeiffer wrote: > since it has become relevant to the discussion about the "Edit Activities" > dialog, I will now present an idea that Fania, Thorsten Prante from > Zeitgeist and me had at the last PA sprint. this sounds cool. will it get used? in this manner? would a more common use case be that when "Anne receives an email asking her to prepare a presentation for a meeting on very short notice." she wants to pull together all information related to that topic that already exists? or an activity that reflects / is based on / is the activity related to that task of the person who sent it to her? i don't have enough usage data to know. i doubt any of us do because this kind of data will only come through people using it. right now it is speculative: it could be a feature lots of people use fairly frequently, one that is used by a few people lots, or used by lots of people rarely. or by "no one". my concern is that implementing this kind of feature (including Ivan's expansion of it into activity clone-and-reduce) increases the UI load for all users of activities. if it ends up not being a common use case, we'll have degraded the experience. honestly: i really do not think we should be doing much more work on the shell right now. it will likely only make it more complex before we have a strong user base that has learned what we have already (which already comes with some learning curve, but an approachable one right now), and we have tons of things that actually do need doing elsewhere in the user experience. example: i have received _numerous_ requests for shared and/or synchronized activities, based on actual not-made-up use cases. implementing that would be guaranteed to grow out user base. it may not sound as sexy, but it's completely practical and desired and could probably be done without impacting the shell itself. another example: we have recently received a possible entry for ebook reader, and it needs UI love. i already gave the author some feedback and they are currently setting up a repository on git.kde.org for it (previously was hosted elsewhere). -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Workflow and integration
On Friday, March 30, 2012 11:19:32 Lamarque V. Souza wrote: > Em Friday 30 March 2012, Marco Martin escreveu: > > * when a feature is almost ready is merged into integration, people test > > it, fixes are done in the feature branch, then re-merged > > What happened if a feature from on repo depends on a feature from > another repo's integration branch? if you are doing devel, you probably want to be running the integration branch(es). > I use obs to compile packages and test > features here. In my case I would need to hack obs to compile two (or more) > packages whose .tar.bz2 are not in obs. obviously we need to have one of the obs projects tracking the integration branches. it makes no sense otherwise. > more complicated because of the dependencies. People who use Mer SDK would > have the same problem too. no, because they'd be tracking one of: * master * integration * a device specific target > > * when tested enough, it gets merged into master > > * Device specific (Archos, vivaldi, whatever) releases are branches of > > master called like Device/Vivaldi (only a stable state needed? or > > integration/stable for that too?) > > > > This reflects in obs in the following way > > * integration project points to integration branch, (or devel can be > > repurposed to it) > > * testing project points to master: master became a stable branch now > > * Each device specific git branch has an own obs project > > Why use a git branches instead of sub-directories? because these branches need to track the existing code from a "known good" point and stabilize around that. that is precisely what branches are for. > With sub-directories > we can use only one obs project to build all rpm packages for all devices > and minimize the burden of maintaining different copies of the same files. so we'd have a complete copy of all the source code in each subdirectory? and then manually merge diffs between the sub-directories? that makes no sense :) > For instance, we can create a "shared" sub-directory which contains all > configuration files, this has nothing to do with configuration files. this is the code: the shell, the applications, etc. > if a device needs a different configuration file we > create a sub-directory for that device and copy only the files that it > needs. and when changes are made to the original files that are globally applicable? we just copy those changes by hand? how long do we keep those subdirectories? this also ignore the reality that each device target will end up having its own OBS project anyways, so nothing is really to be gained here. > Then we configure the .spec to, during installation phase, copy the > shared directory to the BUILD_ROOT and then override the files there with > the ones from the device's sub-directory. and what about files specific to the device? right: you'll need a different .spec file. and again: this is not about configuration. this is about changes in the source code in plasma-mobile and stabilization for specific device targets. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ 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 --- Comment #2 from Lamarque V. Souza --- I took a look at the kwin-screenlocker.diff patch from kde-workspace package and it is a very intrusive change. We are planning to build a stable image in the next few weeks I think we should postpone porting screenlocker to ksmserver for another time. -- 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
Re: Workflow and integration
Em Friday 30 March 2012, Marco Martin escreveu: > Hi all, Hi, > this is a proposal on how to handle the development in a way where is > easier to assure qa and have device specific images. > > from a short chat with some people it was seen there was a need of > reorganizing a bit how git branches are kept and how this reflects on obs. > I am explaining it now how i understood it, so please correct if wrong ;) > > * Need for a stable, always releasable master > * How to do that? an "integration" branch > * integration is kept always merged, up to date with master > * features are developed in feature only branches > * when a feature is almost ready is merged into integration, people test > it, fixes are done in the feature branch, then re-merged What happened if a feature from on repo depends on a feature from another repo's integration branch? I use obs to compile packages and test features here. In my case I would need to hack obs to compile two (or more) packages whose .tar.bz2 are not in obs. I usually do that for one package, but when I need to do that for two packages at the same time it gets way more complicated because of the dependencies. People who use Mer SDK would have the same problem too. > * when tested enough, it gets merged into master > * Device specific (Archos, vivaldi, whatever) releases are branches of > master called like Device/Vivaldi (only a stable state needed? or > integration/stable for that too?) > > This reflects in obs in the following way > * integration project points to integration branch, (or devel can be > repurposed to it) > * testing project points to master: master became a stable branch now > * Each device specific git branch has an own obs project Why use a git branches instead of sub-directories? With sub-directories we can use only one obs project to build all rpm packages for all devices and minimize the burden of maintaining different copies of the same files. For instance, we can create a "shared" sub-directory which contains all configuration files, if a device needs a different configuration file we create a sub-directory for that device and copy only the files that it needs. Then we configure the .spec to, during installation phase, copy the shared directory to the BUILD_ROOT and then override the files there with the ones from the device's sub-directory. This way we only duplicate the files that needed to be duplicated and not all of them. Moreover we also avoid duplicating several .spec (for each device) that in other way would me almost equal to each other. There is only one problem with that approach, all sub-packages would have the same version, so when doing a change for one device that would trigger a sub-package creation for all other devices and probably an update that is not really needed. As long as the configuration packages are small (and they are for now) I do not see a big problem here. -- Lamarque V. Souza http://www.basyskom.com/ ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Workflow and integration
Marco Hi, Just to throw another axis into the discussion we need to consider Mer core in this workflow as not to end up in the tied to MeeGo 1.2 situation. Mer makes regular releases and also pre releases so vendors can check that the next release won't break their code. Maurice I know has been building against these 'next' Mer releases and this I would say that needs to continue with any change in workflow. >From your proposals from my point of view a place to pull from to build a stable Vivaldi / Archos image would be great and we could get the IMG tool (which runs on the openslx machine) automatically creating stable. images. Talking about the process automation side of things the new proposal means potentially more repos and more activity in SR between them, maybe the BOSS (http://wiki.meego.com/Release_Infrastructure/BOSS) tool can help a bit here, I'm copying in David (lbt) from Mer who has great knowledge in this area of automated release management for products. BR Martin On Fri, Mar 30, 2012 at 1:04 PM, Marco Martin wrote: > Hi all, > > this is a proposal on how to handle the development in a way where is > easier > to assure qa and have device specific images. > > from a short chat with some people it was seen there was a need of > reorganizing a bit how git branches are kept and how this reflects on obs. > I am explaining it now how i understood it, so please correct if wrong ;) > > * Need for a stable, always releasable master > * How to do that? an "integration" branch > * integration is kept always merged, up to date with master > * features are developed in feature only branches > * when a feature is almost ready is merged into integration, people test > it, > fixes are done in the feature branch, then re-merged > * when tested enough, it gets merged into master > * Device specific (Archos, vivaldi, whatever) releases are branches of > master > called like Device/Vivaldi (only a stable state needed? or > integration/stable > for that too?) > > This reflects in obs in the following way > * integration project points to integration branch, (or devel can be > repurposed to it) > * testing project points to master: master became a stable branch now > * Each device specific git branch has an own obs project > > this is just an idea, please comment ;) > in the end a good final workflow document will need to be in place > > Cheers, > Marco Martin > ___ > Active mailing list > Active@kde.org > https://mail.kde.org/mailman/listinfo/active > ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Workflow and integration
Hi all, this is a proposal on how to handle the development in a way where is easier to assure qa and have device specific images. from a short chat with some people it was seen there was a need of reorganizing a bit how git branches are kept and how this reflects on obs. I am explaining it now how i understood it, so please correct if wrong ;) * Need for a stable, always releasable master * How to do that? an "integration" branch * integration is kept always merged, up to date with master * features are developed in feature only branches * when a feature is almost ready is merged into integration, people test it, fixes are done in the feature branch, then re-merged * when tested enough, it gets merged into master * Device specific (Archos, vivaldi, whatever) releases are branches of master called like Device/Vivaldi (only a stable state needed? or integration/stable for that too?) This reflects in obs in the following way * integration project points to integration branch, (or devel can be repurposed to it) * testing project points to master: master became a stable branch now * Each device specific git branch has an own obs project this is just an idea, please comment ;) in the end a good final workflow document will need to be in place Cheers, Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Creating pre-filled Activities
Hi, That was one of the ideas we talked about at bds, and it should be done in the long run. Not only for "last 1 hour", but also to extract a sub-activity into a new one. Cheerio, Ivan p.s. Not to dive into technical discussion now, as this is about UI, but this feature will not be useful now that we have 2 and a half applications reporting which documents they open. -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: PA OpenEmbedded support (WIP)
Em Friday 30 March 2012, Samuel Stirtzel escreveu: > Hi, Hi, > lately I have good progress on my work, normal KDE applications seem > to work fine in OpenEmbedded. > But my main goal, to port PA, still needs some effort. > > Currently I'm at the point that the home screen of PA shows up, > but it seems like something went wrong with the declarative scriptengine. > > So there is a big sign with a "X" as label showing the text: > "Could not create a declarativeappletscript sctiptengine" Enable all debug messages using kdebugdialog program (if possible), restart the graphical interface, try again and send me the ~/.xsession-errors file. > Under /usr/lib/kde4 there are these (relevant?) libraries found: > - > plasma_appletscriptengine_dashboard.so > plasma_runnerscript_javascript.so > plasma_dataenginescript_javascript.so > plasma_appletscript_simple_javascript.so > plasma_appletscriptengine_webapplet.so > plasma_appletscript_declarative.so > - Are you using KDE SC 4.8.0 as I told you? > The Qt and kde libs are at /usr/lib: > - > libQtDeclarative.so.4.8.0 > libkdeclarative.so.5 > libQtDeclarative.so.4.8 > libQtDeclarative.so.4 > libkdeclarative.so.5.8.0 > - > > > So I assume that some library like > "plasma_appletscriptengine_declarative.so" is missing. > But kde-runtime logs don't indicate something like that. Probably you are using the wrong version of the libraries or something else is missing. For exampe, this week a guy tried to install PA on OpenSuse 12.1 and it only succeeded when he installed share-like-connect pacakge. Do you have share-like-connect installed? -- Lamarque V. Souza http://www.basyskom.com/ ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Creating pre-filled Activities
Hi all, since it has become relevant to the discussion about the "Edit Activities" dialog, I will now present an idea that Fania, Thorsten Prante from Zeitgeist and me had at the last PA sprint. The idea is to allow the user to create a new Activity based on what he's actually working on at the moment. The scenario is as follows (this is still work in progress and subject to change, but this is roughly the direction we're heading): Anne receives an email asking her to prepare a presentation for a meeting on very short notice. Since she doesn't have much time, she dives right into work without remembering to create an Activity for the task. Anne does research on the web, opens webpages, source documents, other e-mails etc. Then at some point Anne realizes that all the resources she uses for her task call for their own Activity. She pulls out the Activity Switcher and taps "Add Activity". A wizard pops up, presenting her with a choice between an empty Activity and one pre-filled with the resources relevant to her current context. She chooses to crate a pre-filled activity. Next, she chooses the last hour as the time-frame of her current context. In the next step, Anne chooses a name and wallpaper for her new Activity and finishes the Activity creation. A new Activity is created, containing all the resources she has worked with during the last hour. This process of choosing between empty and pre-filled Activity and adjusting the time-frame (we might even offer different sets of resources, e.g. some based on time and others based on location or semantic connections) is something that is only done during Activity creation, not when editing an Activity later. Therefore the two processes differ if want to offer users the benefit of Recommendation during Activity creation. I hope this explains why Fania is pushing for a wizard to create an Activity. Yes, this does make the Activity creation process a bit slower, but having an Activity which already contains relevant resources right form the start instead of having to manually connect them all should more than compensate for that. Cheers, Thomas ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: activity configuration UI
On Friday 30 March 2012, Thomas Pfeiffer wrote: > On 30.03.2012 10:53, Marco Martin wrote: > >> however, if we do want to keep the "close" button and if we put buttons > >> int he title bar, it could be drawn exactly as we do the "close" button > >> on plasmoids. > > I think we should just make a decision now. > Personally, I tend towards "Either both buttons or none" to clearly > separate the two different kinds of "dialogs", and I think that in > addition to the presence or absence of buttons we should offer other > visual distinctions so that the user immediately knows if this is a dialog > where she has to tap "Save" or not. But that is more of a personal > preference. I don't have a problem with abolishing the close/cancel > buttons altogether, so if the majority is for that, I won't object. yeah, i would also be for none if also save can be avoided, both otherwise, this both for sheets and for dialogs > entry was made on a screen with multiple input fields. What I don't want > to see is a form with multiple input fields each popping up its own error > balloon because the user has made several problematic entries and they are > all validated at the same point. If that doesn't happen, I'm totally fine > with the balloons. i think should be used if is something that can be verified "as you type" , so the problem wouldn't occur, this wouldn't work together a bulk of verify input fields as you type -- Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: activity configuration UI
On 30.03.2012 10:53, Marco Martin wrote: however, if we do want to keep the "close" button and if we put buttons int he title bar, it could be drawn exactly as we do the "close" button on plasmoids. I think we should just make a decision now. Personally, I tend towards "Either both buttons or none" to clearly separate the two different kinds of "dialogs", and I think that in addition to the presence or absence of buttons we should offer other visual distinctions so that the user immediately knows if this is a dialog where she has to tap "Save" or not. But that is more of a personal preference. I don't have a problem with abolishing the close/cancel buttons altogether, so if the majority is for that, I won't object. yeah, that's an idea as well would basically look like a tooltip? basically, yes, but with a "pointer" pointing to the element in question. bad ascci art [ Already Taken ] ^ |=/ \===| | | Error mesage | | |=| | in this case could be tap over to dimiss if cover something the user doesn't want yes, that would work ... i did an experiment with a baloon tip for dialogs at a certain point. it was abandoned because was quite difficult to be used in Plasma::Dialog but the graphics is still there (well, almost impossible due to the requirement of window mask in non composited case ;) if we stay with something just on-canvas in this case there would be no problem tough I like that, since it generally spares us having to allocate space for possible error messages in every UI where there might be any. However, this only works if we can check for errors immediately after each entry was made on a screen with multiple input fields. What I don't want to see is a form with multiple input fields each popping up its own error balloon because the user has made several problematic entries and they are all validated at the same point. If that doesn't happen, I'm totally fine with the balloons. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: Merging plasmaextracomponents branch
On Friday 30 March 2012, Sebastian Kügler wrote: > > In the sebas/plasmacomponents branch, those have all been ported, requiring > kde-runtime master. I've not noticed any problems with the branch, so I'd > like to merge it this weekend. > > Cheers, I propose this: plasma-mobile master gets branched now to some stable branch, obs goes to that one until needed then master can be broken again ;) -- Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: share-like-connect icons
On 30.03.2012 10:45, Marco Martin wrote: On Friday 30 March 2012, Aaron J. Seigo wrote: On Thursday, March 29, 2012 21:52:11 Marco Martin wrote: Hi all, since nothing moved yet, i gave it a go, nice; a 100%+ improvement over the current ones. they are used now, with an update of slc repo and kde-runtime they should appear Great! I would have wished that Sam helped us here so you didn't have to do everything by yourself, but if you're the only person with visual design skills we can count on and since your results are always very good, so be it ;) I'm looking forward to seeing the icons arrive on my tablet :) ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: activity configuration UI
On Friday 30 March 2012, Aaron J. Seigo wrote: > On Friday, March 30, 2012 10:17:15 Marco Martin wrote: > > On Friday 30 March 2012, Aaron J. Seigo wrote: > > > the buttons in the title do work, indeed... i wonder if they make more > > > sense on the same side of the dialog together, but that's something i > > > can experiment with easily enough on my own, though if we do buttons > > > up there we need to get some agreed on UI standard for it. > > > > i think if there are two and on opposite sides looks more balanced and > > thumb friendly > > yes, for two buttons .. i'm just wondering if that translates to other > dialogs which may have more or fewer buttons and which should be > consistent with these dialogs. yep, this at the moment is just for the Sheet component, Dialog is still as it was a problem of putting buttons there for normal dialogs is that they may get quite small so they could be too narrow for title+ a row of buttons > > > and then if we move to the "tap outside to close without saving" as per > > > Sebas' suggestion we get down to one button anyways and that's all a > > > moot point. > > > > that is already done, this is another old topic do we need a close button > > in every dialog because is discoverable or try not having them that is > > not obvious, but becomes easy once trained > > i like the the idea of less buttons. > > however, if we do want to keep the "close" button and if we put buttons int > he title bar, it could be drawn exactly as we do the "close" button on > plasmoids. yeah, that's an idea as well > > would basically look like a tooltip? > > basically, yes, but with a "pointer" pointing to the element in question. > bad ascci art > > [ Already Taken ] > ^ > |=/ \===| > | > | Error mesage | > | > |=| > | > > in this case could be tap over to dimiss if cover something the user > > doesn't want > > yes, that would work ... i did an experiment with a baloon tip for dialogs at a certain point. it was abandoned because was quite difficult to be used in Plasma::Dialog but the graphics is still there (well, almost impossible due to the requirement of window mask in non composited case ;) if we stay with something just on-canvas in this case there would be no problem tough -- Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: activity configuration UI
On Friday, March 30, 2012 09:58:48 Fania Bremmer wrote: > While doing a concept for this toggle, I also came across this Privacy > Settings Slider: > http://dribbble.com/shots/415967-Privacy-Settings?list=popular&offset=28 > Do you mean something like this? Would it work without labeling it at all? interesting approach ... i just tried it on a house guest (not scientific or enough testing at all, really ;) and they got it immediately. i actually quite like it, but it would need reasonable artwork to work well. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: share-like-connect icons
On Friday 30 March 2012, Aaron J. Seigo wrote: > On Thursday, March 29, 2012 21:52:11 Marco Martin wrote: > > Hi all, > > since nothing moved yet, i gave it a go, > > nice; a 100%+ improvement over the current ones. they are used now, with an update of slc repo and kde-runtime they should appear -- Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: activity configuration UI
On Friday, March 30, 2012 10:17:15 Marco Martin wrote: > On Friday 30 March 2012, Aaron J. Seigo wrote: > > the buttons in the title do work, indeed... i wonder if they make more > > sense on the same side of the dialog together, but that's something i can > > experiment with easily enough on my own, though if we do buttons up there > > we need to get some agreed on UI standard for it. > > i think if there are two and on opposite sides looks more balanced and thumb > friendly yes, for two buttons .. i'm just wondering if that translates to other dialogs which may have more or fewer buttons and which should be consistent with these dialogs. > > and then if we move to the "tap outside to close without saving" as per > > Sebas' suggestion we get down to one button anyways and that's all a moot > > point. > > that is already done, this is another old topic do we need a close button in > every dialog because is discoverable or try not having them that is not > obvious, but becomes easy once trained i like the the idea of less buttons. however, if we do want to keep the "close" button and if we put buttons int he title bar, it could be drawn exactly as we do the "close" button on plasmoids. > would basically look like a tooltip? basically, yes, but with a "pointer" pointing to the element in question. bad ascci art [ Already Taken ] ^ |=/ \===| | Error mesage | |=| > in this case could be tap over to dimiss if cover something the user doesn't > want yes, that would work ... -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: activity configuration UI
On 30.03.2012 00:32, Aaron J. Seigo wrote: my concern is that this takes too much time to set up an activity and that it also would deviate from the "configure activity" UI. We actually wanted to come up with a more comprehensive concept before presenting it to the list, but in order to make the benefits of an activity creation wizard clear at this point, it looks like I have to explain our ideas a bit. To prevent pushing another discussion into this already overcrowded thread, however, I will present the ideas in a new thread called "Creating pre-filled Activities". See you on that thread ;) Thomas ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: activity configuration UI
On 30.03.2012 10:19, Marco Martin wrote: that one would be better i think. one like the example in scribus always confuses me, because i never know if the open locker means unlocked now or click to unlock +1. Although it doesn't really matter whether there is people or an open padlock on the left side, as long as there are different icons on both sides of the switch. I also often have the problem Marco mentioned of current state vs. action. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: PA OpenEmbedded support (WIP)
2012/3/6 Lamarque V. Souza : > Em Tuesday 06 March 2012, Samuel Stirtzel escreveu: > >> 2012/3/6 Lamarque V. Souza : > >> > Em Tuesday 06 March 2012, Samuel Stirtzel escreveu: > >> >> Hi, > >> > > >> > Hi, > >> > > >> >> after some work plasma active builds for me now, although it needs some > >> >> > >> >> tweaks. Now it comes to the most interesting part, doing run-tests. > >> >> > >> >> After flashing the SD card of the machine and booting up, the tension > >> >> > >> >> raises, but it seems like there is something missing. > >> >> > >> >> > >> >> > >> >> While running "xinit /usr/bin/startactive" shows the splash screen, > >> >> > >> >> some time later it disappears and all that is left on the screen is > >> >> > >> >> the default X mouse pointer. > >> >> > >> >> The startactive log file: http://pastebin.com/KSijm8MS > >> >> > >> >> > >> >> > >> >> Any ideas what is missing? > >> > > >> > startactive is trying to launch kstartupconfig4. The startactive module > >> > for that executable was removed from the development version of Plasma > >> > Active image, it is still present in Plasma Active 2 image though. Are > >> > you using startactive package from PA2? Do you have > >> > /usr/bin/kstartupconfig4 installed? > >> > >> Hi, > > > > Hi, > > > >> kstartupconfig4 is not installed on the machine. > >> Yes the version used was from the git tag Active 2.0 release, > >> kde-workspace has version v4.7.4. > > > > kstartupconfig4 comes from kde-workspace package. > Did you compile kde-workspace from source? By the way, PA2 uses > kde-workspace master, not 4.7.4. The version 4.7.4+git* means 4.7.4 with > commits from master applied. If you are compiling kde-workspace from source > you should use 4.8.0 instead, which was the master version when PA2 was > built. > >> Has/had startactive a runtime dependency to kde-workspace? Seems like > >> kde-workspace was not picked up at the root filesystem creation. > >> The next step seems to be Contour, is there a file where the startup > >> sequences and the needed files / packages are listed? > > > > startactive is a replacement for startkde, the script that kde-workspace > uses to start a KDE session. So yes, startactive is a runtime dependency for > kde-workspace used in Plasma Active. The startup sequency is defined by the > dependencies defined in startactive's modules in > /usr/share/kde4/apps/startactive/modules/. But changing the order is not > trivial, you must correctly fullfill the depencies and not cause ciclic > dependencies or you will cause a dead-lock in startactive. The current order > works as long as you have all programs listed in the exec line in > /usr/share/kde4/apps/startactive/modules/*.modules installed. > > > > -- > > Lamarque V. Souza > > http://www.basyskom.com/ Hi, lately I have good progress on my work, normal KDE applications seem to work fine in OpenEmbedded. But my main goal, to port PA, still needs some effort. Currently I'm at the point that the home screen of PA shows up, but it seems like something went wrong with the declarative scriptengine. So there is a big sign with a "X" as label showing the text: "Could not create a declarativeappletscript sctiptengine" Under /usr/lib/kde4 there are these (relevant?) libraries found: - plasma_appletscriptengine_dashboard.so plasma_runnerscript_javascript.so plasma_dataenginescript_javascript.so plasma_appletscript_simple_javascript.so plasma_appletscriptengine_webapplet.so plasma_appletscript_declarative.so - The Qt and kde libs are at /usr/lib: - libQtDeclarative.so.4.8.0 libkdeclarative.so.5 libQtDeclarative.so.4.8 libQtDeclarative.so.4 libkdeclarative.so.5.8.0 - So I assume that some library like "plasma_appletscriptengine_declarative.so" is missing. But kde-runtime logs don't indicate something like that. Could anyone please point me in the right direction? -- Regards Samuel ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
[Bug 296943] copy/paste feature is great, but are the icons intuitive?
https://bugs.kde.org/show_bug.cgi?id=296943 Sebastian Kügler changed: What|Removed |Added CC||se...@kde.org --- Comment #2 from Sebastian Kügler --- It only works with the PlasmaComponents.Text* classes. The addressbar in the webbrowser, for example, and the text entries in the news app. -- 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
Re: activity configuration UI
On Friday 30 March 2012, Fania Bremmer wrote: > > "lock as private" sounds awkward. How about a slider with (or as) an > > unlock/lock icon and "private" to the the appropriate side of the > > slider, similar to layers in Inkscape or objects in Scribus. > > (Especially on small screens, the Inkscape method is not as good). > > Maybe "make private" with lock/unlock icon? Or is it possible to make > > the slider look like a lock instead of a rounded rectangle? Scribus > > icons attached. > > While doing a concept for this toggle, I also came across this Privacy > Settings Slider: > http://dribbble.com/shots/415967-Privacy-Settings?list=popular&offset=28 > Do you mean something like this? Would it work without labeling it at all? that one would be better i think. one like the example in scribus always confuses me, because i never know if the open locker means unlocked now or click to unlock -- Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: activity configuration UI
On Friday 30 March 2012, Aaron J. Seigo wrote: > > the buttons in the title do work, indeed... i wonder if they make more > sense on the same side of the dialog together, but that's something i can > experiment with easily enough on my own, though if we do buttons up there > we need to get some agreed on UI standard for it. i think if there are two and on opposite sides looks more balanced and thumb friendly > with two buttons it is nice and ballanced; with more or less it probably > doesn't matter so much. > > with buttons on both sides then we need ot decide which kinds of buttons go > where, which is not always a completely clear thing ... though at least on > the tablet the UI we tend not to have many buttons (thankfully) > > and then if we move to the "tap outside to close without saving" as per > Sebas' suggestion we get down to one button anyways and that's all a moot > point. that is already done, this is another old topic do we need a close button in every dialog because is discoverable or try not having them that is not obvious, but becomes easy once trained > i like how it _really_ frees up room for the content and now moving the > "lock as private" item to the top starts to make even more sense. > > as for the error message when the name is already taken, i have been > thinking about this in context of other areas we face the same problem. > > something that occured to me as a possibility is that we could have a > "balloon" that contains the error and points at the field (in this case the > name text edit) with the error. this would move the error outside the fixed > layout. the downside is that such messages could occlude other content > undesirably ... but looking at various places this would/could get used it > doesn't seem to be a real problem. what do our UI people think? would basically look like a tooltip? in this case could be tap over to dimiss if cover something the user doesn't want -- Marco Martin ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: share-like-connect icons
On Friday, March 30, 2012 00:06:27 Aaron J. Seigo wrote: > On Thursday, March 29, 2012 21:52:11 Marco Martin wrote: > > Hi all, > > since nothing moved yet, i gave it a go, > > nice; a 100%+ improvement over the current ones. Indeed, very nice work! :) -- 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: activity configuration UI
Hi,
Am 28.03.2012 18:03, schrieb Carl Symons:
On Wed, Mar 28, 2012 at 5:11 AM, Fania Bremmer
wrote:
Hi,
Am 28.03.2012 13:17, schrieb Aaron J. Seigo:
hi everyone.
please take a look at the attached screenshot of the activity
configuration.
(ignore the rendering issue with the selected wallpaper.) on smaller
resolution screens this is what it looks like; with icon settings tweaked
for
lower resolutions we get two rows of wallpapers and things look a bit
better
but i think it is clear that there is room for improvement.
Generally, I like the idea of sparsity, especially on the small
screen. Not a bunch of extra images and words. An interface where
people's first interaction is "That's cool" or "Clever". Where after a
few operations, there is no more thinking involved...the interface
fades into the background of thinking.
This function seems to be already more explicit than the Activity
Spinner or Recommendations where there is just a peeking handle just
waiting to be tugged on. Yet with a new person, one time is all it
takes and they no longer think about it.
a quick anatomy of that window, moving vertically:
* a titlebar
* a text edit
* content
* a toggle button
* control buttons
it would be nice to limit the number of vertical pixels used so that
content
space is maximized. it would also be nice to eliminate redundant and
obvious
text. as such, here is a set of proposals which i will implement if there
are
no objections:
* change title to "Activity Settings" ("settings" being less "tech" than
"configuration" and shorter, at least in english; use title
capitalization)
+1. I would even prefer a title that integrates a verb, like "edit
activity". But that's a wording question. I guess we use more often nouns
than verbs... if we decide for one, we should apply it everywhere.
I like "Edit Activity". Verb+predicate makes sense. The user arrived
at this screen to do something.
* change "Activity name:" to just "Name:". that it is an Activity is
implied,
and is redundant with the title directly above it. the name also appears
right
next to the buttons on the activity view so there is an evident corelation
+1. Maybe even write the label into the text field until the user enters the
first key? So we would save even more space.
+1. "Activity" is redundant. Label in the text field implies sparsity.
* move "Lock as private" next to the Name entry. this eliminates an entire
row
from the vertical space usage and puts all of the controls in one place
We moved it from up there to the very bottom, because it implicates a second
page with the setting of the password. To link this clearly in the user
interaction flow, we decided to put it directly on top of the buttons, to
show with the changing button label that one more step needs to be done, to
have a final private activity.
* change "Lock as private" to just "Private". the phrase "Lock as private"
is
a bit awkward (it is not a natural phrasing one would use in conversation)
and
specifying "Lock" speaks to the mechanism rather than the intention of the
user. the intention is "this is private"; the mechanism we use is "locking
it".
Before integrating this phrase we tested with a lot of people. We tested
different words and phrases like "protect, lock, mark...as private, secure"
etc. The result has beenthat most people preferred and understood the
phrase "lock as private". Here both results, the locking of the activity
with a password AND the encryption of the private data, have been
understood.
Only "Private" would not clearly communicate the underlying action for the
user.
"lock as private" sounds awkward. How about a slider with (or as) an
unlock/lock icon and "private" to the the appropriate side of the
slider, similar to layers in Inkscape or objects in Scribus.
(Especially on small screens, the Inkscape method is not as good).
Maybe "make private" with lock/unlock icon? Or is it possible to make
the slider look like a lock instead of a rounded rectangle? Scribus
icons attached.
While doing a concept for this toggle, I also came across this Privacy
Settings Slider:
http://dribbble.com/shots/415967-Privacy-Settings?list=popular&offset=28
Do you mean something like this? Would it work without labeling it at all?
one further thing i'd like to experiment with is moving the save/close
buttons
into the title bar. some other mobile OSes do this and it would accomplish
two
things: better use of screen real estate, make it more obvious to people
where
these buttons are. people often do not find the buttons at the bottom;
i've
watched dozens of people go through the UI and this is a recurring issue.
+1, also because the buttons are often covered by the virtual keyboard. But
if we move buttons up in the title bar, we should check that we make this is
a general UI guidelines and have it consistently in the system
on thing that would make this harder is that currently when marking an
activity as "private" the label on the Save but
