Re: Plasma Active 3 and Spark OS
On Saturday, February 25, 2012 16:09:45 Sascha Manns wrote: > Will be any differences between the standard PA and Spark's OS? we're really trying not to have differences. any work we do on PA (or other software) is being done upstream. that's really the whole point of the project: to get PA onto devices, and to also help bootstrap the development around it. the more divergence there is, the harder it is to achieve those goals. right now i think we'll carry a patch for the capabilities dataengine to reflect the hardware available, unless i find time (or someone does, doesn't have to be :) to make it flexible enough to e.g. read at least some settings off of a config file (which would be nice anyways as it would make testing against different hardware configurations easier) -- 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: Can Plasma Active run on ARM Tablets?
On Saturday, March 3, 2012 13:50:55 Phoenix Nemo wrote: > But I found nothing about android on the wiki.How should I do with it? Plasma Active does not run on top of Android; rather it provides a whole Linux OS, one that is much more "vanilla" than Android. this does mean, however, that you need to flash the device .. which in turn means an unlocked bootloader. once that is done, one needs the appropriate kernel for the device. i see that it is a Rockhip 2918. i don't believe anyone has done that CPU yet, but if you have access to the kernel sources (e.g. for Android) then you can use that to bring up the system. this part is handled by the Mer OS stack which Plasma Active runs on top of (among other Linux OSes) -- 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: Plasma Active SDK Notes
On Friday, March 9, 2012 18:02:18 Aleix Pol wrote: > As I said on the "workout", having a device image is good for having an > overview of what the end result looks like, but I don't really think that > this is going to scale: have you looked at how people develop for other device platforms? the nice thing about a VM approach is that we can: * provide ready-to-go-images in different configurations so you can easily test your app with different screen sizes, version of PA, etc. * people can develop on their rather more powerful laptops what doesn't work with the VM approach: * multitouch * actual hands-on-feel testing my experience thus far with development has been that one does 95%+ of development on a local, non-device system just fine and then final testing and validation can be done on the device. by that point you should know that your code builds and works (making OBS failures a non-issue) and that the interaction is generally in place.] ultimately, having a "in the can" build env that builds your app and sends it (over USB? network?) to the device directly would be terrific ... but i'll (and i imagine others) will still use that for near-completion-testing and not for general development cycles which tend to benefit from being as quick as possible .. something that it is hard to beat a on-dev-system-VM for. also, i'd suggest that if you are building IN the VM ... something is pretty drastically wrong. ditto for multiple snapshots of the same code, which makes no sense whatsoever; maybe different build directories but not src snapshots. you should be building outside the VM against the OS target þat the VM runs and this should be a stock configuration we distribute. if your concerns are driven by the limitations of open source VMs, despite not being open vmWare makes this a generaly moot point. -- Aaron 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: Plasma Active App Store Notes
l be > hard to change certain issues, and can slow down the process as a > result of losing some potential participants. i appreciate your concerns. i don't agree, however, with your conclusions :) note that in future, we will (if successful) innevitably work with various companies who will quietly work on projects and only release them once they are confident that the intended product will ship. it would be nice to make this a welcoming place for such efforts, one that appreciates gifts of Free software, rather than one that criticizes when something is shared. -- 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: Plasma Active 3 Sprint - KDE Edu Notes
On Monday, March 12, 2012 01:27:17 Laszlo Papp wrote: > dependencies will also be simpler for the Plasma Active App Store than > Ovi hopefully because we do not hopefully need to bundle the > dependencies up with our packages. that is correct :) > Then there were general realizations about not having enough manpower > in the project (there are nowadays more and more platforms to port > to), and it would be nice to improve the collaboration with teachers > and students as well in the future. i think having devices with Plasma Active on it will help a lot in this regard. as it becomes a "real product" more people are paying attention to it. > Another smaller, but very important topic to me is that it would be > nice to get a qml frontend for the khns and get hot new stuff > functionality. Unfortunately, it is not a big enough task for a GSoC > student in my opinion, and I have already put many ideas about Gluon > in there, thus it is not gonna happen as part of that session. i think that "done right" it is a more significant proposition than one might consider at first. what would be very nice is to have a general "show the add-ons interface" QML component that make it easy to integrate with the platform. GHNS is just one possible target, while other platform may have specific requirements that differ. imho GHNS is a "KDE desktop platform" component and, as can be seen with things like Ovi or Bodega for our tablet, may not translate well to other device experiences. i do not think this makes sense to expose in the khns library, but rather it would make sense to have a QML component with a reference implementation that uses KHNS but which can be easily swapped out on-device for a different provision mechanism. note that one important / useful feature which khns currently lacks afaics is the ability to define a developer account so that in-app purchases can be associated with a proper developer. additionally, getting a touch UI that works really well is not perhaps as trivial as it may seem at first. the desktop ghns window is not really directly translatable as it is very mouse and keyboard centric. for the average skill level of a gsoc student (at least IME) getting that UI to "good" could easily take a month of effort. > == Implementation side == > > === Packaging > 1) libkdeedu > 2) analitza > 3) kalgebra > 4) kanagram > 5) khangman > > See my private repository on the Community OBS for details (things are > there pretty much the results of this event): > https://build.pub.meego.com/project/packages?project=home%3Adjszapi%3AKDE-De > vel coool... btw, a couple people asked specifically about KDE Edu availability for Plasma Active at CeBIT. there is interest! > 1) Kanagram now has a plasma active subfolder with the initial steps > (metadata desktop file, ui contents, kdeclaratiview, etc). Ui needs to > be developed (qml files will be added into the package/contents/ui > folder), but the proper structure is already in place. > > 2) KHangMan has the same establishment, plus I decoupled the "engine" > and the harmattan relevant code, so the engine I established for > Harmattan is reusable for the Plasma Active frontend in the future. > Same thing as with kanagram, ui needs to be developed, thus not much > happened on that front. as soon as this is "demo-able" we should definitely blog about it and perhaps even use it as an example in a tutorial on Techbase for how to make an app ready for Plasma Active and / or touch in general (in addition to the existing desktop UI, e.g.) -- 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: Plasma Active App Store Notes
On Thursday, March 15, 2012 23:25:48 you wrote: > > i appreciate your concerns. i don't agree, however, with your conclusions > > :) > I agree with you about this point. From the blog post that Shantanu > pasted above, it seems to me you dislike certain things about > opendesktop.org. if i want to bake bread, i'll use an oven. not a hammer or a blender. an oven. i like hammers. and blenders. but when baking bread, they aren't useful. when making synchrotron, opendesktop.org simply could not do what was needed. and other than the non-free implementation, none of the actual issues are fixable. it is a hammer when i needed an oven. so no, it has nothing to do with liking or disliking, but realizing the appropriateness of a tool. the same is true for OCS and our add-ons app. OCS needs a _lot_ of work before we could use it, and even then it would be at best a partial fit. we don't have the time to wait for that to happen nor the resources (time or otherwise) to involve ourselves in such a larger project where we need to discuss features and inclusion with a larger group that does not share our needs. we need something that does precisely what we need it to, not a compromise solution, which is an understandable limitation when something is used by many different parties. if OCS2 becomes something amazingly great, we'll consider adopting it. as it stands, OCS contains mostly features we do not need, misses features we do and the features that are of interest are not usefully implemented for us. you yourself note this with things such as the json API; i'm happy for OCS that you are looking at improving these things, but that doesn't make the json API (or other requirements) a reality right now. that's simply how it is and we do not have the resources to fix OCS. please keep in mind that OCS is relevant to the most minor aspects of our project, and so having to invest resources in improving it when the item listing protocol is a tiny part of the overall design just doesn't make sense here. compare that with the benefits we'd gain from using OCS, which is essentially zero for us, and the math is very simple. you may disagree with our decision and that's fine. i don't want to polute this list with more of this discussion, so this will be my last email in this thread. if there is something substantial to discuss, you can find me 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
[Bug 296223] Latest update destroyed all my settings
https://bugs.kde.org/show_bug.cgi?id=296223 Aaron J. Seigo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DOWNSTREAM --- Comment #3 from Aaron J. Seigo --- wrong product (this is nothing to do with Plasma Active) and is a downstream packaging issue. -- 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 296223] Latest update destroyed all my settings
https://bugs.kde.org/show_bug.cgi?id=296223 Aaron J. Seigo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DOWNSTREAM --- Comment #5 from Aaron J. Seigo --- please do not re-open reports that have been triaged. thank you. i read your report and took an appropriate action for the report. p.s. while we appreciate bug reports and other such feedback from our users, the initial comment was not in line with our expectations from each other in our community. please check out the KDE code of conduct as that records our expectations quite clearly. thanks :) http://www.kde.org/code-of-conduct/ -- 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: end of proof-of-concept on imx53qsb video
On Sunday, March 18, 2012 21:51:37 Simonas L. wrote: > Dear all, > > Here is the last outcome of the proof-of-concept on KDE PA2 on Freescale > i.MX53 QSB: > http://www.youtube.com/watch?v=8kbQU6n8Zkw neat :) i have seen better performance on similarly (and worse) spec'd ARM devices, however, so i'm wondering what might be causing some of the issues seen in the video. one thing i did notice was when creating a new activity there were graphical glitches that look to be driver related? there are also visible artifacts on e.g. the panel shadow which is rendered as a black block or when applications are started (similar atrifact as when creating an activity). it's a very interesting start, but sorting out which problems are at the OS layer and which are due to PA itself would be very helpful to knowing where we need to focus attention (as we can improve the latter, but do less about the former) > GLES HW accel is in effect, you can see a significant improvement, but the > responsiveness is still not real time. keep in mind that the shell itself is still using QML1 which does not have the full opengl rendering system that QML2 does. i suspect (based on playing with it :) that when we switch to QML2, we'll see a much more useful and visible jump in performance with GLES accel HW. one more reason to push forward to Qt5 -- 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 296371] RFC: Make connecting to / disconnecting from current Activity via SLC easier
https://bugs.kde.org/show_bug.cgi?id=296371 --- Comment #1 from Aaron J. Seigo --- "Fania and I agree that this is a too long sequence for that common action." how long is too long? or rather, how short is quick enough? "Move the "Current Activity" menu entry to the top level" this implies that the point of "connect" is really "connect to activity", which is incorrect conceptually (despite the current implementation having only one implemented target: activities) "because connecting to / disconnecting from the current activity is much more common than connecting to other activities." that is not enough. what is the relative value of connecting to other activities? what about when there are other items in "connect" besides "activity"? what happens to the thought process when a choice about activity is presented before the person expresses that they wish to act on an activity? this is probably rather harder to grasp than it should be because connect only has one entry right now (to activity). -- You are receiving this mail because: You are on the CC list for the bug. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
proposal: new repository for configuration data
hi.. right now we have in the plasma-mobile repository a config/ subdirectory. these files need customization for various OS and device targets. they also, however, share common settings. plasmarc, for instance, will have common settings for many (most? all?) plasma active builds, but also contain specializations for different targets. carrying patches for those differentiations is not optimal, particularly as you are going to want to keep them revisioned anyways. one possible answer is "make a branch for the device in plasma-mobile", but this starts to make it tempting to make all sorts of target-specific changes in the code which is almost always not what we want. so i created a new repository that only contains the config files and given them some structure. i've also added a couple of branches to show what sorts of things are possible, such as including xorg config. (both branches are actually real-world useful as well :) you can get it with: git clone kde:scratch/aseigo/plasma-mobile-config it has all the history of plasma-mobile/config, of course. if there is consensus on this, then i'd like to move this repository alongside plasma- mobile and remove the config/ dir from the plasma-mobile repository. -- 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: Plasma active testers needed
On Thursday, March 22, 2012 12:08:07 Ivan ÄukiÄ wrote: > Please read the whole e-mail :) i did and failed to read the most important bit: what you are looking for :) if you can share that bit of info, you may have more success in finding participants... -- 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: Starting with Plasma Active development
On Thursday, March 22, 2012 13:34:14 Osmo Antero wrote: > This PPA seems to provide these executables there should also be a plasma-device that gives you the tablet UI > I this the right way to start with the coding of plasma widgets? it's one way :) many of us test our plasmoids in plasmoidviewer (ships with kde-workspace, which also includes KDE Plasma Desktop) > >From the documentation I understand that Plasma Active Widgets are written > > with Javascript and QT/QML. that's where we put our focus these days, yes. in some cases, C++ is necessary to expose certain system features, often through DataEngines. > Can you give me your comments and it would be nice to have some easy > Javascript-examples with QML files. the KDE Examples repository contains a number of examples: https://projects.kde.org/projects/kde/kdeexamples/repository and there are some tutorials as well on Techbase http://techbase.kde.org/Development/Tutorials/Plasma and API docs for the QML extensions and components: http://techbase.kde.org/Development/Tutorials/Plasma/QML/API http://api.kde.org/4.x-api/plasma-qml-apidocs/ if you have any specific questions as you go, feel free to ask them here or on irc.freenode.net in #plasma or #active ... cheers :) -- 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
[REVIEW]: plasma-mobile repositories
hi everyone ... the repositories holding the Plasma Active code have been moved into kdereview as plasma-mobile and plasma-mobile-config so as to go through the usual 2 week review period before moving to their permanent home. if there are any question or queries, input or feedback, please don't hesitate :) -- 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: proposal: new repository for configuration data
On Tuesday, March 20, 2012 18:19:07 Aaron J. Seigo wrote: > git clone kde:scratch/aseigo/plasma-mobile-config this has been moved into review and is available with a `git clone kde:plasma- mobile-config` now. as soon as all our packages are updated for image builds so that nothing relies on the config/ dir plasma-mobile (packages: please let me know when that is) then i will remove the config dir from plasma-mobile. cheers :) -- 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: [REVIEW]: plasma-mobile repositories
On Monday, March 26, 2012 20:43:29 Albert Astals Cid wrote: > Lamarque says plasma-mobile-config is still Work In Progress stuff. Please plasma-mobile-config is the exact same content as in plasma-mobile/config. it is broken out into its own repository so that: * per-device branches for configuration can be easily maintained * a build system (or rather, install system since nothing is actually built) can be put in place without hosing people's systems (which would be the case if a build system was added to plasma-mobile/config and then built on/for e.g. a desktop system) as Lamarque replied, it's only a WIP in that none of our device images use it yet. that's also why there is still plasma-mobile/config. as soon our OBS projects shift from using plasma-mobile/config (it gets put into its own tarball and package already) to the plasma-mobile-config repo then plasma- mobile/config will go away. so .. no, i won't move it to playground because it is not playground material. cheers ... -- 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: About Plasma Active
On Tuesday, March 27, 2012 11:06:42 Dean Howell wrote: > We would like to send you some of our questions and *hopefully,* more than > one of you will be able to answer. It would be great for our readers to > get the perspective of some of the other developers. Would you guys be > interested in doing that? sure thing.. we could either do it by email or something "more live" like irc or skype. most of us are UTC + 0-2 hours (i'm UTC+1) so getting us together at the same time is often not too difficult. -- 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 Wednesday, March 28, 2012 14:06:29 Thomas Pfeiffer wrote: > > 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. > This brings us back to the issue Fania and me raised before: Do we really > need ok/cancel buttons in all dialogs? We still think we don't. And instant apply is really not a possibility here for technical reasons. we can get rid of the Close button though by making an outside tap close and cancel the dialog. note that "tap outside" for save borders on "voodoo magic" UI as there is no clear communication to the user that "yes, this really is happening". watching people use the UI, almost nobody attempts apply-by-outside-tap, and only one person so far has tried to use drag-to-apply in the add-to-activity screen (another topic for another thread though) > > p.s. i don't have locking activities working here atm, so i can't see if > > there is any UI for changing the password, or if the password is asked > > for every time a private activity is saved ... in any case, i'm more > > concerned at the moment about the default UI. > > Currently there is no way to change the password except for switching > private off and on again and it does not ask the password every time it is > saved. ok, so this could use some improvement. i do have some ideas there, but we can discuss this later. -- 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 Wednesday, March 28, 2012 17:46:52 Fania Bremmer wrote: > implementation-wise. Now there comes in a new requirement, the smaller > screensize, and we need to find another good solution. I agree that for new while the lack of elegance is more obvious at lower screen sizes, the lack of elegance was quite apparent at larger screen sizes as 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: activity configuration UI
On Wednesday, March 28, 2012 19:56:46 Thomas Pfeiffer wrote: > Generally when designers and developers meet, the developer is in the > stronger position. this statement speaks to a large challenge we apparently face: seeing other members in the team as people to be opposed rather than a team working together towards a shared goal that has a higher operational value than our differences. this is poison. i will address this in a following email in a new thread so as to not drag this one further off-topic. -- 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 Wednesday, March 28, 2012 17:31:00 Sebastian Kügler wrote: > Does this make sense? +1 from me. -- 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
embracing our goals together
hi... listening to the various people involved in the creation of new bits of UI in the shell, it seems that people concentrated on or were distracted by various issues and "let's make a pleasing and elegant UI" got lost. here's the hard and uncomfortable reality: when i first saw the new UI changes, i instantly realized i could not show it to others and be proud. it was not up to the standards we had shown ourselves capable of in the past. it was, in a word, embarrassing. this is not limited to the Activity Settings UI, but when looking at the result of the work on the Activity Settings UI and then listening to various people involved, here is what i noted : * there was a lack of consensus around the implementation * the reasons why certain things could/could not be done was not well understood by everyone (both technical requirements as well as UI design) * there was a feeling of conflict between the different people involved, a feeling derived from the belief that different people had different goals that could not be harmonized put bluntly, people focusing on UI design did not fully appreciate the technical hurdles and those working on the technical requirements seemed to view those working on UI design as obstacles in the path to implementation. the result was something nobody was truly happy with. this leads to a shocking question: if no one involved in the creative process was truly happy with it, how did it become the result of our efforts? it would be easier to understand if someone in our team thought it was the best UI ever; but was anyone truly, deeply proud of that result? did anyone feel that "awesome!" feeling when it was finally completed? or did everyone feel they'd compromised somehow, producing something dominated by the weaknesses of the compromise rather than by the strengths of an answer the team came up with together? we need to remember that we have a shared goal here: to make an elegant user experience that supports life's activities that trumps everything. EVERYTHING. there is no implementation principle that is more important than that, there is no design concept that deserves attention before that goal is understood. technical issues and design decisions are the tools to reach that goal, but they are not the goal in themselves. we each have unique tools which we bring to the team so that we can reach that goal together. our individual skill sets are not to be used in conflict, but to create a coherent direction that brings us to our shared goal. that was seemingly lost in the creation of this particular UI component, and it showed starkly in the results. having thought about it some more, i regret having proposed a set of improvements as i did. it would have been better if i had first asked you if you were truly happy with the result, and if not what you would do to improve it. once improvements had been found by working together, we could then have reflected on the differences in process that got us from "nobody is 100% happy with it" to "something that is elegant" i squandered that opportunity in my desire to "simply fix it", but we still have an opportunity to reflect and learn. i invite each of us to think a little on how it came to be that lines were drawn between "the UI designers" and "the people doing the implementation", how undesired compromise overcame elegance. this is not an invitation to blame others. instead, let each of us consider our own contribution: how did i chose to interact with others? what opportunities for consensus were missed? how did communication between requirements and design broke down? and remember: the problem is not the result. the result can be improved on through iterative input and effort. the problem is the process. we know how it can work, because we've done it many times already with really good results. -- 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 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. -- 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 Thursday, March 29, 2012 17:55:35 Marco Martin wrote: > On Thursday 29 March 2012, Thomas Pfeiffer wrote: > > > as soon as we can break master again i'll merge so people can test it > > > (for both speed differences and difference in look) > > > > Could you please post a screenshot so we can "test" the look immediately? > > Tank you :) > > unfortunately i can't test it on a device and being fullscreen on the devel > machine has a size quite ridiculous ;) 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. 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. 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? -- 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 Wednesday, March 28, 2012 14:11:37 Fania Bremmer wrote: > 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". what were the question(s) that were asked when testing this? > Here both results, the locking > of the activity with a password AND the encryption of the private data, > have been understood. why? could this be accomplished in the UI that sets the password? or in a message that appears in-line when Private is selected? in documentation? (i ask because i'm not sure i understand why this needs to be communicated in the label for the toggle switch, and i do think it makes the dialog overly verbose ... ) > One thing in general: I am thinking about a while now about some kind of > wizard in this case: we could split those 3 steps into a small, little > wizard, at least for the creation of new activities. That makes it easy > to add different steps in between, like the private activities step -> > it would be a handy and guided flow for the user, where he can quickly > create a new activity. 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. -- 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 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 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: 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
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: Creating pre-filled Activities
On Saturday, March 31, 2012 00:06:36 Thomas Pfeiffer wrote: > Does the ebook reader also read simple PDFs? yes. the project is currently at: https://github.com/cristeab/tabletReader/ hopefully it will appear in kde's git sooner rather than later. -- 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: Privacy
On Monday, April 2, 2012 13:06:10 Ivan Cukic wrote: > There is one thing I'd like to propose - removing the 'set private' option > for activities, or marking it as experimental*. how will it be tested? (not saying it shouldn't be hidden, but hiding things almost always means "no actual testing gets done"; i've seen this so many times now that i replace "hide the option for now" as "we will remove the feature in 6 months" ;) -- 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: Privacy
On Monday, April 2, 2012 13:47:52 Marco Martin wrote: > On Monday 02 April 2012, Aaron J. Seigo wrote: > > On Monday, April 2, 2012 13:06:10 Ivan Cukic wrote: > > > There is one thing I'd like to propose - removing the 'set private' > > > option for activities, or marking it as experimental*. > > > > how will it be tested? (not saying it shouldn't be hidden, but hiding > > things almost always means "no actual testing gets done"; i've seen this > > so many times now that i replace "hide the option for now" as "we will > > remove the feature in 6 months" ;) > > maybe by removing it from the (future) vivaldi branch but still have it in > devel, regular x86 images and pa3? that would be ok, but then we're having this conversation at an odd time as there is no vivaldi branch at this point in time and even when there is it should not have any impact on the development (which again gets us back to having an integration branch so that we can avoid such discussions :) -- 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: eBook reader proposal
On Tuesday, April 3, 2012 13:01:29 Bogdan Cristea wrote: > tabletReader, which I would like to expand to became an eBook reader for AP. cool; i cloned it locally, made a few small modifications in a local branch (which git.kde.org is refusing to let me push; i might end up doing a personal clone and pushing my changes there for now?) to things like the animaton speed, the animation shape, spacing and margins in the top level layout .. nothing major, just little tweaks here and there. some things that occured to me while doing this include: * it would be very nice to move from qmake to cmake; main benefit is that cmake makes it easy to get rid of the hard coded values like "/usr/bin" for installation. bonus point: it's the tool we use everywhere else so we have lots of expertise available on this. i'd be happy to make the switch with your blessing. * right now there is a top level QWidget based layout and things like the toolbar, while done in QML, are in QDeclarativeViews inside that QWidget layout. this really limits what is possible, such as being able to place the toolbar on top of the content. what would be much nicer is to have a single QDeclarativeView with all the QML in there and put the C++ document widget inside that (which is pretty easy to do with QML's QObject support). then we can do things like place the toolbar and other elements more freely. it should also improve performance by avoiding the overhead of multiple QML engines and, at least with QML2, will allow painting and updates to be handled all in one render tree. thoughts? (btw, noticed the blue border is already gone around the document area and some of the other changes you've been making behind the scenes as well ... generally nice stuff :) -- 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: Renaming our product in Bugzilla?
On Wednesday, April 4, 2012 10:16:30 Thomas Pfeiffer wrote: > On 22.03.2012 12:23, Fania Bremmer wrote: > > +1 > > Even if a lof of people dont like branding and marketing stuff, its > > still relevant to get recognized in public. > > We should stick to the public project name "Plasma Active" as much > > and as often as we can. > > What about this issue? i didn't weigh in on this discussion previous to this because i really don't feel it matters one way or the other :) -- Aaron 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: eBook reader proposal
On Wednesday, April 4, 2012 18:24:43 Marco Martin wrote: > from a technical point of view, a good way to proceed i think would be this: 100% agreed. (no surprise :) good news is that the viewer area is already nicely separated from the rest of the application. in fact, it is a QWidget that basically just paints pixmaps delivered from the renderers. so what may make sense is to take advantage of QML being able to show pixmaps natively and expose just some QObject based classes which provide the interface for fetching those pixmaps. this is what the current QWidget basically does already, so the work to make this happen should not be very big at all. while having this as a separately loadable QML component should be the end goal, i think that to make that more achievable it would make sense to make the current app work in the manner described above and then once it is working within the app to make it a separate, externally-loaded QML component. .. and that will be VERY cool as it will open up viewer capabilities to any other app as long as this one is installed. -- 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: Hello Plasma Active Community
On Thursday, May 3, 2012 19:09:45 Chris Russell wrote: > Hello Plasma Active Community! > > I met Carl Symons at LinuxFest Northwest last weekend and got my first > hands-on demo of Plasma Active. I am very impressed folks. thanks for kinds words and encouragement, and welcome to fun :) hopefully you'll be able to get your hands dirty at some point in the near future and enjoy working on Plasma Active along with us ... -- 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: KDE Phone subsystem integration
On Tuesday, May 8, 2012 16:01:38 Emmanuel Lepage wrote: > What do you think about these features? Do you have suggestion where to > invest my time the can loosely fit in “Integrate SFLPhone deeper into KDE”? since you're posting to the active@ list, i assume you have an interest in touch based UI's. the app in the video demo you provided is very powerful, but would be difficult to use with touch (not surprising, i imagine, as it was designed for desktop usage). a streamlined workflow and design for tablets would be very interesting to see. iirc, basyskom has worked on something along these lines called Peregrine? -- 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: Archlinux-arm based Plasma Active UI Stack ?
On Thursday, May 3, 2012 12:43:26 Laszlo Papp wrote: > Do you plan to have archlinux-arm [1] based Plasma Active in the > future ? if someone steps up to work on it, sure .. that's how plans get made -> resources become available, and it gets done as a result. in this case, i suppose the question would be what Arch can provide that is unique / different / better than what we already have and who has experience with Arch packaging and maintenance. -- 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: UX suggestions for tabletReader
On Wednesday, May 2, 2012 23:37:03 Inge Wallin wrote: > In both these cases somebody would have to create a file format filter from > epub to odt, the open document text format. this is probably a significant issue; it is likely easier to write a viewer using an existing epub library than using that to write a filter to caligra. it is a question of "what renders a given format well". for ODF and MS Office files i would definitely agree that using calligra is the way to go. -- 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: Some comments on the Add-Ons App
On Friday, April 27, 2012 11:43:29 Thomas Pfeiffer wrote: > Hi people involved in the UI design/development of the Add-Ons App, > I just saw Aaron's presentation at his blog > (http://aseigo.blogspot.de/2012/04/add-ons-app-preview.html) and I really > liked what I saw :) aw, cool :) i'm glad you like it. it's been fun working on it from design to implementation ... as of today we also have the nice little error and confirmation bubbles that i've been dreaming of (see attached screenshot for what pops up when you press "Uninstall") we have the test server up and running, though i have not yet tested the installation for correctly sending email (though hopefully it is; will test this tomorrow) and it is still a beta version so server interuptions are possible ... but it should essentially work for people interested in taking it for a spin, and Sebastian has added it to the PA images... > The column swiping interaction looks very useful. I'll have to see how this > can be generalized and put into an HIG. awesome :) > Here are some small things that I suggest thinking about: > - I found the wording "Uninstall" for books a bit strange. It makes sense > for apps, but I don't think it fits for books. Maybe just "Remove"? even for apps, i figure this makes sense. "Uninstall" is not the opposite of "Download", while "Remove" is much closer. > - Maybe the "Read" button for installed books should be placed above the > "Remove" button. The advantage of the current button order is that it makes > clear that "Download" and "Uninstall" (or "Remove") are basically two sides > of one coin. However, if a user uses the add-ons app as the starting point > for reading e-books, "Read" would be the primary function, not "Remove", > and thus it should come first. agreed. > - There should be a "Remove" button for Wallpapers as well ;) there is now :) -- 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: mer+plasma+active
On Wednesday, April 25, 2012 19:40:21 Nicola De Filippo wrote: > Hi, > FYI among other things i admin/develop "notorious" (in italy) open source > educational project or italian primary school, today i have uploaded first > simple video > http://www.youtube.com/watch?feature=player_embedded&v=Z1lOy5ygriw cool :) with a bit more work this could really be kick ass. one thing i notice is that the keyboard interaction isn't great. hopefully we will get that improved shortly ... -- 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 300327] active-okular does not support djvu and chm files
https://bugs.kde.org/show_bug.cgi?id=300327 --- Comment #1 from Aaron J. Seigo --- "active-okular should use the same okular core library as the classic okular application." it does. the file formats you list require more dependencies which i guess are not on the image: libchm and DjVuLibre. of course, if those dependencies are not met, then the .desktop file should not advertise it spuports them, either. -- 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: Maliit, Plasma Active and Mer
On Monday, May 21, 2012 19:26:08 Marco Martin wrote: > that qml version not yet, the framework supports it (used to do the numeric > keypad on the N9) > the qml version of maliit still needs a lot of bindings to be feature > complete with the old c++ version on the n9 as i hear, so more features > will be eventually possible trough time yes, we'll have to push this forward as we iterate the PA product ... hopefully with a new user of the QML bindings, the maliit crew will help us out here. what's really great about this is that the framework has everything one could want in the framework: screen positioning, layout selected based on app hint (e.g. "show only numeric keys"), internationalization (accented characters, different layouts you can swipe between, multibyte, etc.), word completion (though this requires integration with a system installed completion framework) so while we're losing some of "our" code, we get a full framework and we get rid of some bugs. awesome work on this marco :) -- 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: Okular active
On Friday, May 18, 2012 21:47:01 Marco Martin wrote: > seems some unnecessary painting is still happening, especially when zoomed > in (may require yet another level of pixmap caching) this *should* be improved as of today (so whenever new images are built). the view was getting repainted numerous times during rendering and there was an additional off-screen pixmap being used. please check when you can to see if it is rendering smoother for you now. -- Aaron 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 300280] Okular Active: Tapping a page in Search Results navigates to the wrong page
https://bugs.kde.org/show_bug.cgi?id=300280 Aaron J. Seigo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Latest Commit||http://commits.kde.org/okul ||ar/82e073dc698755ec498822a4 ||14f26de1d137488a --- Comment #1 from Aaron J. Seigo --- Git commit 82e073dc698755ec498822a414f26de1d137488a by Aaron Seigo. Committed on 22/05/2012 at 17:40. Pushed by aseigo into branch 'mart/okularActive'. use the modeldata, not the index in the grid, to switch pages M +2-2active/app/package/contents/ui/Browser.qml http://commits.kde.org/okular/82e073dc698755ec498822a414f26de1d137488a -- 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: Maliit, Plasma Active and Mer
On Saturday, May 26, 2012 15:03:11 Thomas Pfeiffer wrote: > I finally had my first chance to see Maliit Active live in action (on Mer), > and it generally I like it a lot! huzzah! > Even though the keys are currently way too small on the Mer x86 image on a > Wetab (partly because they are not dpi-aware yet, partly because the yes, size is the next thing we need to tackle in the integration ... > However since many keys that are often needed in a terminal (like tab and > arrow keys) are rarely needed in usual mobile usecases, we shouldn't clutter > the normal layouts with them. What I think does make sense, though, is > having a third (or rather fifth) layout specific for terminal use which > includes all keys regularly needed there (letters, /, ., |, <,>, ~, -, > arrow keys and maybe a few more). If that's soo many keys, it may contain > only tab and arrow keys so the user can at least switch to it when needed. > Can we do that for PA or does it have to be implemented in Maliit? we can do it in the PA integration for Maliit. and i agree that "geek characters" are necessary in our keyboard. / is needed for urls, so that should readily available .. the rest should be easily found. having a tab key on the main layout wouldn't be the worst idea, though, as it could also help encourage the use of tabbing between text fields on forms. -- 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 276713] plasma-tablet: focused system tray covers window switch button
https://bugs.kde.org/show_bug.cgi?id=276713 --- Comment #2 from Aaron J. Seigo --- what exactly is it that you are running? i see what looks like the PA activity switcher handle, something that looks sort of like the PA panel .. but the desktop is something else. i'm also not seeing the problem you are describing .. when i click on anything in the system tray i just get the item i clicked on showing its relevant UI (e.g. volume settings or network manager..) -- 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 274580] plasma-tablet applets strip: folderview breaks rendering of applets right of it
https://bugs.kde.org/show_bug.cgi?id=274580 --- Comment #4 from Aaron J. Seigo --- yes, it isn't included in the image. you would need to install it yourself on top of the image, or you could install plasma-mobile from kde's git and run `plasma-device --nodesktop` to try it with the plasmoids on your devel system (probably easiest..) -- 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: Maliit, Plasma Active and Mer
On Monday, May 28, 2012 18:39:24 Thomas Pfeiffer wrote: > On Saturday 26 May 2012 14:22:50 Thomas Pfeiffer wrote: > > However, since with the latest Mer x86 devel image I can update without > > trashing my system again, so I will try Mer again and will try to help > > getting it stable on x86 so we can ditch Meego soon. > > It seems like getting Mer usable on a WeTab will take quite some more time > (I am still helping there whichever way I can, but there are several > problems still present)). So is there anything else I can do to help debug > the problem with Maliit on Meego? to be perfectly honest, there should be no further effort put into the meego images. effort there takes effort away from Mer, and it's like dragging two dead horses behind the cart :) the issues on ExoPC / WeTab should be enumerated and worked through with Mer developers. this will give us a "MeeGo + 1" across all targets that we can work with. -- 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 276713] plasma-tablet: focused system tray covers window switch button
https://bugs.kde.org/show_bug.cgi?id=276713 Aaron J. Seigo changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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: ownCloud Client
On Monday, May 28, 2012 18:58:11 Sascha Manns wrote: > today i've tried out to install Mirall/OwnCloud Client in Plasma Active > 'cause i'm getting this Question from time to time. > The Installation through openSUSEs isv:OwnCloud:community was successful, > and i have a new Icon on my PA Workspace. If i'm pressing it, it starts a > Cloud- Icon into the Systembar and i must configure it through pressing > that Icon. The Problem is, that this Icon isn't visible in PA. > Has anyone tried out this? yes :) tl;dr version: mirall does not work well with PA right now, but the reasons are mostly cosmetic. getting mirall working nicely on PA would not be a huge amount of work: a settings page and not relying on the system tray icon (the settings page is important to this) would be good enough for a first version. and with that done i'd love to see it available for installation on PA. ok, full version (and i've CC'd Klaas so he can be informed as well): the sync systray icon should be avoided if at all possible. right now the tray icon does a couple of things: * access to the configuration * lets the user know when it is syncing or not configuration should be done with a module in the Active Settings app for ownCloud (which would configure mirall behind the scenes). this should be integrated with the accounts system when that becomes available, but that can also happen later on without loss of very much, if any, effort. so imho that would be step 1: give mirall a nice QML based config page for Active Settings. Sebas wrote a nice tutorial here on how to do this: http://techbase.kde.org/Development/Tutorials/Plasma/QML/ActiveSettings that leaves us with letting the user know when synchronization is happening. on the one hand i think it would be pretty neat to see a sync icon appear and start turning about in the panel when the device is syncing ... and on the other hand i think it would be really cool if it just happened and i never had to think about it (which means not being bothered about it). of course, then how do you check when the device was last synchronized? perhaps in the settings page, so if you really need to check on it, you could go and see it there. that might be made more difficult with the account system which will be more generic and may not be able to accomodate that. the main use case i can see for having visual feedback is to let the user know when they can safely disconnect from the network. perhaps this could be reflected in the networking UI itself: a service is busy using the network or not. how to integrate this is an interesting question, though probably not overly difficult to come up with one or more ways to do it cleanly. it would be very nice if services that rely on the network (installers, updaters, sync) all shared a consistent and central UI so that all "stuff using my network" could be seen at a glance. then one can connect to the network, watch the flurry of activity that results and when it's all done and dusted, disconnect. there are also some internal things that need doing with mirall, such as: * tuning the defaults not to kill the battery by syncing too often. * ensuring that its process is properly nice'd so as not to wake up and take the little CPU power there is on these devices for syncing while i'm playing a game ;) this may already be done, i haven't looked. * testing the sync-when-the-network-becomes-available code. there is some code already there, but fwiu it is not well tested at the moment -- 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: ownCloud Client
On Tuesday, May 29, 2012 13:42:46 Sebastian Kügler wrote: > On Monday, May 28, 2012 18:58:11 Sascha Manns wrote: > > today i've tried out to install Mirall/OwnCloud Client in Plasma Active > > 'cause i'm getting this Question from time to time. > > The Installation through openSUSEs isv:OwnCloud:community was successful, > > and i have a new Icon on my PA Workspace. If i'm pressing it, it starts a > > Cloud- Icon into the Systembar and i must configure it through pressing > > that Icon. The Problem is, that this Icon isn't visible in PA. > > Has anyone tried out this? > > Others have already pointed it out in some way. I had a look at ownCloud and > mirall two weeks ago, and found mainly two problems: seems we're very much on the same wavelength :) what do you think of the idea of making a settings page for it as i outlined in my reply? > Those are certainly fixable, but it will take sitting down with owCloud / > mirall devs where they see mirall going. I could imagine it being a kded > module, or a service like nepomukserver (in case that's technically more if the code is very crash safe and does not block anywhere, then kded would be ok .. but a small gui-less process would be even better imho. less to go wrong and it shouldn't take many resources. -- 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
merging mailing lists
hi all ... watching both the active@ and plasma-devel@ mailing lists and what they are used for, i have begun wondering if it might make sense to merge the two lists. pros: * many of the topics discussed here are relevant to the other workspaces (desktop, netbook, ..) and vice versa. this is happening more rather than less as we move forward. examples: QML tooltips are being discussed on plasma- devel; QML HIG is being discussed here; private activities is discussed here; system settings related issues are being discussed on plasma-devel while active settings is discussed here (missing opportunities for collaboration / consistency?); accounts system will likely be discussed on plasma-devel, though that's critical to active; we work on things like the activity switcher here, and that's something that should be harmonized into desktop/netbook. * there are few topics discussed on either mailing list that would not be completely off-topic for the other mailing list * most of us are both lists already * the traffic on each list is not too much, and the signal-to-noise ratio is very high on both cons: * we'd lose a mailing list to discuss active specific things; the main things this would impact are things like discussion of the applications which are more tightly bound on plasma active than in plasma desktop. traffic about this is pretty low, and if we feel the need we can either start a mailing list for the applications or re-use this one for that purpose * bugs would need to go to another mailing list, as that is our policy on plasma-devel (we have a plasma-bugs list for that); this may require some adjustments in work flow for people what are your thoughts? worth doing? would it be too much hassle for you? would it make you drop off the mailing list? woudl it make you happier? etc.. -- 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 300095] Files and Images crash on launch
https://bugs.kde.org/show_bug.cgi?id=300095 --- Comment #12 from Aaron J. Seigo --- "I do not like giving permission to all files in /etc/skel/.kde/share/apps/nepomuk/ , that means anybody in the system can read the nepomuk database from any user." shouldn't the files in /etc/skel be copied to the user's home dir on first boot (or even sooner with a pre-made user home dir in an image), and not be used directly for storing any information after that? -- 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 283420] "Send by email" tries to start kmail
https://bugs.kde.org/show_bug.cgi?id=283420 --- Comment #15 from Aaron J. Seigo --- Git commit 76d6bda20bce82f5ca8127b70eda8d2454b51d9b by Aaron Seigo. Committed on 30/05/2012 at 13:48. Pushed by aseigo into branch 'master'. commit the fix in the correct repository M +3-0appconfig/emaildefaults http://commits.kde.org/plasma-mobile-config/76d6bda20bce82f5ca8127b70eda8d2454b51d9b -- You are receiving this mail because: You are on the CC list for the bug. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
[Bug 300095] Files and Images crash on launch
https://bugs.kde.org/show_bug.cgi?id=300095 --- Comment #21 from Aaron J. Seigo --- the launch time benefits can probably be offset with prelinking. what can't be is the few MB of memory per application that gets saved with a kdeinit style launcher. note also that the crash is happening with intel chipsets (may happen with others, but so far we've only seen it there). a more proper fix would probably be to not build the applications as kdeinit launched apps but regular binaries. that means changing kde4_add_kdeinit_executable in the CMakeLists to just kde4_add_executable. then these workarounds in the .desktop files which trigger the launch of a shell (another process!) can be removed. i'd much, much rather see that approach than the workaround. in fact, i'll go make that change right now. -- 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 300095] Files and Images crash on launch
https://bugs.kde.org/show_bug.cgi?id=300095 Aaron J. Seigo changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Latest Commit||http://commits.kde.org/plas ||ma-mobile/304248e799c2ccd14 ||20b6df9e9630c3ec4047dad --- Comment #22 from Aaron J. Seigo --- Git commit 304248e799c2ccd1420b6df9e9630c3ec4047dad by Aaron Seigo. Committed on 30/05/2012 at 22:53. Pushed by aseigo into branch 'master'. don't build this as a kdeinit4 exec. triggering crashes in Qt opengl code on intel chipsets. M +1-3applications/filebrowser/active-books.desktop M +1-3applications/filebrowser/active-filebrowser.desktop M +1-3applications/filebrowser/active-imageviewer.desktop M +2-3applications/filebrowser/src/CMakeLists.txt M +1-2applications/filebrowser/src/main.cpp http://commits.kde.org/plasma-mobile/304248e799c2ccd1420b6df9e9630c3ec4047dad -- 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: List of problems with Plasma Active on Mer
On Wednesday, May 30, 2012 18:22:13 Lamarque V. Souza wrote: > Em Wednesday 30 May 2012, Aaron Seigo escreveu: > > On Wednesday, May 30, 2012 21:38:35 Thomas Pfeiffer wrote: > > > 2. Several core Plasma Active applications crash on start > > > ( https://bugs.kde.org/show_bug.cgi?id=300095 ). According to Marco, > > > this > > > is caused by an issue with Intel graphics drivers > > > ( https://bugs.kde.org/show_bug.cgi?id=300095#c14 ). > > > > firxed by making it not a kdeinit4 app. do the following apps also crash > > for you: > > > > * About: crash > > * webbrowser: no crash > > * settings > > Only About app crashes here. ok.. so we need to remove the kdeinit status from all of these apps. it looks like a heisenbug (some crash, some don't) and we know the issue is kdeinit+opengl+some_drivers ... i'll do this tomorrow. -- Aaron 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: List of problems with Plasma Active on Mer
On Thursday, May 31, 2012 10:13:30 martin brook wrote: > Just a reminder that Mer does not include hardware adaptations, so kernel > and graphics drivers are out of scope of that project. > > Nemo does aim to support an x86 adaptation. imho, this highlights a scoping error for mer. here's why: * mer doesn't do hardware adaptation. * projects on top of mer do * there are multiple projects on top of mer, all of which need adaptations * there is a finite number of common hardware targets this leads to multiple projects working on the same hardware adaptations without a good place to collaborate. this conflicts with the idea that mer is a place to collaborate on the OS layer. this feels a lot like "we're doing it wrong". possible solutions, of varying benefit, that occur to me: * mer based projects (e.g. nemo, PA, etc.) pay attention to what each other is doing for hardware adaptation and collaborate when possible. this does not scale well and ad-hoc cooperations are messy and error prone. * mer provides a place for hosting hardware adaptations. this can be adjunct to the share core that is mer, but kept within the same workflow and collaboration tools that already exist this would scale well and give a natural place to collaborate. apparently mer does not see the need for this or has concerns (legal?) about $SOMETHING * mer based projects create a place to collaborate on hardware adaptations outside of mer. this will make mer a hell of a lot less influential and useful. which is the opposite of what mer should be trying to do. i understand avoiding UI stack involvement, if only because it is obvious and evident that there are not only multiple divergent UI pathways which are equally valid and unlikely to be shared via mer core, but mer core itself does not imply a UI layer at all. mer core DOES imply hardware adaptation, however. without that it is not useful. so if someone can explain to me why mer is not ammenable to providing places for projects to work on these hardware enablement projects in a central place, that'd be appreciated. -- 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: List of problems with Plasma Active on Mer
On Thursday, May 31, 2012 11:23:30 martin brook wrote: > Carsten has been working on some architecture pages on the wiki which may > help here, while very nice and quite useful, that page unfortunately doesn't address my question at all. i have a reasonably decent idea of what mer currently is. i'm suggesting that that definition creates inneficiencies because it does not fully align with all needs associated with having a shared core. a shared core implies shared adaptations. and while mer core team does not need to work on those adaptations, it makes sense to host those adaptations. adaptations can have maintainers that are not members of mer core, and probably should have to make maintenance, support and workload sensible. right now putting the adaptations above the "individual users of mer core" line simply duplicates efforts. moving those adaptations above mer core but below the uses of (e.g. nemo, plasma active, etc) would resolve that. to make it abundantly clear: nobody is expecting mer core to maintain or develop those adaptations, merely provide a well defined area for collaboration on such adaptations in a place they can be widely shared. and as i noted in my previous email, either mer will provide this or we will. the latter solution is really sub-optimal, since collaboration on common core technology is supposed to be the point of mer as i understand it. the diagram might look like: full products (e.g. vivaldi) - mer based products (nemo, plasma active, etc..) - adaptations (intel, $RANDOM_ARM_BOARDS, etc..) - mer core the corresponding maintainer layers might look like this: manufacturer (e.g. Make Play Live) --- UI community (nemo, kde, ..) -- adaptation community (nemo, kde, $CORPORATION ..) -- mer core team right now what we have is: full products (e.g. vivaldi) - mer based products (nemo, plasma active, etc..) - mer core with adaptations being insert somewhere in an ad-hoc fashion, which is leading to inneficiences. please consider this as feedback from a concerned and highly vested user and fan of mer,, in the form of an appeal to the project leadership in mer :) -- 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: Fwd: List of problems with Plasma Active on Mer
On Thursday, May 31, 2012 11:04:34 martin brook wrote: >From my view there is a place for the x86 adaptations and this is in the > Nemo project and Mer people contribute there. why does this, or any adaptation, belong to a specific mer based project? hardware adaptations are sharable artifacts that ride alongside the core, as opposed to being tightly coupled to presentation layer. well, they CAN be tightly coupled to a presentation layer, but that seems conterproductive, given your statement here: > In my view its the number of resources available to work these adaptations > which is the problem just as in all software development projects I've been > involved in. the way to incrase the # of people working on an adaptation is to de-couple the adaptations from the presentation layer and make them shared projects. which implies an area that we can point to such adaptations from, instead of having to search through each mer based project to see what they are up to. this is not a change in maintainership (e.g. expecting mer core team to take on adaptations or even provide support for them) but a canonicalization of where adaptation efforts can take place for the purpose of cross-product sharing. here's a copy and paste from an email i sent to only the active@ list a few minutes ago, but may be of interest to mer-general too: either mer will provide a place for adaptation collaborations or the projects working with mer will. the latter solution is really sub-optimal, since collaboration on common core technology is supposed to be the point of mer as i understand it. the diagram might look like: full products (e.g. vivaldi) - mer based projects (nemo, plasma active, etc..) - adaptations (intel, $RANDOM_ARM_BOARDS, etc..) - mer core the corresponding maintainer layers might look like this: manufacturer (e.g. Make Play Live) --- UI community (nemo, kde, ..) -- adaptation community (nemo, kde, $CORPORATION ..) -- mer core team right now what we have is: full products (e.g. vivaldi) - mer based products (nemo, plasma active, etc..) - mer core with adaptations being inserted somewhere in an ad-hoc fashion, which is leading to inneficiences. please consider this as feedback from a concerned and highly vested user and fan of mer, in the form of an appeal to the project leadership in mer -- 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: merging mailing lists
On Monday, June 4, 2012 11:07:59 Ivan ÄukiÄ wrote: > Any news on this front? it made my TODO list. when i have time+energy to do it, i will. unless someone else beats me to it. and please .. feel free to do so ;) -- 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: Problem with dependency bodega > PackageKit -> connman/ofono on Mer
On Monday, June 4, 2012 11:49:41 Marco Martin wrote: > yeah, seems that connman or networkmanager support is statically linked in > the packagekit daemon and not a plugin, so doesn't seem possible to have > both backends compled and installed at runtime :/ so here's the next obvious question: why is conman still in Mer? :) it really does not make much sense to have 2 backends mantained unless there is a significant advantage unique to each one. right now, the only advantage i know of is that conman is not actively developed? :) -- 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: Menu Flap
On Sunday, June 3, 2012 22:32:50 Marco Martin wrote: > also note that it has been written before everything else, so nothing was > available yet: neither artwork, components, libraries etc (and considered > that the result is quite remarkable, i have to say to the kontact devs ;), yeah, they did a lot of very basic work to get there! :) > so it really evolved in its own way (it still even uses proxy widgets for > the calendar, just transplanted from the desktop version, that is not > really the best). of course, the problem there was that the calendar widget is 1000s of lines of code that is well tested. that is a huge investment to just get rid of. i would guess it would be easier to get Korganizer to use a new QML version of the calendar widget and share that with Kontact Touch than to try and keep KOrganizer where it is and have something completely separate for kontact touch. > it would be quite awesome if there will be a bit more investment on kontact > mobile in the future, to make it simpler and more integrated with the rest as long as it doesn't get made so simple that we lose the ability to interest corporate and government users. groupware is not a simple thing and has many requirements. in the reach for simplicity, we must keep the use requirements first in mind. "simple" is contextual to that. -- 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: Question about Starter in PA Launch & Peek
On Monday, June 25, 2012 11:22:08 Sascha Manns wrote: > I've tried it out. If i'm typing "yast" in the KDE4/Desktop-Kickoff all > modules are visible. If i'm typing the same in Plasma Active i can see all > icons too. But i can't make them visible in peek and launch. i have to ask: why do you want all the yast modules visible there? are they touch friendly? do they make sense on a tablet device? etc.. -- 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: Plasma Active 3
On Tuesday, September 4, 2012 20:26:51 Marco Martin wrote: > On Thursday 30 August 2012, Marco Martin wrote: > > on more pr side, announcement material: > > * list of some features > > * announcement and dot articles > > * tons of screenshots > > * video (can give a try, but i don't have cameras that shoot decent high > > res video, so anybody with a decent camera is welcome to do so) > > this is a fisrst quick video: > http://www.youtube.com/watch?v=J0JJUTIEcAI looks very good imo; i particularly like how the text in between shots is short and clear .. highlights the progress that's been made quite nicely. it may be worth doing a series of videos over the next weeks highlighting individual improvements. things like the changes to the Add To Activity dialogs, how okular active works, etc ... good blogfodder. :) in general, really nice work and awesome to see the progress that is being made across the board. -- 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: Plasma Active 3
On Wednesday, September 5, 2012 20:10:11 Marco Martin wrote: > On Wednesday 05 September 2012, Bogdan Cristea wrote: > > On Wednesday 05 September 2012 11:07:44 Thomas Pfeiffer wrote: > > > - When using Kmail Touch, it looks like you try swiping several times > > > but > > > nothing happens. Either something actually did happen but you can't tell > > > what happened from the video, or the screen didn't recognize the > > > gesture, or there is a bug in Kmail Touch. Either way, it gives the > > > impression that Plasma Active is sluggish, which is not good for a > > > touchscreen UI, so I think that should be cut. > > > > I had the same impression: everything run smoothly except the kmail Touch > > application. Same feeling, you tried several times to swipe, but nothing > > happens. > > > > regards > > i think i should remove the kmail part altogether. or just shorten it. you switch between a dozen or more emails.. just one or two switches is enough, particularly between messages that are considerably different in size / content so it is evident that switching is happening -- 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: plasma active 1
On Friday, September 7, 2012 21:00:12 Martin Wohlert wrote: > Hi there, > > is there a possibility , running plasma active on a ztpad c71 "upgrade" > (1GB Ram) not currently, and i unfortunately don't expect it to at this point -- 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: Proposal: Plasma Active Three end of August
On Friday, September 14, 2012 22:05:20 Thomas Pfeiffer wrote: > The blockers definitely have to be fixed before we can release. I would > definitely not recommend releasing with the major problems still there, > since it would make us look bad, but they at least leave PA in a usable > state. 2 bits of input here: a) we don't need the editorial to convince why we should no release with "release blockers". :) Let's all just agree that "release blocker" means what it says and then decide on an issue-by-issue basis if that issue is a blocker. b) these should be in a fresh thread for blockers; i'd like to see such a thread on the list at this point in every release cycle so we can collect issues for killing in an easy to find spot. i'll send an email shortly. -- 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 304877] None of the powersaving settings appear to have influence
https://bugs.kde.org/show_bug.cgi?id=304877 Aaron J. Seigo changed: What|Removed |Added Version|unspecified |3.0 Severity|normal |critical -- 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 304879] active-filebrowser attempts to open all files as images
https://bugs.kde.org/show_bug.cgi?id=304879 Aaron J. Seigo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED -- 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 305512] Bangarang crashes when click on media-list
https://bugs.kde.org/show_bug.cgi?id=305512 Aaron J. Seigo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED -- 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 307234] Dell Latitude laptop touchpad scroll wheel does not work
https://bugs.kde.org/show_bug.cgi?id=307234 Aaron J. Seigo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DOWNSTREAM --- Comment #1 from Aaron J. Seigo --- this is unrelated to Plasma Active. this is also an issue that you need to take up with your distribution as this is an x.org configuration / integration issue. -- 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 307508] "The process for the file protocol died unexpectedly". I suddenly can't write ANYWHERE!!!
https://bugs.kde.org/show_bug.cgi?id=307508 Aaron J. Seigo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Aaron J. Seigo --- That sounds utterly horrible. However, neither Skype nor dropbox are KDE applications, and it sounds like it is a problem elsewhere rather than something in the layers we currently maintain. p.s. "Active" is a specific application set, rather than a general bug depot for any/all vaguely/possibly KDE related bugs. -- 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 307544] PDF Thumbnails are created very slowly in Okular Active
https://bugs.kde.org/show_bug.cgi?id=307544 --- Comment #1 from Aaron J. Seigo --- > It would be really helpful if the thumbnails could be created more quickly. this may well be a Unicorn wish. it may be that with all the thumbnails being requested at once it causes a bottleneck, and it may well be better to request fewer pages to be rendered at a time. that may also help with the "starting from page 1 onwards" (though really that needs to be "starting from the first thumbnail visible onwards" otherwise if you are at page 200 you'll wait qute a while for the thumbnails ;) however, this may already be as good as it can get with a managed thread pool in the okular renderer, etc. it's also hard to know how good is good enough. "more quickly" is not a measurable goal :) -- 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 307537] Cannot download a book with Add Ons App
https://bugs.kde.org/show_bug.cgi?id=307537 Aaron J. Seigo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Aaron J. Seigo --- fixed both for forward http and local content; which is a server side detail not visible to the user (included in comment here for future technical reference though). seems node.js devs love to change API a bit too frequently :/ also popped in the wallpaper catalog while i was working on things. so now you have something new to test, too! ;) -- 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 307544] PDF Thumbnails are created very slowly in Okular Active
https://bugs.kde.org/show_bug.cgi?id=307544 --- Comment #3 from Aaron J. Seigo --- awesome comment; i really, really appreciate the time, though and insight offered. i've looked at the code a bit today and have some ideas on how to hopefully improve things. will keep this report updated as that happens. -- 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: PA3 release screenshots
On Monday, October 1, 2012 23:39:42 Thomas Pfeiffer wrote: > Sorry, I'll have to be a bit nagging about names again because we're still > quite inconsistent here: > > On Monday 01 October 2012 17:27:46 Marco Martin wrote: > > > - SLC > > > - document viewer > > It's called Okular Active (although the name is intentionally not > user-visible anywhere). i think the Document Viewer is Calligra, actually .. Okular is our eBook reader. but yes, i'd prefer to keep those names out of the marketing and application listings for a variety of reasons. hopefully the distinction between Books and Documents is clear enough for people ... though we hide that detail nicely by replacing the "launch the application, open the resource" workflow with "find the resource, open the resource" > I'm okay with it being called "Files" for now, but it should be called that > _everywhere_ then (in the Launcher, in the window title, in crash reports > etc.). +1 for Files consistently across the board. > > > - activities (create new activity shot) > > > - market application (what are we actually calling that?) > > > > "addons store" > > The window title and the title for the kwallet dialog was still "Add Ons > App" last time I checked. In the Launcher it's currently called "Store". i'd prefer "App" over "Store" as it's a lot more value-neutral. if we could drop 'App' altogether and just call it "Add Ons" that'd be great, but it doesn't seem meaningful enough to communicate the purpose of it to people without "Apps" (or "Store" or something like it) attached. -- 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
taglines on PA3 website.
hi...
some suggested minor edits for the taglines at the top of the PA3 website,
mostly little grammar improvements:
Plasma ActiveAn interface for people on the
move.
Organize your workflow with the power of
activities.
Sharing has never been this easy.
Yes, we have an addons store. You can have one,
too.
Power to the user with our semantic file
browser.
Top of the class document viewer and e-book
reader.
note that i switched the order of Activities to the top. this lets us talk
about Activities first later on, which is the foundational concept here.
i'm on the fence with "Power to the users with our semantic file browser."
since it uses the technical and unfamiliar term "semantic" and it doesn't
particularly say anything about the benefit of it ("Power to the user" is kind
of a generic "rah-rah" slogan :). sth that talks directly to the benefit might
be more effective, such as "All files are at your fingertips with the semantic
file browser." it still uses the word "semantic", but it now hints as to the
benefit a bit more?
if this is to be the elevator pitch, i really think we need an entry there for
Kontact Touch. email/calendaring is a BIG deal for us. it's a feature set most
devices don't do well or even at all.
are we going to have a page somewhere about each of these items? i think it
would be a good idea to do so, and i'd be willing to crank out the text for at
least one per day so we can describe the full benefits more.
the text below "What is Plasma Active" should then reflect these main points
above in the list of things we're talking about it (the list that currently
starts with activities). that means the same nouns in the same order as they
appear in the slideshow.
thoughts?
--
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: taglines on PA3 website.
On Wednesday, October 3, 2012 12:40:33 Marco Martin wrote: > On Wednesday 03 October 2012, Ivan Čukić wrote: > > > makes pretty obvious how outdated kontact touch looks and behaves > > > compared to the rest tough :p > > > > Maybe it could have some events in the calendar? :) > > here we go > http://www.notmart.org/Photos/PA3/snapshot15.png +1 vote for this one from me :) "Email, calendars and contacts for groupware on the go." or sth :) -- Aaron 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: release
On Friday, October 5, 2012 13:55:15 Marco Martin wrote: > what about release for sunday evening or monday? +1 for getting everything done sunday evening and sending out announcements for others to pick up on monday morning. > what is still missing i guess are tarballs. do we need tarbals? is this even really plausible to do anymore? patches again kdelibs, numerous repos ... i'm not against the idea, just wondering if it is meaningful to do or if we should simply point people to the images and OBS repository? -- 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: release
On Friday, October 5, 2012 15:41:16 Marco Martin wrote: > shouldn't be that big ok :) my next question is: based on our marketing wordsmithing (anding othering wordings ending withing 'ing'ing ;) what will our "3 important messages" be that we flog in our blogs and elsewhere? shall we start a suggestions list and then pick from them? here's my first nomination: * new apps -> reader, file browser, ? -- 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: release
On Friday, October 5, 2012 08:12:26 you wrote: > So I thought it was a tablet-ized version of KDE it is. > tablets. However I have significant usability concerns based off > screenshots alone) screenshots alone are indeed not enough on their own. i would ask what your "significant usability concerns" are, but i fear it would not be a great use of our time due to that. > Also, where the heck is Vivaldi? we're working on it. > I'd like to D/L the s/w and put it on my > tablet and give it a shot since the specs line up so much. this really depends a *lot* on what chipset is in that device. unlike x86 devices, ARM is very target specific. and you don't need to wait on Vivaldi -> there are already several ARM adaptations of Mer out there along with HOWTOs out there to get you started. -- 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: release
On Friday, October 5, 2012 17:00:50 Marco Martin wrote: > On Friday 05 October 2012, Aaron J. Seigo wrote: > > On Friday, October 5, 2012 15:41:16 Marco Martin wrote: > > > shouldn't be that big > > > > ok :) > > > > my next question is: based on our marketing wordsmithing (anding othering > > wordings ending withing 'ing'ing ;) what will our "3 important messages" > > be > > that we flog in our blogs and elsewhere? > > > > shall we start a suggestions list and then pick from them? > > > > here's my first nomination: > > > > * new apps -> reader, file browser, ? > > apps += addons store > > second nomination: > * incremental improvements: better multitouch support, better keyboard i was hesitant to nominate "better keyboard" because while it is indeed better ... it also has some minor regressions (worse for terminal usage; not completely clear that you can move it to the top with swiping; e.g.) and is not better (yet) in some key ways (layout switching e.g.) than what it will likely get compared to if we tout it as improved .. it is definitely now on a better foundation to work from and has a number of very real imprvements, but i'm not sure we want to draw attention to that as one of the Main Things to focus people on. if we can come up with Three Really Great Things to focus on, and have the incremental improvements as an "...and also" that gives us something snappy, short and curiosity-inspiring. that's sth we can use in social media (where space and attention spans are limited) to get people to visit the website which has the expanded elevator pitch which then leads into the more in-depth information. waterfalls of attention span :) if those 3 things are individual applications, that's also just fine .. and perhaps even easier to talk about. -- 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: release
On Friday, October 5, 2012 08:39:58 Carl Symons wrote: > +1 to Marco's suggestion to mention Mer. ok, so that more votes for Mer. an OS rebase like this is indeed significant .. just need to think about how to position that so its both exciting and communicates the benefits ... -- 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 307926] Dragging files to a tag in Files duplicates the tag
https://bugs.kde.org/show_bug.cgi?id=307926 --- Comment #1 from Aaron J. Seigo --- I can confirm. Even worse, if the thing tagged was associated with another tag, it no longer shows up on that tag. I added a bunch of images to a new tag called "Pretty". Then I added the (stock) dog and fox pictures to a new tag called "Animals". Then I dragged the fox to "Pretty" and: a) a new pretty tag was created b) the fox does not show up in either "pretty" tag, even though one "pretty" tag shows a big dot (4 items in it) and the dupe shows a small dot (1 item in it). i'm guessing it's listing the contents of the first tag matching the text "pretty" c) the fox also no longer shows up when selecting just "animals" -- 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: release
On Friday, October 5, 2012 09:28:41 Jason H wrote: > 1. You put the adjective after the noun. Plasma Desktop, Plasma Netbook, Plasma Active. Active is not an adjective in this case. > 3. It's "more complicated than loading a Linux distro on a standard laptop" > (Why?) if there's a pre-built image for the device you have, then it's dead simple. i just installed an image with ~4 keystrokes and 10 minutes of my time. if there isn't a pre-built image for your exact device, then it's a lot harder because of the lack of standardization in ARM based devices. > 4. And this is where I really have concerns. > Several of the screenshots have windows. they aren't windows. please try the software before forming opinions and offering input :) > Trashcans on every image in what I assume is a gallery. it isn't a gallery. it's the activity switcher. please read the documentation, or watch one of the Plasma Active intro videos, to see how it works > http://plasma-active.org/screenshots/PlasmaActive_AddResource.png > I dread what the Add Items button does. that's because you haven't used it, nor, apparently, read any documentation or watched even an intro video :) > It it open a file browser, FAIL. no, it doesn't. > Why does this have a "close" button but everything else in the previous > snapshot had an X in the top right? you'll like PA3 more then, as the cancel button is in the top right. and it's "cancel" as opposed to an "X" since it actually cancels the action (symetry with the Add button). it works in practice. > Search box is way too mall. again, try it. it's better than you think. i can fit ~12 characters into it, and i rarely need more than 5-6 before the options are narrowed down to just a couple of items. > Ditch the window size thing. Tablet users don't want to manage that stuff. all applications run full-screen. > - Forget the icon containers as they are. I think I understand what you're > trying to do though. i don't think you do. > Rather it'd be cooler to have application sets and > each set is docked to an edge of the screen (like the gallery) and much > like the OSX bar. you really need to try it. then you'll discover that we've done exactly what you describe here, only much much much better because it isn't limited to applications or even to just the home screen. > Then attach to it the task killer/switcher thing in a > later slide. Also on that, put the apps list so you can drag/drop from the > global app pool to the application set for that screen. instead of spending your time writing this email you could tried PA out or even just watched some videos of PA. you would have discovered this is very much how it works. instead, this unfortunate email of yours is now immortalized in a searchable online email list archive. eep. now, i don't want to discourage your enthusiasm, and i hope you appreciate the time i've taken to respond; however this kind of engagement is really not how we work with each other. :) we try and maintain an informed and thoughtful discourse with each other on this mailing list which is devoted to the design and development of PA. this results in higher quality from each individual participant as well as the entire project, and is one way we demonstrate our respect and appreciation for each other as professionals and enthusiasts. > - Why are there multiple icon containers per screen? try it and find out :) > - How do you get to the icon containers if they are under a window? via peek or tapping the home button. > One of the things that I think are neesed for tablet input to work is a > Swype style keyboard unfortunately swype is proprietary, but the keyboard we use in PA3 allows us to hook into such things so there is hope for the future here. -- 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
touch components issue with okular active
hi... i've run into an odd situation with active-documentviewer (aka okular touch :) where when using the touch components, the toolbar at the bottom that shows the buttons to switch between thumbnails, TOC, etc. will usually disappear off the bottom and is not reachable. if you start scrolling up it will show either momentarily, or until you release the touch. oddly, this does *not* happen with the desktop components. i can reproduce both on an exopc and on my laptop. i thought i might be a ToolBar issue at first, but this does not seem to have a touch specific implementation (or did i just miss it?). does anyone have an idea what might be causing this issue? -- 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: touch components issue with okular active
On Friday, October 5, 2012 22:59:28 Marco Martin wrote: > when the page, being thumbnails or table of contents are shorter then the > screen they should be supposed to be always there yes, this works nicely when the pages are shorter. :) it's more on file with lots of pages and/or long TOCs so it fills the page and then some -> scrolling down makes the bottom toolbar show .. and then hide again. (and that only happens with touch components.) -- 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
time for a re-roll?
hi... i just pushed the change into bodega-client to make "Store" become "Add-Ons". as this was noted as an important detail to get right (i agree..) it would be nice to re-roll the image ... is there time to do this before monday though? i've also pushed a bunch of micro-fixes into plasma-mobile that would be "nice" but not critical. if there isn't time to re-roll an image, perhaps we can announce anyways and re-roll as soon as we can. still, would be nice to go out with our best face forward ... the tag issue is a big issue that needs fixing anyways, the okular touch tabbar is a minor issue ... just might be worth a re-roll. thoughts? -- 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: time for a re-roll?
On Friday, October 5, 2012 23:55:12 Thomas Pfeiffer wrote: > On Friday 05 October 2012 23:14:55 Aaron J. Seigo wrote: > > hi... > > > > i just pushed the change into bodega-client to make "Store" become > > "Add-Ons". > > Nice :) Sorry for being really nitpicky now, but while you're at it, could > you maybe also change the window tittle? It currently says "Add Ons App". > This would make it perfect :) perfection it is. it's in master now, just needs to be picked up by the build. > we haven't even announced a date yet, so I don't think we'd lose much by > delaying the release a few days. well, we're over a month after we thought we'd release (though we didn't set a firm date. bad us! let's put a date on our next release once this one is out). but, yes .. i'd rather delay a day or two at this point as well. > > the tag issue is a big issue that needs fixing anyways, the okular touch > > tabbar is a minor issue ... just might be worth a re-roll. thoughts? > > We should not release without the tag issue fixed. We're strongly > advertising Files, so people will try it out and when they run into that > problem right away, it looks really bad. agreed. -- 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: time for a re-roll?
On Friday, October 5, 2012 23:44:00 Marco Martin wrote: > seems really that Nepomuk::Tag tag( string ); > creates a new tag any time sounds like an email (and maybe a minimal test case) is in order for vhanda? -- 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: time for a re-roll?
On Sunday, October 7, 2012 20:25:14 Marco Martin wrote: > On Friday 05 October 2012, Aaron J. Seigo wrote: > > the tag issue is a big issue that needs fixing anyways, the okular touch > > tabbar is a minor issue ... just might be worth a re-roll. thoughts? > > in the repository now tags seems to work (would like others test it too :p) > and your last commits are in. cool; will update tonight and test. as a side note -> i pushed a bunch of fixes to okular active. most importantly, a fix for the "some thumbnails don't paint" bug. thumbnails requesting pixmap renders is also decreased by 2-3x. a few other little bugs were fixed, but nothing critical compared to those two things. as for serializing the thumbnail painting requests, i tried one approach (still here in a local branch) which ran into some walls as to how QML works (lots of creating and deleting of thumbnail items, for instance) and how Okular works (can't cancel a page render). it wasn't a complete waste of time, as it has led to an alternative mechanism that should hopefully work. in any case, the okular repo could use a re-pull if we need to re-roll the image still. -- 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: time for a re-roll?
On Monday, October 8, 2012 00:17:34 Thomas Pfeiffer wrote: > Now with Aarons updates, Okular Active segfaults directly on launch :( hm.. it was dieing here on launch as well, but after a rebuild of both plasma- mobile and okular-active it started working again for me. seemed like a binary compat issue as a simple rebuild cleared up the issue ... if you can get a backtrace, that'd be handy. -- 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: Calligra Active's main screen
On Monday, October 8, 2012 08:31:23 Shantanu Tushar Jha wrote: > Seems like missed communication here, I was told that once Plasma Active's > "Files" application is complete, documents would be launched from there and > so Calligra Active won't be included in the launcher. of course, once there is editing capabilities in the touch version which can be used to create documents from scratch (which is a lower priority than getting the viewer functionality into amazing shape), then it should go into the launcher again. opening existing files should probably still go into the file manager. or who knows, perhaps we'll also put file creation triggering into the file manager? -- 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: Calligra Active's main screen
On Monday, October 8, 2012 11:07:12 Marco Martin wrote: > I think that is mostly a design problem, the two things are not really > against each other, in the end apps should either reuse the file browser as > a component (still figuring out how to do that) or be able to provide > custom components (and artwork) for the file browser when browsing the > files of type x. very good points we need to work out in more detail. my suggestion is that we table these discussions for the next release. the file browser is a great start, and i think we polish up the existing feature set in a number of ways. but let's focus right now on getting this out as it is .. it's already pretty sexy; hard to believe it's a "1.0" application. -- 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 308101] all Activities switcher thumbnails are the same; no new Activity can be selected
https://bugs.kde.org/show_bug.cgi?id=308101 --- Comment #2 from Aaron J. Seigo --- i can replicate this on my test build on the laptop as well. looking into it now... (and i have a suspicion as to what it might be) -- You are receiving this mail because: You are on the CC list for the bug. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
[Bug 308101] all Activities switcher thumbnails are the same; no new Activity can be selected
https://bugs.kde.org/show_bug.cgi?id=308101 Aaron J. Seigo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Latest Commit||http://commits.kde.org/kde- ||runtime/b7f490bd6b6e0d12d60 ||573b4316e2931b0dc51f0 --- Comment #3 from Aaron J. Seigo --- Git commit b7f490bd6b6e0d12d60573b4316e2931b0dc51f0 by Aaron Seigo. Committed on 09/10/2012 at 11:17. Pushed by aseigo into branch 'KDE/4.9'. dataengine based models set their roles when setting the data, so respond to that syncRoleNames is fast (and faster now that we check that the role names actually changed) but it may be nicer to find a more efficient way in future than checking the role names on all / any data changes. in fact, the documentation for QAbstractItemModel::setRoleNames says: "This function must be called before the model is used. Modifying the role names after the model has been set may result in undefined behaviour." M +5-5plasma/declarativeimports/core/datamodel.cpp http://commits.kde.org/kde-runtime/b7f490bd6b6e0d12d60573b4316e2931b0dc51f0 -- You are receiving this mail because: You are on the CC list for the bug. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
[Bug 308101] all Activities switcher thumbnails are the same; no new Activity can be selected
https://bugs.kde.org/show_bug.cgi?id=308101 Aaron J. Seigo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Latest Commit||http://commits.kde.org/kde- ||runtime/b7f490bd6b6e0d12d60 ||573b4316e2931b0dc51f0 Latest Commit|http://commits.kde.org/kde- |http://commits.kde.org/kde- |runtime/b7f490bd6b6e0d12d60 |runtime/88463eabb8c45c91778 |573b4316e2931b0dc51f0 |f5d97991467e08dc28a53 --- Comment #3 from Aaron J. Seigo --- Git commit b7f490bd6b6e0d12d60573b4316e2931b0dc51f0 by Aaron Seigo. Committed on 09/10/2012 at 11:17. Pushed by aseigo into branch 'KDE/4.9'. dataengine based models set their roles when setting the data, so respond to that syncRoleNames is fast (and faster now that we check that the role names actually changed) but it may be nicer to find a more efficient way in future than checking the role names on all / any data changes. in fact, the documentation for QAbstractItemModel::setRoleNames says: "This function must be called before the model is used. Modifying the role names after the model has been set may result in undefined behaviour." M +5-5plasma/declarativeimports/core/datamodel.cpp http://commits.kde.org/kde-runtime/b7f490bd6b6e0d12d60573b4316e2931b0dc51f0 --- Comment #4 from Aaron J. Seigo --- Git commit 88463eabb8c45c91778f5d97991467e08dc28a53 by Aaron Seigo. Committed on 09/10/2012 at 11:17. Pushed by aseigo into branch 'master'. dataengine based models set their roles when setting the data, so respond to that syncRoleNames is fast (and faster now that we check that the role names actually changed) but it may be nicer to find a more efficient way in future than checking the role names on all / any data changes. in fact, the documentation for QAbstractItemModel::setRoleNames says: "This function must be called before the model is used. Modifying the role names after the model has been set may result in undefined behaviour." M +5-5plasma/declarativeimports/core/datamodel.cpp http://commits.kde.org/kde-runtime/88463eabb8c45c91778f5d97991467e08dc28a53 -- You are receiving this mail because: You are on the CC list for the bug. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
[Bug 308101] all Activities switcher thumbnails are the same; no new Activity can be selected
https://bugs.kde.org/show_bug.cgi?id=308101 --- Comment #5 from Aaron J. Seigo --- Git commit 67ed4501818386fb16f9e31dda496514382133d4 by Aaron Seigo. Committed on 09/10/2012 at 11:29. Pushed by aseigo into branch 'KDE/4.9'. turns out we have to set the role names constantly to make sorting actually work even just setting the sort/filter roles is not enough. role names must also be set again! gh. thankfully this seems to be very fast, though would still be nice to avoid it if possible somehow. M +3-3plasma/declarativeimports/core/datamodel.cpp http://commits.kde.org/kde-runtime/67ed4501818386fb16f9e31dda496514382133d4 -- You are receiving this mail because: You are on the CC list for the bug. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
