RFC: Removing of decorations
Hi all, I was considering to clean up the window decorations in KWin. Currently we ship: * Oxygen (default) * Aurorae (theme engine) * b2 * laptop * Plastik At least for Plastik we know that it is currently broken with Compositing and nobody is going to fix that. All decorations except Oxygen and Aurorae have not seen any (real) commits since 2009. I consider them as bitrotting. In the past we did one decoration removal where we moved the decorations to kde-artwork. I don't think that kde-artwork should be the dumping ground for visually outdated decorations. And with git that would not be possible anyway. Another solution of the past had been to move the code to tag/unsupported which also does no longer work. So what to do? So I propose the following changes: 1. git rm b2 laptop plastik 2. move Oxygen out of the KWin source tree to have all of Oxygen in one place 3. rename "clients" to "decoration" as I personally find the name confusing due to the fact that there is also a Client class in KWin Deleting the old decorations will mean removing the only decorations which work well for thin clients or X forwarding. But I don't consider this an important enough use case to keep visually outdated decorations around. Any comments? Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workflow Idea for 4.10
Hello, 2012/3/9 Alex Fiestas : > Hi there > > At Active sprint we've used a lunch break for talking about some > "Workflow Issues" we find with the current way of using git in the > workspace, just for mention a few discussed things from the top of m > head: > > - People merge things not ready to be merged (aka using git as we did svn) > - We don't want to change to a 3 month release (or something like that). > - Reviewboard is not the perfect tool for big changes > - Current time schedule has its benefits > > The resulting workflow if we take into account all of that is: > > - Keep the 6 month release period > - Keep the current schedule (soft freeze, hard freeze...) > - Move to a review based workflow before hard freeze (we need gerrit). > - Once we are on hard freeze, open merge for everyone so we can > continue fixing things easily. As many of you might know, I have been a strong advocate of such a thing for quite some time and I cannot be more in agreement with Alex here. I think we should really improve the way our reviews are handled, and enforce more control over the quality of our code. > > Putting manpower aside, I think that this would be a good tentative > attempt for moving to a different thing, we keep a lot of the good > things we have right now and it will allow us to explore the benefits > of the merge based workflow. > > What do you think of it? > > BTW don't mention what we don't have enough reviewers, that's > something that can be work on later, ATM let's just assume we have > infinite man power ;p > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: March Iteration of Frameworks epic
On Friday 09 March 2012 18:11:53 Kevin Ottens wrote: > On Friday 09 March 2012 17:58:35 Martin Gräßlin wrote: > > A few things I will have to discuss with the KDE Frameworks maintainers. > > E.g. I think we should drop the Windows and MacOS X implementations of > > KWindowSystem as it is too close to our X world. > > Disclaimer: I'm close to clueless about KWindowSystem and friends, mainly > shuffling options here. > > I'm wondering if that's a wise choice or if it would be better to make the > API of KWindowSystem less "X oriented". Especially if it lands in Tier 1 I > would see a strong value in the possibility of using KWindowSystem API on > non-X systems. I count at least Wayland based systems which will appear at > some point, we'd better be ready for them if possible. Also the Windows and > MacOS X support are an interesting asset for the library reusability. The library is mostly a wrapper for the Extended Window Manger Hints freedesktop spec. It contains things like setting a window to be kept above other windows. Features not at all available on any system except X (and later on KWin+Wayland). I just had a look at the implementations on Windows [1] and Mac [2]. Both are mostly stubs around "isn't yet implemented" debug messages. So personally I question the usefulness of this API for non X (or KWin+Wayland) systems. I just did a short lxr.kde.org search and it seems that applications using it do not have the calls in an ifdef block. So this might be problematic. Supporting Wayland will btw require quite some work as that will be a change of how the API is designed. The API currently assumes that there is just one windowing system compiled (usage of ifdef). But that won't be the case with Wayland. On the same platform we will have either Wayland or X or most likely both. I have some ideas how to handle that but it will require more thinking. Cheers Martin [1]: http://api.kde.org/4.x-api/kdelibs- apidocs/kdeui/html/kwindowsystem__win_8cpp_source.html [2]: http://api.kde.org/4.x-api/kdelibs- apidocs/kdeui/html/kwindowsystem__mac_8cpp_source.html signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: March Iteration of Frameworks epic
On Friday 09 March 2012, Martin Gräßlin wrote: > Hi all, > > the March Iteration of splitting kdelibs [1] involves KWindowSystem. As I > was appointed to be responsible for that I will concentrate my work on > this epic starting from next week. Any help is more than appreciated. > > What I plan to achieve: > * getting kwindowsystem as a Tier 1 library (currently it's planned as a > Tier 2) > * moving Plasma::WindowEffects into this library +1. by the way if in libplasma2 (at least in the qml version) there is 0 of window management related stuff (and x dependencies) i would be just happy(tm) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: March Iteration of Frameworks epic
On Friday 09 March 2012 17:58:35 Martin Gräßlin wrote: > the March Iteration of splitting kdelibs [1] involves KWindowSystem. As I > was appointed to be responsible for that I will concentrate my work on this > epic starting from next week. Any help is more than appreciated. Glad to read that. In case you missed it though, Aaron started a bit on the split, so there's already something in staging/. Probably worth talking to him in case he had plans not yet available in the repo. > What I plan to achieve: > * getting kwindowsystem as a Tier 1 library (currently it's planned as a > Tier 2) I honestly don't remember the reason why it was tentatively earmarked Tier 2. But if you manage to make it Tier 1, all the better. > * moving Plasma::WindowEffects into this library > * reaching a test coverage of > 90 % Thumb up to that. :-) > * removing all deprecated atom hints/legacy functionality etc. > * clean up coding style ;-) > * where it makes sense introduce Q_PROPERTIES > > A few things I will have to discuss with the KDE Frameworks maintainers. > E.g. I think we should drop the Windows and MacOS X implementations of > KWindowSystem as it is too close to our X world. Disclaimer: I'm close to clueless about KWindowSystem and friends, mainly shuffling options here. I'm wondering if that's a wise choice or if it would be better to make the API of KWindowSystem less "X oriented". Especially if it lands in Tier 1 I would see a strong value in the possibility of using KWindowSystem API on non-X systems. I count at least Wayland based systems which will appear at some point, we'd better be ready for them if possible. Also the Windows and MacOS X support are an interesting asset for the library reusability. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com 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
March Iteration of Frameworks epic
Hi all, the March Iteration of splitting kdelibs [1] involves KWindowSystem. As I was appointed to be responsible for that I will concentrate my work on this epic starting from next week. Any help is more than appreciated. What I plan to achieve: * getting kwindowsystem as a Tier 1 library (currently it's planned as a Tier 2) * moving Plasma::WindowEffects into this library * reaching a test coverage of > 90 % * removing all deprecated atom hints/legacy functionality etc. * clean up coding style ;-) * where it makes sense introduce Q_PROPERTIES A few things I will have to discuss with the KDE Frameworks maintainers. E.g. I think we should drop the Windows and MacOS X implementations of KWindowSystem as it is too close to our X world. I plan to do a review request for each change and include the kwin group, for things needing discussions I will start an RFC thread first (e.g. should we change desktop with number 0 to be the first desktop as it is in NETWM spec). Cheers Martin [1] http://community.kde.org/Frameworks/Epics/Splitting_kdelibs#March_Iteration signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: activity aware plasmoids
On Friday, March 09, 2012 10:30:40 Marco Martin wrote: > On Monday 05 March 2012, Sebastian Kügler wrote: > > On Saturday, February 25, 2012 16:01:15 Marco Martin wrote: > > > not storing the entries of the various social media i think, since is > > > too > > > volatile data that loses meaning pretty quickly, but having the "twitter > > > source" facebook source and so on as resources, that gets associated to > > > the activitiy resources (funny fact, association of any nepomuk resource > > > to an activity is something already supported, is just the desktop that > > > lacks an ui for it.. yet > > > > This could (probably should) be unified through Akonadi, which would make > > give us most of the complicated things for free. THere's already a > > (unmaintained) microblogging resource, we support all kinds of emails > > (social networking for geeks ;)), Thomas McGuire has been working on a > > Facebook Akonadi resource, etc. > > > > So what's needed is a mechanism to combine and display this data, and > > probably a bit more streamlined configuration. Ow, and more resources for > > social networks. > > btw, do we have note on the breakout session at the active sprint on > exactly this topic? should be published and used as starting point *pokes Marty* -- 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: Workflow Idea for 4.10
On 9 March 2012 01:27, Alex Fiestas wrote: > - Move to a review based workflow before hard freeze (we need gerrit). > That's really great. We need gerrit and I hope that we will have it available soon. The usage of gerrit has some cons but eventually we have to use it. Regards, Giorgos -- Giorgos Tsiapaliwkas (terietor) KDE Developer terietor.gr ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: activity aware plasmoids
On Monday 05 March 2012, Sebastian Kügler wrote: > On Saturday, February 25, 2012 16:01:15 Marco Martin wrote: > > not storing the entries of the various social media i think, since is too > > volatile data that loses meaning pretty quickly, but having the "twitter > > source" facebook source and so on as resources, that gets associated to > > the activitiy resources (funny fact, association of any nepomuk resource > > to an activity is something already supported, is just the desktop that > > lacks an ui for it.. yet > > This could (probably should) be unified through Akonadi, which would make > give us most of the complicated things for free. THere's already a > (unmaintained) microblogging resource, we support all kinds of emails > (social networking for geeks ;)), Thomas McGuire has been working on a > Facebook Akonadi resource, etc. > > So what's needed is a mechanism to combine and display this data, and > probably a bit more streamlined configuration. Ow, and more resources for > social networks. btw, do we have note on the breakout session at the active sprint on exactly this topic? should be published and used as starting point -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
