Re: Review Request 114396: Fix KWindowSystem_X11 changeWindow signal emitting
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114396/#review45590 --- Ship it! Ship It! - Kevin Ottens On Dec. 11, 2013, 6:57 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114396/ --- (Updated Dec. 11, 2013, 6:57 a.m.) Review request for KDE Frameworks and Plasma. Repository: kdelibs Description --- I don't mind whether that goes in before or after the split. Just creating the review request as I have the patch ready, but it's no problem to recreate the patches after the split. commit d6756e252fb05bfc88041ce1d2896be66097de26 Author: Martin Gräßlin mgraess...@kde.org Date: Wed Dec 11 07:36:29 2013 +0100 Properly set the event mask on the windows watched by KWindowSystem KWindowSystem tried to only change the event mask for windows not belonging to the same process by using QWidget::find to test whether the window belongs to the same process or not. This does no longer work in a QWindow world. If the window belongs to a Q(Quick)Window QWidget::find returns a nullptr just like for windows of another process. This caused the XSelectWindow to overwrite the event mask used by Qt and thus for example mouse events were no longer recieved at all. With this change the event mask is updated for all windows, no matter whether it's an own or a foreign window. But the event mask currently installed on the window is preserved, so Qt still gets the events it expects. commit 87fda66987516c6fa04582c75f50af184d641a26 Author: Martin Gräßlin mgraess...@kde.org Date: Wed Dec 11 07:31:13 2013 +0100 Adjust KWindowSystem_X11 to the changes in connectNotify The functionality was rather broken, the conditions on the arguments to pass into the init() method were never evaluated. This meant that the windowChanged signal never got emitted. Diffs - tier1/kwindowsystem/src/kwindowsystem_x11.cpp f152929 Diff: http://git.reviewboard.kde.org/r/114396/diff/ Testing --- Tested with Plasma2's taskmanager. Without the connectNotify adjustment the taskmanager does not update on window changes. With the connectNotify patch but without the select input patch it properly updates but all of plasma is broken because it doesn't get mouse events. With both patches everything works as expected \o/ This was a fun investigation... Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 114396: Fix KWindowSystem_X11 changeWindow signal emitting
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114396/ --- (Updated Dec. 12, 2013, 10:40 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Plasma. Repository: kdelibs Description --- I don't mind whether that goes in before or after the split. Just creating the review request as I have the patch ready, but it's no problem to recreate the patches after the split. commit d6756e252fb05bfc88041ce1d2896be66097de26 Author: Martin Gräßlin mgraess...@kde.org Date: Wed Dec 11 07:36:29 2013 +0100 Properly set the event mask on the windows watched by KWindowSystem KWindowSystem tried to only change the event mask for windows not belonging to the same process by using QWidget::find to test whether the window belongs to the same process or not. This does no longer work in a QWindow world. If the window belongs to a Q(Quick)Window QWidget::find returns a nullptr just like for windows of another process. This caused the XSelectWindow to overwrite the event mask used by Qt and thus for example mouse events were no longer recieved at all. With this change the event mask is updated for all windows, no matter whether it's an own or a foreign window. But the event mask currently installed on the window is preserved, so Qt still gets the events it expects. commit 87fda66987516c6fa04582c75f50af184d641a26 Author: Martin Gräßlin mgraess...@kde.org Date: Wed Dec 11 07:31:13 2013 +0100 Adjust KWindowSystem_X11 to the changes in connectNotify The functionality was rather broken, the conditions on the arguments to pass into the init() method were never evaluated. This meant that the windowChanged signal never got emitted. Diffs - tier1/kwindowsystem/src/kwindowsystem_x11.cpp f152929 Diff: http://git.reviewboard.kde.org/r/114396/diff/ Testing --- Tested with Plasma2's taskmanager. Without the connectNotify adjustment the taskmanager does not update on window changes. With the connectNotify patch but without the select input patch it properly updates but all of plasma is broken because it doesn't get mouse events. With both patches everything works as expected \o/ This was a fun investigation... Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 114396: Fix KWindowSystem_X11 changeWindow signal emitting
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114396/#review45593 --- This review has been submitted with commit 8bab9b8cfc129c34f9c2a1c92d56e51c8708a671 by Martin Gräßlin to branch frameworks. - Commit Hook On Dec. 11, 2013, 6:57 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114396/ --- (Updated Dec. 11, 2013, 6:57 a.m.) Review request for KDE Frameworks and Plasma. Repository: kdelibs Description --- I don't mind whether that goes in before or after the split. Just creating the review request as I have the patch ready, but it's no problem to recreate the patches after the split. commit d6756e252fb05bfc88041ce1d2896be66097de26 Author: Martin Gräßlin mgraess...@kde.org Date: Wed Dec 11 07:36:29 2013 +0100 Properly set the event mask on the windows watched by KWindowSystem KWindowSystem tried to only change the event mask for windows not belonging to the same process by using QWidget::find to test whether the window belongs to the same process or not. This does no longer work in a QWindow world. If the window belongs to a Q(Quick)Window QWidget::find returns a nullptr just like for windows of another process. This caused the XSelectWindow to overwrite the event mask used by Qt and thus for example mouse events were no longer recieved at all. With this change the event mask is updated for all windows, no matter whether it's an own or a foreign window. But the event mask currently installed on the window is preserved, so Qt still gets the events it expects. commit 87fda66987516c6fa04582c75f50af184d641a26 Author: Martin Gräßlin mgraess...@kde.org Date: Wed Dec 11 07:31:13 2013 +0100 Adjust KWindowSystem_X11 to the changes in connectNotify The functionality was rather broken, the conditions on the arguments to pass into the init() method were never evaluated. This meant that the windowChanged signal never got emitted. Diffs - tier1/kwindowsystem/src/kwindowsystem_x11.cpp f152929 Diff: http://git.reviewboard.kde.org/r/114396/diff/ Testing --- Tested with Plasma2's taskmanager. Without the connectNotify adjustment the taskmanager does not update on window changes. With the connectNotify patch but without the select input patch it properly updates but all of plasma is broken because it doesn't get mouse events. With both patches everything works as expected \o/ This was a fun investigation... Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Sprint Dates!
On Wednesday 11 December 2013 17:18:40 Sebastian Kügler wrote: * arrange stuff locally (is office big enough, plans for food and accommodation, make sure chocolate supply is green, etc.) * Meet, hack, have fun The office will be ready to host ~20 people sprints by then, so something less to worry about (unless we end up being 40 people xD) Cheers. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Nepomuk in 4.13 and beyond
Hey everyone During the KDE 4.11 cycle Nepomuk reached a maturity level that we were happy with, it is reasonably fast, stable, and unless used together with Akonadi it is no longer the CPU consumer it was before. We reached this state after years of analyzing what was wrong and what could be improved to the point where we no longer think any more improvement is possible only by modifying our code. The next place where we could seek improvement was the RDF storage. We have been using Virtuoso for about 4 years and it's been a game changer for us performing way faster than any other of the alternatives we ever used before and more efficiently, but as many of you know (and others suffer) it is not a RDF storage designed for the desktop and it will never be. Since nothing better than Virtuoso exists for our use-case, we started to implement our own RDF storage mechanism (codenamed Vishuoso). At some point during that progress we took a step back and re-analyzed the problems of the workspace and the current implementation. The problems are - - Resource Description Framework (RDF) The biggest problem with RDF is that it raises the knowledge needed to contribute to a point where most developers decide to to skip it. After all these years only a handful of brave developers have worked with it and the experience hasn't been good. Then we need something easier to use so we can see a more broad adoption. Additionally, RDF is a very flexible way to store data, it is however not the most efficient way. Data is generally completely normalized even though it is quite often not required. Eg - One doesn't need to store music file artists as a separate contact. This is great, from a theoretical point of view, but it is not very useful in practice. - RDF Storage There is no existing RDF storage designed to work in a Desktop. Virtuoso is great but it quickly uses hundreds of megabytes of ram and it has its own share of problems. The other alternative is tracker, but they lack certain features required in Nepomuk. - Data duplication Nepomuk has been used as both a search store and a data store. This results in massive data duplication and synchronization problems. In the case of Akonadi, emails are stored in Akonadi and are then duplicated in virtuoso, and are then duplicated in virtuoso's index. Every time data is changed in Akonadi it has to be updated in Nepomuk and vice-versa. This results in a process being responsible just for synchronizing the two stores. - API Duplication With the data residing in both Nepomuk and other stores (Akonadi/Files/etc), it isn't always clear which store it should be accessed from. This essentially results in duplication of APIs. Eg - Using KABC vs accessing contacts from Nepomuk. These problems would still exist even if we had the fastest and most efficient RDF storage in the world. At this point it was clear to us that the future was not going to be RDF. The next thing we did was to analyze our actual needs based on the last 5 years of Nepomuk. Our needs are - * Full text index for searching * Data store for simple objects such as tags / ratings / activities / etc * Relations - Forming relations between different objects. Eg - This file is related to this activity or person. Each of these problems is independently solvable without RDF. About 2 months ago we started to draft Baloo [1], a metadata solution that will cover the bare necessities of each use case we have. I'd like to avoid getting into the technical details of the implementation in this thread. Another thread can be started about its different aspects once you've read the basic ideas behind Baloo [2] Current Plans - After a month of designing the solution and a month of implementing it, Baloo is working way better than Nepomuk does. So, I'd like to switch to Baloo by default in 4.13, while keeping Nepomuk in maintenance mode for more conservative distributions. This is not a completely new project as large parts of Baloo code are derived from Nepomuk and therefore comes with years of testing and real world use. Baloo was also discussed in PIM Sprint and the PIM developers are happy to completely drop Nepomuk support for 4.13 and move to Baloo. Similarly, the telepathy developers are also working on moving KPeople away from Nepomuk. Migration - There will be an automated migration mechanism for migrating tags, ratings and comments from Nepomuk to Baloo. Trying it out? --- Developers are welcome to try out Baloo and have a look at the current source code. It's a still a work in progress, but we strongly feel that it is a step in the right direction. I'd recommend using Milou [3] for searching. -- Vishesh Handa [1] https://projects.kde.org/projects/playground/base/baloo [2] http://techbase.kde.org/Projects/Baloo [3] https://projects.kde.org/projects/playground/base/milou
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: Nepomuk in 4.13 and beyond
On Thursday 12 December 2013, Ignacio Serantes wrote: Welcome Baloo, New suggestions about development direction to avoid some problems related to Nepomuk: 1) Baloo must work as a service to share information with other users and minimize resources consumption. With Nepomuk a login is required and in multiuser environment this is a problem. 2) Data must be stored in one repository to improve information sharing with other users in the same or other computers. Sharing information between users opens the door for security issues. If it should be running as a service, I'm quite sure some kind of login or authentication will always be required. And you will need access permissions and manage them. Or am I missing something ? 3) Remote installation will be a good solution in cases you have several, with mixed OS or old, computers in your home or your office because some users prefer sharing data over speed. With cheap cloud computing have an own server running some services will be more common (owncloud, mpd, quassel, etc...) so considering this for the future would be great. This changes the security issues from local exploits to remote exploits. Are you sure we want to go that way, if the plan is to make things simpler ? Alex ___ 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
Re: Plasma Sprint Dates!
On Wed, Dec 11, 2013 at 5:18 PM, Sebastian Kügler se...@kde.org wrote: Hi all, Our doodle has pretty clearly shown that the next Plasma sprint should be taking part from Fri, 10th January to Thu, 16th. (Meaning: plan to arrive on Friday, plan to depart on Thu.) Please be quick to add your participation to the following page as this is he basis for all planning. Ideally, do it right now. https://sprints.kde.org/sprint/176 Location is planned to be Barcelona, we can use the Blue Systems office there. Barcelona is easy to reach for most people, some are already there (reducing travel cost and CO2 footprint), and Spain is not too cold in winter. Next steps are: * get everyone to sign up on sprints.kde.org * find a way to cover travel costs * buy tickets * arrange stuff locally (is office big enough, plans for food and accommodation, make sure chocolate supply is green, etc.) * Meet, hack, have fun So, head over to sprints.kde.org already, and information as detailed as possible, and ask me if you've questions. 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 6 days of sprinting! Wow, not used to that, pim is always 3 days. How many people usually attend the plasma sprints? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Sprint Dates!
On Thursday, December 12, 2013 22:47:17 Mark Gaiser wrote: 6 days of sprinting! Wow, not used to that, pim is always 3 days. How many people usually attend the plasma sprints? 15 is pretty normal, though we had smaller and larger ones. -- 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
Review Request 114424: Add shadow to lancelot main window when using a qt style which supports kde shadow hints
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114424/ --- Review request for Plasma, Aaron J. Seigo and Martin Gräßlin. Bugs: 320995 http://bugs.kde.org/show_bug.cgi?id=320995 Repository: kdeplasma-addons Description --- The lancelot main window sets the _KDE_NET_WM_SHADOW property to 1 but never set anything valid to it and therefore has no drop shadow. This patch add the shadow when using a qt style that is aware of the KDE shadow hint in the widget's property. I haven't found a documentation for this property but it seems that they are recognized by oxygen and are also copied to qtcurve (and probably bespin, haven't checked). A better solution might be using the plasma shadow although I don't know how to do that without copying the code to install shadows from kdelibs, unless someone adds a new api to apply plasma themed shadows to a window. Diffs - applets/lancelot/application/LancelotWindow.cpp c66c565 Diff: http://git.reviewboard.kde.org/r/114424/diff/ Testing --- Compiles. Have shadow with both oxygen and qtcurve. Thanks, Yichao Yu ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 114428: Replaced Text {} by Label {} using PlasmaComponents in mediaelements
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/114428/
---
Review request for Plasma.
Repository: plasma-mediacenter
Description
---
Replaced Text {} by PlasmaComponents.Label {}
Diffs
-
mediaelements/mediawelcome/BackendsListDelegate.qml e76af63
mediaelements/mediawelcome/CategoriesListDelegate.qml f011bae
mediaelements/mediawelcome/HomeScreenFooter.qml d2c0eb7
mediaelements/mediawelcome/HomeScreenText.qml 35cd20a
Diff: http://git.reviewboard.kde.org/r/114428/diff/
Testing
---
works fine .
Thanks,
Heena Mahour
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 114429: use of time data engine - less code
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/114429/
---
Review request for Plasma, Shantanu Tushar, Sinny Kumari, and Sujith Haridasan.
Repository: plasma-mediacenter
Description
---
Replaced Text{} by Label {}
Time Data engine instead of creating Date() and hours - less code !
text color is predefined in Label {}
Diffs
-
mediaelements/mediawelcome/BackendsListDelegate.qml e76af63
mediaelements/mediawelcome/CategoriesListDelegate.qml f011bae
mediaelements/mediawelcome/HomeScreenFooter.qml d2c0eb7
mediaelements/mediawelcome/HomeScreenText.qml 35cd20a
Diff: http://git.reviewboard.kde.org/r/114429/diff/
Testing
---
yeah ,works fine ,displays days as well now.
Thanks,
Heena Mahour
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 114428: Replaced Text {} by Label {} using PlasmaComponents in mediaelements
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/114428/
---
(Updated Dec. 13, 2013, 7:09 a.m.)
Review request for Plasma, Shantanu Tushar, Sinny Kumari, and Sujith Haridasan.
Repository: plasma-mediacenter
Description
---
Replaced Text {} by PlasmaComponents.Label {}
Diffs
-
mediaelements/mediawelcome/BackendsListDelegate.qml e76af63
mediaelements/mediawelcome/CategoriesListDelegate.qml f011bae
mediaelements/mediawelcome/HomeScreenFooter.qml d2c0eb7
mediaelements/mediawelcome/HomeScreenText.qml 35cd20a
Diff: http://git.reviewboard.kde.org/r/114428/diff/
Testing
---
works fine .
Thanks,
Heena Mahour
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 114428: Replaced Text {} by Label {} using PlasmaComponents in mediaelements
On Dec. 13, 2013, 7:10 a.m., Shantanu Tushar wrote:
mediaelements/mediawelcome/HomeScreenText.qml, line 25
http://git.reviewboard.kde.org/r/114428/diff/1/?file=224648#file224648line25
Label should pick this up automatically, check if we can remove this.
yeah the color stays same if I remove it
- Heena
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/114428/#review45622
---
On Dec. 13, 2013, 7:09 a.m., Heena Mahour wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/114428/
---
(Updated Dec. 13, 2013, 7:09 a.m.)
Review request for Plasma, Shantanu Tushar, Sinny Kumari, and Sujith
Haridasan.
Repository: plasma-mediacenter
Description
---
Replaced Text {} by PlasmaComponents.Label {}
Diffs
-
mediaelements/mediawelcome/BackendsListDelegate.qml e76af63
mediaelements/mediawelcome/CategoriesListDelegate.qml f011bae
mediaelements/mediawelcome/HomeScreenFooter.qml d2c0eb7
mediaelements/mediawelcome/HomeScreenText.qml 35cd20a
Diff: http://git.reviewboard.kde.org/r/114428/diff/
Testing
---
works fine .
Thanks,
Heena Mahour
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 114428: Replaced Text {} by Label {} using PlasmaComponents in mediaelements
On Dec. 13, 2013, 7:10 a.m., Shantanu Tushar wrote:
mediaelements/mediawelcome/HomeScreenFooter.qml, line 54
http://git.reviewboard.kde.org/r/114428/diff/1/?file=224647#file224647line54
Please verify that. If it looks the same, then go ahead and remove.
Default size of Label is smaller than 20 So I did not changed it .
- Heena
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/114428/#review45622
---
On Dec. 13, 2013, 7:24 a.m., Heena Mahour wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/114428/
---
(Updated Dec. 13, 2013, 7:24 a.m.)
Review request for Plasma, Shantanu Tushar, Sinny Kumari, and Sujith
Haridasan.
Repository: plasma-mediacenter
Description
---
Replaced Text {} by PlasmaComponents.Label {}
Diffs
-
mediaelements/mediawelcome/BackendsListDelegate.qml e76af63
mediaelements/mediawelcome/HomeScreenFooter.qml d2c0eb7
mediaelements/mediawelcome/HomeScreenText.qml 35cd20a
Diff: http://git.reviewboard.kde.org/r/114428/diff/
Testing
---
works fine .
Thanks,
Heena Mahour
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 114428: Replaced Text {} by Label {} using PlasmaComponents in mediaelements
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/114428/#review45627
---
mediaelements/mediawelcome/HomeScreenFooter.qml
http://git.reviewboard.kde.org/r/114428/#comment32577
The PMC time doesn't get synced with desktop time. Can you tune this
further to get it synced?
mediaelements/mediawelcome/HomeScreenFooter.qml
http://git.reviewboard.kde.org/r/114428/#comment32576
Remove the white space
- Sujith Haridasan
On Dec. 13, 2013, 7:24 a.m., Heena Mahour wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/114428/
---
(Updated Dec. 13, 2013, 7:24 a.m.)
Review request for Plasma, Shantanu Tushar, Sinny Kumari, and Sujith
Haridasan.
Repository: plasma-mediacenter
Description
---
Replaced Text {} by PlasmaComponents.Label {}
Diffs
-
mediaelements/mediawelcome/BackendsListDelegate.qml e76af63
mediaelements/mediawelcome/HomeScreenFooter.qml d2c0eb7
mediaelements/mediawelcome/HomeScreenText.qml 35cd20a
Diff: http://git.reviewboard.kde.org/r/114428/diff/
Testing
---
works fine .
Thanks,
Heena Mahour
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
