Re: Looking around and thinking ahead
On Thursday, December 12, 2013 02:26:42 Sebastian Kügler wrote: Today, I'm running Plasma 2 almost exclusively on my laptop. The most you wonderful, crazy man. :) In plasma-shell, we have some construction sites as well. Kickoff still feels quite unfinished (some would say broken ;)), configuration of do we even want to keep kickoff? we need the menu based launcher for legacy support, but i really really wonder if the kickoff UX is at all relevant anymore. that’s a different thread, though. plasma-framework needs some work on APIs, too. With large version number change, we can reduce the delta between libplasma and our declarative imports. There are some candidates which currently use quite some glue code for our declarative bindings. Can cook this down and maybe move some implementations into libplasma, or adding necessary Q_PROPERTYs to our API? sounds like a perfect candidate for a class-by-class examination of what is in the declarative imports. The scriptengine has quite a large bunch of code as well. Does it make sense to move the plasmoid. object (offered to our Plasma/Applets) into libplasma, it's pretty much core of our current API, but otoh is currently fixed to QML. no QML (or other rendering system) in libplasma. graphics stack was the base work we had to lay. The UI side is where we can really make a difference, we've built quite an awesome base, but we need to turn this into real, added value for our users. yep. We're not very well equipped in the artwork department. Perhaps we can try to find artists more actively. I think we have some very exciting work to be done, with a large audience. There *must* be good designers around who want to help us making Plasma beautiful. i have worked with 2 groups now .. and despite regular and supportive feedback and assistance from my side, both failed to produce completed results. this may be “heresy” but perhaps we should entertain a freemium model whereby there is some $ on the table for the artist. i’m rather out of ideas how to motivate such people, while at the same time some of the community art groups are already moving in that direction. Part of this communication is that we should settle the name question. We had a good discussion about that some time ago, but it died out before reaching a conclusion. Let's put the options back on the table, and come to a decision there. (Relevant thread is naming the next major release on 19th August on plasma-devel.) i’m all for `Plasma 2` with the shells named after the form factor they target. Plasma Desktop, Plasma Netbook (renamed to?), Plasma Tablet, etc. the Plasma Active name is still relevant for the applications involved .. but perhaps we should retire it in general. this means thinking about how we name/refer to our applications that target different form factors. this is not limited to Plasma Active. we have Kontact Touch, Marble To Go (iirc?), Calligra Active ... chaos :) perhaps we could re-purpose Active for those. regardless, i think that particular discussion is out of scope for Plasma and ought to be had with the general KDE application dev community Q3 and 4, I imagine, could shift the focus from the bare basics to a more complete product. Multi-device usecases realized by different shells, meaning porting and integrating the Plasma Active UI, Plasma Mediacenter, how is shell switching being tested currently? the ‘netbook’ interface will also need porting to a proper shell package and probably could use a rename. this should all hopefully go rather quickly given that we can drop a number of hacks and workarounds with the move to pure QML. -- Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Looking around and thinking ahead
how is shell switching being tested currently? It is not. We have only one shell :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Looking around and thinking ahead
On Thursday, December 12, 2013 13:06:21 Aaron J. Seigo wrote: The scriptengine has quite a large bunch of code as well. Does it make sense to move the plasmoid. object (offered to our Plasma/Applets) into libplasma, it's pretty much core of our current API, but otoh is currently fixed to QML. no QML (or other rendering system) in libplasma. Exactly that is my concern as well. The plasmoid object collates what we present as public API, and the QML tricks, so maybe put a skeleton API class in libplasma, and derive from that in the scriptengine (and putting the QML specific bits in there). This would need some surgery though, but would make it possible to reuse at least the API code in the systray (where we fake the plasmoid object). Do I make sense? -- 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: Looking around and thinking ahead
On Thursday 12 December 2013, Aaron J. Seigo wrote: On Thursday, December 12, 2013 02:26:42 Sebastian Kügler wrote: Today, I'm running Plasma 2 almost exclusively on my laptop. The most you wonderful, crazy man. :) In plasma-shell, we have some construction sites as well. Kickoff still feels quite unfinished (some would say broken ;)), configuration of do we even want to keep kickoff? we need the menu based launcher for legacy support, but i really really wonder if the kickoff UX is at all relevant anymore. that’s a different thread, though. I would like still giving by default a menu, but way simpler, even somewhat more similar to a traditional menu (kickoff ui should really go i think, some/most of the code of the qml port may be saved/reused tough) plasma-framework needs some work on APIs, too. With large version number change, we can reduce the delta between libplasma and our declarative imports. There are some candidates which currently use quite some glue code for our declarative bindings. Can cook this down and maybe move some implementations into libplasma, or adding necessary Q_PROPERTYs to our API? sounds like a perfect candidate for a class-by-class examination of what is in the declarative imports. yes, a tough api review of the qml imports is something i wish since uuh, 3 years :p (may be an argument for the sprint, maybe the last couple of days when we are too cooked for doing productive hacking anyways) We're not very well equipped in the artwork department. Perhaps we can try to find artists more actively. I think we have some very exciting work to be done, with a large audience. There *must* be good designers around who want to help us making Plasma beautiful. i have worked with 2 groups now .. and despite regular and supportive feedback and assistance from my side, both failed to produce completed results. I think it's again a bit social/culture barrier (in a sense not unlike the fun we're having with hardware people) Currently opensource software has the reputation (deserved or not, this is a completely different argument) to be badly designed, and i guess many designers don't particularly want to be involved in something that in their community has a bad reputation. This combined to a more diffused adversion to work for free (and after all there are paid developers to work on code right now) other problems may be collaboration, it's difficult to find a designer willing to collaborate with others. Right now at the current state of development, to have art/design work we can actually use, we need a designer capable of thinking *inside* the box, quality very difficult to find in that field ;) I'm sure someone does exist tough ;) In the end, I'm favourable of even paying someone, if $ for that do exist at all, as long as is *not* a contest. Part of this communication is that we should settle the name question. We had a good discussion about that some time ago, but it died out before reaching a conclusion. Let's put the options back on the table, and come to a decision there. (Relevant thread is naming the next major release on 19th August on plasma-devel.) i’m all for `Plasma 2` with the shells named after the form factor they target. Plasma Desktop, Plasma Netbook (renamed to?), Plasma Tablet, etc. for Plasma Netbook in my long sleepless nights (meh) I tought about a slight, not radical redesign that besides being i think a bit better would allow to reuse pieces of most of the desktop and active ui bits, so hopefully little effort involved (last famous words) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Looking around and thinking ahead
On Thursday, December 12, 2013 13:33:38 Sebastian Kügler wrote: The plasmoid object collates what we present as public API, and the QML tricks, so maybe put a skeleton API class in libplasma, and derive from that in the scriptengine (and putting the QML specific bits in there). This just so i know we’re talking about the same thing ... you mean the AppletInterface class? if so .. the uglyness there is that both QtQuickItem and Plasma::Applet are QObjects, so they can’t be synthesized into one class by MI. that said ... it shouldn’t be necessary. taking a look at what is there now, it is quite clear that the class should be refactored out. many of the methods simply proxy to Plasma::Applet as it is; so my suggestion would be to import Plasma::Applet *as* plasmoid into the runtime. that still leaves us with a large number of methods to reshuffle. suggestions: a number of methods which have become purely business logic (easily seen as they are POD properties) were moved out of Plasma::Applet. they should be returned to Plasma::Applet. these include: * isBusy * backgroundHints * file (use the package) * scripting API version (which would get it from the AppletScript object) others should probably be moved elswhere, e.g. to DeclarativeAppletScript itself, such as: * compactRepresentationCheck * updatePopupSize * expanded * bool fillWidth() const; * bool fillHeight() const; * qreal minimumWidth() const; * qreal minimumHeight() const; * qreal maximumWidth() const; * qreal maximumHeight() const; * qreal implicitWidth() const; * qreal implicitHeight() const; most of these simply query the root QML object from the plasmoid and are read- only. the geometry methods are probably the most difficult: these seem to be there specifically for containments and dialogs. or is there some other purpose to them? assuming they are there primarily for containments and dialogs, i assume these already have access to the root qml objects? the only trick is whether to use the compact representation or the root item itself, and one would hope that this would be made simple: the dialog should know what item is in it, the containment should also. i fail to see why these continue to exist at all rather than using the properties directly from QML. some methods are deprecated: * hideOnWindowDeactivate (Dialog handles this now) this leaves us with two issues: Actions API: this API *sucks*. it was there to make it as easy as possible to make simple additions to the context menu from javascript. it is not very declarative at all, however. it would be far nicer to have an actual AppletContextMenu QML item imho and then just drop this API. Configuration read/write: similarly, the read/write config object API should probably die, die die. it is also not very declarative, and we have a declarative replacement for it already from Plasma Active that Sebas wrote. yes, this means some in summary: * actions and config API axed * get rid of unused / deprecated API * move some business logic methods back into Plasma::Applet * move the rest of it into DeclarativeAppletScript thoughts? problems? -- Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Looking around and thinking ahead
On Thursday 12 December 2013, Aaron J. Seigo wrote: yes, this means some in summary: * actions and config API axed * get rid of unused / deprecated API * move some business logic methods back into Plasma::Applet * move the rest of it into DeclarativeAppletScript thoughts? problems? +1 for phasing it out and remove duplicates and methods that just proxy... ...but: who becomes the qquickitem then? (after trying many combinations in the past, the concept to have a c++ object that goes in the scene and contains the applet qml was the way that caused less pain) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Looking around and thinking ahead
On Thursday 12 December 2013 02:26:42 Sebastian Kügler wrote: In plasma-shell, we have some construction sites as well. Kickoff still feels quite unfinished (some would say broken ;)) I wrote a new menu implementation for KDE 4 recently: http://i.imgur.com/eiq6D5w.png http://i.imgur.com/h9Y5jH2.png http://i.imgur.com/o3s3Bzk.png http://i.imgur.com/KG2R98u.png It's fairly simple on the one hand, but decently sophisticated in some respects on the other (for example, it treats diagonal pointer moves into subdialogs differently based on their escape angle, to avoid accidental category switches, and some other attempts to make user interaction as nice as possible). Key- board navigation largely matches QMenu, etc. It's currently based on the Homerun sources framework, which is conceptually redundant to Plasma Runners, but more con- venient to use from QML views, as Homerun sources publish categorized data in the form of Qt models. This will definitely be ported to Plasma 2 some time in the first half of 2014. In an ideal world, with enough time to see what we could do to runners to make Homerun sources obsolete. QML 2 is also going to make it a bit nicer to use, as the need to do some things in hotpaths due to bugs in QML 1's ListView implementation will fall, improving latencies in the UI quite a bit. Tester response has been mostly excited and happy so far. De- spite the 'oldschool' appearance, at least for mouse but also many touchpad users, the classic cascading popup menu design simply is a better match to their human ability to point at things within reasonable distances than the perennially fiddly let's have a little smartphone VM in a corner of the screen design of Kickoff. Meanwhile, configurable favorites for apps that are frequently used but not frequently enough to have on one's panel and support for the search-and-hit-enter usage patterns mostly succeed in marrying it with the best bits of Kickoff. If there's interest, it would be sweet to ponder in what way or form it might have a place in the mainline shell release. Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Looking around and thinking ahead
On Thursday, December 12, 2013 14:42:28 Marco Martin wrote: who becomes the qquickitem then? the root item in the QML itself? is there really a need for an additional container item? (after trying many combinations in the past, the concept to have a c++ object that goes in the scene and contains the applet qml was the way that caused less pain) if a container QQuickItem is absolutely required, this sounds good -- Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Looking around and thinking ahead
On Thursday, December 12, 2013 15:09:25 Eike Hein wrote: On Thursday 12 December 2013 02:26:42 Sebastian Kügler wrote: In plasma-shell, we have some construction sites as well. Kickoff still feels quite unfinished (some would say broken ;)) I wrote a new menu implementation for KDE 4 recently: there a 1000 ways to do a launch ‘menu’, and each will be appreciated by someone out there. give me a menu implementation and i’ll show you someone who loves it to death and someone who wants to do physical harm to the author. so i don’t think it makes much sense to toss N of them in a ring and discuss relative merits. i’d much rather have a list of goals and then work towards something that meets them. those goals ought to follow the design purpose of the Plasma 2 desktop shell and should probably not be confined to “how can i launch applications?” http://i.imgur.com/KG2R98u.png as an aside: this really makes zero sense to have. it requires plasmoid A to work with plasmoid B in a way that makes lots of assumptions. drag and drop + SLC should replace these misfeatures entirely. let's have a little smartphone VM in a corner of the screen given when kickoff was designed (and by whom/where), this is a folk etymology of the kickoff UI which bears no resemblance to what actually transpired. get the motives wrong, learn the wrong lessons. -- Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Looking around and thinking ahead
On Thursday 12 December 2013 15:29:00 Aaron J. Seigo wrote: so i don’t think it makes much sense to toss N of them in a ring and discuss relative merits. Ah yup, and that's the sort of reply I expected from this mailing list, which is why I wasn't going to do so until I was prodded. Plasma is bundles of fun and joy sometimes. as an aside: this really makes zero sense to have. it requires plasmoid A to work with plasmoid B in a way that makes lots of assumptions. Add to Desktop and Add to Panel are present in Kickoff as well, and hence are present there because they're expected to be there in a replacement. Add to Task Manager is backed by an undesirable fixed-function implementation indeed, although it improves things for the user in a real way, which made it desirable to implement for now. Discussion in #plasma between Marco, me and others was about ideas like a data engine for launchers that various things could source from; SLC didn't come up. If you feel like your SLC technology could solve this problem more nicely for us, I'd be interested to hear the pitch for how, though! drag and drop + SLC should replace these misfeatures entirely. I'm looking forward to you making me excited to work with you on adopting your approach (this mail did not; I think you understand humans well enough to reason about why). let's have a little smartphone VM in a corner of the screen given when kickoff was designed (and by whom/where), this is a folk etymology of the kickoff UI which bears no resemblance to what actually transpired. I was around during those times, so I'm aware. However, I felt it's an interesting analogy to highlight just why Kickoff never really worked all that well :). Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Looking around and thinking ahead
On Thu, Dec 12, 2013 at 3:29 PM, Aaron J. Seigo ase...@kde.org wrote: On Thursday, December 12, 2013 15:09:25 Eike Hein wrote: On Thursday 12 December 2013 02:26:42 Sebastian Kügler wrote: In plasma-shell, we have some construction sites as well. Kickoff still feels quite unfinished (some would say broken ;)) I wrote a new menu implementation for KDE 4 recently: there a 1000 ways to do a launch ‘menu’, and each will be appreciated by someone out there. give me a menu implementation and i’ll show you someone who loves it to death and someone who wants to do physical harm to the author. so i don’t think it makes much sense to toss N of them in a ring and discuss relative merits. I don't think it makes much sense to dismiss the one and only tossed in (so far anyway) simply because...well, I even don't know why. It's there. It's done. It's usable. Why not at least try it out and actually see if it meets the goals we're trying to reach? It's a different view on how launching apps can be done. I don't see anything wrong with discussing relative merits of how this particular case meets or meets not the goals (and what goals). The result of such discussion can even be used as a basis for new launchers being developed. Plasma2 is still quite far, if Eike's new menu serves mostly well to our needs, there's still enough time Eike can shape it up. Instead we see just a blunt dismissal without any consideration. Which is ok, but not something a maintainer should do imho. If only because it turns down good developers with interest in working on a particular problem. And I don't like that these things even happen in our ranks. I'm happy to take this discussion (new launcher for Plasma2) outside of this thread, but make it actually happen. i’d much rather have a list of goals and then work towards something that meets them. those goals ought to follow the design purpose of the Plasma 2 desktop shell and should probably not be confined to “how can i launch applications?” http://i.imgur.com/KG2R98u.png as an aside: this really makes zero sense to have. it requires plasmoid A to work with plasmoid B in a way that makes lots of assumptions. drag and drop + SLC should replace these misfeatures entirely. I hope that drag'n'drop is not going to replace all context menus out there. Dragging things especially on touchpad is just painful. In these cases context menu is all you ever want. Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Looking around and thinking ahead
On Thursday, December 12, 2013 15:41:05 Eike Hein wrote: On Thursday 12 December 2013 15:29:00 Aaron J. Seigo wrote: as an aside: this really makes zero sense to have. it requires plasmoid A to work with plasmoid B in a way that makes lots of assumptions. Add to Desktop and Add to Panel are present in Kickoff as well, and hence are present there because they're expected to be there in a replacement. yes, it’s also broken in kickoff. i noted that when it was first contributed as well. Discussion in #plasma between Marco, me and others was about ideas like a data engine for launchers that various things could source from; SLC didn't come up. a generic service for this would probably go a long way to improving the situation. let’s look at the use case: * there is an application in place A * i would like it to appear in place B to provide quicker access to it places A / B can be: * application menu * search results (type ‘A’ only, e.g. in krunner) * dock * tasks widget * desktop icon area * icon strip (as in netbook containment) complicating this is that one can have multiple tasks widgets or docks, you might be running the netbook containment (or not), etc. there’s a lot of dynamic pieces there. so i’d propose that one principle needs to be: * place ‘B’ needs to advertise itself as being a possible location an implementation will end up in two parts: a) how the components talk to each other (places A B) b) how the user interacts with the system to initiate that communication drag and drop makes it pretty simple - pick it up here, put it down there. the problem is that “there” is not easy to perceive. many people, it turns out, do not figure out that they can drop an application icon in places they can. they also often don’t think to drag them from places. the “drag from” gap can be resolved with runtime help (as is becoming more and more popular in mobile apps) ... “drop to” probably requires some on-screen hinting so it’s evident where you can drag something to. the “does it accept this mimetype” feature of the drag and drop system gets us at least part-way there perhaps. besides drag and drop, there is the right click menu. it seems more people (though apparently still not enough) have learned that this is where you can look for such things even in the app menu. it doesn’t work with krunner (nearly no one i’ve tested krunner with has tried it.. it’s just too “unusual” to RMB on search results? dunno) ... but perhaps the “from” is at least more obvious. the “to” is more difficult. if there is more than one task widget ... or activity .. where do i send it to? how can that be made clear in a menu listing? how do we refer to “the shortcut strip on the desktop layer” in the netbook interface in a way that most people will quickly identify it and not confront them with jargon? i don’t have answers to this, i just know that all the means we currently offer are letting down a large % of our users. that’s why i suggested we back up, start from goals and move forward from there. doing an amazing job reimplementing things we know don’t work well by design doesn’t move us very far forward. anyways, pursuant to our conversation on irc, this is my last communication and involvement with plasma for a good while. do whatever the rest of your feel makes sense. -- Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Looking around and thinking ahead
On Thursday, December 12, 2013 17:30:47 Martin Klapetek wrote: I don't think it makes much sense to dismiss the one and only tossed in (so far anyway) simply because...well, I even don't know why. It's there. It's done. It's usable. Why not at least try it out and actually see if it meets the goals we're trying to reach? because we have not set out the goals. those will necessarily be derived from decisions made in the larger design of the desktop shell. decisions made w/regards to notifications, for instance, can very well end up influencing the requirements. Instead we see just a blunt dismissal without any consideration. Which is it was not a blunt dismissal of Eike’s plasmoid. it was the suggestion that instead of trying to figure out which of a N different implementations is most desirable, to start with setting our design goals clearly first. not doing so is how we ended up with kickoff. it has served us very well, but most of us agree something better could be done. so my suggestion was: don’t do it the same way. there was *nothing* in my email that suggested that having gone through a design goals process we don’t end up precisely at Eike’s solution. and if we do, we’ll then know why we have without guesswork. ok, but not something a maintainer should do imho. If only because it turns down good developers with interest in working on a particular problem. And saying “no” is one of the most valuable things a maintainer does. in this case, the “no” was pointed at the idea of presenting solutions before we have questions. I don't like that these things even happen in our ranks. I'm happy to take rejoice: you don’t have to worry about it any longer. -- Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Looking around and thinking ahead
On Thursday 12 December 2013 17:46:13 Aaron J. Seigo wrote: complicating this is that one can have multiple tasks widgets or docks, you might be running the netbook containment (or not), etc. there’s a lot of dynamic pieces there. Aye, Add to Panel for example tries to add to the panel containment hosting the applet - in the fullscreen Homerun shell, which runs in a separate process, this actually in- volves D-Bus negotiation with the panel applet to agree on containment id and state, which is sort of a super-primi- tive approximation of a proper system-grade approach to this that e.g. lacks enumeration of possible targets. besides drag and drop, there is the right click menu. it seems more people (though apparently still not enough) have learned that this is where you can look for such things even in the app menu. it doesn’t work with krunner (nearly no one i’ve tested krunner with has tried it.. it’s just too “unusual” to RMB on search results? dunno) ... but perhaps the “from” is at least more obvious. the “to” is more difficult. if there is more than one task widget ... or activity .. where do i send it to? how can that be made clear in a menu listing? how do we refer to “the shortcut strip on the desktop layer” in the netbook interface in a way that most people will quickly identify it and not confront them with jargon? Loosely related: I've always been a bit envious of those scripted interface tutorials in video games that involve steps like click on the highlighted thing on screen to open the dialog. If shell elements/theming pervasively supported a draw attention to this area state it could be used for things like that, but possibly also repurposed to communicate drop targets. It's a big thing to ask of theme artists to support generically, though. that’s why i suggested we back up, start from goals and move forward from there. doing an amazing job reimplementing things we know don’t work well by design doesn’t move us very far forward. I take no issue with a sentiment like no, your menu doesn't cut it in the current form, we can do better. The intention was to create awareness about existing work to see if it could be usefully appropriated towards the goals we come up with. anyways, pursuant to our conversation on irc, this is my last communication and involvement with plasma for a good while. do whatever the rest of your feel makes sense. Let me say that I regret this outcome and will personally miss your insight and experience in the problem space. Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Looking around and thinking ahead
On Thu, Dec 12, 2013 at 5:59 PM, Aaron J. Seigo ase...@kde.org wrote: On Thursday, December 12, 2013 17:30:47 Martin Klapetek wrote: I don't think it makes much sense to dismiss the one and only tossed in (so far anyway) simply because...well, I even don't know why. It's there. It's done. It's usable. Why not at least try it out and actually see if it meets the goals we're trying to reach? because we have not set out the goals. those will necessarily be derived from decisions made in the larger design of the desktop shell. decisions made w/regards to notifications, for instance, can very well end up influencing the requirements. Instead we see just a blunt dismissal without any consideration. Which is it was not a blunt dismissal of Eike’s plasmoid. it was the suggestion that instead of trying to figure out which of a N different implementations is most desirable, to start with setting our design goals clearly first. not doing so is how we ended up with kickoff. it has served us very well, but most of us agree something better could be done. so my suggestion was: don’t do it the same way. there was *nothing* in my email that suggested that having gone through a design goals process we don’t end up precisely at Eike’s solution. and if we do, we’ll then know why we have without guesswork. I very much like to see the kickoff discussion appear in a separate plasma-devel thread. It sounds very interesting, but is quite hard to follow while mixed in all the other ideas being talked about in here. Please do include the goals it should fulfill. From the way you write about kickoff it sounds like you even see an option where there is no start menu at all (aka, the horrible windows 8 route).. I hope i'm wrong :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
