I'm fine with GPL-2.0-or-later, if that's fine with you. Otherwise let
me know and I'll pick a different one.
Thanks for getting in touch, and sorry for the delay.
Jason
zx2c4 added a comment.
In https://phabricator.kde.org/D10188#201097, @davidedmundson wrote:
> That would break very core functionality of existing clients and goes
against the notification spec.
Then the spec itself is vulnerable and needs to change.
Switch people to data: UR
zx2c4 reopened this revision.
zx2c4 added a comment.
This revision is now accepted and ready to land.
+ const QUrl url(src);
+ if (url.isLocalFile()) {
+ out.writeAttribute(QStringLiteral("src"), src);
+ } else {
+ //image denied for security reasons! Do not copy the image src here!
+
ssion that went into
the nearly identical code in kde-gtk-kcm.
Diffs
-
kcms/cursortheme/xcursor/thememodel.cpp
e0cb420b7787261d9b5a54b9c0d448d8dd65a988
Diff: https://git.reviewboard.kde.org/r/128899/diff/
Testing
---
Thanks,
Jason A. Donenfeld
view99206
---
On Sept. 14, 2016, 10:11 a.m., Jason A. Donenfeld wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewb
This revision was automatically updated to reflect the committed changes.
Closed by commit rPLASMADESKTOPb2347e37975a: xcursor discovery: modernize
(authored by zx2c4).
REPOSITORY
rPLASMADESKTOP Plasma Desktop
CHANGES SINCE LAST UPDATE
https://phabricator.kde.org/D2772?vs=6724&id=6734
REVIS
zx2c4 added a reviewer: Plasma.
REPOSITORY
rPLASMADESKTOP Plasma Desktop
REVISION DETAIL
https://phabricator.kde.org/D2772
EMAIL PREFERENCES
https://phabricator.kde.org/settings/panel/emailpreferences/
To: zx2c4, mart, #plasma
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abe
zx2c4 created this revision.
zx2c4 added a reviewer: mart.
zx2c4 added a subscriber: plasma-devel.
Restricted Application added a project: Plasma.
REVISION SUMMARY
First we remove the fallback code for a version of Xcursor that
corresponds with an X server KDE doesn't even support any more.
emodel.cpp
e0cb420b7787261d9b5a54b9c0d448d8dd65a988
Diff: https://git.reviewboard.kde.org/r/128899/diff/
Testing
---
Thanks,
Jason A. Donenfeld
configkcmodule.cpp 7afe69841c321b93e59292e55af02eaa81e831b5
Diff: https://git.reviewboard.kde.org/r/128897/diff/
Testing
---
Works extremely well, and since this is the same algorithm as with the other
KCM, with code written years ago, it's certainly received quite a bit of
testing.
Thanks,
Jason A. Donenfeld
31b5
Diff: https://git.reviewboard.kde.org/r/128897/diff/
Testing
---
Works extremely well, and since this is the same algorithm as with the other
KCM, with code written years ago, it's certainly received quite a bit of
testing.
Thanks,
Jason A. Donenfeld
31b5
Diff: https://git.reviewboard.kde.org/r/128897/diff/
Testing
---
Works extremely well, and since this is the same algorithm as with the other
KCM, with code written years ago, it's certainly received quite a bit of
testing.
Thanks,
Jason A. Donenfeld
.kde.org/r/128897/diff/2/?file=476792#file476792line68>
> >
> > Better use `QDir::homePath()`.
Will do.
- Jason A.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128897/#
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128897/#review99150
-----------
On Sept. 13, 2016, 1:06 p.m., Jason A. Donenfeld wrote:
>
> ---
31b5
Diff: https://git.reviewboard.kde.org/r/128897/diff/
Testing
---
Works extremely well, and since this is the same algorithm as with the other
KCM, with code written years ago, it's certainly received quite a bit of
testing.
Thanks,
Jason A. Donenfeld
31b5
Diff: https://git.reviewboard.kde.org/r/128897/diff/
Testing
---
Works extremely well, and since this is the same algorithm as with the other
KCM, with code written years ago, it's certainly received quite a bit of
testing.
Thanks,
Jason A. Donenfeld
-
Works extremely well, and since this is the same algorithm as with the other
KCM, with code written years ago, it's certainly received quite a bit of
testing.
Thanks,
Jason A. Donenfeld
same algorithm as with the other
KCM, with code written years ago, it's certainly received quite a bit of
testing.
Thanks,
Jason A. Donenfeld
Any takers?
On Sat, Aug 18, 2012 at 5:57 AM, Jason A. Donenfeld wrote:
>This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106068/
> Review request for Plasma, Jason A. Donenfeld and Aaron J. Seigo.
> By Jason A. Donenfeld.
&
Buler? Buler?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
On Sat, Aug 18, 2012 at 1:58 AM, Aaron J. Seigo wrote:
>
> please put it in a branch in the kdeplasma-addons repository and open a review
> request for it. this is the most efficient way to get it in (seeing as it will
> need to be put into kdeplasma-addons to be a part of it, this will not be
> w
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106068/
---
Review request for Plasma, Jason A. Donenfeld and Aaron J. Seigo
Hey Everyone,
Over two years ago I wrote the initial revision of the dictionary
krunner, but it was never completed, due to threading limitations in
AbstractRunner's coordination with DataEngine. I've reworked things,
now, to work around this, and the result is exactly as intended [1].
It current
3.0
wpwEAQMCAAYFAk1AykYACgkQXmKxG1YEboqMawQA8GAhH3IIT+Y4HRkSIhJ+wopbBclY
JJsuFReRn4OQrNVt7ud/SueyP2hXjq3zlJRF6Wocp8jY30ycF2A+Y8beyXRIxYKN1OPn
rfAFYmu2mgiPE8+TzCV0g7/bGkoKaGLg8GuwrhbChMqXEMnMWFh8ys/JAxYszVNCZ0M5
EOV2QzE=
=6rTe
-END PGP SIGNATURE-
--
From: *Jason A. Donenfeld*
Date: Thu, Jan 27, 2011 at 19:38
To:
On Sun, Aug 29, 2010 at 17:54, Jason A. Donenfeld wrote:
>
> I'm going to re-factor the dictionary runner to use this approach so that
> the new setReentrant(true) switch will have something to test against, for
> whoever ends up implementing that.
>
On Sat, Aug 28, 2010 at 17:10, Aaron J. Seigo wrote:
>
> well, we can fix that. if nothing else, this was a great exercise in
> discovering what needs to be improved exactly, and how :)
>
> match is given the RunnerContext on each invocation. that RunnerContext may
> become invalid at any time, th
On Tue, Aug 24, 2010 at 16:59, Aaron J. Seigo wrote:
> * when the teardown() signal is emitted, the runner should disconnect from the
> DataEngine
Fixed with r1169251.
> * a thread can wait indefinitely on m_wait.wait(&m_mutex);
But isn't dataUpdated guaranteed to be run at /some point/ ? Or sh
27 matches
Mail list logo