Re: Workflow Idea for 4.10

[Ignat Semenov]

Hello fellow KDE devs!

While I'm not an experienced developer nor manager, the planned transition 
to gerrit really troubles me. In particular, I have the following questions:

1)The gerrit installation used in qt makes it impossible to add comments 
other than directly to the diff. No way to add comments on the main review 
request page as it is in the RB installation we're currently using. Is there 
any way to overcome that limitation?

2)The user interface of gerrit is horrible to say the least. The diff / 
comment area is the last class citizen there. RR is way more clear and user-
friendly (esp. newcomers).

3)Does this transition mean we will have to use the full gerrit contribution 
cycle, like it is in qt now, with branches and the special tools, even for 
the smallest fixes? This will drive off new contributors, I'm afraid.

4)The Qt gerrit installation requires authentication just to browse the 
existing requests read-only. Is it possible to do it differently or is this 
a shortcoming of gerrit ( or its "design feature")? Pretty user- and 
newcomer-unfriendly, too.

Best regards,
Ignat Semenov
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Workflow Idea for 4.10

[Antonis Tsiapaliokas]

>
> On each occasion the conclusion reached was that Gerrit would be
> difficult to maintain and would increase the complexity involved for
> pre-existing contributors.
>

On big/complex projects contributors are using branches instead of the
reviewboard,
because it is to difficult to keep track on which changes has be done. Also
with git diff
it is more difficult to avoid git conflicts. Furthermore testing big
patches with git diff is not
possible. For examples on kdelibs-frameworks. So contributors MUST learn
how to handle
git branches and merges between their branch and the origin one. Which
sometimes, is very
stressful for the contributor, also some mistakes are happen. And as a
result of that, the mentors
and the contributors are losing a lot of time in order to fix those.


> Among the issues found:
> - Gerrit implements the git protocol itself, and has an internal SSH
> server.
> - Changes would be necessary to integrate it with Identity as we store
> SSH keys in Identity. It is not clear how invasive these changes would
> be.
>

In my opinion, before we make a big change into our infrastructure, we must
first test it. Because without testing, we cannot be sure if the new
infrastructure
is useful/harmful for our community. Also big changes like that should not
be
applied in the whole KDE. Because they might create some panic. So in my
opinion the best think that we have to do is to search for some teams which
they want to test it, and based on the result, then we can either start
applied the
new infrastructure to the whole KDE or we could just reject the idea.

Of course a new infra might not cover our needs with its
original structure, so we could
keep both gerrit and reviewboard. And as regards the contributors, they can
choose which
one they want to use.

Also when KDE moved from svn to git, the amarok was one of the projects
which was moved
to the gitorious. In order to test if the gitorious fit our needs. So since
we are talking about the infra
i do not see a valid reason for which we should not do the same here.

As regards the ssh keys, gerrit allows the contributor to upload his ssh
key and a "trusted" user to
approve it. So this close the security issue. Also in order for someone to
take git access, he need someone
to approve him. So it is clear that when a developer from
plasma,kwin,kdelibs,amarok etc is approving someone
then it is his own responsibility to choose wise, before he says the "ok".

As regards the contributor, it is clear enough that people that don't know
how to copy/paste their ssh key into
gerrit, that they don't even know what git means. So those people are not
ready to have access on those tools.
They could simple use the reviewboard.

Of course the above idea is just a "work around", i don't say that this
will be our policy but until we decide if
gerrit is good for us or not, then it will simple do its work :)


> - Gerrit is a Java application, and past experience with them indicate
> that are very resource intensive.
> - Gerrit operates with the assumption it has permission to push to the
> master repositories, providing a security vulnerability to our
> infrastructure.
> - Permissions would need to be duplicated between Gerrit and Gitolite,
> the system responsible for managing git repositories on git.kde.org.
>
> The security of git.kde.org and svn.kde.org is something which can
> never be affected or weakened in any form.
>
>
After we test gerrit, we could simple decide if we have the infra which is
required or not.
Also on active projects, the mentors are using the commitfilter.kde.org
and the rss from the projects.kde.org, so they could see if there is a bug
or some kind of an abuse. After all this is the meaning of the "testing".

EVERY change into the infra might cause some security issues but there
is nothing that we can do with that. Also your custom patches might not work
without a little adjustment BUT when you rewrite an application or the
infra this
is something that cannot be avoid. Also if we always want to have an
application/infra which was going to be 98% secure (there is nothing like
100% SAFE :))
then we shouldn't move from git to svn and we shouldn't move from KDE3 to
KDE4.
In every thing there are cons and ads. The point is if there are more ads
than the cons. :)

Also KDE4 is much bigger than the KDE3 was. And KDE5 will be even bigger.
So we must change our infra in order the mentors will not lose time trying
to
fix the mistakes of the contributors which might happen because of a bad
merge
or push. Also gerrit can build projects or try to see if their unit tests
are 100% ok.
So WITH GERRIT will we be able to reduce the REGRASSIONS!!!

In conclusion, i think that we should use gerrit because it will simple
make our lives
easier and our code better :)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Make thumbnail size configurable and tell KIO to use all thumbnailer plguins

[Commit Hook]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104229/#review11334
---


This review has been submitted with commit 
072cc784c614614e177efa2b6aebe1ba1ab02de6 by Shantanu Tushar to branch master.

- Commit Hook


On March 11, 2012, 4:51 p.m., Shantanu Tushar Jha wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104229/
> ---
> 
> (Updated March 11, 2012, 4:51 p.m.)
> 
> 
> Review request for Plasma and Marco Martin.
> 
> 
> Description
> ---
> 
> This patch makes two additions-
> 1. Thumbnail size is hardcoded into metadatamodel, this patch adds a property 
> to make it configurable
> 2. KIO Thumbnailer uses a default set of plugins (from global config, which 
> can't be set from PA) which doesn't include video thumbnailers for example. 
> This makes metadatamodel fail when its asked for a thumbnail for a video 
> file. This patch explicitly tells KIO to use all plugins.
> 
> 
> Diffs
> -
> 
>   components/metadatamodel/metadatamodel.h 85750fe 
>   components/metadatamodel/metadatamodel.cpp 74ad09c 
> 
> Diff: http://git.reviewboard.kde.org/r/104229/diff/
> 
> 
> Testing
> ---
> 
> Both features work when tested from QML and don't seem to have any 
> side-effects.
> 
> 
> Thanks,
> 
> Shantanu Tushar Jha
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Make thumbnail size configurable and tell KIO to use all thumbnailer plguins

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104229/#review11327
---

Ship it!


Ship It!

- Marco Martin


On March 11, 2012, 4:51 p.m., Shantanu Tushar Jha wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104229/
> ---
> 
> (Updated March 11, 2012, 4:51 p.m.)
> 
> 
> Review request for Plasma and Marco Martin.
> 
> 
> Description
> ---
> 
> This patch makes two additions-
> 1. Thumbnail size is hardcoded into metadatamodel, this patch adds a property 
> to make it configurable
> 2. KIO Thumbnailer uses a default set of plugins (from global config, which 
> can't be set from PA) which doesn't include video thumbnailers for example. 
> This makes metadatamodel fail when its asked for a thumbnail for a video 
> file. This patch explicitly tells KIO to use all plugins.
> 
> 
> Diffs
> -
> 
>   components/metadatamodel/metadatamodel.h 85750fe 
>   components/metadatamodel/metadatamodel.cpp 74ad09c 
> 
> Diff: http://git.reviewboard.kde.org/r/104229/diff/
> 
> 
> Testing
> ---
> 
> Both features work when tested from QML and don't seem to have any 
> side-effects.
> 
> 
> Thanks,
> 
> Shantanu Tushar Jha
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: RFC: Removing of decorations

[Martin Gräßlin]

On Monday 12 March 2012 10:54:52 Hugo Pereira Da Costa wrote:
> 1. I'm all for removing the unmaintained decoration.
> 2. I'm not sure about the rationale for moving oxygen's (deco) out of
> kwin tree.
> It is a decoration client, and therefore would best stay is in
> kwin/clients.
> (especially since it has to be build on top of kwin, unlike oxygen's
> "libs" and oxygen's "style").
> 
> As for the argument "having all oxygen's code in one place". Well, that
> would also require to have oxygen's widget style and oxygen's lib at the
> same place.  (which one ?). And you would still need a "liboxygen.so"
> anyway, I think, for the code that is shared by the widget style and the
> decoration.
> 
> This to say, what would the moving actually address, solve ?
> (you do need to build kwin anyway in order to build oxygen's client).
I thought that Oxygen would have wanted to have all code in one place and that 
this has never been possible because the deco has to be inside kwin.

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: Review Request: Make thumbnail size configurable and tell KIO to use all thumbnailer plguins

[Marco Martin]

> On March 11, 2012, 10:36 p.m., Marco Martin wrote:
> > looks fine, but i would prefer the thumbnail plugins to be configurable if 
> > more than images are going to be used
> 
> Shantanu Tushar Jha wrote:
> I didn't understand the "more than images are going to be used" part :(
> 
> (KIO includes three plugins by default "directorythumbnail", 
> "imagethumbnail", "jpegthumbnail")

i mean, support for different types of thumbnail plugins configurable.

but since they are generated in a quite lazy way (no preview is generated until 
asked for) you can go for it, then we'll see if it impacts performancein any way


- Marco


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104229/#review11302
---


On March 11, 2012, 4:51 p.m., Shantanu Tushar Jha wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104229/
> ---
> 
> (Updated March 11, 2012, 4:51 p.m.)
> 
> 
> Review request for Plasma and Marco Martin.
> 
> 
> Description
> ---
> 
> This patch makes two additions-
> 1. Thumbnail size is hardcoded into metadatamodel, this patch adds a property 
> to make it configurable
> 2. KIO Thumbnailer uses a default set of plugins (from global config, which 
> can't be set from PA) which doesn't include video thumbnailers for example. 
> This makes metadatamodel fail when its asked for a thumbnail for a video 
> file. This patch explicitly tells KIO to use all plugins.
> 
> 
> Diffs
> -
> 
>   components/metadatamodel/metadatamodel.h 85750fe 
>   components/metadatamodel/metadatamodel.cpp 74ad09c 
> 
> Diff: http://git.reviewboard.kde.org/r/104229/diff/
> 
> 
> Testing
> ---
> 
> Both features work when tested from QML and don't seem to have any 
> side-effects.
> 
> 
> Thanks,
> 
> Shantanu Tushar Jha
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Workflow Idea for 4.10

[Marco Martin]

On Friday 09 March 2012, Alex Fiestas wrote:
> 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.

that's sounds good.

to me the ideal(tm) would be to not have much open/frozen master periods but 
rather have a master that is always in a releasable state, so a bit more 
destructured, but that seems even harder and this seems a good first step for 
it

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Widgets Sidebar

[Yi Xia]

I was not subscribed to the mailing list so didn't get anything back from
the post before.
So for the reply to :

>On Sunday, March 4, 2012 20:04:28 Yi Xia wrote:
>>* Hello,*
> >* *
> >* Our team is trying to simply the Kubuntu 11.10 operating system and one
*
> >* major task is to remove the sidebar of the widgets which will appear
when*
> >* the mouse is moved onto the widget.*
>
> the easiest way is to change the type of the containment from
> DesktopContainment to CustomContainment.
>
>in libplasma2 we intend to make the applet handles customizable / provided
by
> the containment and/or shell much as how the context menus are.
>
> >* Our goal is to get rid of the sidebar but still keep the widgets
unlocked.*
>
>and how is the user going to reliably move or configure the widgets?
>
>while what you ask for is possible, unless you provide a reasonable
> replacement you will simply cause your users more grief by making it
>impossible for them reliably move, configure or close widgets. i would
also
>suggest that making users rely on right click menus is not simplifying
>anything.
>
>can you tell us which OS and/or device this will appear on so we know how
to
>identify incoming bug reports that may end up related to this? thanks...
>
>--
>Aaron J. Seigo___
>Plasma-devel mailing list
>Plasma-devel@xxx
>https://mail.kde.org/mailman/listinfo/plasma-devel

 *Could you give more information on how to change the type of containment
or where the files are located?*

*Regarding the configuration of the widgets, our idea is to use Kinect as
the input source and since most widgets can be moved around by clicking on
themselves rather than the side menu bar.
Per resizing, we are trying to map two cursors in the X11 and use two
clicking to zoom, like someone does on the iPad or other multi-touch
tablets. But that's still under progress.
Other configurations like settings, rotating will just be discarded since
this is not going be become a commercial product but rather just a design
project. *

*Our OS is Kubuntu 11.10, device is just the Microsoft Kinect.
*

*Thank you.*

*Yi Xia
*
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Make thumbnail size configurable and tell KIO to use all thumbnailer plguins

[Shantanu Tushar Jha]

> On March 11, 2012, 10:36 p.m., Marco Martin wrote:
> > looks fine, but i would prefer the thumbnail plugins to be configurable if 
> > more than images are going to be used

I didn't understand the "more than images are going to be used" part :(

(KIO includes three plugins by default "directorythumbnail", "imagethumbnail", 
"jpegthumbnail")


- Shantanu Tushar


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104229/#review11302
---


On March 11, 2012, 4:51 p.m., Shantanu Tushar Jha wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104229/
> ---
> 
> (Updated March 11, 2012, 4:51 p.m.)
> 
> 
> Review request for Plasma and Marco Martin.
> 
> 
> Description
> ---
> 
> This patch makes two additions-
> 1. Thumbnail size is hardcoded into metadatamodel, this patch adds a property 
> to make it configurable
> 2. KIO Thumbnailer uses a default set of plugins (from global config, which 
> can't be set from PA) which doesn't include video thumbnailers for example. 
> This makes metadatamodel fail when its asked for a thumbnail for a video 
> file. This patch explicitly tells KIO to use all plugins.
> 
> 
> Diffs
> -
> 
>   components/metadatamodel/metadatamodel.h 85750fe 
>   components/metadatamodel/metadatamodel.cpp 74ad09c 
> 
> Diff: http://git.reviewboard.kde.org/r/104229/diff/
> 
> 
> Testing
> ---
> 
> Both features work when tested from QML and don't seem to have any 
> side-effects.
> 
> 
> Thanks,
> 
> Shantanu Tushar Jha
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: activity aware plasmoids

[Martin Klapetek]

On Fri, Mar 9, 2012 at 11:30, Sebastian Kügler  wrote:

> 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*
>


Sorry for the delay, I was mostly away the whole weekend, but here it goes.

So the idea is to have one central auth handling component, which will
shield the apps themselves from account credentials, ie. the apps will work
only with an auth token provided by the auth library. This library is
almost done btw. For getting the feeds from social networks, we'll use
akonadi resources/agents, which will cache that stuff in there. We don't
really want that stuff in Nepomuk as we want to only cache it, not store
it. We can still make some use of those data in Nepomuk though. Contacts
will be feeded there for free by the akonadi feeders. The frontend, (the
social apps themselves), will then be built on top of Akonadi. We also need
a KCM to have one place to configure it all, this is currently in the works
by Alex Fiestas. A prerequisite is working metacontacts.

I plan to work on this as a GSoC project and I plan to write it in details
and well structured in the proposal, which can later be published for
reference/starting point.

--
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Merge the final and fixed QML battery monitor to master.

[Sebastian Kügler]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104226/#review11311
---


The changes as they are add a few translation problems. There's also a bit of 
nitpicking here and there.

I haven't tested it yet, but the problems I'm pointing out will definitely need 
fixing before we can merge this into master.

Pretty good progress, however! :)


plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml


The word puzzle here is not translatable. You'll need to enclose a full 
string into i18n(), with the current code, translators can't figure out what 
the message is.

Also, appending strings to each other doesn't work, as the word order might 
be different. So you have to identify the cases, and then return a completely 
translated string.



plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml


This should not be in there, basically only if it has been enabled by 
config showRemainingTime (look at the C++ version when it's shown). We 
explicitely excluded this feature by default since the remaining time cannot be 
accurately computed.



plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml


Word puzzles do not work for translators.

This has to be done through KLocale, I don't see an option how to do it 
nicely and translatable.



plasma/generic/applets/batterymonitor/contents/ui/batterymonitor.qml


instead of plasmoid.rootItem.pmSource, try using just pmSource. If 
necessary, that means moving pmSource somewhere visible.

Should make porting to QML2 easier.



plasma/generic/applets/batterymonitor/contents/ui/batterymonitor.qml


Same for plasmoid.pmSource location



plasma/generic/applets/batterymonitor/contents/ui/batterymonitor.qml


This guy is unnecessary, as the exact same info is already shown in the 
dialog. I'd prefer getting rid of this overlay altogether (including the config 
option).



plasma/generic/applets/batterymonitor/contents/ui/batterymonitor.qml


What's missing here? 

Either ditch // TODO, or add a note what's missing



plasma/generic/dataengines/powermanagement/powermanagementjob.cpp


This line always sets result to false, no matter what happened earlier.

I think the code you added here is correct, could you check why it worked 
earlier?



plasma/generic/dataengines/powermanagement/powermanagementjob.cpp


if it always returns true, it's useless to return anything. Make it void.


- Sebastian Kügler


On March 11, 2012, 1:59 p.m., Viranch Mehta wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104226/
> ---
> 
> (Updated March 11, 2012, 1:59 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> ---
> 
> I fixed the QML battery monitor to be fairly usable and this diff merges it 
> to master.
> 
> 
> Diffs
> -
> 
>   plasma/generic/applets/CMakeLists.txt 2dedcb2 
>   plasma/generic/applets/battery/CMakeLists.txt 7794f88 
>   plasma/generic/applets/battery/Messages.sh 8b06e2d 
>   plasma/generic/applets/battery/README.txt 5b352e8 
>   plasma/generic/applets/battery/battery-oxygen-inkscape.svgz b68ba66 
>   plasma/generic/applets/battery/battery-oxygen.svgz a037e60 
>   plasma/generic/applets/battery/battery.h ebc1a3d 
>   plasma/generic/applets/battery/battery.cpp 3a5cda3 
>   plasma/generic/applets/battery/batteryConfig.ui 5595ca2 
>   plasma/generic/applets/battery/plasma-battery-default.desktop e254028 
>   plasma/generic/applets/batterymonitor/CMakeLists.txt PRE-CREATION 
>   plasma/generic/applets/batterymonitor/Messages.sh PRE-CREATION 
>   plasma/generic/applets/batterymonitor/README.txt PRE-CREATION 
>   plasma/generic/applets/batterymonitor/battery-oxygen-inkscape.svgz 
> PRE-CREATION 
>   plasma/generic/applets/batterymonitor/battery-oxygen.svgz PRE-CREATION 
>   plasma/generic/applets/batterymonitor/contents/config/main.xml PRE-CREATION 
>   plasma/generic/applets/batterymonitor/contents/ui/IconButton.qml 
> PRE-CREATION 
>   plasma/generic/applets/batterymonitor/contents/ui/PopupDialog.qml 
> PRE-CREATION 
>   plasma/generic/applets/batterymonitor/contents/ui/batterymonitor.qml 
> PRE-CREATION 
>   plasma/generic/applets/batterymoni

Re: RFC: Removing of decorations

[Hugo Pereira Da Costa]

On 03/10/2012 07:51 AM, Martin Gräßlin wrote:

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

Hi Martin,


1. I'm all for removing the unmaintained decoration.
2. I'm not sure about the rationale for moving oxygen's (deco) out of 
kwin tree.
It is a decoration client, and therefore would best stay is in 
kwin/clients.
(especially since it has to be build on top of kwin, unlike oxygen's 
"libs" and oxygen's "style").


As for the argument "having all oxygen's code in one place". Well, that 
would also require to have oxygen's widget style and oxygen's lib at the 
same place.  (which one ?). And you would still need a "liboxygen.so" 
anyway, I think, for the code that is shared by the widget style and the 
decoration.


This to say, what would the moving actually address, solve ?
(you do need to build kwin anyway in order to build oxygen's client).




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


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel