Re: Workspace Next Sprint Organization
On Wednesday, May 16, 2012 05:24:56 Alex Fiestas wrote: On Tuesday, May 15, 2012 10:07:08 AM Björn Balazs wrote: Have you been aware of this vision? No. If no: looking back would it have been helpful for your work if you had known it (and how)? No (I don't see how to apply it on Bluedevil / RandR / Kamoso). two that are immediately applicable: * organic and scalable user interfaces * integration with activities beyond that, bluedevil (to pick an example) will also have its own goals that are not generic to the overall shell development, just as, say, the microblog plasmoid does. Is it too general / just right / too specific? I think it is focused on the shell while we are working towards a workspace, which includes more things than the shell in your opinion, in what ways is it focused on the shell? (working out a definition for workspace would be nice too). so we can determine what is and what is not part of the workspace? (just to be clear before i start writing about it, only to find out i'm writing about something you weren't talking about ;) Is there anything missing or unnecessary in it? I'm surprised that the word application doesn't appear even once, the most this is where i pop out of a giant birthday cake and yell SURPRISE! ;) applications are a means to an end. imho: the various aspects of how to interact with applications (launch, switch..) can be viewed as specific use cases to define and accomodate, but applications are not the primary focus of the workspace in the sense that everything else is secondary to that. basic thing to do with the shell is switching and launching applications. so is setting the network, checking the time, etc. Once that is done in a excellent way, then we can think on how complement it. this is considering mechanism (how to do X) before defining the principles. i think it would be great if people wish to focus on making application interaction fantastic, but be clear that can not be an overarching vision. btw, when it comes to applications specifically, some principles we agreed on: * the workspace components should look distinct from applications so it is immediately clear which is mine and which is the system * the workspace should frame applications nicely but not get in their way * the workspace should provide centralized, consistent management and display of services applications use (downloading, notifications, etc) (p.s. instead of in an excellent way i would suggest in an elegant way; excellent is an personally subjective value judgement, while elegance has a definition for what it means to the end product .. prefer objective over subjective statements in these exercises as that will make creating results based on the resulting goal statements easier to keep consistent.) My answer is based on my experience using the current shell. A possible objective for the next thing would be change that habit and make users spent more time on the shell. s/make user spent more time on the shell/make the shell something people want to spend more time with/ the question is, of course, why? nothing should be done just because. i do think that the shell should receive more time by the person using the computer, and the why is that it can do a rather good job as a starting point and overview of tasks and information in a way that individual applications can't. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workspace Next Sprint Organization
On Wednesday 16 May 2012, Alex Fiestas wrote: On Tuesday, May 15, 2012 10:07:08 AM Björn Balazs wrote: Have you been aware of this vision? No. If no: looking back would it have been helpful for your work if you had known it (and how)? No (I don't see how to apply it on Bluedevil / RandR / Kamoso). Is it too general / just right / too specific? I think it is focused on the shell while we are working towards a workspace, which includes more things than the shell (working out a definition for workspace would be nice too). Is there anything missing or unnecessary in it? I'm surprised that the word application doesn't appear even once, the most basic thing to do with the shell is switching and launching applications. Once that is done in a excellent way, then we can think on how complement it. probably because one of the goals was always getting away with the traditional application centric paradigm (contrary to the other tendencies of making a big iphone launcher the center of the workspace ;), putting in the center instead activities and resources (not necessarily files, a bit beyond the other usual one, the document centric ui) so if something gets open by an application or a workspace components, or what is what becomes a not too relevant question. is something that is still miles from being realized, and unsurprisingly enough is a bit more complete on plasma active (no legacy there) that's just to clarify a bit of why of the design Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
request: create panel and plasma colors configuration tool
Please, create panel and plasma colors, fonts and other plasma elements configuration tool. Especially I'd like to be able easily change font size, font color, active and inactive application tab color on panel, date color, kickoff fonts and color, transparency, gradient. As a new KDE user I find it a nightmare. Please, don't take it as another complaint. I appreciate all your hard work. I just describe my experience. I tried to customize for two days my KDE desktop and I am very confused. I have an impression that some panel colors can be changed from settings, I mean has something to do with global application colors and some cannot be changed. Maybe I am wrong. I just wish it could be more intuitive and simple. There are some plasma themes on KDE-look but honestly, there is not a big choice and it is hard for me to pick one that suits my specific custom color set for applications. For users that are not developers it is hard to edit all these configuration files manually. So, the choice is narrow - either you like what you get or you can't customize. Perhaps it won't be a priority for you but at least please accept the idea and start talking about it. You can also discuss the topic here: http://forum.kde.org/viewtopic.php?f=113t=101989 I also wish color setting in desktop settings section could be more intuitive. I mention about it here: http://forum.kde.org/viewtopic.php?f=17t=101931 But perhaps this is a different story. I write here on development list because I am not sure whether you read forum. -- Gnomek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: powermanagementprofilesrc: slow down dimming time
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104944/ --- Review request for Plasma and Marco Martin. Description --- This patch slows down the display dimming time from nearly a second to 120 seconds. Diffs - appconfig/powermanagementprofilesrc 12bfd1a Diff: http://git.reviewboard.kde.org/r/104944/diff/ Testing --- Verified on 2012-05-14-12-42-basyskom-plasma-active-devel-mer-usb-live.iso Thanks, Maurice de la Ferte ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Backport 'Fixed Lancelot build when pimlibs are not present'
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104875/#review13862 --- Any objections here? - Michael Palimaka On May 6, 2012, 7:27 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104875/ --- (Updated May 6, 2012, 7:27 p.m.) Review request for Plasma. Description --- This patch is currently in master and works great, but the problem is still present in KDE/4.8. Any objection to backporting it? Diffs - libs/lancelot-datamodels/MessagesKmail.cpp 7c663704dfa2079a99f58935784559de73abb03a Diff: http://git.reviewboard.kde.org/r/104875/diff/ Testing --- Thanks, Michael Palimaka ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workspace Next Sprint Organization
On Wednesday, May 16, 2012 05:34:47 Alex Fiestas wrote: Plasma workspace should be excellent on launching, switching and getting applications and it shouldn't bother the user while using those. i think it is a fine (start to a) functional goal to reach for, in that it approaches a specific use case (applications). i don't see the why, nor something that could be used as a way to know when excellence is reached or how to get there. and to echo an earlier question of yours, i don't see how to apply it to Bluedevil / RandR / Kamoso? (i'm fine that it doesn't, i'm just curious that this was on your mind earlier, but i don't see how it fits here..) For the users that need it, which people need it? which don't? why? There is another part of my vision focused on developers, I don't think it is relevant here. be daring and share it anyways ;) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Workspace Next Sprint Organization
On Wednesday, May 16, 2012 11:02:34 AM Aaron J. Seigo wrote: On Wednesday, May 16, 2012 05:34:47 Alex Fiestas wrote: Plasma workspace should be excellent on launching, switching and getting applications and it shouldn't bother the user while using those. i think it is a fine (start to a) functional goal to reach for, in that it approaches a specific use case (applications). I think I already asked this in another email (I'm jetlagged so my brain is acting weird XD) but, why is this specific? and to echo an earlier question of yours, i don't see how to apply it to Bluedevil / RandR / Kamoso? (i'm fine that it doesn't, i'm just curious that this was on your mind earlier, but i don't see how it fits here..) It doesn't, it only applies to the shell (plasma-workspae + kwin), which I did in purpose because I'm not sure of what a desktop | workspace contain. If we include bluedevil, randr etc into the workspace then the vision should be extended. For the users that need it, which people need it? which don't? why? You only need to organize things when you have things to organize. A user that only wants to watch lolcats on youtube and talk to friends via facebook doesn't. A user that use the computer for multiple things or in multiple areas (work, home) may want to. There is another part of my vision focused on developers, I don't think it is relevant here. be daring and share it anyways ;) The workspace should be extensible by third party developers and thus should be able to integrate their applications with it not mattering on which technology the application is written. Nothing that current plasma can't do. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Versions and commit hooks
Hi everyone, after checking with Aaron and to make bug handling easier I have set versions and milestones to the product plasma in http://bugs.kde.org. It would be great if you could from now on use the commit hook FIXED-IN when you fix a bug. The currently available milestones you can use are: 4.6 4.7 4.8 4.8.1 4.8.2 4.8.3 4.8.4 4.9-git 4.9.0 4.9.1 4.9.2 The milestones prior to 4.9.0 can be used by triagers when finding fixed bugs that were not closed already. A default milestone can be set as a target if there is need for, I left it blank for now. I didn't add product versions prior to 4.5 as this is already obsolete anyway, so all reports for 4.5 or before have exactly that version number: 4.5 or before. Please tell me if a version is missing or something needs to be changed. Regards, Myriam -- Proud member of the Amarok and KDE Community Protect your freedom and join the Fellowship of FSFE: http://www.fsfe.org Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workspace Next Sprint Organization
On Wednesday 16 May 2012, Alex Fiestas wrote: On Wednesday, May 16, 2012 09:49:22 AM Aaron J. Seigo wrote: On Wednesday, May 16, 2012 05:24:56 Alex Fiestas wrote: On Tuesday, May 15, 2012 10:07:08 AM Björn Balazs wrote: Have you been aware of this vision? No. If no: looking back would it have been helpful for your work if you had known it (and how)? No (I don't see how to apply it on Bluedevil / RandR / Kamoso). two that are immediately applicable: * organic and scalable user interfaces I don't exactly now what those are, can you explain? or better, can you apply those concepts to the current BlueDevil implementation? organic: looking less as a computer object, but interacting more as a real object: so animated instead of immediate transitions (something appearing immediately is magic), rounded corners, shadows, preferring direct manipulation rather than by some proxy (ie resize by dragging instead of writing the number of pixels somewhere) and many things like that. if you compare with kde3 we are miles ahead on this regard but still not there. note that this is different, and risking to be confused with skeuomorphism (http://en.wikipedia.org/wiki/Skeuomorph), that tends to destroy coherence and create uncanny valleys, so one moves over a thin line here ;) scalable: mostly referring to the available space so screen size (or just containment size, applets in panels vs desktop) we started with the formfactor concept and gone forward with the device specific qml files for plasmoids (experimental news reader, microblog) to go in implementation details (ok, we shouldn't too much just yet :p), in the future, provided decent quality desktop components will be there, i see both workspace and applications being able to work as full desktop apps, limited mobile apps and plasmoids with the same c++ logic, and the least possible difference in qml files (from experience is possible to do 2 completely different interfaces still sharing 90% of the qml code) * integration with activities How would you integrate BlueDevil or Kamoso with Activities? like the power profiles right now... possible scenario: you use often browse the web on the laptop while on the train every day, that involves using the 3g phone modem over bluetooth, but more powersave for things != from bluetooth in the laptop... (probably use cases like that should be used as starting point to see what could be useful or not) For RandR I could add the posibility of modify the default settings and tied them to Activity (pretty much like PowerDevil does right now). Not that interesting imho. a little inner voice is whispering presentation with a beamer ;) the activity switch causing also the powermanagement settings to switch and the right presentation files to open could even be triggered by the detection of the projector :p /bluesky Is it too general / just right / too specific? I think it is focused on the shell while we are working towards a workspace, which includes more things than the shell in your opinion, in what ways is it focused on the shell? (working out a definition for workspace would be nice too). so we can determine what is and what is not part of the workspace? (just to be clear before i start writing about it, only to find out i'm writing about something you weren't talking about ;) Well my objective would be So we can create a vision around it. So, what is the workspace for you? Considering that applications like Dolphin or Gwenview are part of it as well as Solid (hardware integration) I find many parts of that vision vaguely applicable or at least not clearly applicable. to me the boundaries should blurry more and more until nobody cares what an app is, every functionality shared in any way between apps, just going in the global environment (like we did with slc) dolphin should be part of the workspace without the user even noticing on what they are using (yeah, i know that for the developer having the name of his product well visible is important and ) Also there are some parts of the vision I don't understand, imho we should explain them or use other words. yep, i agree especially in last years there wasn't much put out on the outside -scalable interfaces ? -today's contexts ? -direct manipulation interfaces -organic look and feel. hmm, maybe a glossary could be compiled on the wiki? also some of them derive from actual psychology studies (like why not having sliding animations for appearing things plays bad tricks to the brain), I would like having a bit of bibliography on this, but sadly i don't :/ there is a minimum common language that should really be a given for participating on a thing like that, I advise to everybody (but especially to who is coming there) some good reads (those are more about ux design details but are concept useful anyways for a broader vision definition):
Re: Workspace Next Sprint Organization
On Wednesday, May 16, 2012 11:14:46 Alex Fiestas wrote: On Wednesday, May 16, 2012 09:49:22 AM Aaron J. Seigo wrote: On Wednesday, May 16, 2012 05:24:56 Alex Fiestas wrote: On Tuesday, May 15, 2012 10:07:08 AM Björn Balazs wrote: Have you been aware of this vision? No. If no: looking back would it have been helpful for your work if you had known it (and how)? No (I don't see how to apply it on Bluedevil / RandR / Kamoso). two that are immediately applicable: * organic and scalable user interfaces I don't exactly now what those are, can you explain? or better, can you apply those concepts to the current BlueDevil implementation? * integration with activities How would you integrate BlueDevil or Kamoso with Activities? For RandR I could add the posibility of modify the default settings and tied them to Activity (pretty much like PowerDevil does right now). Not that interesting imho. Is it too general / just right / too specific? I think it is focused on the shell while we are working towards a workspace, which includes more things than the shell in your opinion, in what ways is it focused on the shell? (working out a definition for workspace would be nice too). so we can determine what is and what is not part of the workspace? (just to be clear before i start writing about it, only to find out i'm writing about something you weren't talking about ;) Well my objective would be So we can create a vision around it. So, what is the workspace for you? Considering that applications like Dolphin or Gwenview are part of it as well as Solid (hardware integration) I find many parts of that vision vaguely applicable or at least not clearly applicable. Also there are some parts of the vision I don't understand, imho we should explain them or use other words. -scalable interfaces ? -today's contexts ? -direct manipulation interfaces -organic look and feel. I can understand Steve's or President John F. Kennedy visions without having to know specifics about politics, device designing or any particular area. Is there anything missing or unnecessary in it? I'm surprised that the word application doesn't appear even once, the most this is where i pop out of a giant birthday cake and yell SURPRISE! ;) applications are a means to an end. imho: the various aspects of how to interact with applications (launch, switch..) can be viewed as specific use cases to define and accomodate, but applications are not the primary focus of the workspace in the sense that everything else is secondary to that. That applies to the current vision I guess. basic thing to do with the shell is switching and launching applications. so is setting the network, checking the time, etc. How many times do you do operations with your applications and how many times you do other things? The only thing I do repeatedly with the shell (now that you say it) is checking the time. * the workspace components should look distinct from applications so it is immediately clear which is mine and which is the system * the workspace should frame applications nicely but not get in their way * the workspace should provide centralized, consistent management and display of services applications use (downloading, notifications, etc) Are all these things docummented somewhere? there was something started quite some time ago by .. i forget who? .. here: http://community.kde.org/Plasma/TheWaysOfThePlasma there are other bits spread around the wiki there as well. i am fully supportive of streamlining and updating the text. i do think that the shell should receive more time by the person using the computer, and the why is that it can do a rather good job as a starting point and overview of tasks and information in a way that individual applications can't. I can imagine a future where my workspace acts as a iGoogle (www.google.com/ig) or something like that, and I can imagine that being sorted by activity etc I saw it in Active and I like it but I don't think that should be the vision but instead part of it. here's where you lose me because that *is* the vision we've been working towards. device spectrum, organic scalable interfaces and activities. arriving 4 years into that and then saying let's not to those who have been doing the work is .. well ... :/ the alternative proposed of make applications launch great is anemic in comparison. it is very clear you have a set of concepts you wish to work on, and that is important. but i'd like to challenge you to look around those concepts and place them within the context of a larger scope of ideas, and then design from that point of reference. this is what vision and design do for each other ... Applications are too important to be excluded from it in many ways, the i agree that applications need to be well supported. how that happens
Re: Workspace Next Sprint Organization
On Wednesday, May 16, 2012 11:50:45 Alex Fiestas wrote: On Wednesday, May 16, 2012 11:02:34 AM Aaron J. Seigo wrote: On Wednesday, May 16, 2012 05:34:47 Alex Fiestas wrote: Plasma workspace should be excellent on launching, switching and getting applications and it shouldn't bother the user while using those. i think it is a fine (start to a) functional goal to reach for, in that it approaches a specific use case (applications). I think I already asked this in another email (I'm jetlagged so my brain is acting weird XD) but, why is this specific? an answer to finding alex's email is not manage applications. an answer to turn my computer off is not manage applications. an answer to have my music volume be appropriate to what i'm doing on the system (e.g. mute it when i get an incoming call on mumble / jabber / googletalk / etc) is not manage applications. an answer to how do i organize my information, which is the reason i turned on this damn thing in the first place, so that it reflects what i'm most interest in is not manage applications etc... and to echo an earlier question of yours, i don't see how to apply it to Bluedevil / RandR / Kamoso? (i'm fine that it doesn't, i'm just curious that this was on your mind earlier, but i don't see how it fits here..) It doesn't, it only applies to the shell (plasma-workspae + kwin), which I did in purpose because I'm not sure of what a desktop | workspace contain. If we include bluedevil, randr etc into the workspace then the vision should be extended. does it need to be? the vison is not meant to be (and can not be) an explicit blueprint of every possible feature and how it looks. it is the collection of goals and values that every feature must meet when it is implemented. so we don't necessarily extend the vision when the applications involved grows; we need to see how those applications can reflect the vision. of course, these new additions may raise new questions, widen the scope. and if so, then yes, we need to tune the vision in recognition of that. however, that is not a given. the vision does not automatically require extension because the tool set grows. For the users that need it, which people need it? which don't? why? You only need to organize things when you have things to organize. A user that only wants to watch lolcats on youtube and talk to friends via facebook doesn't. (another example might be: a person working in a call center that uses 2-3 applications on their computer which is defined by the IT staff) A user that use the computer for multiple things or in multiple areas (work, home) may want to. which is more common, which do we want to design for? is one a super-set of the other? if so, can we design for that super-set of needs? There is another part of my vision focused on developers, I don't think it is relevant here. be daring and share it anyways ;) The workspace should be extensible by third party developers and thus should be able to integrate their applications with it not mattering on which technology the application is written. sounds good to me .. we've also tried to focus on easy so that we avoid something super duper flexble and extensible but also too hard to make things for preventing people from doing so; we've also tried to focus on produces nice results so that people feel rewarded for their efforts (sth kicker failed at imho, resulting in orders of magnitude fewer addons for it compared to plasma) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workspace Next Sprint Organization
On Wednesday, May 16, 2012 11:14:46 Alex Fiestas wrote: So, what is the workspace for you? the components that take care of supporting the working area of the computer and practices of the person using the system. these tasks include: * user session start / stop / switch * power management * application launch * window management * locating resources available on or to the device * quick reference to information (some items in the system tray do this, some plasmoids do this) * interaction with system services (local file indexing, sound, networking, etc.) * presentation of actions belonging to the system (from a user's POV), which would include things like file operation progress or notifications perhaps there are others as well. all of these bits need to be fit well together. and applications which don't play a key role in the above are not part of the workspace. so there's a bit of scope to which we can add a set of big idea goals (aka vision) so we can chart how to accomplish each of the things in the list above. Considering that applications like Dolphin or Gwenview are part of it as dolphin and gwenview are applications. they are not part of the workspace. this is evident because: * they fulfill specific tasks (file management, image viewing); in contrast plasma-desktop, kwin, krunner and system integration components such as bluedevil do not meet specific tasks but enable one to engage in those tasks. you can use kwin without a file manager; it's annoying to use dolphin without a file manager. it's the app/system split. * they can be used in other desktop / workspace implementations without feeling foreign or that they are duplicating an integral system service * the workspace can be used without them without any degredation of service well as Solid (hardware integration) I find many parts of that vision vaguely applicable or at least not clearly applicable. that's because they are not part of the workspace. that begs the question: should we have an application vision? hell yes! (we have one for Active, btw...) should it harmonize with the workspace vision? double hell yes! there will be commonalities, there will also be differences. big ones. applications are all about framing and delivering content. the workspace needs to get out of the way of that as much as possible and provide an integrative system for those applications to tap into. the vision for an image viewer is neatly confined by the defined task. the vison for a workspace is not, so those boundaries and parameters need to be derived from a much large possible solution space. on the other hand, it can also embody more dynamics as a result of not having a single, self-evident task as an image viewer or file manager does. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Versions and commit hooks
On Wednesday, May 16, 2012 12:41:01 Myriam Schweingruber wrote: It would be great if you could from now on use the commit hook FIXED-IN when you fix a bug. The currently available milestones you thanks for doing this, Myriam. now let's actually use this. Myriam wrote it would be great and i agree, so .. let's DO IT. :) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Versions and commit hooks
On Wed, May 16, 2012 at 12:41 PM, Myriam Schweingruber myr...@kde.org wrote: Hi everyone, after checking with Aaron and to make bug handling easier I have set versions and milestones to the product plasma in http://bugs.kde.org. It would be great if you could from now on use the commit hook FIXED-IN when you fix a bug. The currently available milestones you can use are: 4.6 4.7 4.8 4.8.1 4.8.2 4.8.3 4.8.4 4.9-git 4.9.0 4.9.1 4.9.2 The milestones prior to 4.9.0 can be used by triagers when finding fixed bugs that were not closed already. A default milestone can be set as a target if there is need for, I left it blank for now. I didn't add product versions prior to 4.5 as this is already obsolete anyway, so all reports for 4.5 or before have exactly that version number: 4.5 or before. Please tell me if a version is missing or something needs to be changed. Regards, Myriam -- Proud member of the Amarok and KDE Community Protect your freedom and join the Fellowship of FSFE: http://www.fsfe.org Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel I'm sorry but I never understood the FIXED-IN: tag, if somebody explains it maybe if I understand it, it will be easier to add this information (like I've done with others, like BUG). In git you know if a bug it's fixed in a release because the release log contains the bug fix. That is: git log KDE/4.8..KDE/4.9 | grep BUG: id To know if it's in a minor version, we can check if it's after the release tag (if it's after 4.9.2 tag, then it's in 4.9.3). So, what does FIXED-IN tag offer? Or is it just a hack because we don't have the proper tool set? Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Versions and commit hooks
Am 16.05.2012 13:28, schrieb Aleix Pol: So, what does FIXED-IN tag offer? Or is it just a hack because we don't have the proper tool set? Your users who reported the bug don't have git log and cannot know when the bug fix will appear. Adding the information will fill in the Version fixed-in field in the bug report so that your user sees when the bug will be fixed. Consider the situation when master is opened again and 4.9 not yet released. A user would not understand that the bug will not be fixed before 4.10 unless you state so. For us it's not such a useful information, but for the user it's a very valuable information which we can and should easily provide. Furthermore you can use the ChangelogGenerator to generate the changelog based on the version fixed-in field. The git log is unsuited for changelogs as it is too technical. Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workspace Next Sprint Organization
On Wednesday, May 16, 2012 11:14:46 Alex Fiestas wrote: well as Solid (hardware integration) separate email for a separate topic: frameworks and the workspace definition. :) Solid is not part of the workspace. neither is libplasma. they are frameworks that can and are used by applications that are not part of the workspace and function outside of our workspace environments just fine. plasma-desktop, krunner, kwin, plasma networkmanager, kmix, bluedevil etc etc are (or could be) part of the workspace. they are application and use both of these frameworks. libplasmagenericshell, libplasmaclock, libkworkspace, libtaskmanager .. these are all parts of the workspace as well, though they are essentially implementation details. unlike Solid or libplasma, they do not make sense outside of the plasma workspace and are exclusively designed for and used by workspace components. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Versions and commit hooks
On Wednesday, May 16, 2012 13:28:55 Aleix Pol wrote: In git you know if a bug it's fixed in a release because the release log contains the bug fix. That is: git log KDE/4.8..KDE/4.9 | grep BUG: id very few of our users will, or even know how, to do this. everyone who reports a bug, however, knows how to check the bug reports, and that is where this tag ends up feeding into. -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: more thoughts on kwin and window thumbnails in plasma shells
On Tuesday 15 May 2012, Martin Gräßlin wrote: well, is just that when the world goes into the compositor, the probability of this happening skyrockets ;) Let's try to get our software working and not thinking about solutions for the case that our software is buggy. If we allow ourself to consider that software components could lock up, our users who blame us for bad quality are right. I want us all to get to a point where we don't have to even think in the direction of a compositor lockup. uuuh, not really, our software should be less buggy? sure. but fault tolerance is an essential part of quality, not just fault prevention. one should not influence the other. Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Workspace Next Sprint Organization
On Wednesday, May 16, 2012 12:51:16 PM Marco Martin wrote: On Wednesday 16 May 2012, Alex Fiestas wrote: On Wednesday, May 16, 2012 09:49:22 AM Aaron J. Seigo wrote: On Wednesday, May 16, 2012 05:24:56 Alex Fiestas wrote: On Tuesday, May 15, 2012 10:07:08 AM Björn Balazs wrote: Have you been aware of this vision? No. If no: looking back would it have been helpful for your work if you had known it (and how)? No (I don't see how to apply it on Bluedevil / RandR / Kamoso). two that are immediately applicable: * organic and scalable user interfaces I don't exactly now what those are, can you explain? or better, can you apply those concepts to the current BlueDevil implementation? organic: looking less as a computer object, but interacting more as a real object: so animated instead of immediate transitions (something appearing immediately is magic), rounded corners, shadows, preferring direct manipulation rather than by some proxy (ie resize by dragging instead of writing the number of pixels somewhere) and many things like that. if you compare with kde3 we are miles ahead on this regard but still not there. note that this is different, and risking to be confused with skeuomorphism (http://en.wikipedia.org/wiki/Skeuomorph), that tends to destroy coherence and create uncanny valleys, so one moves over a thin line here ;) scalable: mostly referring to the available space so screen size (or just containment size, applets in panels vs desktop) we started with the formfactor concept and gone forward with the device specific qml files for plasmoids (experimental news reader, microblog) Thanks for the definitions. Both organic and scalable interfaces are means to an end if i understood them correctly: making interfaces that feel natural. Maybe we should put that into the vision instead? For RandR I could add the posibility of modify the default settings and tied them to Activity (pretty much like PowerDevil does right now). Not that interesting imho. a little inner voice is whispering presentation with a beamer ;) the activity switch causing also the powermanagement settings to switch and the right presentation files to open could even be triggered by the detection of the projector :p /bluesky Oh that's a good idea indeed! I'm a bit worried though about things changing automagically. Considering that applications like Dolphin or Gwenview are part of it as well as Solid (hardware integration) I find many parts of that vision vaguely applicable or at least not clearly applicable. to me the boundaries should blurry more and more until nobody cares what an app is, every functionality shared in any way between apps, just going in the global environment (like we did with slc) dolphin should be part of the workspace without the user even noticing on what they are using (yeah, i know that for the developer having the name of his product well visible is important and ) *** fuck ego's *** :p Also there are some parts of the vision I don't understand, imho we should explain them or use other words. yep, i agree especially in last years there wasn't much put out on the outside -scalable interfaces ? -today's contexts ? -direct manipulation interfaces -organic look and feel. hmm, maybe a glossary could be compiled on the wiki? also some of them derive from actual psychology studies (like why not having sliding animations for appearing things plays bad tricks to the brain), I would like having a bit of bibliography on this, but sadly i don't :/ there is a minimum common language that should really be a given for participating on a thing like that, I advise to everybody (but especially to who is coming there) some good reads (those are more about ux design details but are concept useful anyways for a broader vision definition): http://www.andrewschechterman.com/AndrewSchechterman/Qi_Fa_files/UX%20Glossa ry.pdf http://cyborganthropology.com/UX_Glossary http://blog.usabilla.com/the-usability-abc-part-2/#more-3075 http://uxmag.com/ If for understanding our vision we have to read all that then it is not a good vision imho. Maybe I don't understand what a vision should is though (this is the first time I'm participating in something like this). i think most of what's written in a permanent place is there: http://community.kde.org/Plasma#Interface_Standards_and_Research sadly quite outdated. a thing that would be very good from the sprint by the non coders that will participate is to write, write and write about those topics ;) I hope seba's is updated since he is the only core plasma developer comming (aham aham u.U). At the end a user spent most of its time on applications. true, but the fact that this distinction exists in the first place may be part of the problem (false dichotomy?) ie with the machine i want to perform task x to produce or view a certain thing,
Re: more thoughts on kwin and window thumbnails in plasma shells
On Tuesday, May 15, 2012 23:25:40 Martin Gräßlin wrote:
On Tuesday 15 May 2012 20:35:01 Marco Martin wrote:
On Tuesday 15 May 2012, Martin Gräßlin wrote:
On Tuesday 15 May 2012 14:13:24 Aaron J. Seigo wrote:
how
does this resolve the window thumbnail issue? you can share GL
textures
between processes. this is dependent on the OpenGL stack on the system
(it is not something OpenGL itself provides and it is done different
on
windows than x.org; probably different again in wayland), but it
works.
in fact, we found an example that does exactly this in zack's graphics
dojo repo from when he worked at trolltech (yes, trolltech .. before
nokia).
I am not sure whether that would work at all. What we have here are not
normal textures but textures from pixmaps. I fear that this makes quite
some difference especially concerning the damage events.
since kwin can draw thumbnails with the correct update window, i assume it
has the correct pixmap any given moment? can't that be shared?
We don't need KWin to share the pixmap - Plasma can play compositor any time
it wants. But be aware that a window is composited through more than just
the pixmap.
And now we are back to what I don't want to see any more: adding hacks on
hacks to make hacks working. Seriously?
do we need to pass X pixmaps around
because we know that the activation of X properties is too slow?
well, sharing textures, which is a bit different. (yes, addressed using
pixmaps, since those give a unique ID which gl textures don't on their own.
this may be different on wayland, i don't know what is available in a wayland-
only case.)
but aside from semantics, yes, i'd rather share pixmap data because the
activation of events across processes is too slow. one is slower than the
other, one keeps painting control in one place while the other tries to get
multiple processes to cooperate on it (with all the problems for interactivity
and visual consistency i said would occur years ago when people bitched about
plasmoids all being in the same process)
Aaron's initial mail described actually yet another huge hack
how is publishing and sharing textures a hack?
note that i described how what we're doing now (and have tried previously) is
a hack that causes problems.
which is
unknown to work on the future windowing system.
which windowing system does this not work on today?
why would a future windowing system drop this feature?
(there's a reason its there in the first place ...)
Can we please step back and think about what we technically want to achieve
and find the best way to achieve it.
that is precisely what i did. thanks, though.
I don't know whether moving the
Thumbnails to KWin is the best way to achieve it, but technically it sounds
more sane to me to move the complete rendering to KWin instead adding more
hacks.
moving the complete rendering to kwin *creates the need for more hacks*
itself. it is not the silver bullet solution you have convinced yourself it
is. we know this because we've been busy separating different rendering and
data paths from plasma-desktop and plasma-device for some time now to avoid
this all in one process approach specifically because it has caused real
world, user noticeable, unacceptable problems. i've enumerated some of them.
saying let's do what didn't work, but this time over there is simply not
learning from history.
Let's try to get our software working and not thinking about solutions for
the case that our software is buggy. If we allow ourself to consider that
software components could lock up, our users who blame us for bad quality
are right. I want us all to get to a point where we don't have to even
think in the direction of a compositor lockup.
with third party plasmoids and people writing plugins for plasma shells, this
happens. even if everything is QML, it still doesn't give us a great answer to
the while (1) { hah(); } problem.
let's also keep in mind that lock up can be seen at the small timeslice
scale too.
we want, what, 60fps performance? let's be kind and say nah, we're lowe
achievers ... 30fps. that gives us 33ms ... which means to hit our goal, we
need to have no code paths in the painting thread that spin the cpu for more
than 33ms at a time; well actually, it means that no code paths can spin the
cpu for more time than 33ms-$TIME_TO_COMPOSITE_THE_SCREEN .. and that's for
just 30fps.
good luck.
no, let the kernel and GPU sort it out and let's partition processes where we
reasonably can.
--
Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Workspace Next Sprint Organization
On Wednesday, May 16, 2012 12:54:16 PM Aaron J. Seigo wrote: there was something started quite some time ago by .. i forget who? .. here: According to the history of the page, by you. http://community.kde.org/Plasma/TheWaysOfThePlasma there are other bits spread around the wiki there as well. i am fully supportive of streamlining and updating the text. This is something we need to do so we can work on them before, during and after the sprint. I can imagine a future where my workspace acts as a iGoogle (www.google.com/ig) or something like that, and I can imagine that being sorted by activity etc I saw it in Active and I like it but I don't think that should be the vision but instead part of it. here's where you lose me because that *is* the vision we've been working towards. device spectrum, organic scalable interfaces and activities. arriving 4 years into that and then saying let's not to those who have been doing the work is .. well ... :/ Well you have to understand (you and any other plasma developer) that newcomers are always newcomers and if they come with preconceived ideas they are even worse so please, have patience with us/me. I have been years reading all plasma-devel and #plasma channel talking with you about all kind of things related to plasma (with you, notmart, sebas, etc) and is just know I'm learning all this vision so I need time to digest and process :p the alternative proposed of make applications launch great is anemic in comparison. it is very clear you have a set of concepts you wish to work on, and that is important. but i'd like to challenge you to look around those concepts and place them within the context of a larger scope of ideas, and then design from that point of reference. this is what vision and design do for each other ... I'm really afraid that willing to do this more complex vision we will end into something that is not good doing the basics, whatever the basics are. Specially I'm burned with the current paradigm as you all know, I hate being stressed by the defaults we have that's why I'm so tiring with the app switching. Applications are too important to be excluded from it in many ways, the i agree that applications need to be well supported. how that happens needs to be derived from the goals of the workspace in terms of user benefit, which means knoing what those goals are. support application work flow is not a vision. perhaps where you and i disagree is that i do not think any one uses an app because we like using applications. i believe we use apps because they let us accomplish specific things like read a web page. and we do those things because they fulfill needs for information, social contact, etc etc etc. I see this now (previous notmart email opened my eyes in this area), I'm still processing it. those are the elements of the goals that need to be met. the eventual design needs to reflect a deep awareness and respect of those goals. there are N different ways to launch, switch between, integrate, etc. applications. which one(s) do we want to create? well, that depends on what we want them to help the person using the system accomplish. which means: the design needs to be prefaced by the goals, or vision. vision should include: -What the desktop does when an app is executed (for example be quiet and not bother) i assume you read that i wrote almost exactly this in my previous email, yes? Yes, but it wasn't part of the vision, instead it was part of some vision extension for the application management. -Application integration. absolutely .. we started with centralized, consistent management and display of services applications use; i'm sure we can go much further, too. the question is: to accomplish what? the centralization was to provide single well-known places to do common things that run (from a user's POV) largely external to an application (aka the window we can see) in a consistent manner. the hope is to limit the number of things / places people need to learn and think about when using the system. that principle, extended, brings us to things like SLC ... what other sorts of application integration can we do, based on that goal? and, btw, i can think of other sorts of application integration we could do that don't meet the principle above. which is why starting with principles is important, because otherwise saying integrate applications will likely not result in a coherent and usefully designed thing, but a bunch of features smacked together because they are cool or seem to look nice. At the end a user spent most of its time on applications. is that why they are using the computer, to use applications? or is there something more fundamental going on for them, and applications are a means to that end? if so, what is it and how can we support that. Still processing this :p ___
Re: Workspace Next Sprint Organization
On Wednesday 16 May 2012, Alex Fiestas wrote: scalable: mostly referring to the available space so screen size (or just containment size, applets in panels vs desktop) we started with the formfactor concept and gone forward with the device specific qml files for plasmoids (experimental news reader, microblog) Thanks for the definitions. Both organic and scalable interfaces are means to an end if i understood them correctly: making interfaces that feel natural. Maybe we should put that into the vision instead? yeah, they are two parts of our definition of feel natural and maybe there are many other points, maybe some may be wrong, but we have i think to define things in different levels of detail: from a general one (having interfaces that feels natural, probably everybody agrees) to more specific definitions on what this means to us. this becomes a second level of what we want to actually achieve (animated transitions, natural looking surfaces, correct illuminations effects and so on) note that this is still quite generic, only after a while it becomes a third level: using qml or not, this or that component etc. this is is implementation. so: * what is the target ** what is our definition our parts that defines that target *** how we get there, implementation (directly resulting in tasks for people, from writing code to higs) http://www.andrewschechterman.com/AndrewSchechterman/Qi_Fa_files/UX%20Gl ossa ry.pdf http://cyborganthropology.com/UX_Glossary http://blog.usabilla.com/the-usability-abc-part-2/#more-3075 http://uxmag.com/ If for understanding our vision we have to read all that then it is not a good vision imho. Maybe I don't understand what a vision should is though (this is the first time I'm participating in something like this). if we want to start to do ux designers tasks, besides finding real ones that know how to do it, we should start to enter a bit in that mindset too. And is not only designing that particular little piece of app, this is just the last small step of the process, is understanding the system, the problems and what we need as a whole. I'm just a little amateur in that, but I find looking at existing literature of those very same problems can be enlightening, it also helps in putting yourself on others clothes (non programmers, designers, ux people etc). this, besides some years of practiche in zooming the problem solving from that particular piece of code or that particular misaligned pixel to how the ui of the whole shell interacts. try to visualize something that actually graphically zooms like a Marble map from the code that is the atoms of a particular applet/grapihc element to the whole shell and how the informations flows between the parts of this zoomed out mental picture. easy useful little mental exercise ;) sadly quite outdated. a thing that would be very good from the sprint by the non coders that will participate is to write, write and write about those topics ;) I hope seba's is updated since he is the only core plasma developer comming (aham aham u.U). 90% i should be there for some days ;) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Workspace Next Sprint Organization
On Wednesday, May 16, 2012 01:20:21 PM Aaron J. Seigo wrote: On Wednesday, May 16, 2012 11:14:46 Alex Fiestas wrote: So, what is the workspace for you? the components that take care of supporting the working area of the computer and practices of the person using the system. these tasks include: * user session start / stop / switch * power management * application launch * window management * locating resources available on or to the device * quick reference to information (some items in the system tray do this, some plasmoids do this) * interaction with system services (local file indexing, sound, networking, etc.) * presentation of actions belonging to the system (from a user's POV), which would include things like file operation progress or notifications perhaps there are others as well. all of these bits need to be fit well together. and applications which don't play a key role in the above are not part of the workspace. so there's a bit of scope to which we can add a set of big idea goals (aka vision) so we can chart how to accomplish each of the things in the list above. Considering that applications like Dolphin or Gwenview are part of it as dolphin and gwenview are applications. they are not part of the workspace. this is evident because: * they fulfill specific tasks (file management, image viewing); in contrast plasma-desktop, kwin, krunner and system integration components such as bluedevil do not meet specific tasks but enable one to engage in those tasks. you can use kwin without a file manager; it's annoying to use dolphin without a file manager. it's the app/system split. * they can be used in other desktop / workspace implementations without feeling foreign or that they are duplicating an integral system service * the workspace can be used without them without any degredation of service well as Solid (hardware integration) I find many parts of that vision vaguely applicable or at least not clearly applicable. that's because they are not part of the workspace. that begs the question: should we have an application vision? hell yes! (we have one for Active, btw...) should it harmonize with the workspace vision? double hell yes! there will be commonalities, there will also be differences. big ones. applications are all about framing and delivering content. the workspace needs to get out of the way of that as much as possible and provide an integrative system for those applications to tap into. the vision for an image viewer is neatly confined by the defined task. the vison for a workspace is not, so those boundaries and parameters need to be derived from a much large possible solution space. on the other hand, it can also embody more dynamics as a result of not having a single, self-evident task as an image viewer or file manager does. I see and I agree on all you said (again be patience with me :p). We need then something like active where we can put all visions (workspace, applications, hardware support...) and create a more unified experience. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Workspace Next Sprint Organization
On Wednesday, May 16, 2012 01:44:26 PM Aaron J. Seigo wrote: On Wednesday, May 16, 2012 11:14:46 Alex Fiestas wrote: well as Solid (hardware integration) separate email for a separate topic: frameworks and the workspace definition. :) Solid is not part of the workspace Solid == subcommunity of KDE dedicated to hardware support. When I said solid I meant BlueDEvil, Power Management, NetworkManagement, etc. You mean libsolid not solid. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workspace Next Sprint Organization
On Wednesday, May 16, 2012 14:22:40 Alex Fiestas wrote: If for understanding our vision we have to read all that then it is not a good vision imho. i offered a short paragraph that describes the overall vision we've had to date in this thread. let me try again: create an elegant and organic user interface that enables anyone to enjoyably use a machine for different activities with large amounts of diverse files, contacts, locations and other information. create a system that works across the device spectrum with a minimum of additional effort to target additional devices, enabling both variety in supported systems and great integration and consistency between devices. i recognize that actually understanding the implications of that vision is non-trivial. this is to be expected. Björn gave the example of JFK's to the moon! BHAG (Big Hairy Audacious Goal). we can all read and understand what put a man on the moon means. it's short and conceptually simple to grasp. now put ourselves in the place of the engineers who had to actually make the machines to make that happen (not to mention get the austronauts trained and ready). same thing. the game of Go (http://en.wikipedia.org/wiki/Go_%28game%29) is another one. you can learn the rules in 5 minutes flat. there is one board that is just a grid with two kinds of stones (black and white). it takes years to thoroughly undestand it and play well, though. this is why it's taken so long to get this far, and why there is so much to read in support of the directions the vision has led us down (e.g. activities, SLC, plasmoids, ...). we have all gone through the process of learning and understanding, and continue to do so. it's doubly hard since we don't accept copy someone else as the best answer even though it's often the most obvious answer. but it's also why we have been able to do plasma active while other f/oss projects have ... well .. what do they have again? i see a community fork of android (the imho rather cool cyanogenmod) and that's about it. and they don't have a desktop. :) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workspace Next Sprint Organization
On Wednesday, May 16, 2012 14:48:58 Alex Fiestas wrote: We need then something like active where we can put all visions (workspace, applications, hardware support...) and create a more unified experience. i agree ... and, btw, i'm stupidly excited that we're actually at a point where we can even conceive of doing this! -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workspace Next Sprint Organization
On Wednesday, May 16, 2012 14:51:17 Alex Fiestas wrote: On Wednesday, May 16, 2012 01:44:26 PM Aaron J. Seigo wrote: On Wednesday, May 16, 2012 11:14:46 Alex Fiestas wrote: well as Solid (hardware integration) separate email for a separate topic: frameworks and the workspace definition. :) Solid is not part of the workspace Solid == subcommunity of KDE dedicated to hardware support. When I said solid I meant BlueDEvil, Power Management, NetworkManagement, etc. You mean libsolid not solid. ah, ok.. noted and corrected! thanks .. :) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Workspace Next Sprint Organization
On Wednesday, May 16, 2012 01:04:13 PM Aaron J. Seigo wrote: an answer to finding alex's email is not manage applications. Good point. an answer to turn my computer off is not manage applications. Not a valid example, I never turn off my computer (suspend) and even if I did I turn off the computer once a day. an answer to have my music volume be appropriate to what i'm doing on the system (e.g. mute it when i get an incoming call on mumble / jabber / googletalk / etc) is not manage applications. Good point, though we don't need an interface for this. an answer to how do i organize my information, which is the reason i turned on this damn thing in the first place, so that it reflects what i'm most interest in is not manage applications Well this is a need you believe people have, in my case I do but I'm not sure if the the average user have this problem. Is there any user story written? which kind of users are we targeting? Do you think that Penny[1] needs to organize information? A user that only wants to watch lolcats on youtube and talk to friends via facebook doesn't. A user that use the computer for multiple things or in multiple areas (work, home) may want to. which is more common, which do we want to design for? is one a super-set of the other? if so, can we design for that super-set of needs? Well imho there are more people from the first group than for the second, most people I know don't want to use computers but they do because they need them to ex: play games, surf web, write documents, etc No doubts they will change the computer for something simpler when the alternative exists. The need of having to organize information implies having information to organize, most people only have few mp3, few videos and few documents. The workspace should be extensible by third party developers and thus should be able to integrate their applications with it not mattering on which technology the application is written. sounds good to me .. we've also tried to focus on easy so that we avoid something super duper flexble and extensible but also too hard to make things for preventing people from doing so; we've also tried to focus on produces nice results so that people feel rewarded for their efforts (sth kicker failed at imho, resulting in orders of magnitude fewer addons for it compared to plasma) Yay we agree on something! xD step by step :p [1] http://community.kde.org/NetworkManagement#Persona_2:_Penny ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workspace Next Sprint Organization
On Wednesday, May 16, 2012 15:06:58 Marco Martin wrote: Ideas? love it. i bet this will bring high quality, big pay-off results at the sprint if employed ... -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workspace Next Sprint Organization
On Wednesday, May 16, 2012 15:05:03 Alex Fiestas wrote: On Wednesday, May 16, 2012 01:04:13 PM Aaron J. Seigo wrote: an answer to turn my computer off is not manage applications. Not a valid example, I never turn off my computer (suspend) and even if I did I turn off the computer once a day. *cough* we're making this for everyone. not you. not me. everyone. minus the people we aren't making it for. so everyone minus them. which is still a lot more people than you and me. given that i waded through a looong thread sent to me on forum.kde.org about log in times, apparently a lot of people do log in / out and turn their machines on/off throughout the day. and i assume we'll continue to offer that feature since people rely on it. which means it needs design thinking applied. but let's assume for argument's sake that suspend is the one true way of the future and we can afford to design in a way that only suspend is ever needed and used. we still are left with a lock screen on unsuspend. and ways to inhibit that sleep process selectively (just want to close my laptop lid and move a few feet, not lose all my network connections). this all takes design thought, UI care and is one more thing that isn't manage applications. an answer to have my music volume be appropriate to what i'm doing on the system (e.g. mute it when i get an incoming call on mumble / jabber / googletalk / etc) is not manage applications. Good point, though we don't need an interface for this. but we need a mechanism. that needs to go into the design even if it doesn't have UI. and often times it will end up having UI influence anyways. example: with activities and powermanagement, my #($*ing screen finally doesn't go off when i'm watching movies or doing slidecasts. i explained this to a lawyer i had dinner with last night and he instantly saw the value and said he'd love that exact feature because the screen on his laptop constantly goes blank when he's using it for slide presentations (or maybe the moral there is that lawyers should talk less in general so the slides go faster? ;) the number of use cases on the desktop are obscenely large. many, perhaps even most, do not involve app launching or window management. an answer to how do i organize my information, which is the reason i turned on this damn thing in the first place, so that it reflects what i'm most interest in is not manage applications Well this is a need you believe people have, in my case I do but I'm not sure if the the average user have this problem. i discovered the need by observing average users. Is there any user story written? which kind of users are we targeting? we've done all this for plasma active, they are all relevant to plasma desktop. more stories and more user archetypes would be great, and i think would help new comers grasp the vision more personally. in fact, that should perhaps become a Rite of Passage for getting commit rights to the workspaces: write a user story and a new user archetype. :) Do you think that Penny[1] needs to organize information? how many friends does she have on facebook, how many events has she accepted invitations to from friends, what is her work schedule like, how full is her music player, how many vacations / nights out on the town / special events does she have pictures from ..? yeah, i think Penny has a real need and desire to organize things. it's why every photo app, on the web and off, has albums. nobody would use one that doesn't. it's why tagging people in said photos is so popular. it's why music players group songs by artist, album, etc. it's why calendars let you associate people with events. sadly, we don't do this very much for actual files on disk .. we miss a lot of opportunities with contacts. events are hardly touched (though facebook with their timeline is trying things there.. good or not, i dunno). and when you talk to someone, how do they describe their various informational artifacts? by the context in which they experienced them. they might describe a company budget spreadsheet in terms of the company it relates to, who sent it to them (my boss, my co-worker), when they sent it to them, which work projects it relates to, the content, when it is due to be finished, etc... they might describe an album of music in terms of when they like to listent to it most: when i'm driving down the highway, when we're having dinner with friends, when i'm happy, when i'm doing yoga ... they might describe a photo in terms of who is in the picture, where it was taken (on vacation to ..., that christmas party...) and when. these are all ways of organizing information so that it is not just manageable but *meaningful* to us as humans. so yes, i think penny would bloody well love a christmas activity with all the christmas photos from the last N years on her computer, all the obnoxious christmas music she loves to torment, er,
Re: Re: Workspace Next Sprint Organization
On Wednesday, May 16, 2012 03:04:04 PM Aaron J. Seigo wrote: On Wednesday, May 16, 2012 14:48:58 Alex Fiestas wrote: We need then something like active where we can put all visions (workspace, applications, hardware support...) and create a more unified experience. i agree ... and, btw, i'm stupidly excited that we're actually at a point where we can even conceive of doing this! Yay! we agree on two things now xD (better take all this with humor :p) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workspace Next Sprint Organization
On Wed, May 16, 2012 at 2:06 PM, Marco Martin notm...@gmail.com wrote: On Wednesday 16 May 2012, Alex Fiestas wrote: On Wednesday, May 16, 2012 12:54:16 PM Aaron J. Seigo wrote: there was something started quite some time ago by .. i forget who? .. here: According to the history of the page, by you. http://community.kde.org/Plasma/TheWaysOfThePlasma there are other bits spread around the wiki there as well. i am fully supportive of streamlining and updating the text. This is something we need to do so we can work on them before, during and after the sprint. So, those are some my random toughts about a possible methodology. may or may not make sense, just quick mind map done while i was thinking about it: * Methodology: - current vision, ideas, concepts and terminology: are we thinking the same thing when we say a thing? - identify user scenarios, what do you want to do, why and in what situation in the machine (example: being at work on a document while discussing about it simultaneously on email, chat and audio call) - what in current suituation of things matches with this? - what doesn't? - personality switch: try to answer the problem without looking at other answers.. because it works on OSX or even because it works on Plasma Desktop are not valid answers ;) - personality switch: why the solution of other system does work/why it doesn't work? - Collect high level points of intent, like - natural feeling ui - few user interruptions - settings always correct for what i'm doing now - right level of mono/multitasking in different situations (complete dedication to a task vs listening mucic/glancing over news items while working) - ... - Collect user scenarions, like - working on a document while talking about it - doing a presentation - doing a call - ... - what are possible sub tasks, more detailed (note: still nothing to do with implementation) of those points we collected? *Tasks examples (but not limited to it) * Organic ui - transitions - realistic light effects - ... * Efficience in doing tasks - think in steps required to do a task, not just in launching applications (that is just an aspect of it) - what is and what should be the boundary between what is an app and what is the workspace - generic information flow of everything that i see on the screen (so yes, include applications switching, not limited to it) * Activities: - what are the scenarios and the problem they are designed to solve - what are the ui-wise problems in them right now? - A possible one: gulf of execution (http://cyborganthropology.com/UX_Glossary#Gulf_of_Execution) - How to reduce it? * Hardware integration - when to turn on/off bluetooth, audio level, camera? - what to do if i attach a screen? a beamer? - what to do if i disconnect to office wifi and connect to home wifi? - ... * And many others * How to do those? * Write an updated version of what is now ways of the plasma, ui guidelines etc * identify where the work has to be done for an abstract task item: bluedevil? libplasma? qml components? tasks applet? * actual coding/documenting/coding tasks up for grab ;) Ideas? opinions? We could do with a wiki page with a basic list of possible agenda items (starting with this list). This email is just going to get drowned out in the large volume of other traffic in this thread, which is a million miles away from the original subject. If anything this thread has highlighted that there are unclear visions and terminologies. I've never seen that vision before, which implies that few others wanting to get more involved in the workspace will have. I'm still none-the-wiser as to where the workspace ends, and applications start. Only a month or two ago there was a thread on Plasma about application status bars, and I was told that is part of the workspace. Each reader probably has an opinion but we could do with getting it settled and defined. * Write an updated version of what is now ways of the plasma, ui guidelines etc This will be a great task to do with Bjorn around (to give a definitive view). I actually already have a draft list, which we can go through and work upon. I know there's already a UI guidelines for plasma active, but this doesn't transfer 100% to the desktop. Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Workspace Next Sprint Organization
It sounds good, maybe we should start a new thread since this got contaminated with offtopic (sorry for that :( ) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workspace Next Sprint Organization
On Wednesday 16 May 2012, David Edmundson wrote: Ideas? opinions? We could do with a wiki page with a basic list of possible agenda items (starting with this list). This email is just going to get drowned out in the large volume of other traffic in this thread, which is a million miles away from the original subject. here we go: http://community.kde.org/Plasma/Workspace_Sprint feel free to edit/add/move stuff ;) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Versions and commit hooks
On Wed, May 16, 2012 at 1:46 PM, Aaron J. Seigo ase...@kde.org wrote: On Wednesday, May 16, 2012 13:28:55 Aleix Pol wrote: In git you know if a bug it's fixed in a release because the release log contains the bug fix. That is: git log KDE/4.8..KDE/4.9 | grep BUG: id very few of our users will, or even know how, to do this. everyone who reports a bug, however, knows how to check the bug reports, and that is where this tag ends up feeding into. -- Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Well, it's not about people doing this, but that we're asking people to put redundant information in the commit message. Maybe this information could be gathered in a commit hook? Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Versions and commit hooks
On Wednesday 16 May 2012 17:18:40 Aleix Pol wrote: Well, it's not about people doing this, but that we're asking people to put redundant information in the commit message. I don't consider this to be redundant information, but also see it as a quite useful information when using git log to go through the commits or in combination with git blame and afterwards using git show. Basically it gives me all the information I need when looking at a given commit: what? why? when? Given that it is also just one additional line which goes with the BUG field I don't see an issue with adding the field at all. Maybe this information could be gathered in a commit hook? Given that different products have different release schedules, I doubt that's possible to do with a git hook. What I would like to have is a git hook which blocks a commit to stable branch if it has not the fixed-in field ;-) Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: more thoughts on kwin and window thumbnails in plasma shells
On Wednesday 16 May 2012 14:14:51 Marco Martin wrote: On Tuesday 15 May 2012, Martin Gräßlin wrote: well, is just that when the world goes into the compositor, the probability of this happening skyrockets ;) Let's try to get our software working and not thinking about solutions for the case that our software is buggy. If we allow ourself to consider that software components could lock up, our users who blame us for bad quality are right. I want us all to get to a point where we don't have to even think in the direction of a compositor lockup. uuuh, not really, our software should be less buggy? sure. but fault tolerance is an essential part of quality, not just fault prevention. one should not influence the other. good, we agree. I just wanted to point out we should not discard possible technical solutions with such arguments. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Bugsquad] Versions and commit hooks
Hi, A very good practice for all developers would be to use the KDE Git Commit Template http://techbase.kde.org/Development/Git/Configuration#Commit_Template and to fill in there all the appropriate fields including FIXED-IN whenever you commit. Best regards, Anne-Marie On 05/16/2012 05:18 PM, Aleix Pol wrote: On Wed, May 16, 2012 at 1:46 PM, Aaron J. Seigoase...@kde.org wrote: On Wednesday, May 16, 2012 13:28:55 Aleix Pol wrote: In git you know if a bug it's fixed in a release because the release log contains the bug fix. That is: git log KDE/4.8..KDE/4.9 | grep BUG:id very few of our users will, or even know how, to do this. everyone who reports a bug, however, knows how to check the bug reports, and that is where this tag ends up feeding into. -- Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Well, it's not about people doing this, but that we're asking people to put redundant information in the commit message. Maybe this information could be gathered in a commit hook? Aleix ___ Bugsquad mailing list bugsq...@kde.org https://mail.kde.org/mailman/listinfo/bugsquad ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma_UX_improvement_project news
Hello all KDE developers! Over the course of our school semester we have been assigned the task of helping the development of Plasma Active, a task that has been very intriguing and interesting for all of us. We are a student group of six members that have been asked to improve the Plasma Active user experience in any way that we could, and have focused on two main aspects of the framework, namely the keyboard and the internet browser. Please see details at: community.kde.org/Plasma/Plasma_UX_improvement_project Being able to work with a framework and a design that bases itself on such revolutionary principles in innovative software such as Plasma Active, we have had a lot of fun working on the project, and as the semester comes toward a close, we would like some feedback from KDE developers to help us realize the potential and approval (or disproval) of our work. Having produced design documents and simple prototypes to back our claims of what would be an improvement to an already groundbreaking framework; we would ask all interested developers to please give any feedback to us, so that we can build an even better project report for our final delivery. We are somewhat delayed in our appeal to you all, as our deadline for this assignment is the 20th of May. Hopefully you have some time to look at our designs and ideas and give us your thoughts on what we did right or wrong. Are these designs something you would have liked to work with or help develop further? Would the designs fit in with the already innovative and intuitive designs that Plasma Active facilitate? Seeing developers embrace the ideas and for the benefit of the community would mean a lot to us. If this seems interesting to you, please reply with your thoughts on this. Any feedback is good feedback. On behalf of the entire student group, I thank you in advance for your help and cooperation. Keep up the awesome jobs you are doing! - Erik Joramo Jana Majeed (Students at NITH, Norwegian School of Information Technology) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Plasmate: fix publisher's combobox and doCMake slot
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104969/ --- Review request for Plasma. Description --- Hello, those are some issues which plasmate's publisher has problem 1: the publisher's combobox wasn't aware for the right slot. When currentIndex was emitted both slots(doPlasmaPkg and doCMake was called.) I fixed that. problem 2: publisher's cmake process was trying to install a projectName.plasmoid file and not projectPath/CMakeLists.txt. I fixed that. problem 3: when the cmake slot is called, cmake creates the known temporary files in directory like ~/.kde4/share/apps/plasmate/projectName. I haven't fixed that. How can I change the current directory with Qt? Diffs - publisher/publisher.h 6eba693 publisher/publisher.cpp 3fcd268 Diff: http://git.reviewboard.kde.org/r/104969/diff/ Testing --- WIP Thanks, Giorgos Tsiapaliwkas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workspace sprint, workplan/methodology
On Wed, May 16, 2012 at 5:24 PM, Marco Martin notm...@gmail.com wrote: So, to put it in a new thread: possible work plan and methodology: http://community.kde.org/Plasma/Workspace_Sprint is completely open, anybody that wants to modify it is welcome to do so. other thing and topic, since is about that sprint anyways, infos about the place, how to reach etc would be nice as well. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Regarding the local organization, we've been delaying this because both Alex and I we're swamped with the Akademy-es organization that's going to happen this weekend. Starting from the next week we'll start doing these things. Regarding the document, I think it's a great thing to have. I'm a bit afraid that we're focusing a bit too much on how do applications integrate to Plasma instead of how does Plasma integrate applications. I have to catch up with all the literature that has happened today :). Furthermore, I see things like on-screen keyboard in this document. From my point of view, this sprint should be about how to iterate KDE on the desktop systems (with this mouse and keyboard we've all grown to love), others are already taken care of by the Active project which is doing great but on the desktop we have some void. If I misinterpreted anything, please tell me. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workspace sprint, workplan/methodology
On Wednesday 16 May 2012, Aleix Pol wrote: integrate to Plasma instead of how does Plasma integrate applications. I have to catch up with all the literature that has happened today :). Furthermore, I see things like on-screen keyboard in this document. From my point of view, this sprint should be about how to iterate KDE uhm, on screen keyboard? sure you are not referring to community.kde.org/Plasma/Plasma_UX_improvement_project (that's an unrelated thing) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma_UX_improvement_project news
Hi Erik and Jana, On Wednesday, May 16, 2012 19:54:42 J.K. Majeed wrote: Over the course of our school semester we have been assigned the task of helping the development of Plasma Active, a task that has been very intriguing and interesting for all of us. We are a student group of six members that have been asked to improve the Plasma Active user experience in any way that we could, and have focused on two main aspects of the framework, namely the keyboard and the internet browser. Please see details at: community.kde.org/Plasma/Plasma_UX_improvement_project Being able to work with a framework and a design that bases itself on such revolutionary principles in innovative software such as Plasma Active, we have had a lot of fun working on the project, and as the semester comes toward a close, we would like some feedback from KDE developers to help us realize the potential and approval (or disproval) of our work. Having produced design documents and simple prototypes to back our claims of what would be an improvement to an already groundbreaking framework; we would ask all interested developers to please give any feedback to us, so that we can build an even better project report for our final delivery. We are somewhat delayed in our appeal to you all, as our deadline for this assignment is the 20th of May. Hopefully you have some time to look at our designs and ideas and give us your thoughts on what we did right or wrong. Are these designs something you would have liked to work with or help develop further? Would the designs fit in with the already innovative and intuitive designs that Plasma Active facilitate? Seeing developers embrace the ideas and for the benefit of the community would mean a lot to us. If this seems interesting to you, please reply with your thoughts on this. Any feedback is good feedback. I've only quickly gone through the results of your research, and my first impression is that it is well done, pays good attention to understanding why we did things how we did them, and it also points out good starting points for improvements. My first thought is that at least some of these ideas will most likely find their way into a future Plasma Active release. So, good work! :) I haven't had the time to read through all of it, so concentrated on the bits about the browser, first. Here's a few comments and questions that came up in me while reading: - The clear button in the lineedit atop has already been fixed, it's not in line with other clear buttons. Well spot that it reuses the same metaphore as the adjacent stop button. (We did replace it for consistency, though, not really because of that clash (which is still a valid concern.) - For bookmarks, I'm actually using the star icon. I don't think it was different in the past, so not sure where you got the heart from, maybe the peak and launch bar, in the share-like-connect plasmoid? (In which case, I'd argue that bookmarks is not equal to, but a subtask of Like, hence the different icons. Arguable, though, could probably be improved. - Scrolling: we use flick scrolling in the webbrowser, the scrollbars are not interactive at all. Therefore, I don't understand that concern. - Tabs / second level: This is one of the things I purposefully avoided, let me tell you why. In Plasma Active, we use a document-centric approach. Documents (often equivalent to windows) are switched through the peak and launch bar. Introducing browser tabs would make it rather application centric. More importantly though, it would make navigation more complicated. Why introduce an alternative way to switching open documents (webpages)? We already have one. If your answer is to separate different sets of documents, my answer to that is use activities, it's what they're there for. I honestly think that browserstabs are a fundamentally broken concept, trying to make up for workspaces that do a poor job in managing many open documents. Nothing I'd like to transport into the new world. There are a few comments, which I really don't understand. Could you post a screenshot of the browser, as you've investigated it? I have the gut feeling that we're not talking about the same thing. (No heart icon, browser has not zoom buttons, but you're talking about them, some more.) Still digesting the rest of your document ... :) On behalf of the entire student group, I thank you in advance for your help and cooperation. Keep up the awesome jobs you are doing! - Erik Joramo Jana Majeed (Students at NITH, Norwegian School of Information Technology) Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workspace sprint, workplan/methodology
On 05/16/2012 12:07 PM, Aleix Poi wrote: Furthermore, I see things like on-screen keyboard in this document. From my point of view, this sprint should be about how to iterate KDE on the desktop systems (with this mouse and keyboard we've all grown to love), others are already taken care of by the Active project which is doing great but on the desktop we have some void. If I misinterpreted anything, please tell me. You are likely correct, and I was probably wrong to add this item into an Agenda for a meeting among KDE's DE visionaries. I was emphasizing A18n (in particular, Plasma DE for one-handed users, who may be unable to reach widely used modifier KeySequence with one hand, or with a less-than-typical number of fingers). If it should not be treated as a strategic goal, and plays more as a mere feature, then please DO feel free to remove the item. BTW, Does the 'Active' project have a separate ML? (If it does, I should go ahead and start lurking!) As you probably know already, I am going to be creating the Qt QMouseShortcut Classes and Events in Qt. If Plasma Sprint is not suitable for brainstorming of A18n needs, and/or Mouse SHortcut HIG, I'll remove both of these noisy Agenda items. Thanks for noticing that I'd stuck them in there! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma Applet Testing for 4.9
As you may know the KDE Quality team was set up recently with the aim of conducting organised testing of KDE just before a release. The overall plan is to have several days of specific testing, (dates TBC) trying to drum up involvment marking it easier, and have a specific targetted lists of things to check. This will be from a team of people who have been trained (forced to read a wiki page) on how to write good bug reports. I'm tasked with leading testing of the plasmoids which is why I'm writing here. I'm going to focus purely on the new QML plasmoids because: 1) They're new and untested by a wide audience 2) Realistically any bugs on anything else will be met with ...we're going to rewrite it anyway, which is a waste of my time and yours. I have a (fairly vague) checklist of items to go through for each plasmoid: http://community.kde.org/Getinvolved/Testing/Beta/Plasma#Check_List I need: - a list of all the new QML-based applets (by the time of the first beta) (afaik, nowplaying, battery, locklogout, activitymanager.. but there are so many more random branches about, and I don't know the status of these) - any suggestions/additions to my checklist or our workflow plans Obviously raising a lot of bugs on it's own isn't very useful. I'll be spending some of my time helping fix things afterwards, but it really needs involvement from a lot of people available on the testing weekends to fix issues as quickly as they're opened. David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
