On Friday, June 8, 2012 12:35:46 Martin Klapetek wrote: > While I share your idea of Plasma Workspaces, I would imagine that > different parts of the kernel are maintained/developed by different people.
and they don't whinge at each about it ;) > Sure, the core is the same, but the platform-specific stuff needs to be > different (if only a little). So one needs to see the difference between > core and the "workspace" in our Plasma case. the "core" makes up 95%+ of the "workspace". i'm beginning to think that people are judging on the looks rather than the code, and that worries me because it would mean people are making conclusions without knowledge. the design of Plasma lets us take the overwhelming majority of code and re-use it across workspace shells. that's the entire point. i've calculated that the current delta between Active and Desktop is ~15000 LOC, and that once we merge some branches (e.g. the QML screen locking branch) that will drop down to ~10k LOC. the other ~250 LOC (not counting kdelibs, qt, and all that of course :) is shared. from libplasma to the script engines to the plasmoids themselves there is great consistency. so differentiating between core and workspace is not as useful as one might expect at first. > In other words - if you add > method to the core and make use of it in Active, it doesn't magically > happen on desktop too. not always, but often yes it does. did you notice the new activity manager. > Which I think might be on of the problems - seeing > the Plasma team focusing on Active, bringing new features there many of those new features are available to and have appeared in the desktop. the new activity manager daemon, the QML components, improvements in various plasmoiods, etc. there is still much more to take advantage of in Desktop, and thankfully the design lets that happen easily. the same design that has let us do Active. it is *not* a zero-sum game where Active takes away from Desktop or vice versa. efforts in one improve the others. they also bring in more developers. there's also the fact that working on a touch interface gives new interest in and perceived (and real) sustainability to the KDE Workspaces. let's look at the big picture here. btw, it sounds very whingy when people get annoyed that we've worked on Active just because they'd like us to work more on Desktop. it sounds very much like we're being told "do what *i* want". well, all of us who worked on Desktop and now contribute to Active have also continued working on Desktop in parallel. who do you think did the new Applets chooser, work of libtaskmanager and the tasks widget, etc. etc.? my hope is that instead of whinging at us about working on Active and ignoring our parallel efforts on Desktop, that people will pitch in and work on the parts that interest them and move those things forward faster. > desktop is...well, it's the same for the past 3 years. tasks launchers, new window switcher (in QML no less :), several plasmoids ported to QML (only somewhat user visible in that the results are usually graphically smoother, but necessary work), addition of javascript for the layouts (and many improvements to that in the last 18 months), system tray refinements, the Plasma KPart now used in a number of apps ... now, i do understand what you're saying: the desktop hasn't had a major set of visual changes in the last few years. it's all been incremental and evolutionary. that does *not* mean people have not been working on it or caring for it. performance improvements and bug fixes are critical to the maturing and therefore the adoption of the desktop interface. > And just look at > Facebook - they change stuff every 2 years or so. Now I'm not saying let's > forget what we have and start over. Not at all. But we're quite stagnating. compare 4.5 with 4.9. use 4.5 for a week or two, then come back to 4.9. there's been forward movement. now, when we make change, we need to be able to say why we're making those changes. change for its own sake is useless. which means that not doing a revolution every N years is not necessarily a bad thing. major changes should happen when they need to. not sooner, not later. so saying "we're stagnating" when we not only have things like Active going on (which really takes the wind out of our sails, btw: "what you're doing has no value" is exactly how it ends up sounding like.) but also moving Desktop forward is ludicrous. btw, if you want to see a shell that is stagnating: Netbook. it hasn't seen any major work in a while. so if we wish to talk about stagnation let us: * stay real to the actual efforts, not invent "nothing has been happening" when there has been * define what change we want to see and describe why that change should happen. speaking in generalities ("it's stangating") will not move things forward. > And that's in my opinion, where we need the vision. Aaron's vision is > great, but to me it sounds more like a general textbook "workspace vision". can you point me to another workspace that is doing what we're doing? or, go back 8 years when i did my first presentation on the prototype of this vision at Akademy in Ludwigsburg and compare the ideas of what a desktop was then to what it is now ... > I personally think we need a more precise vision (we already do have > organic uis, don't we?). in some places. we still have work to do in many places. and we only have that now because we had that vision in the first place. other workspaces were not looking at this, especially not KDE. > For example - what's our vision for integrating > social media in the shell/Plasma? > What's our vision for integrating IM? And great questions! :) they are also domain specific, akin to "what's our vision for managing files from the desktop?" there is a global "first principles" vision. i think it can be refined and improved. based on that we have domain specific visions. like "how do we integrate social media better?" btw, are you familiar with Share Like Connect? > so on. Sure, there are teams doing these tasks, but we should imho have a > common vision, or goal if you wish, clearly defined by the Workspace > leaders. agreed. > it. To reach one great Workspace. Just like for Active - you have a vision > of creating a touch-based interfaces (very simply speaking), that isn't the vision of Active. "touch based" is a domain-specific implementation vision within Active (the domain is "tablets"), but the goal is to also support set top boxes and other form factors that are not primarily/exclusively touch. the actual vision is in 3 quick points. the UX goal is: "an interface that adapts as users change Activities". the other two parts are: * a fast embedded UX platform with minimal memory requirements * customizable and modular to support different form factors in support of this we have a HIG in formation to describe our visual and touch-based UI language. if you're wondering where i found this information, it's all on the main page of plasma-active.org right near the top. > so basically > there's a vision of how you'd like Okular to behave in such environment. > And I would like to have this precise vision for the rest of the Workspace, > not just "to have scalable interfaces". you mean something like: * an interface that adapts as users change Activities * integrate social interation patterns with the desktop * seamlessly blend all "system" (from a user's POV) UX into a single uninterupted visual design to frame applications with this is what we've been working towards all this time, btw. if you want to know why we aren't fully there yet, i'd be happy to share the last 4 years of history of the project. > Each and every team can do their own vision. But then there will be > inconsistencies, different functionality etc. agreed. we need to come together. that's what the intent was here. i think it got off to a very poor start because some people think they know what we've been doing, what the design of plasma is and they haven't bothered to do any actual research .. while being quite willing to share their opinions. > Just look at System Settings > - common place for so many apps and yet each module looks different. And it > looks bad in the final result. interestingly, the #1 thing people often write about Plasma Desktop when reviewing it is how beautiful it looks and how everything seems to fit. we know they are wrong ;) and that much is left to be done. but i am also a big believer in realism. if we overstate how shitty things are, we will be more likely to change things that do not need it, or even just give up because after all this effort things still "suck". > So I think there should be some well > understood "lead", a way the Workspace should go. Which currently there's > not. Or it's not well known. it's just not well known. or, more accurately, it has been ignored. it used to be fought against, then it was ignored and now ... btw, did you know that just recently a developer on this list started working on harmonizing the tooltips between dolphin, system settings and libplasma, so we'll have consistency there? there was also a discussion on g+ (not a good location, i know :) about QML'ifying system settings between myself and the system settings maintainer (and others). we'll probably take things we've learned from Active Settings and apply it there. and you do realize that when we started, KWin was also a separate component. it was only because we invited KWin in and the KWin developers really "got it" why this was important. as a result, KWin has brought all sorts of improvements and new ideas to the table that would never have happened without them. we shared a vision, we shared development effort, we brought things together. even with kwin, there is still vision sharing to be done (as can be seen in Martin's recent emails :), but we have been picking up the pieces and bringing them together. as for apps, many design concepts in today's dolphin have come directly from the workspace vision we've had. we do need to take this further out, but we have been bringing the ideas to those who have been open to them and within the limits of how fast our hands can write code. i could point to any number of similar things in KDE3 that now work/look seamless in Plasma Desktop. and now that you are here, we can go even further together! :) the reason it hasn't gone further sooner? in part because these things take time. we had a lot of work to do in Plasma to get us to this point (and Qt changing about so much in the last 5 years did not help). in part because KDE people were not ready for this discussion. it used to be a hobby of some KDE hackers to take a shit on Plasma on the mailing lists, in their blogs, on web discussion boards and even in person. how could we have these discussions when that was the atmosphere? now more people see that Plasma may be on to something and the idea of working together to bring about a seamless workspace starts to make more natural sense to people. it also helps that some of our competition has also moved in this direction (and to some extent they have done so because of Plasma), which helps more KDE people understand this is a good thing to prioritize. but the Plasma people have been here for 3-4 years trying to make this happen and writing code that has brought it this far. i'm glad it finally is happening faster and with more people, because we all agree it's the best way forward and we need more hands. denying the work and effort we've put in or the leadership we've offered is not a nice way to start this, however. -- 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