Re: Moving libkfacebook to extragear

[Martin Klapetek]

On Thu, Jan 3, 2013 at 11:12 PM, Martin Klapetek
wrote:

>
> Anyways, anything else that should be fixed in the library?
>

If there are no more comments, I'm going to ask sysadmins to move it
tonight (it's been in review since October).

Thanks everyone for your reviews and comments!

Cheers
-- 
Martin Klapetek | KDE Developer

Re: plasma and new shadow mess

[Aaron J. Seigo]

On Sunday, January 6, 2013 17:40:42 Thomas Lübking wrote:
> 1. it will make kwin link generic-shell what is sematically the gnome/unity
> shell approach.

it is a library. that does not rely on the desktop (or other) shell. it
provides shared functionality for applications in kde-workspace, but without a
guaranteed API for others (ergo no headers).

so, no, it is not at all the same approach as gnome/unity. at all.

> 2. it will visually break non-plasma QMLs (so virtually
> they're no longer supported, see Martins concern in [1])

???

which QML are you thinking of that is "non-plasma"? what are they doing using
Plasma's SVG theming?

> Notice that this is a dead stupid and cumbersome way to do things [2], but
...
> [2] Instead of dumb copying the shadow implementation of plasma we could
> maybe rather just load the Plasma::Svg and hand over the pixmap(id)
> internally to the Shadow system - less tested, though, but could be then
> also easily extended to proper QML/Component shadow support, thus not
> pointless either.

handing over the pixmap id intenrally to the shadow system is exactly what we
do in plasma. granted, it is outside of kwin and we're doing this with an
xatom ... but this is precisely how plasma is doing it now: we rely on kwin
(or another window manager) to paint the shadows using pixmaps we hand over by
id.

--
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.

Re: KDEREVIEW: share like connect and plasmate

[Ben Cooksley]

On Sun, Jan 6, 2013 at 2:10 PM, Aaron J. Seigo  wrote:
> On Thursday, January 3, 2013 09:56:47 Ben Cooksley wrote:
>> What about Share-Like-Connect?
>
> i was waiting until i was back in the office with time to work on it again
> before requesting the move. :)
>
> so ... yes, SLC is ready to be moved out of kdereview.

Where is it destined? This was never stated it seems.

>
> we have it working properly on desktop as well as for touch devices and while
> not all of our (internal) API modifications are where we want them to be, it 
> is
> sufficiently developed for another proper release ... (we've already made 3
> releases of it with Plasma Active, fww)
>
> thanks in advance :)

Regards,
Ben

>
> --
> Aaron J. Seigo
> ___
> Plasma-devel mailing list
> plasma-de...@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>

Re: Review Request: use Plasma::Dialog for brightness osd

[Xuetian Weng]

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

(Updated Jan. 6, 2013, 10:25 p.m.)


Review request for kde-workspace, Plasma and Aaron J. Seigo.


Changes
---

change the size


Description
---

well, you know.. this would fix the shadow problem, and clean up code actually.


Diffs (updated)
-

  powerdevil/daemon/brightnessosdwidget.h ef08903 
  powerdevil/daemon/brightnessosdwidget.cpp e4cf80a 

Diff: http://git.reviewboard.kde.org/r/108222/diff/


Testing
---

locally tested, no problem.


Thanks,

Xuetian Weng

Re: Review Request: Add some new User Agent files for spoofing browser identities in konqueror, rekonq

[Guillaume de Bure]

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

(Updated Jan. 6, 2013, 10:33 p.m.)


Review request for KDE Base Apps.


Changes
---

Removed some old browser entries, updated some others, and updated the 
CMakeLists. The list of user agents is now :

android 2.3.5
android 4.0.3
chrome 23
chrome 24
ie 6
ie 7
ie 8
ie 9
firefox 15
firefox 16
opera 11
opera 12
safari 5
safari 6
lynx
w3m
wget
googlebot

I kept 4 versions of IE as their respective engines do have large differences 
when rendering web pages, and they are quite often treated in a special way by 
websites...


Description
---

I find that the current list of Browser identities that you can use in 
konqueror or rekonq is so very obsolete... I used information from 
http://www.useragentstring.com/pages/Browserlist/ and wrote some additional 
.desktop files, specifically:
* Chrome 22, 23, 24
* Firefox 15, 16
* IE 8, 9
* Opera 11, 12
* Safari 5, 6

I purposely did not update the CMakeLists.txt yet, waiting for some initial 
feedback first. I also intend to remove some other entries from the current 
file list, unsure whether that should come in a separate review request


Diffs (updated)
-

  dolphin/src/CMakeLists.txt 9f650ce4387c9132e5afdd7eafac96a2d7193ae9 
  dolphin/src/kitemviews/kfileitemmodel.cpp 
6c015db372cdb1df85995e56c3d79560cc21b97a 
  dolphin/src/panels/information/informationpanelcontent.h 
c0412e567b706b08178db51367d80cec60881e85 
  dolphin/src/panels/information/informationpanelcontent.cpp 
39ed1d2bdc52a5f70f087820390ba06f6fe06713 
  dolphin/src/views/tooltips/filemetadatatooltip.h 
856b557463d8d71db587940b0038a75567fe3027 
  dolphin/src/views/tooltips/filemetadatatooltip.cpp 
1f4fb69aecbead34ba250014da4e04f36ae31892 
  konqueror/settings/kio/uasproviders/CMakeLists.txt 
6c49f42773bb20404ae94e92d8d60c49506505f5 
  konqueror/settings/kio/uasproviders/android10.desktop 
07b393b631363ae8e4a12200508f331bd1fc20a5 
  konqueror/settings/kio/uasproviders/android235.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/android403.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/chrome10onwinnt51.desktop 
e9f777f87872c975df69ae424f23594162f5f3e5 
  konqueror/settings/kio/uasproviders/chrome23oncurrent.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/chrome24oncurrent.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/chrome50oncurrent.desktop 
401b5df32cd61f705369e719bb7f5e1376a0af9f 
  konqueror/settings/kio/uasproviders/firefox15oncurrent.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/firefox16oncurrent.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/firefox20oncurrent.desktop 
1e7c477b7805be443e3513aaaf98df28d763ce46 
  konqueror/settings/kio/uasproviders/firefox30oncurrent.desktop 
cc6c68f940157966a6a31dad5d65db1503a47f37 
  konqueror/settings/kio/uasproviders/firefox36oncurrent.desktop 
3567a094ceb0d055f00977092431abddc5e4b9d0 
  konqueror/settings/kio/uasproviders/ie401onwinnt4.desktop 
9f8a8115f10a6293fc832141b4fd6014285530f4 
  konqueror/settings/kio/uasproviders/ie50onppc.desktop 
a3a833bc4040a4d17b11733b4d28ad79b8913319 
  konqueror/settings/kio/uasproviders/ie55onwinnt5.desktop 
569241ac08d80adce7266c177011527916cf2b98 
  konqueror/settings/kio/uasproviders/ie60oncurrent.desktop 
05ea3f11b49ff67a13e8c17b97416f84e122f552 
  konqueror/settings/kio/uasproviders/ie80onwinnt60.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/ie90onwinnt71.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/lynxoncurrent.desktop 
57036675d9f7419e6f952fbc1c41709564bf4057 
  konqueror/settings/kio/uasproviders/nn301oncurrent.desktop 
702247f7c5a1edccf7364ee09ecd8b3781b32fe0 
  konqueror/settings/kio/uasproviders/nn475oncurrent.desktop 
ac5e1fcd4a6c9617f90d7d6aa799346d224ba955 
  konqueror/settings/kio/uasproviders/nn475onwin95.desktop 
f3f1920f93e448166dd174aec36ffd7e32313798 
  konqueror/settings/kio/uasproviders/ns71oncurrent.desktop 
50b3d0cca7cac210f2ac6eb7db86fda14b024b9a 
  konqueror/settings/kio/uasproviders/ns71onwinnt51.desktop 
6d5e9f1630462c997467d9a09874afd249dd5d40 
  konqueror/settings/kio/uasproviders/op1162oncurrent.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/op1202oncurrent.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/op403onwinnt4.desktop 
a0caf0646f1b35bd712556087965c3ce6dbff3ac 
  konqueror/settings/kio/uasproviders/op85oncurrent.desktop 
98557fab1b5286149505d0aba2d5c9d5709d9910 
  konqueror/settings/kio/uasproviders/op90oncurrent.desktop 
c8e025cafce8e7b1e2df9022aeb908fd01fb1940 
  konqueror/settings/kio/uasproviders/op962oncurrent.desktop 
c7072d6424f64b132727ec61515404921e0be3ce 
  konqueror/settings/kio/uasproviders/safari20.desktop 
5ba0d25635b5cf55ec51f5ac4e2b99e08e5233c9 
  konqueror/settings/kio/uasproviders/safari30oniphone.desktop 
eaac

Re: Review Request: Add some new User Agent files for spoofing browser identities in konqueror, rekonq

[Guillaume de Bure]

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

(Updated Jan. 6, 2013, 10:44 p.m.)


Review request for KDE Base Apps.


Changes
---

Previous diff (r2) was not correctly generated, sorry for the noise :(. This 
one should be better.


Description
---

I find that the current list of Browser identities that you can use in 
konqueror or rekonq is so very obsolete... I used information from 
http://www.useragentstring.com/pages/Browserlist/ and wrote some additional 
.desktop files, specifically:
* Chrome 22, 23, 24
* Firefox 15, 16
* IE 8, 9
* Opera 11, 12
* Safari 5, 6

I purposely did not update the CMakeLists.txt yet, waiting for some initial 
feedback first. I also intend to remove some other entries from the current 
file list, unsure whether that should come in a separate review request


Diffs (updated)
-

  konqueror/settings/kio/uasproviders/CMakeLists.txt 
6c49f42773bb20404ae94e92d8d60c49506505f5 
  konqueror/settings/kio/uasproviders/android10.desktop 
07b393b631363ae8e4a12200508f331bd1fc20a5 
  konqueror/settings/kio/uasproviders/android235.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/android403.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/chrome10onwinnt51.desktop 
e9f777f87872c975df69ae424f23594162f5f3e5 
  konqueror/settings/kio/uasproviders/chrome23oncurrent.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/chrome24oncurrent.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/chrome50oncurrent.desktop 
401b5df32cd61f705369e719bb7f5e1376a0af9f 
  konqueror/settings/kio/uasproviders/firefox15oncurrent.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/firefox16oncurrent.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/firefox20oncurrent.desktop 
1e7c477b7805be443e3513aaaf98df28d763ce46 
  konqueror/settings/kio/uasproviders/firefox30oncurrent.desktop 
cc6c68f940157966a6a31dad5d65db1503a47f37 
  konqueror/settings/kio/uasproviders/firefox36oncurrent.desktop 
3567a094ceb0d055f00977092431abddc5e4b9d0 
  konqueror/settings/kio/uasproviders/ie401onwinnt4.desktop 
9f8a8115f10a6293fc832141b4fd6014285530f4 
  konqueror/settings/kio/uasproviders/ie50onppc.desktop 
a3a833bc4040a4d17b11733b4d28ad79b8913319 
  konqueror/settings/kio/uasproviders/ie55onwinnt5.desktop 
569241ac08d80adce7266c177011527916cf2b98 
  konqueror/settings/kio/uasproviders/ie60oncurrent.desktop 
05ea3f11b49ff67a13e8c17b97416f84e122f552 
  konqueror/settings/kio/uasproviders/ie80onwinnt60.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/ie90onwinnt71.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/lynxoncurrent.desktop 
57036675d9f7419e6f952fbc1c41709564bf4057 
  konqueror/settings/kio/uasproviders/nn301oncurrent.desktop 
702247f7c5a1edccf7364ee09ecd8b3781b32fe0 
  konqueror/settings/kio/uasproviders/nn475oncurrent.desktop 
ac5e1fcd4a6c9617f90d7d6aa799346d224ba955 
  konqueror/settings/kio/uasproviders/nn475onwin95.desktop 
f3f1920f93e448166dd174aec36ffd7e32313798 
  konqueror/settings/kio/uasproviders/ns71oncurrent.desktop 
50b3d0cca7cac210f2ac6eb7db86fda14b024b9a 
  konqueror/settings/kio/uasproviders/ns71onwinnt51.desktop 
6d5e9f1630462c997467d9a09874afd249dd5d40 
  konqueror/settings/kio/uasproviders/op1162oncurrent.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/op1202oncurrent.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/op403onwinnt4.desktop 
a0caf0646f1b35bd712556087965c3ce6dbff3ac 
  konqueror/settings/kio/uasproviders/op85oncurrent.desktop 
98557fab1b5286149505d0aba2d5c9d5709d9910 
  konqueror/settings/kio/uasproviders/op90oncurrent.desktop 
c8e025cafce8e7b1e2df9022aeb908fd01fb1940 
  konqueror/settings/kio/uasproviders/op962oncurrent.desktop 
c7072d6424f64b132727ec61515404921e0be3ce 
  konqueror/settings/kio/uasproviders/safari20.desktop 
5ba0d25635b5cf55ec51f5ac4e2b99e08e5233c9 
  konqueror/settings/kio/uasproviders/safari30oniphone.desktop 
eaacee26722e9a0997f9f9bc0e7e52f56f2384c5 
  konqueror/settings/kio/uasproviders/safari32.desktop 
5c511a6601355a8cfd064497dc74a364546dfe8b 
  konqueror/settings/kio/uasproviders/safari40.desktop 
682c1e4b84742d9d85a5397627d637404eccc47b 
  konqueror/settings/kio/uasproviders/safari517.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/safari60.desktop PRE-CREATION 
  konqueror/settings/kio/uasproviders/w3moncurrent.desktop 
27160d603484857e99656caabc3a070a72119236 

Diff: http://git.reviewboard.kde.org/r/108057/diff/


Testing
---


Thanks,

Guillaume de Bure

Re: Review Request: use Plasma::Dialog for brightness osd

[Kai Uwe Broulik]

> On Jan. 6, 2013, 3:45 p.m., Kai Uwe Broulik wrote:
> > Just applied the patch from Review 107983 and your patch resolves the 
> > issue. Would you mind if I use that code to fix KMix OSD?
> 
> Xuetian Weng wrote:
> Well.. actually I have a review for kmix :P
> https://git.reviewboard.kde.org/r/108223/

Haven't seen it :) Looks good from my POV but add the solid group because these 
are the ones responsible for PowerDevil :)


- Kai Uwe


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


On Jan. 6, 2013, 10:25 p.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108222/
> ---
> 
> (Updated Jan. 6, 2013, 10:25 p.m.)
> 
> 
> Review request for kde-workspace, Plasma and Aaron J. Seigo.
> 
> 
> Description
> ---
> 
> well, you know.. this would fix the shadow problem, and clean up code 
> actually.
> 
> 
> Diffs
> -
> 
>   powerdevil/daemon/brightnessosdwidget.h ef08903 
>   powerdevil/daemon/brightnessosdwidget.cpp e4cf80a 
> 
> Diff: http://git.reviewboard.kde.org/r/108222/diff/
> 
> 
> Testing
> ---
> 
> locally tested, no problem.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

Re: Review Request: use Plasma::Dialog for brightness osd

[Xuetian Weng]

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

(Updated Jan. 6, 2013, 11:53 p.m.)


Review request for kde-workspace, Plasma, Solid, and Aaron J. Seigo.


Description
---

well, you know.. this would fix the shadow problem, and clean up code actually.


Diffs
-

  powerdevil/daemon/brightnessosdwidget.h ef08903 
  powerdevil/daemon/brightnessosdwidget.cpp e4cf80a 

Diff: http://git.reviewboard.kde.org/r/108222/diff/


Testing
---

locally tested, no problem.


Thanks,

Xuetian Weng

Re: plasma and new shadow mess

[Weng Xuetian]

On Sun, Jan 6, 2013 at 10:37 AM, Aaron J. Seigo  wrote:

> On Sunday, January 6, 2013 13:35:16 Martin Graesslin wrote:
>
> btw, these changes were made in mid-November of 2012. i'm a little
> surprised
> people are only noticing now.
>

I'm sure this change is not included the first beta, people might see
things goes alright and then we have Christmas which worse the case.

I'm working on some of fix.. those changes go into 4.10 or 4.11 I don't
really care.. but I don't want have visual regression for 4.10.
[1] https://git.reviewboard.kde.org/r/108222/
[2] https://git.reviewboard.kde.org/r/108223/

If code is not reverted, we may discuss the solution?

As for kwin tabbox shadow, though I'm not expert for kwin, there is two
problem
1. how to do the shadow for tabbox? use X property or some kwin custom way
because it's in kwin.
Well.. I guess later way it not easy and will duplicate the shadow drawing
code path, so I still propose to use X property for passing shadow.

2. who provide the shadow, qml or the current declarativeview?
I think qml is much more easy, since the Svg object in qml is the
Plasma::Svg. If qml tabbox want to use shadow, it can pass the property to
rootObject and let declarativeview easily get and render it.

Re: plasma and new shadow mess

[Aaron J. Seigo]

On Sunday, January 6, 2013 17:01:06 Martin Gräßlin wrote:
> On Sunday 06 January 2013 16:37:47 Aaron J. Seigo wrote:
> > btw, these changes were made in mid-November of 2012. i'm a little
> > surprised people are only noticing now.
>
> maybe because the hard feature freeze was on November 8th and nobody expects
> that they need to adjust their applications after the hard feature freeze?

my point was that apparently people have neither tested or noticed for nearly
2 months. it's a surprising result.

> And now it's really, really late to fix these issues.

perhaps. i personally don't think it is too late given the trivial nature of
the changes needed to make it happen due to having code that has been tested
for a couple releases now that can be repurposed (the code in use is NOT new
to 4.10)

btw, we would have patches done already if we took the time writing these
emails and instead spent it writing those patches. it's not rocket science or
invasive type changes.

> shall be fixed" based on experience what last minute changes which cannot
> be properly tested can cause issues in a compositor. So no, in KWin that
> won't be fixed for 4.10.

i respect that this is your call to make as kwin maintainer.

> Overall I'm rather disappointed on how the situation came up and how it is
> handled now.

me too. i'll discuss this on the plasma-devel list as i believe that is where
this discussion belongs.

> It's not too late to revert the change and do it for 4.11 in a
> coordinated way that doesn't require rushed in changes.

a reversion is not going to happen at this point. it is the proper way to do
the shadows (one that relies on window manager functionality which kwin has
thankfully provided for quite some time now; i'm a bit surprised that of all
applications, kwin was doing shadows incorrectly for its own windows) and it
allows us to use shadows on more elements without breaking the UI in the
desktop. a reversion would likely mean also rolling back some changes in the
Air theme and a bunch of re-testing of the desktop.

--
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.

Re: Review Request: use Plasma::Dialog for brightness osd

[Aaron J. Seigo]

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

Ship it!


Ship It!

- Aaron J. Seigo


On Jan. 6, 2013, 11:53 p.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108222/
> ---
> 
> (Updated Jan. 6, 2013, 11:53 p.m.)
> 
> 
> Review request for kde-workspace, Plasma, Solid, and Aaron J. Seigo.
> 
> 
> Description
> ---
> 
> well, you know.. this would fix the shadow problem, and clean up code 
> actually.
> 
> 
> Diffs
> -
> 
>   powerdevil/daemon/brightnessosdwidget.h ef08903 
>   powerdevil/daemon/brightnessosdwidget.cpp e4cf80a 
> 
> Diff: http://git.reviewboard.kde.org/r/108222/diff/
> 
> 
> Testing
> ---
> 
> locally tested, no problem.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

Re: plasma and new shadow mess

[Aaron J. Seigo]

On Sunday, January 6, 2013 20:47:55 Weng Xuetian wrote:
> On Sun, Jan 6, 2013 at 10:37 AM, Aaron J. Seigo  wrote:
> > On Sunday, January 6, 2013 13:35:16 Martin Graesslin wrote:
> > 
> > btw, these changes were made in mid-November of 2012. i'm a little
> > surprised
> > people are only noticing now.
> 
> I'm sure this change is not included the first beta,

assuming it didn't make the release (which happened 1 week after the changes 
were made), this implies we rely on beta testers and the developers aren't 
paying attention to their own applications. this surprises me.
 
> I'm working on some of fix.. those changes go into 4.10 or 4.11 I don't
> really care.. but I don't want have visual regression for 4.10.
> [1] https://git.reviewboard.kde.org/r/108222/
> [2] https://git.reviewboard.kde.org/r/108223/

both look good, and as you noted in the reviews they actually simplify the 
code in the process. i've processed both reviews and they should go into the 
4.10 and master branches imo.

> As for kwin tabbox shadow, though I'm not expert for kwin, there is two
> problem
> 1. how to do the shadow for tabbox? use X property or some kwin custom way
> because it's in kwin.

obviously up to the kwin devs, but the x property approach should work and 
then there's no special code path to worry about: all shadows will be handled 
the same way. it would also allow the use of code in the plasmagenericshell 
library.

> 2. who provide the shadow, qml or the current declarativeview?
> I think qml is much more easy, since the Svg object in qml is the
> Plasma::Svg. If qml tabbox want to use shadow, it can pass the property to
> rootObject and let declarativeview easily get and render it.

i don't know about this one, as i'm not familiar enough with the internals of 
kwin's tab box .. i'm sure Martin or Thomas can offer direction here though.

-- 
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.

Re: Re: plasma and new shadow mess

[Martin Gräßlin]

On Monday 07 January 2013 10:51:11 Aaron J. Seigo wrote:
> On Sunday, January 6, 2013 17:40:42 Thomas Lübking wrote:
> > 1. it will make kwin link generic-shell what is sematically the
> > gnome/unity
> > shell approach.
>
> it is a library. that does not rely on the desktop (or other) shell. it
> provides shared functionality for applications in kde-workspace, but without
> a guaranteed API for others (ergo no headers).
why then not in libkworkspace? If it's meant for more then just the desktop
shells the name sounds confusing.
>
> so, no, it is not at all the same approach as gnome/unity. at all.
>
> > 2. it will visually break non-plasma QMLs (so virtually
> > they're no longer supported, see Martins concern in [1])
>
> ???
>
> which QML are you thinking of that is "non-plasma"? what are they doing
> using Plasma's SVG theming?
I think it was bad worded by Thomas as it's actually a Plasma which would get
broken: the window strip of Plasma Active.

But: we make it possible to load any Qml styled window switcher theme. There
is no requirement to use Plasma Components, it's just a Qml file that gets
loaded. If a user wants to have a KDE 3 style all grey that's possible. If we
enforce Plasma that's no longer possible and if there is someone who uses that
already it gets broken if we require the shadows. That's exactly the concern
mentioned in the review request.
>
> > Notice that this is a dead stupid and cumbersome way to do things [2], but
>
> ...
>
> > [2] Instead of dumb copying the shadow implementation of plasma we could
> > maybe rather just load the Plasma::Svg and hand over the pixmap(id)
> > internally to the Shadow system - less tested, though, but could be then
> > also easily extended to proper QML/Component shadow support, thus not
> > pointless either.
>
> handing over the pixmap id intenrally to the shadow system is exactly what
> we do in plasma. granted, it is outside of kwin and we're doing this with
> an xatom ... but this is precisely how plasma is doing it now: we rely on
> kwin (or another window manager) to paint the shadows using pixmaps we hand
> over by id.
Yeah well, I don't want a roundtrip to X just to set an information which we
have internally already available. For KWin we need a better approach.

Btw. for the use case of the window switcher the approach of setting the
shadow is a performance regression. It's actually for everything inside KWin
(and Plasma) a performance regression.

The shadow system has been designed to work around the problem which occurs if
we try to have the shadow in the panel. That is for any window where the
shadow should not be part of the window geometry. It makes sense for the
panel, for KRunner and the Oxygen menus.

This approach comes with an additional rendering cost inside KWin. We need to
create textures from multiple pixmaps, we don't have the window as a
consistent texture any more (causes rendering glitches with various effects)
and we need several rendering passes - one for the shadow, one for the window.
The cost for rendering is higher from throughput to graphics card and from
memory consumption (both GPU and X).

In the case of TabBox or anything else in KWin (and also for most things in
Plasma like tooltips, extenders) we don't have the requirement that the
shadows may not be part of the window geometry as it just does not matter. So
we get the disadvantage without any advantage.

Oh and the fact that the window is one texture instead of multiple is the only
valid argument for Client Side Window Decorations and has been the only
argument presented by Kristian Hogsberg in his Wayland presentation on XDC.
And you know what? I have to agree in that point.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.

Re: Re: plasma and new shadow mess

[Martin Gräßlin]

On Monday 07 January 2013 11:03:24 Aaron J. Seigo wrote:
> a reversion is not going to happen at this point. it is the proper way to do
> the shadows (one that relies on window manager functionality which kwin has
> thankfully provided for quite some time now; i'm a bit surprised that of
> all applications, kwin was doing shadows incorrectly for its own windows)
see my other mail to the thread why in the case of KWin it's a disadvantage to 
use its own shadow system
> and it allows us to use shadows on more elements without breaking the UI in
> the desktop. a reversion would likely mean also rolling back some changes
> in the Air theme and a bunch of re-testing of the desktop.
> 
> --
> Aaron J. Seigo


signature.asc
Description: This is a digitally signed message part.

Re: KDEREVIEW: share like connect and plasmate

[Aaron J. Seigo]

On Monday, January 7, 2013 22:58:12 Ben Cooksley wrote:
> On Sun, Jan 6, 2013 at 2:10 PM, Aaron J. Seigo  wrote:
> > On Thursday, January 3, 2013 09:56:47 Ben Cooksley wrote:
> >> What about Share-Like-Connect?
> > 
> > i was waiting until i was back in the office with time to work on it again
> > before requesting the move. :)
> > 
> > so ... yes, SLC is ready to be moved out of kdereview.
> 
> Where is it destined? This was never stated it seems.

good question :) i suppose extragear/base. 

in future, i want to use it as part of the default layout of the panel if it 
is installed, but that will be at least one more release and we may even 
postpone that until a libplasma2 based shell hapens. but eventually there will 
be a soft run-time dep on from kde-workspace on this repository ... but this 
is not something that prevents it going into extragear.

the "many repository" approach is going to make releases of the desktop 
workspaces more and more ... "interesting" :) we may end up needing to adjust 
how we define such releases at some point in the future. the Frameworks 5 era 
seems like a good time to examine if changes would be beneficial for workspace 
releases.

-- 
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.

Re: Review Request: Add some new User Agent files for spoofing browser identities in konqueror, rekonq

[Frank Reininghaus]

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


Please run git pull --rebase before pushing any non-merge commits to prevent 
polluting the logs with commits like

http://quickgit.kde.org/?p=kde-baseapps.git&a=commit&h=94b3817429b470eed5687922661832b260bcc06c

Thanks.

- Frank Reininghaus


On Jan. 6, 2013, 10:44 p.m., Guillaume de Bure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108057/
> ---
> 
> (Updated Jan. 6, 2013, 10:44 p.m.)
> 
> 
> Review request for KDE Base Apps.
> 
> 
> Description
> ---
> 
> I find that the current list of Browser identities that you can use in 
> konqueror or rekonq is so very obsolete... I used information from 
> http://www.useragentstring.com/pages/Browserlist/ and wrote some additional 
> .desktop files, specifically:
> * Chrome 22, 23, 24
> * Firefox 15, 16
> * IE 8, 9
> * Opera 11, 12
> * Safari 5, 6
> 
> I purposely did not update the CMakeLists.txt yet, waiting for some initial 
> feedback first. I also intend to remove some other entries from the current 
> file list, unsure whether that should come in a separate review request
> 
> 
> Diffs
> -
> 
>   konqueror/settings/kio/uasproviders/CMakeLists.txt 
> 6c49f42773bb20404ae94e92d8d60c49506505f5 
>   konqueror/settings/kio/uasproviders/android10.desktop 
> 07b393b631363ae8e4a12200508f331bd1fc20a5 
>   konqueror/settings/kio/uasproviders/android235.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/android403.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/chrome10onwinnt51.desktop 
> e9f777f87872c975df69ae424f23594162f5f3e5 
>   konqueror/settings/kio/uasproviders/chrome23oncurrent.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/chrome24oncurrent.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/chrome50oncurrent.desktop 
> 401b5df32cd61f705369e719bb7f5e1376a0af9f 
>   konqueror/settings/kio/uasproviders/firefox15oncurrent.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/firefox16oncurrent.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/firefox20oncurrent.desktop 
> 1e7c477b7805be443e3513aaaf98df28d763ce46 
>   konqueror/settings/kio/uasproviders/firefox30oncurrent.desktop 
> cc6c68f940157966a6a31dad5d65db1503a47f37 
>   konqueror/settings/kio/uasproviders/firefox36oncurrent.desktop 
> 3567a094ceb0d055f00977092431abddc5e4b9d0 
>   konqueror/settings/kio/uasproviders/ie401onwinnt4.desktop 
> 9f8a8115f10a6293fc832141b4fd6014285530f4 
>   konqueror/settings/kio/uasproviders/ie50onppc.desktop 
> a3a833bc4040a4d17b11733b4d28ad79b8913319 
>   konqueror/settings/kio/uasproviders/ie55onwinnt5.desktop 
> 569241ac08d80adce7266c177011527916cf2b98 
>   konqueror/settings/kio/uasproviders/ie60oncurrent.desktop 
> 05ea3f11b49ff67a13e8c17b97416f84e122f552 
>   konqueror/settings/kio/uasproviders/ie80onwinnt60.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/ie90onwinnt71.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/lynxoncurrent.desktop 
> 57036675d9f7419e6f952fbc1c41709564bf4057 
>   konqueror/settings/kio/uasproviders/nn301oncurrent.desktop 
> 702247f7c5a1edccf7364ee09ecd8b3781b32fe0 
>   konqueror/settings/kio/uasproviders/nn475oncurrent.desktop 
> ac5e1fcd4a6c9617f90d7d6aa799346d224ba955 
>   konqueror/settings/kio/uasproviders/nn475onwin95.desktop 
> f3f1920f93e448166dd174aec36ffd7e32313798 
>   konqueror/settings/kio/uasproviders/ns71oncurrent.desktop 
> 50b3d0cca7cac210f2ac6eb7db86fda14b024b9a 
>   konqueror/settings/kio/uasproviders/ns71onwinnt51.desktop 
> 6d5e9f1630462c997467d9a09874afd249dd5d40 
>   konqueror/settings/kio/uasproviders/op1162oncurrent.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/op1202oncurrent.desktop PRE-CREATION 
>   konqueror/settings/kio/uasproviders/op403onwinnt4.desktop 
> a0caf0646f1b35bd712556087965c3ce6dbff3ac 
>   konqueror/settings/kio/uasproviders/op85oncurrent.desktop 
> 98557fab1b5286149505d0aba2d5c9d5709d9910 
>   konqueror/settings/kio/uasproviders/op90oncurrent.desktop 
> c8e025cafce8e7b1e2df9022aeb908fd01fb1940 
>   konqueror/settings/kio/uasproviders/op962oncurrent.desktop 
> c7072d6424f64b132727ec61515404921e0be3ce 
>   konqueror/settings/kio/uasproviders/safari20.desktop 
> 5ba0d25635b5cf55ec51f5ac4e2b99e08e5233c9 
>   konqueror/settings/kio/uasproviders/safari30oniphone.desktop 
> eaacee26722e9a0997f9f9bc0e7e52f56f2384c5 
>   konqueror/settings/kio/uasproviders/safari32.desktop 
> 5c511a6601355a8cfd064497dc74a364546dfe8b 
>   konqueror/settings/kio/uasproviders/safari40.desktop 
> 682c1e4b84742d9d85a5397627d637404eccc47b 
>   konqueror/settings/kio/uasproviders/safari517.desktop PRE-CREATIO

Re: plasma and new shadow mess

[Aaron J. Seigo]

On Monday, January 7, 2013 11:14:49 Martin Gräßlin wrote:
> The shadow system has been designed to work around the problem which occurs
> if we try to have the shadow in the panel. That is for any window where the
> shadow should not be part of the window geometry. It makes sense for the
> panel, for KRunner and the Oxygen menus.

it also matters for tooltips where we would like them to align with other
windows without including shadows in those calculations (shadows are
conceptually immaterial things, so should not cause a visual gap).

given that our popup applets also have semantics similar to menus, it matters
there as well.

i agree there are some cases where it doesn't matter.

> This approach comes with an additional rendering cost inside KWin.

has the cost been measured?

this is the most important thing imho. if it costs us 10fps maybe it matters.
if it costs us 1fps maybe it doesn't.

> We need
> to create textures from multiple pixmaps, we don't have the window as a
> consistent texture any more (causes rendering glitches with various
> effects) and we need several rendering passes - one for the shadow, one for
> the window.

the shadow+windowframe is not cached somewhere?

--
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.

Re: Review Request: set brightness to zero in profile doesn't work

[Lukáš Tinkl]

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

Ship it!


Ship It!

- Lukáš Tinkl


On Jan. 6, 2013, 6 p.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108230/
> ---
> 
> (Updated Jan. 6, 2013, 6 p.m.)
> 
> 
> Review request for kde-workspace and Kai Uwe Broulik.
> 
> 
> Description
> ---
> 
> fix is trivial, since -1 is the invalid value in this part of code, not zero.
> 
> Uncheck the brightness will set m_defaultValue to -1 so no function is lost.
> 
> 
> This addresses bug 306925.
> http://bugs.kde.org/show_bug.cgi?id=306925
> 
> 
> Diffs
> -
> 
>   powerdevil/daemon/actions/bundled/brightnesscontrol.cpp 5088e4e 
> 
> Diff: http://git.reviewboard.kde.org/r/108230/diff/
> 
> 
> Testing
> ---
> 
> now zero in profile works.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

Re: plasma and new shadow mess

[Thomas Lübking]

On Montag, 7. Januar 2013 14:18:04 CEST, Aaron J. Seigo wrote:

> the shadow+windowframe is not cached somewhere?
It's not "shadow+windowframe" but "shadow+window" - doubling memory usage for 
that window (once more) since the window texture/picture is provided as pixmap 
by the redirection, you cannot extend that and ofset the redirection in your 
shadow-prepared window. (no, wayland should rather not change that)

*that* can make things *really* slow if you run out of VRAM (or explicitly 
leave it by caching in some QImage) - not to speak of the nvidia driver being 
quite unhappy everytime you allocate memory at runtime.

Re: Review Request: use Plasma::Dialog for brightness osd

[Commit Hook]

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


This review has been submitted with commit 
d2cd9b46c506063fbd1520927e5c6d18c66e505f by Weng Xuetian to branch KDE/4.10.

- Commit Hook


On Jan. 6, 2013, 11:53 p.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108222/
> ---
> 
> (Updated Jan. 6, 2013, 11:53 p.m.)
> 
> 
> Review request for kde-workspace, Plasma, Solid, and Aaron J. Seigo.
> 
> 
> Description
> ---
> 
> well, you know.. this would fix the shadow problem, and clean up code 
> actually.
> 
> 
> Diffs
> -
> 
>   powerdevil/daemon/brightnessosdwidget.h ef08903 
>   powerdevil/daemon/brightnessosdwidget.cpp e4cf80a 
> 
> Diff: http://git.reviewboard.kde.org/r/108222/diff/
> 
> 
> Testing
> ---
> 
> locally tested, no problem.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

Re: plasma and new shadow mess

[Thomas Lübking]

On Montag, 7. Januar 2013 10:51:11 CEST, Aaron J. Seigo wrote:

> it is a library. that does not rely on the desktop (or other) shell. it 
> provides shared functionality for applications in kde-workspace, but without
> a guaranteed API for others (ergo no headers).

=

$ for name in /usr/bin/*; do if [ ! -z "`ldd "$name" | grep 
libplasmagenericshell`" ]; then echo "$name"; fi; done

/usr/bin/krunner
/usr/bin/plasma-desktop
/usr/bin/plasma-netbook
/usr/bin/plasma-overlay

---

$ ls libs/plasmagenericshell

BackgroundDialog.ui  backgrounddialog.cpp  mouseplugins.h 
plasma-layout-template.desktop  toolbutton.h
CMakeLists.txt   backgrounddialog.hmousepluginwidget.cpp  
plasmagenericshell_export.h wallpaperpreview.cpp
Messages.sh* mouseinputbutton.cpp  mousepluginwidget.hscripting/
  wallpaperpreview.h
MousePlugins.ui  mouseinputbutton.hpanelshadows.cpp   tests/
  widgetsexplorer/
TODO mouseplugins.cpp  panelshadows.h toolbutton.cpp

=

So it provides panelshadows, a widgetexplorer, a "Click to change how an action 
is triggered" mouseinputbutton, a wallpaperpreview, a backgrounddialog (seems 
wallpaper picker) ...

plasma-* are thin wrappers on the libs that effectively form the desktop shell.
If it wasn't, KWin and other stuff was by now "linking" the desktop process 
(usually in order to use a common theme) anyway, and if the WM links 
"libplasmagenericshell.so" it is even *semantically* the gnome/unity approach - 
or i need a new dictionary.

Thomas

Re: plasma and new shadow mess

[Fredrik Höglund]

On Monday 07 January 2013, Martin Gräßlin wrote:
> > handing over the pixmap id intenrally to the shadow system is exactly what
> > we do in plasma. granted, it is outside of kwin and we're doing this with
> > an xatom ... but this is precisely how plasma is doing it now: we rely on
> > kwin (or another window manager) to paint the shadows using pixmaps we hand
> > over by id.
> Yeah well, I don't want a roundtrip to X just to set an information which we 
> have internally already available. For KWin we need a better approach.

It actually adds 25 roundtrips per window, including 8 image transfers
from the X server.

Fredrik

Re: plasma and new shadow mess

[Martin Gräßlin]

Am 07.01.2013 14:18, schrieb Aaron J. Seigo:

On Monday, January 7, 2013 11:14:49 Martin Gräßlin wrote:
The shadow system has been designed to work around the problem which 
occurs
if we try to have the shadow in the panel. That is for any window 
where the
shadow should not be part of the window geometry. It makes sense for 
the

panel, for KRunner and the Oxygen menus.


it also matters for tooltips where we would like them to align with 
other

windows without including shadows in those calculations (shadows are
conceptually immaterial things, so should not cause a visual gap).

given that our popup applets also have semantics similar to menus, it
matters
there as well.

ok, that makes sense there


i agree there are some cases where it doesn't matter.


This approach comes with an additional rendering cost inside KWin.


has the cost been measured?

very difficult as it depends on:
a) driver
b) hardware
c) graphics system

What I have measured is the rendering of window decorations which is 
basically the pain point of our complete rendering stack and follows a 
similar approach to rendering (each side rendered to a pixmap, TFP done 
from it, rendered in addition to the window) as the shadows. All lags 
during animations are caused by that architecture - though mostly due to 
rendering the decorations in the same thread as the compositor.


It's not exactly comparable to the shadow situation as the shadows are 
rendered out of KWin process and are not supposed to be change and 
stored in one texture. But still if the combination of the three points 
above is bad, it can cause a lack during first TFP operation.


Overall it has an impact due to the OpenGL state changes, but how much: 
depends, though for most cases not badly.


this is the most important thing imho. if it costs us 10fps maybe it
matters.
if it costs us 1fps maybe it doesn't.


We need
to create textures from multiple pixmaps, we don't have the window 
as a

consistent texture any more (causes rendering glitches with various
effects) and we need several rendering passes - one for the shadow, 
one for

the window.


the shadow+windowframe is not cached somewhere?

no that doesn't make sense as the window content changes.

Cheers
Martin

Re: Review Request: qml based kwin shadow

[Martin Gräßlin]

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


Approach seems fine to me (though I haven't tested it yet). I'm wondering 
whether this could become part of Plasma Components?

In case not we should move it somewhere to make it part of the "KWin 
components" as we also need that in the KWin scripts (e.g. desktop change OSD).


kwin/tabbox/declarative.cpp


nitpick: coding style
} else {



kwin/tabbox/declarative.cpp


all the variables are only set once, so maybe const them?



kwin/tabbox/declarative.cpp


watch the whitespaces

(in case you use any Kate-based editor: there's an option to only remove 
whitespaces on changed lines)


- Martin Gräßlin


On Jan. 7, 2013, 3:11 p.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108243/
> ---
> 
> (Updated Jan. 7, 2013, 3:11 p.m.)
> 
> 
> Review request for kde-workspace, kwin, Plasma, Thomas Lübking, Aaron J. 
> Seigo, Marco Martin, and Martin Gräßlin.
> 
> 
> Description
> ---
> 
> This is a different solution solve problem in 
> https://git.reviewboard.kde.org/r/108224/
> 
> 1. use qml to draw shadow in DeclarativeView.
> 2. set blur mask svg property in qml
> 3. and fix some layout problem in big icons and small icons.
> 
> 
> Diffs
> -
> 
>   kwin/tabbox/declarative.cpp 3bdcfac 
>   kwin/tabbox/qml/CMakeLists.txt d4bc863 
>   kwin/tabbox/qml/ShadowedSvgItem.qml PRE-CREATION 
>   kwin/tabbox/qml/clients/big_icons/contents/ui/main.qml 7115b7f 
>   kwin/tabbox/qml/clients/compact/contents/ui/main.qml 1f6f036 
>   kwin/tabbox/qml/clients/informative/contents/ui/main.qml 3a2c4a3 
>   kwin/tabbox/qml/clients/present_windows/contents/ui/main.qml 14a54d3 
>   kwin/tabbox/qml/clients/small_icons/contents/ui/main.qml ea09ed0 
>   kwin/tabbox/qml/clients/text/contents/ui/main.qml c0def27 
>   kwin/tabbox/qml/clients/thumbnails/contents/ui/main.qml efe3ebe 
>   kwin/tabbox/qml/tabbox.qml 4176231 
> 
> Diff: http://git.reviewboard.kde.org/r/108243/diff/
> 
> 
> Testing
> ---
> 
> all desktop tabbox is tested with Air and Slim Glow, composite and 
> non-composite, no problem.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

Re: Review Request: qml based kwin shadow

[Martin Gräßlin]

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


I need to think about whether I want to have it in org.kde.kwin.tabbox or 
org.kde.kwin. Even if the QML scripts work with Plasma.Dialog I'm not sure 
whether we should continue to use it or better have our own component which 
uses the background (and some other KWin specific adjustments). I just don't 
like the thought of KWin communicating with KWin through X :-) For 4.10 it 
shall be Plasma.Dialog there of course.


kwin/tabbox/qml/qmldir


please don't include the IconTabBox in the qmldir. I consider it private 
API :-)


- Martin Gräßlin


On Jan. 7, 2013, 4:07 p.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108243/
> ---
> 
> (Updated Jan. 7, 2013, 4:07 p.m.)
> 
> 
> Review request for kde-workspace, kwin, Plasma, Thomas Lübking, Aaron J. 
> Seigo, Marco Martin, and Martin Gräßlin.
> 
> 
> Description
> ---
> 
> This is a different solution solve problem in 
> https://git.reviewboard.kde.org/r/108224/
> 
> 1. use qml to draw shadow in DeclarativeView.
> 2. set blur mask svg property in qml
> 3. and fix some layout problem in big icons and small icons.
> 
> 
> Diffs
> -
> 
>   kwin/tabbox/declarative.cpp 3bdcfac 
>   kwin/tabbox/qml/CMakeLists.txt d4bc863 
>   kwin/tabbox/qml/IconTabBox.qml 23bb11b 
>   kwin/tabbox/qml/ShadowedSvgItem.qml PRE-CREATION 
>   kwin/tabbox/qml/clients/big_icons/contents/ui/main.qml 7115b7f 
>   kwin/tabbox/qml/clients/compact/contents/ui/main.qml 1f6f036 
>   kwin/tabbox/qml/clients/informative/contents/ui/main.qml 3a2c4a3 
>   kwin/tabbox/qml/clients/present_windows/contents/ui/main.qml 14a54d3 
>   kwin/tabbox/qml/clients/small_icons/contents/ui/main.qml ea09ed0 
>   kwin/tabbox/qml/clients/text/contents/ui/main.qml c0def27 
>   kwin/tabbox/qml/clients/thumbnails/contents/ui/main.qml efe3ebe 
>   kwin/tabbox/qml/qmldir PRE-CREATION 
>   kwin/tabbox/qml/tabbox.qml 4176231 
> 
> Diff: http://git.reviewboard.kde.org/r/108243/diff/
> 
> 
> Testing
> ---
> 
> all desktop tabbox is tested with Air and Slim Glow, composite and 
> non-composite, no problem.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

Re: Review Request: qml based kwin shadow

[Martin Gräßlin]

> On Jan. 7, 2013, 4:39 p.m., Martin Gräßlin wrote:
> > kwin/tabbox/qml/qmldir, line 2
> > 
> >
> > please don't include the IconTabBox in the qmldir. I consider it 
> > private API :-)
> 
> Xuetian Weng wrote:
> I saw IconTabBox is used twice.. so I just guess it should be put some 
> where.
> 
> Actually no one objects, I would also like to consider that 
> ShadowedSvgItem for private API in 4.10 .. and improve it to something really 
> useful in KDE 4.10 (current one is half-baked)

that's of course fine with me (if you meant improving in 4.11 ;-). But then we 
maybe should not move it into a package and go for the multiple copy approach 
of your first patch for the 4.10 branch.


- Martin


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


On Jan. 7, 2013, 4:07 p.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108243/
> ---
> 
> (Updated Jan. 7, 2013, 4:07 p.m.)
> 
> 
> Review request for kde-workspace, kwin, Plasma, Thomas Lübking, Aaron J. 
> Seigo, Marco Martin, and Martin Gräßlin.
> 
> 
> Description
> ---
> 
> This is a different solution solve problem in 
> https://git.reviewboard.kde.org/r/108224/
> 
> 1. use qml to draw shadow in DeclarativeView.
> 2. set blur mask svg property in qml
> 3. and fix some layout problem in big icons and small icons.
> 
> 
> Diffs
> -
> 
>   kwin/tabbox/declarative.cpp 3bdcfac 
>   kwin/tabbox/qml/CMakeLists.txt d4bc863 
>   kwin/tabbox/qml/IconTabBox.qml 23bb11b 
>   kwin/tabbox/qml/ShadowedSvgItem.qml PRE-CREATION 
>   kwin/tabbox/qml/clients/big_icons/contents/ui/main.qml 7115b7f 
>   kwin/tabbox/qml/clients/compact/contents/ui/main.qml 1f6f036 
>   kwin/tabbox/qml/clients/informative/contents/ui/main.qml 3a2c4a3 
>   kwin/tabbox/qml/clients/present_windows/contents/ui/main.qml 14a54d3 
>   kwin/tabbox/qml/clients/small_icons/contents/ui/main.qml ea09ed0 
>   kwin/tabbox/qml/clients/text/contents/ui/main.qml c0def27 
>   kwin/tabbox/qml/clients/thumbnails/contents/ui/main.qml efe3ebe 
>   kwin/tabbox/qml/qmldir PRE-CREATION 
>   kwin/tabbox/qml/tabbox.qml 4176231 
> 
> Diff: http://git.reviewboard.kde.org/r/108243/diff/
> 
> 
> Testing
> ---
> 
> all desktop tabbox is tested with Air and Slim Glow, composite and 
> non-composite, no problem.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

Re: Review Request: qml based kwin shadow

[Marco Martin]

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



kwin/tabbox/qml/ShadowedSvgItem.qml


you could even just do a FrameSvg on the "shadow" prefix

then the child will be anchored to it using the shadow element sizes as 
margins for top,right,left etc

is simpler code and less qobjects in memory vs. a bit more pixmap memory, 
so has advantages and disadvantages so your call ;)


- Marco Martin


On Jan. 7, 2013, 5:49 p.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108243/
> ---
> 
> (Updated Jan. 7, 2013, 5:49 p.m.)
> 
> 
> Review request for kde-workspace, kwin, Plasma, Thomas Lübking, Aaron J. 
> Seigo, Marco Martin, and Martin Gräßlin.
> 
> 
> Description
> ---
> 
> This is a different solution solve problem in 
> https://git.reviewboard.kde.org/r/108224/
> 
> 1. use qml to draw shadow in DeclarativeView.
> 2. set blur mask svg property in qml
> 3. and fix some layout problem in big icons and small icons.
> 
> 
> Diffs
> -
> 
>   kwin/tabbox/declarative.cpp 3bdcfac 
>   kwin/tabbox/qml/CMakeLists.txt d4bc863 
>   kwin/tabbox/qml/IconTabBox.qml 23bb11b 
>   kwin/tabbox/qml/ShadowedSvgItem.qml PRE-CREATION 
>   kwin/tabbox/qml/clients/big_icons/contents/ui/main.qml 7115b7f 
>   kwin/tabbox/qml/clients/compact/contents/ui/main.qml 1f6f036 
>   kwin/tabbox/qml/clients/informative/contents/ui/main.qml 3a2c4a3 
>   kwin/tabbox/qml/clients/present_windows/contents/ui/main.qml 14a54d3 
>   kwin/tabbox/qml/clients/small_icons/contents/ui/main.qml ea09ed0 
>   kwin/tabbox/qml/clients/text/contents/ui/main.qml c0def27 
>   kwin/tabbox/qml/clients/thumbnails/contents/ui/main.qml efe3ebe 
>   kwin/tabbox/qml/tabbox.qml 4176231 
> 
> Diff: http://git.reviewboard.kde.org/r/108243/diff/
> 
> 
> Testing
> ---
> 
> all desktop tabbox is tested with Air and Slim Glow, composite and 
> non-composite, no problem.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

Review Request: KHTML, imload: Fix wrong version of last line of scaled tile

[Aurélien Gâteau]

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

Review request for kdelibs, Martin Tobias Holmedahl Sandsmark and Maks Orlovich.


Description
---

Code in scaledLoop32bit() has an off-by-one error in computation of the 
versions index, causing some images to contain garbage on their last line. This 
is visible in Konqueror and Akregator intro pages.


Diffs
-

  khtml/imload/scaledimageplane.cpp e8ab684 

Diff: http://git.reviewboard.kde.org/r/108246/diff/


Testing
---

Tested Akregator and Konqueror about pages. Browsed a few websites with 
Konqueror + KHTML.


Screenshots
---

Konqueror, before - after
  http://git.reviewboard.kde.org/r/108246/s/988/


Thanks,

Aurélien Gâteau

Re: Review Request: KHTML, imload: Fix wrong version of last line of scaled tile

[Albert Astals Cid]

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


Evil: do you think you could provide a test? Seems like if you already have an 
image that files, maybe it wouldn't be that hard?

- Albert Astals Cid


On Jan. 7, 2013, 6:16 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108246/
> ---
> 
> (Updated Jan. 7, 2013, 6:16 p.m.)
> 
> 
> Review request for kdelibs, Martin Tobias Holmedahl Sandsmark and Maks 
> Orlovich.
> 
> 
> Description
> ---
> 
> Code in scaledLoop32bit() has an off-by-one error in computation of the 
> versions index, causing some images to contain garbage on their last line. 
> This is visible in Konqueror and Akregator intro pages.
> 
> 
> Diffs
> -
> 
>   khtml/imload/scaledimageplane.cpp e8ab684 
> 
> Diff: http://git.reviewboard.kde.org/r/108246/diff/
> 
> 
> Testing
> ---
> 
> Tested Akregator and Konqueror about pages. Browsed a few websites with 
> Konqueror + KHTML.
> 
> 
> Screenshots
> ---
> 
> Konqueror, before - after
>   http://git.reviewboard.kde.org/r/108246/s/988/
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

Re: Review Request: Correction of bug 235710 : Plasma Wallpaper Slideshow to periodially recheck contents of image folder

[Jeremy Paul Whiting]

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


Looks good to me, I wonder why you changed the suffix bits the way you did, why 
not just make it initialized in the BackgroundFinder constructor and use 
m_suffixes directly instead of calling suffixes() itself?

- Jeremy Paul Whiting


On Dec. 21, 2012, 5:11 p.m., Erwan MATHIEU wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107821/
> ---
> 
> (Updated Dec. 21, 2012, 5:11 p.m.)
> 
> 
> Review request for kde-workspace.
> 
> 
> Description
> ---
> 
> Patch which corrects bug 235710 : Plasma Wallpaper Slideshow to periodially 
> recheck contents of image folder
> 
> 
> This addresses bug 235710.
> http://bugs.kde.org/show_bug.cgi?id=235710
> 
> 
> Diffs
> -
> 
>   plasma/generic/wallpapers/image/backgroundlistmodel.h a289f49 
>   plasma/generic/wallpapers/image/backgroundlistmodel.cpp f5a4dce 
>   plasma/generic/wallpapers/image/image.h 417f5a7 
>   plasma/generic/wallpapers/image/image.cpp 006a748 
> 
> Diff: http://git.reviewboard.kde.org/r/107821/diff/
> 
> 
> Testing
> ---
> 
> Many pictures in many folders with many subfolders, adding and removing files 
> (sometimes no more files available)
> 
> 
> Thanks,
> 
> Erwan MATHIEU
> 
>

Re: Review Request: KHTML, imload: Fix wrong version of last line of scaled tile

[Martin Tobias Holmedahl Sandsmark]

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

Ship it!


hmm, I wonder why valgrind didn't pick this up for me, but looks good to me.

- Martin Tobias Holmedahl Sandsmark


On Jan. 7, 2013, 6:16 p.m., Aurélien Gâteau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108246/
> ---
> 
> (Updated Jan. 7, 2013, 6:16 p.m.)
> 
> 
> Review request for kdelibs, Martin Tobias Holmedahl Sandsmark and Maks 
> Orlovich.
> 
> 
> Description
> ---
> 
> Code in scaledLoop32bit() has an off-by-one error in computation of the 
> versions index, causing some images to contain garbage on their last line. 
> This is visible in Konqueror and Akregator intro pages.
> 
> 
> Diffs
> -
> 
>   khtml/imload/scaledimageplane.cpp e8ab684 
> 
> Diff: http://git.reviewboard.kde.org/r/108246/diff/
> 
> 
> Testing
> ---
> 
> Tested Akregator and Konqueror about pages. Browsed a few websites with 
> Konqueror + KHTML.
> 
> 
> Screenshots
> ---
> 
> Konqueror, before - after
>   http://git.reviewboard.kde.org/r/108246/s/988/
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

Re: plasma and new shadow mess

[Aaron J. Seigo]

On Monday, January 7, 2013 15:15:21 Thomas Lübking wrote:
> On Montag, 7. Januar 2013 10:51:11 CEST, Aaron J. Seigo wrote:
> > it is a library. that does not rely on the desktop (or other) shell. it
> > provides shared functionality for applications in kde-workspace, but
> > without a guaranteed API for others (ergo no headers).
>
> >
> $ for name in /usr/bin/*; do if [ ! -z "`ldd "$name" | grep
> libplasmagenericshell`" ]; then echo "$name"; fi; done
>
> /usr/bin/krunner
> /usr/bin/plasma-desktop
> /usr/bin/plasma-netbook
> /usr/bin/plasma-overlay

so far so good ... these 4 processes use the library. the library has no
dependencies on them.

> So it provides panelshadows, a widgetexplorer, a "Click to change how an
> action is triggered" mouseinputbutton, a wallpaperpreview, a
> backgrounddialog (seems wallpaper picker) ...

it also includes the desktop js scripting used for layouts, activity
templates, etc.

so yes, it's really a grab bag of "things used in common by the workspace
apps". as an internal library, such "design-less" factor-out-common-stuff
pragmatism is fine.

as an aside: during the move to libplasma2 + qml2, at least some of these
things (perhaps the majority, even) will likely become individual QML
components.

> plasma-* are thin wrappers on the libs that effectively form the desktop

plasma-desktop is over 2x the lines of code of libplasmagenericshell. it
extends classes from the libraries, even. so it is not a thin wrapper by any
reasonable definition.

> links "libplasmagenericshell.so" it is even *semantically* the gnome/unity
> approach - or i need a new dictionary.

i don't think you need a new dictionary. but digging a bit deeper into the
facts and actually understanding the design of the software you are writing
about would be useful.

in this case, the library is not where the core code, or even the semantic
definition, of the shell processes resides. in fact, the bits that make them
shells (the panels, the desktop views, screen handling, configuration, etc..)
are predominantly in the shell processes. using libplasmagenericshell does not
somehow integrate it more (or less) with Plasma Desktop or any other plasma
shell.

this is all a moot discussion, however, and i engage only to help you
understand something better which you evidently have misconceptions about.

the actual solution, however, is not dependent on getting this particular
aspect right. if we focus on solution instead of pointless discussion we
probably come to this:

if libplasmagenericshell is too big of a library or contains functionality
kwin is allergic to (for whatever reason one finds/invents), the obvious answer
is to move the shadow classes to one of the smaller kde-workspace libraries
kwin already links to such as libkworkspace, which the shells also already
link to. as they are internal libraries shipped with the binaries, such a
shuffle is easy to do and completely allowed, even between minor releases.

in fact, the *best* answer would probably be to copy the DialogShadows class
from kdelibs/plasma/private/ and put it in kworkspace (or wherever we figure is
appropriate so as to meet the needs of kwin and the other binaries in kde-
workspace). it is an improvement over the PanelShadows, which assumes the
window is edge docked and shadows can therefore be applied all the way around
without regard for the reality of the window's borders.

"porting" the use in plasma-desktop to this replacement class is trivial: it's
the same API except addWindow has one more parameter, the default argument of
which would be equivalent to the existing PanelShadows behaviour. so .. no
porting other than perhaps changing the name of the class used.

if this is a fitting / desired solution, i can easily make it happen in a very
short time span.

cheers.

--
Aaron J. Seigo

signature.asc
Description: This is a digitally signed message part.

Re: Re: plasma and new shadow mess

[Weng Xuetian]

On Mon, Jan 7, 2013 at 5:14 AM, Martin Gräßlin  wrote:
On Monday 07 January 2013 10:51:11 Aaron J. Seigo wrote:
> On Sunday, January 6, 2013 17:40:42 Thomas Lübking wrote:
> > 1. it will make kwin link generic-shell what is sematically the
> > gnome/unity
> > shell approach.

In the case of TabBox or anything else in KWin (and also for most things in
Plasma like tooltips, extenders) we don't have the requirement that the
shadows may not be part of the window geometry as it just does not matter.
So
we get the disadvantage without any advantage.

Ok,  it's also not hard if we want to do so.

Here is something I have locally for trying to workaround kwin's shadow in
different approach.
It draw the shadow inside qml by using svg (well, just like what plasma do
in the past).

The only remain problem while I was trying is how to set the blur mask.
Actually current code already suggest the blur region is svg and using it
without plasma will somehow fails.
One way to set blur mask properly, is to set the imagePath by qml itself
(since Plasma::FrameSvg is not exported to qml), and add proper offset.
These can be all passed by rootObject.

http://paste.ubuntu.com/1506434/ (also attached)

This patch only change the big icon tabbox, but change to other is trivial.
It draw the shadow inside tabbox by Plasma::Svg.

Screenshot:
http://wstaw.org/m/2013/01/07/plasma-desktopoj1171.png

Well, it's not perfect, since if we really want qml based blur mask, we
should get region and apply all qml transform agaisnst the mask, which is
not possible from current API, but for tabbox, we may survive with such
limitation.


kwin-qml-shadow.patch
Description: Binary data

Review Request: qml based kwin shadow

[Xuetian Weng]

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

Review request for kde-workspace, kwin, Plasma, Thomas Lübking, Aaron J. Seigo, 
Marco Martin, and Martin Gräßlin.


Description
---

This is a different solution solve problem in 
https://git.reviewboard.kde.org/r/108224/

1. use qml to draw shadow in DeclarativeView.
2. set blur mask svg property in qml
3. and fix some layout problem in big icons and small icons.


Diffs
-

  kwin/tabbox/declarative.cpp 3bdcfac 
  kwin/tabbox/qml/CMakeLists.txt d4bc863 
  kwin/tabbox/qml/ShadowedSvgItem.qml PRE-CREATION 
  kwin/tabbox/qml/clients/big_icons/contents/ui/main.qml 7115b7f 
  kwin/tabbox/qml/clients/compact/contents/ui/main.qml 1f6f036 
  kwin/tabbox/qml/clients/informative/contents/ui/main.qml 3a2c4a3 
  kwin/tabbox/qml/clients/present_windows/contents/ui/main.qml 14a54d3 
  kwin/tabbox/qml/clients/small_icons/contents/ui/main.qml ea09ed0 
  kwin/tabbox/qml/clients/text/contents/ui/main.qml c0def27 
  kwin/tabbox/qml/clients/thumbnails/contents/ui/main.qml efe3ebe 
  kwin/tabbox/qml/tabbox.qml 4176231 

Diff: http://git.reviewboard.kde.org/r/108243/diff/


Testing
---

all desktop tabbox is tested with Air and Slim Glow, composite and 
non-composite, no problem.


Thanks,

Xuetian Weng

Re: Review Request: qml based kwin shadow

[Xuetian Weng]

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

(Updated Jan. 7, 2013, 4:07 p.m.)


Review request for kde-workspace, kwin, Plasma, Thomas Lübking, Aaron J. Seigo, 
Marco Martin, and Martin Gräßlin.


Changes
---

so how about move them into org.kde.kwin.tabbox?

BTW, desktopchangeosd uses PlasmaCore.Dialog, so it doesn't have shadow problem 
I think.


Description
---

This is a different solution solve problem in 
https://git.reviewboard.kde.org/r/108224/

1. use qml to draw shadow in DeclarativeView.
2. set blur mask svg property in qml
3. and fix some layout problem in big icons and small icons.


Diffs (updated)
-

  kwin/tabbox/declarative.cpp 3bdcfac 
  kwin/tabbox/qml/CMakeLists.txt d4bc863 
  kwin/tabbox/qml/IconTabBox.qml 23bb11b 
  kwin/tabbox/qml/ShadowedSvgItem.qml PRE-CREATION 
  kwin/tabbox/qml/clients/big_icons/contents/ui/main.qml 7115b7f 
  kwin/tabbox/qml/clients/compact/contents/ui/main.qml 1f6f036 
  kwin/tabbox/qml/clients/informative/contents/ui/main.qml 3a2c4a3 
  kwin/tabbox/qml/clients/present_windows/contents/ui/main.qml 14a54d3 
  kwin/tabbox/qml/clients/small_icons/contents/ui/main.qml ea09ed0 
  kwin/tabbox/qml/clients/text/contents/ui/main.qml c0def27 
  kwin/tabbox/qml/clients/thumbnails/contents/ui/main.qml efe3ebe 
  kwin/tabbox/qml/qmldir PRE-CREATION 
  kwin/tabbox/qml/tabbox.qml 4176231 

Diff: http://git.reviewboard.kde.org/r/108243/diff/


Testing
---

all desktop tabbox is tested with Air and Slim Glow, composite and 
non-composite, no problem.


Thanks,

Xuetian Weng

Re: Review Request: qml based kwin shadow

[Xuetian Weng]

> On Jan. 7, 2013, 4:39 p.m., Martin Gräßlin wrote:
> > kwin/tabbox/qml/qmldir, line 2
> > 
> >
> > please don't include the IconTabBox in the qmldir. I consider it 
> > private API :-)

I saw IconTabBox is used twice.. so I just guess it should be put some where.

Actually no one objects, I would also like to consider that ShadowedSvgItem for 
private API in 4.10 .. and improve it to something really useful in KDE 4.10 
(current one is half-baked)


- Xuetian


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


On Jan. 7, 2013, 4:07 p.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108243/
> ---
> 
> (Updated Jan. 7, 2013, 4:07 p.m.)
> 
> 
> Review request for kde-workspace, kwin, Plasma, Thomas Lübking, Aaron J. 
> Seigo, Marco Martin, and Martin Gräßlin.
> 
> 
> Description
> ---
> 
> This is a different solution solve problem in 
> https://git.reviewboard.kde.org/r/108224/
> 
> 1. use qml to draw shadow in DeclarativeView.
> 2. set blur mask svg property in qml
> 3. and fix some layout problem in big icons and small icons.
> 
> 
> Diffs
> -
> 
>   kwin/tabbox/declarative.cpp 3bdcfac 
>   kwin/tabbox/qml/CMakeLists.txt d4bc863 
>   kwin/tabbox/qml/IconTabBox.qml 23bb11b 
>   kwin/tabbox/qml/ShadowedSvgItem.qml PRE-CREATION 
>   kwin/tabbox/qml/clients/big_icons/contents/ui/main.qml 7115b7f 
>   kwin/tabbox/qml/clients/compact/contents/ui/main.qml 1f6f036 
>   kwin/tabbox/qml/clients/informative/contents/ui/main.qml 3a2c4a3 
>   kwin/tabbox/qml/clients/present_windows/contents/ui/main.qml 14a54d3 
>   kwin/tabbox/qml/clients/small_icons/contents/ui/main.qml ea09ed0 
>   kwin/tabbox/qml/clients/text/contents/ui/main.qml c0def27 
>   kwin/tabbox/qml/clients/thumbnails/contents/ui/main.qml efe3ebe 
>   kwin/tabbox/qml/qmldir PRE-CREATION 
>   kwin/tabbox/qml/tabbox.qml 4176231 
> 
> Diff: http://git.reviewboard.kde.org/r/108243/diff/
> 
> 
> Testing
> ---
> 
> all desktop tabbox is tested with Air and Slim Glow, composite and 
> non-composite, no problem.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

Re: Review Request: qml based kwin shadow

[Xuetian Weng]

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

(Updated Jan. 7, 2013, 5:49 p.m.)


Review request for kde-workspace, kwin, Plasma, Thomas Lübking, Aaron J. Seigo, 
Marco Martin, and Martin Gräßlin.


Changes
---

still multiple copy file for now.


Description
---

This is a different solution solve problem in 
https://git.reviewboard.kde.org/r/108224/

1. use qml to draw shadow in DeclarativeView.
2. set blur mask svg property in qml
3. and fix some layout problem in big icons and small icons.


Diffs (updated)
-

  kwin/tabbox/declarative.cpp 3bdcfac 
  kwin/tabbox/qml/CMakeLists.txt d4bc863 
  kwin/tabbox/qml/IconTabBox.qml 23bb11b 
  kwin/tabbox/qml/ShadowedSvgItem.qml PRE-CREATION 
  kwin/tabbox/qml/clients/big_icons/contents/ui/main.qml 7115b7f 
  kwin/tabbox/qml/clients/compact/contents/ui/main.qml 1f6f036 
  kwin/tabbox/qml/clients/informative/contents/ui/main.qml 3a2c4a3 
  kwin/tabbox/qml/clients/present_windows/contents/ui/main.qml 14a54d3 
  kwin/tabbox/qml/clients/small_icons/contents/ui/main.qml ea09ed0 
  kwin/tabbox/qml/clients/text/contents/ui/main.qml c0def27 
  kwin/tabbox/qml/clients/thumbnails/contents/ui/main.qml efe3ebe 
  kwin/tabbox/qml/tabbox.qml 4176231 

Diff: http://git.reviewboard.kde.org/r/108243/diff/


Testing
---

all desktop tabbox is tested with Air and Slim Glow, composite and 
non-composite, no problem.


Thanks,

Xuetian Weng

Re: Review Request: qml based kwin shadow

[Xuetian Weng]

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

(Updated Jan. 7, 2013, 7:01 p.m.)


Review request for kde-workspace, kwin, Plasma, Thomas Lübking, Aaron J. Seigo, 
Marco Martin, and Martin Gräßlin.


Changes
---

use prefix from frameSvg as shadow instead of multiple svg item


Description
---

This is a different solution solve problem in 
https://git.reviewboard.kde.org/r/108224/

1. use qml to draw shadow in DeclarativeView.
2. set blur mask svg property in qml
3. and fix some layout problem in big icons and small icons.


Diffs (updated)
-

  kwin/tabbox/declarative.cpp 3bdcfac 
  kwin/tabbox/qml/CMakeLists.txt d4bc863 
  kwin/tabbox/qml/IconTabBox.qml 23bb11b 
  kwin/tabbox/qml/ShadowedSvgItem.qml PRE-CREATION 
  kwin/tabbox/qml/clients/big_icons/contents/ui/main.qml 7115b7f 
  kwin/tabbox/qml/clients/compact/contents/ui/main.qml 1f6f036 
  kwin/tabbox/qml/clients/informative/contents/ui/main.qml 3a2c4a3 
  kwin/tabbox/qml/clients/present_windows/contents/ui/main.qml 14a54d3 
  kwin/tabbox/qml/clients/small_icons/contents/ui/main.qml ea09ed0 
  kwin/tabbox/qml/clients/text/contents/ui/main.qml c0def27 
  kwin/tabbox/qml/clients/thumbnails/contents/ui/main.qml efe3ebe 
  kwin/tabbox/qml/tabbox.qml 4176231 

Diff: http://git.reviewboard.kde.org/r/108243/diff/


Testing
---

all desktop tabbox is tested with Air and Slim Glow, composite and 
non-composite, no problem.


Thanks,

Xuetian Weng

Re: Review Request: Correction of bug 235710 : Plasma Wallpaper Slideshow to periodially recheck contents of image folder

[Jeremy Paul Whiting]

> On Jan. 7, 2013, 6:38 p.m., Jeremy Paul Whiting wrote:
> > Looks good to me, I wonder why you changed the suffix bits the way you did, 
> > why not just make it initialized in the BackgroundFinder constructor and 
> > use m_suffixes directly instead of calling suffixes() itself?

Ah nevermind I see you call it in image.cpp also.  Ok, it looks good I'll push 
it to master branch (so it will make it into KDE SC 4.11)  mind if I put your 
e-mail address in the commit message?


- Jeremy Paul


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


On Dec. 21, 2012, 5:11 p.m., Erwan MATHIEU wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107821/
> ---
> 
> (Updated Dec. 21, 2012, 5:11 p.m.)
> 
> 
> Review request for kde-workspace.
> 
> 
> Description
> ---
> 
> Patch which corrects bug 235710 : Plasma Wallpaper Slideshow to periodially 
> recheck contents of image folder
> 
> 
> This addresses bug 235710.
> http://bugs.kde.org/show_bug.cgi?id=235710
> 
> 
> Diffs
> -
> 
>   plasma/generic/wallpapers/image/backgroundlistmodel.h a289f49 
>   plasma/generic/wallpapers/image/backgroundlistmodel.cpp f5a4dce 
>   plasma/generic/wallpapers/image/image.h 417f5a7 
>   plasma/generic/wallpapers/image/image.cpp 006a748 
> 
> Diff: http://git.reviewboard.kde.org/r/107821/diff/
> 
> 
> Testing
> ---
> 
> Many pictures in many folders with many subfolders, adding and removing files 
> (sometimes no more files available)
> 
> 
> Thanks,
> 
> Erwan MATHIEU
> 
>

Re: Review Request: Correction of bug 235710 : Plasma Wallpaper Slideshow to periodially recheck contents of image folder

[Jeremy Paul Whiting]

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

Ship it!


Ship It!

- Jeremy Paul Whiting


On Dec. 21, 2012, 5:11 p.m., Erwan MATHIEU wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107821/
> ---
> 
> (Updated Dec. 21, 2012, 5:11 p.m.)
> 
> 
> Review request for kde-workspace.
> 
> 
> Description
> ---
> 
> Patch which corrects bug 235710 : Plasma Wallpaper Slideshow to periodially 
> recheck contents of image folder
> 
> 
> This addresses bug 235710.
> http://bugs.kde.org/show_bug.cgi?id=235710
> 
> 
> Diffs
> -
> 
>   plasma/generic/wallpapers/image/backgroundlistmodel.h a289f49 
>   plasma/generic/wallpapers/image/backgroundlistmodel.cpp f5a4dce 
>   plasma/generic/wallpapers/image/image.h 417f5a7 
>   plasma/generic/wallpapers/image/image.cpp 006a748 
> 
> Diff: http://git.reviewboard.kde.org/r/107821/diff/
> 
> 
> Testing
> ---
> 
> Many pictures in many folders with many subfolders, adding and removing files 
> (sometimes no more files available)
> 
> 
> Thanks,
> 
> Erwan MATHIEU
> 
>

Re: Finalized proposal for changes to i18n in KF5

[Oswald Buddenhagen]

On Sat, Jan 05, 2013 at 06:38:58PM +0100, Chusslove Illich wrote:
> > [: Oswald Buddenhagen :]
> > of course, it would be even better if you strived for submission to qt-
> > project, if at all realistic (for now probably an add-on, but definitely
> > under cla). otherwise you'll see the same effect every other useful lgpl'd
> > qt framework sees sonner or later: it gets re-implemented (if the effort
> > is deemed acceptable by an interested party).
> 
> I'm not opposed to some additional bureaucracy in order to make the
> framework more accessible to potential users. But I'd have to see what it
> actually means, and what could be the tradeoff.
> 
well, the bureaucracy is finding all code which is not fully copyrighted
by you, and determining whether the authors can be reached and agree to
signing the CLA. if not, rewrite the code, or drop the idea.

> As for another party reimplementating the framework, I don't see what factor
> is that.
>
well, it's a personal factor. i'd hate it to see my thoroughly
engineered code being displaced by a (possibly even slightly inferior)
competitor just because i can't compete on licensing compatibility
terms.
this is of course a challenge that all of kde frameworks will face, and
all but the most specialized+big ones will lose in the longer term - as
they always have.

> (Hypothetically speaking, though, I don't see it happening: if someone
> wants Gettext-based translation in Qt code but not through Ki18n, I
> expect he will, well, use Gettext directly.)
> 
nobody wants gettext as such (only setting up a compatible workflow is
important, and that mostly "only" in the FOSS world). i couldn't care
less, and i even see it as an disincentive (because i have no direct
control over the data formats and tools, and even if i can change
something, there is the problem of slow independent distribution of
these newer versions).
the real worth of your work (and majority of effort, i suppose) lies in
all that semantic and scripting stuff, including the documentation
(which implies standardization on sane guidelines).

> > [...] make klocalizedstring.h #undef TRANSLATION_CATALOG at the end (may
> > need to use a macro indirection to ensure that the macro is fully expanded
> > already at definition time (see QT_STRINGIFY in qt 5)).
> 
> I looked, but couldn't figure out how to use it in this context.
> 
#define RESOLVE_TRANSLATION_CATALOG(c) (c)
#define i18n(...) i18nd(RESOLVE_TRANSLATION_CATALOG(TRANSLATION_CATALOG), 
__VA_ARGS__)
#undef RESOLVE_TRANSLATION_CATALOG
#undef TRANSLATION_CATALOG

i'm not sure this actually works ...

> I'd definitelly like to have the version markers visible for all elements.
> For example, so that there is no uncertainty whether a marker was forgotten
> or not.
> 
> I struggled with how to present it, and in particular thought that a
> separate colon is an overkill. Maybe have the superscript yet smaller and a
> bit dimmer?
> 
dunno. not sure what vision-impaired people will say to that.
but a separate column is definitely easier to (visually) skip over than
some appendage to the actual items. especially if you put that column
last.

> > and as usual for native-only-in-slavic speakers, some "the"s are missing.
> > i was too lame to record their locations. ^^
> 
> I've given up and put a pox on them.
> 
> (I did toy with another idea though: compute the statistical average of
> the's-per-word for a given class of texts, and then pepper my text
> proportionally.)
> 
lol

> > i don't like the recommendation for extracted vs. disambiguating comments
> > (and closed-source authors will typically do the exact opposite anyway).
> > wouldn't it be sufficient for disambiguiation to strongly recommend
> > consistent use of user interface markers, and thus allow all comments to
> > be extracted?

> > the matter of flagging changes is merely tooling-related.
> 
> Yes, but tooling decisions are related to PO convention and workflow.
> There'd be awful lot of tooling to modify, and modify by adding
> options and not changeing the default behavior.
>
the change is trivial: just add a flag to indicate that the comment
changed. the backwards compatible variant would be just (ab)using fuzzy
for that (e.g., set "fuzzy,fuzzcmt", so updated tools see these "soft
fuzzies", while older tools just treat them as normal fuzzies).

> There would also be no practical purpose to having both types of
> contexts, unless there was a significant difference between them.
> 
well, proprietary users don't like exposing their comments, so they want
minimal disambiguation (what the end user will see in the ui anyway).
also, getting people into the habit of defaulting to comments (paired
with consistent use of @markers) makes it less likely that they put an
epic into a disambiguation when they really meant to put it into a
comment (which is easier to edit and produces leaner catalogs).
of course, sometimes the line between comment and disambiguation is a
tad thin (think annotating "%1: %2"),