D9840: Tentative patch to reduce I/O overhead of plasmashell when copying files

[Nathaniel Graham]

ngraham added a comment.


  In https://phabricator.kde.org/D9840#203563, @jtamate wrote:
  
  > Just to let you know that I know how to reproduce the high I/O of 
plasmashell and continuous calls to Kservice.
  >  You can reproduce it just having opened the vivaldi web browser. (I never 
though it could be a problem).
  >  If it goes to a webpage that still uses flash, the effect is even bigger.
  >  F5700774: plasmashell_disk.png .
  
  
  Do any of the active or recently-landed patches address this?

REPOSITORY
  R309 KService

REVISION DETAIL
  https://phabricator.kde.org/D9840

To: jtamate, #frameworks, dfaure
Cc: ngraham, mmustac, michaelh

D10365: New icon for Elisa music player

[Diego Gangl]

januz added a comment.


  Agree with the text not being useful for small sizes, but it could look good 
for a large logo-style image (like say, a 256px logo on the wiki/homepage). 
  A cassette is definitely an interesting idea for an icon. At least it's not 
another musical note or play icon 

 :)
  
  It's true that it's old school, but we also use CDs for albums which is also 
kind of old school now, so it's not totally off. Green is ok too, since the CDs 
and their background are all green (and blueish). You could also mixing it with 
some subtle blue/cyan tints in there.
  
  Also, I think if we're going 80s we should go all the way. Instead of a 
gradient (green to white), consider using some 80s motif like the vanishing 
lines in here:
  
https://www.google.com.ar/search?dcr=0=imgo%3A1=isch=1=zzp-WvW5MsPCwATB-LGwAQ=awesome+mix+vol+2=awesome+mix_l=psy-ab.3.1.0l10.345494.346631.0.348056.11.9.0.2.2.0.144.983.4j5.9.00...1c.1.64.psy-ab..1.10.890...0i67k1.0.QW76y1ueao8#imgrc=66ooLxhTsA9q2M
  
  You should probably limit it to 1-2 lines for the smaller sizes though. You 
could probably replace the text with the lines/motif in small sizes too.
  
  More ideas for that: 
https://www.google.com.ar/search?dcr=0=imgo%3A1=isch=1=Rj1-WvPjLYaTwgTj1p2YCw=80s+cassette=80s+cassette_l=psy-ab.3..0l2j0i30k1l4j0i8i30k1l2.18392.20298.0.20566.12.12.0.0.0.0.115.1019.11j1.12.00...1c.1.64.psy-ab..0.12.1013...0i67k1j0i10i24k1.0.PyemoiQ5FVk
  
  BTW, love your avatar!

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D10365

To: paullesur, #breeze, #vdg, #elisa, andreaska
Cc: januz, astippich, andreask, andreaska, ltoscano, ngraham, #frameworks, 
paullesur, michaelh, ognarb, kmf, progwolff, mgallien

D10416: When initialize devicePixelRatio when rendering into a pixmap

[Aleix Pol Gonzalez]

apol abandoned this revision.
apol added a comment.


  https://phabricator.kde.org/D10420 this one works better.

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D10416

To: apol, #plasma, davidedmundson
Cc: davidedmundson, ngraham, plasma-devel, #frameworks, michaelh, ZrenBot, 
progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D10420: Make sure the FrameSvg and Svg instances have the right devicePixelRatio

[Aleix Pol Gonzalez]

apol created this revision.
apol added a reviewer: Plasma.
Restricted Application added projects: Plasma, Frameworks.
Restricted Application added subscribers: Frameworks, plasma-devel.
apol requested review of this revision.

REVISION SUMMARY
  On wayland (at least) it's initialized when the window is assigned, so
  we need to listen to the itemChanged to adopt it.

TEST PLAN
  manual testing

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D10420

AFFECTED FILES
  src/declarativeimports/core/framesvgitem.cpp
  src/declarativeimports/core/framesvgitem.h
  src/declarativeimports/core/iconitem.cpp

To: apol, #plasma
Cc: plasma-devel, #frameworks, michaelh, ZrenBot, ngraham, progwolff, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D10416: When initialize devicePixelRatio when rendering into a pixmap

[David Edmundson]

davidedmundson requested changes to this revision.
davidedmundson added a comment.
This revision now requires changes to proceed.


  > Fixes rendering of svg in many places, for example now icons don't look
  
  By editing FrameSVG? That seems unlikely.
  
  I think you've got some results mixed up.
  
  This patch doesn't change the resolution of anything. QPixmap::setDPR just 
sets metadata used when rendering using the sizes of one paint device when 
painting into another. However here we don't use the pixmap size, we use 
frame->frameSize...and then multiply it by the devicePixelRatio anyway on line 
793.

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D10416

To: apol, #plasma, davidedmundson
Cc: davidedmundson, ngraham, plasma-devel, #frameworks, michaelh, ZrenBot, 
progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

KDE CI: Frameworks kcoreaddons kf5-qt5 SUSEQt5.7 - Build # 41 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kcoreaddons%20kf5-qt5%20SUSEQt5.7/41/
 Project:
Frameworks kcoreaddons kf5-qt5 SUSEQt5.7
 Date of build:
Fri, 09 Feb 2018 23:23:51 +
 Build duration:
17 min and counting
   JUnit Tests
  Name: (root) Failed: 1 test(s), Passed: 23 test(s), Skipped: 0 test(s), Total: 24 test(s)Failed: TestSuite.kdirwatch_qfswatch_unittest

KDE CI: Frameworks kcoreaddons kf5-qt5 FreeBSDQt5.9 - Build # 30 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kcoreaddons%20kf5-qt5%20FreeBSDQt5.9/30/
 Project:
Frameworks kcoreaddons kf5-qt5 FreeBSDQt5.9
 Date of build:
Fri, 09 Feb 2018 23:23:51 +
 Build duration:
9 min 55 sec and counting
   JUnit Tests
  Name: (root) Failed: 1 test(s), Passed: 22 test(s), Skipped: 0 test(s), Total: 23 test(s)Failed: TestSuite.kdirwatch_inotify_unittest

D10114: Fix bug #382437 "Regression in kdialog causes wrong file extension"

[Nathaniel Graham]

ngraham added a comment.


  It doesn't merge cleanly on master. Can you re-base it?

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D10114

To: ijanssen, #plasma, dfaure
Cc: ngraham, aacid, broulik, plasma-devel, #frameworks, michaelh, ZrenBot, 
progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

KDE CI: Frameworks kcoreaddons kf5-qt5 SUSEQt5.10 - Build # 46 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kcoreaddons%20kf5-qt5%20SUSEQt5.10/46/
 Project:
Frameworks kcoreaddons kf5-qt5 SUSEQt5.10
 Date of build:
Fri, 09 Feb 2018 23:23:51 +
 Build duration:
5 min 9 sec and counting
   JUnit Tests
  Name: (root) Failed: 2 test(s), Passed: 22 test(s), Skipped: 0 test(s), Total: 24 test(s)Failed: TestSuite.kdirwatch_inotify_unittestFailed: TestSuite.kdirwatch_qfswatch_unittest

D10333: Introduce K_PLUGIN_CLASS_WITH_JSON

[Albert Astals Cid]

This revision was not accepted when it landed; it landed in state "Needs 
Revision".
This revision was automatically updated to reflect the committed changes.
Closed by commit R244:97ca9ee095cd: Introduce K_PLUGIN_CLASS_WITH_JSON 
(authored by aacid).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D10333?vs=26729=26852#toc

REPOSITORY
  R244 KCoreAddons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10333?vs=26729=26852

REVISION DETAIL
  https://phabricator.kde.org/D10333

AFFECTED FILES
  CMakeLists.txt
  src/lib/plugin/kpluginfactory.h

To: aacid, dfaure, mlaurent
Cc: mlaurent, kossebau, apol, #frameworks, michaelh, ngraham

D8351: API dox: add note about calling setApplicationDomain after QApp creation

[Friedrich W . H . Kossebau]

This revision was automatically updated to reflect the committed changes.
Closed by commit R249:9ae1a9b2e923: API dox: add note about calling 
setApplicationDomain after QApp creation (authored by kossebau).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D8351?vs=20928=26851#toc

REPOSITORY
  R249 KI18n

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D8351?vs=20928=26851

REVISION DETAIL
  https://phabricator.kde.org/D8351

AFFECTED FILES
  docs/programmers-guide.md
  src/klocalizedstring.h

To: kossebau, #frameworks, ilic, ltoscano, dfaure
Cc: dfaure, michaelh, ngraham

D10141: Restore Persistence=session for the file ioslave kauth helper

[Fabian Vogt]

fvogt added a comment.


  In https://phabricator.kde.org/D10141#203726, @aacid wrote:
  
  > In https://phabricator.kde.org/D10141#203664, @fvogt wrote:
  >
  > > In https://phabricator.kde.org/D10141#203545, @chinmoyr wrote:
  > >
  > > > In https://phabricator.kde.org/D10141#197039, @fvogt wrote:
  > > >
  > > > > There is one issue I have with this. While this is close to the 
`sudo`-mode of temporary authorization grants, it doesn't work that way as the 
whole session has full access via file.so.
  > > >
  > > >
  > > > How exactly? Is there any way for an application to choose a slave 
process instead of being assigned one at random?
  > >
  > >
  > > There isn't. Which makes any mitigation attempt impossible.
  >
  >
  > There actually kind of is, kio has this "special" mode called 
KDE_FORK_SLAVES in which slaves are directly forked by the app instead of by 
klauncher. I'm not sure how much that would help here. Maybe @dfaure can shed 
some light?
  
  
  The issue is that file.so decides whether to use the helper or not, so this 
doesn't actually help.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D10141

To: elvisangelaccio, lbeltrame, dfaure, davidedmundson, fvogt, chinmoyr
Cc: aacid, #frameworks, michaelh, ngraham

D10141: Restore Persistence=session for the file ioslave kauth helper

[Albert Astals Cid]

aacid added a comment.


  In https://phabricator.kde.org/D10141#203664, @fvogt wrote:
  
  > In https://phabricator.kde.org/D10141#203545, @chinmoyr wrote:
  >
  > > In https://phabricator.kde.org/D10141#197039, @fvogt wrote:
  > >
  > > > There is one issue I have with this. While this is close to the 
`sudo`-mode of temporary authorization grants, it doesn't work that way as the 
whole session has full access via file.so.
  > >
  > >
  > > How exactly? Is there any way for an application to choose a slave 
process instead of being assigned one at random?
  >
  >
  > There isn't. Which makes any mitigation attempt impossible.
  
  
  There actually kind of is, kio has this "special" mode called KDE_FORK_SLAVES 
in which slaves are directly forked by the app instead of by klauncher. I'm not 
sure how much that would help here. Maybe @dfaure can shed some light?

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D10141

To: elvisangelaccio, lbeltrame, dfaure, davidedmundson, fvogt, chinmoyr
Cc: aacid, #frameworks, michaelh, ngraham

Re: what about the scalable subdir in the oxygen-icons5 sources?

[Rex Dieter]

René J. V. Bertin wrote:

> Rex Dieter wrote:
> 
>> I'm not aware of fedora providing any such thing.
> 
> I still had the link in my terminal scrollback:
> http://ftp.gwdg.de/pub/opensuse/tumbleweed/repo/oss/suse/noarch/oxygen5-icon-theme-scalable-5.42.0-1.1.noarch.rpm

That's an opensuse rpm, not fedora or arch (as you'd previously mentioned).

-- rex

D10114: Fix bug #382437 "Regression in kdialog causes wrong file extension"

[Igor Janssen]

ijanssen added a comment.


  In https://phabricator.kde.org/D10114#202694, @ngraham wrote:
  
  > Is this committable?
  
  
  I think yes

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D10114

To: ijanssen, #plasma, dfaure
Cc: ngraham, aacid, broulik, plasma-devel, #frameworks, michaelh, ZrenBot, 
progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D10416: When initialize devicePixelRatio when rendering into a pixmap

[Aleix Pol Gonzalez]

apol added a comment.


  This breaks the rendering of buttons (exclusively, as long as I've seen), any 
idea why?

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D10416

To: apol, #plasma
Cc: plasma-devel, #frameworks, michaelh, ZrenBot, ngraham, progwolff, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D10416: When initialize devicePixelRatio when rendering into a pixmap

[Aleix Pol Gonzalez]

apol created this revision.
apol added a reviewer: Plasma.
Restricted Application added projects: Plasma, Frameworks.
Restricted Application added subscribers: Frameworks, plasma-devel.
apol requested review of this revision.

REVISION SUMMARY
  Plasma::Svg uses this information to know the pixel density.
  Fixes rendering of svg in many places, for example now icons don't look
  pixelated in the system tray when using a fancy high dpi display.

TEST PLAN
  Manual testing

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D10416

AFFECTED FILES
  src/plasma/framesvg.cpp

To: apol, #plasma
Cc: plasma-devel, #frameworks, michaelh, ZrenBot, ngraham, progwolff, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D10141: Restore Persistence=session for the file ioslave kauth helper

[Fabian Vogt]

fvogt added a comment.


  In https://phabricator.kde.org/D10141#203545, @chinmoyr wrote:
  
  > In https://phabricator.kde.org/D10141#197039, @fvogt wrote:
  >
  > > There is one issue I have with this. While this is close to the 
`sudo`-mode of temporary authorization grants, it doesn't work that way as the 
whole session has full access via file.so.
  >
  >
  > How exactly? Is there any way for an application to choose a slave process 
instead of being assigned one at random?
  
  
  There isn't. Which makes any mitigation attempt impossible.
  
  > Till now what I have observed is after a successful authentication only the 
slave process is authorised to perform the action and not the application 
itself. So if a malicious app wants to perform some kind of privileged file 
operation then it has to (somehow) pick up a slave that had been already 
authorized. And even if that were possible the slave will still show a 
confirmation dialog.
  
  Yes, this is a design issue and why I don't think this can ever be made 
secure without disabling Persistence completely.
  
  >> It would be great if this could work with just the application which 
initially requested the privilege.
  >> With this, the whole session has full root-level access to literally 
everything on the system.
  > 
  > I do understand having authorization persist for the entire session means 
disaster but when kauth generates the policy file this option only results in 
"auth_admin_keep". 
  >  Polkit's manpage says : **auth_admin_keep - Like auth_admin but the 
authorization is kept for a brief period (e.g. five minutes).**
  > 
  > Also when I execute **pkcheck --list-temp** after authenticating a file 
operation started by dolphin the output I get includes these lines
  > 
  >   subject:  unix-process:9532:1210162 (file.so [kdeinit5] file 
local:/run/user/1000/klauncherTJ7042.1.slave-socket 
local:/run/user/1000/kioslavetestAX7208.3.slave-socket)
  >   expires:  4 min 47 sec from now (Fri Feb  9 21:43:47 2018)
  > 
  > 
  > This suggests **auth_admin_keep** results in temporary authorization of one 
particular process for 5 minutes and not for the entire user session.
  >  So can you explain me one more time why you think persistence=session is a 
bad idea? Do correct me if I got anything (or everything?) above wrong.
  
  Session refers to two independant things: The time from login to logout and 
all processes started by the user.
  The latter meaning is the issue.
  Now imagine you have a proprietary application running on wayland. It can 
just wait until you try to make a change using the kauth helper and then just
  inject its own files somewhere. Currently it does not even have to be a 
change, reading a file is enough as the helper does not care.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D10141

To: elvisangelaccio, lbeltrame, dfaure, davidedmundson, fvogt, chinmoyr
Cc: #frameworks, michaelh, ngraham

Re: what about the scalable subdir in the oxygen-icons5 sources?

[kainz.a]

Hi all together,

first, yes I'm the maintainer of oxygen-icons5 and there are png file the
the origin svgz files.

I don't know how the svg rendering work in plasma, BUT the svg folder is
350 mb in size
the png ones are 34 mb. I don't think it's a good idea to use the svgz
icons.

And here is the key "problem" oxygen-icons are in maintenance mode. Not
really new
icons the last 8 years and I'm not interested into change something in
oxygen-icons.
I will fix some tiny bugs but that's it.

I don't think that use the svg files didn't help someone. The icons are way
to complex

Cheers
Andreas

2018-02-09 19:45 GMT+01:00 Friedrich W. H. Kossebau :

> Adding Andreas as cc:, given he semi-maintains the oxygen icons.
>
> Am Freitag, 9. Februar 2018, 17:49:54 CET schrieb René J. V. Bertin:
> > Friedrich W. H. Kossebau wrote:
> > > Am Freitag, 9. Februar 2018, 10:07:35 CET schrieb René J.V. Bertin:
> > > > Two questions arise:
> > > > - why are they there so many more than there are png icons (= what
> are
> > > > they
> > > > used for)?
>
> Too focussed on the second question, I missed this one. Hm, doing a quick
> incomplete ls -1 | wc -l on some categories I would rather see more PNG
> files
> per size than SVG files.
>
> IIRC the scalable folder simply contains the raw data/sources used to
> generate
> the PNG versions, kept there as source material for any further icons or
> modification of existing ones.
>
> Andreas should know actually :)
>
> > > > - where are the instructions on how to install (only) the
> > > > scalable version?
> [snip]
> > > SVG versions no longer need handcrafted substitutes) that would not
> really
> > > be recommended, so no-one has yet added support for that.
> >
> > I actually discovered the existence of the scalable icons because of
> > "oxygen- icons5-scalable" packages provided by Fedora and Arch.
>
> That is a decision of downstream then, compare e.g. the custom code to
> install
> the SVGZ icon data done for Arch:
> https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?
> h=packages/oxygen-icons
>
> Possibly something to discuss with them, either their decision to also
> provide
> the scalable icons to the user makes sense, if the rendered results are
> acceptable, or something to ask them to revert, if the rendered result
> results
> in visual glitches and leaves a bad impression of Oxygen/KDE.
> (From what I tested, the latter seems more sane to me, but needs full
> investigation by someone using the stuff in reality)
>
> Given you seem a user of Arch or Fedora as you found those packages, you
> might
> want to pick up this task?
> Andreas, what would do you think about those downstream approach to the
> Oxygen
> SVG files?
>
> > Can we assume that QIcon will use the bitmap version if it exists for a
> > given size?
>
> If the implementation of the QIconEngine deployed (e.g. by the Plasma
> integration QPlatformTheme) correctly implements the algorithm as defined
> by
> https://specifications.freedesktop.org/icon-theme-
> spec/icon-theme-spec-latest.html#icon_lookup
> then yes.
>
> > If so, installing the scalable versions as well shouldn't hurt
> > the smaller icons on normal resolution screens, while still given the
> best
> > quality where even on those screens a large/huge/humongous icon size is
> > used (think application icons in the app switcher on Mac).
>
> "Best quality" deoends on the capabilities of the SVG renderer deployed by
> the
> QIconTheme. As you found yourself, chance is that not.
>
> > > indeed at least QSvg seems to fail on some icons by a quick test, so
> that
> > > might be the reason.
> >
> > Yeah, I also thought it might be a work-in-progress; I noticed some of
> those
> > too:
> >
> > view-list-tree.svg
> > qt.svg: link use5411 hasn't been detected!
> > qt.svg: tab-close.svg:6352: Could not resolve property:
> radialGradient3709
> > qt.svg: document-new.svg:602:58: Could not resolve property:
> > linearGradient5167 qt.svg: document-open.svg:4290: Could not resolve
> > property: pattern5614 qt.svg: document-open.svg:4290: Could not resolve
> > property: pattern5626 qt.svg: document-open-folder.svg:4224: Could not
> > resolve property: pattern5614 qt.svg: document-open-folder.svg:4224:
> Could
> > not resolve property: pattern5626
>
> IIRC it is less work-in-progress, but simply due to mismatch of SVG
> features
> used to do the Oxygen icons and of what the deployed SVG runtime renderer,
> i.e. typically the QSvg* one, officially supports.
>
> "Qt supports the static features of SVG 1.2 Tiny."
> http://doc.qt.io/qt-5/svgrendering.html
>
> While the Oxygen icons make use of more SVG features to achieve the desired
> look. That's why even the higher sizes are installed pre-rendered as PNGs.
>
> So unless someone works on deploying a more powerful runtime SVG renderer
> or
> someone works on trying to port all the SVG features used in the Oxygen
> icons
> to SVG 1.2 Tiny (might not be even feasible), this situation is 

Re: what about the scalable subdir in the oxygen-icons5 sources?

[René J . V . Bertin]

Friedrich W. H. Kossebau wrote:

> Too focussed on the second question, I missed this one. Hm, doing a quick
> incomplete ls -1 | wc -l on some categories I would rather see more PNG files
> per size than SVG files.

You're right actually, I see now that I missed directory level in one of my own 
ls commands (I blame a keyboard that's just too small =] )

> IIRC the scalable folder simply contains the raw data/sources used to generate
> the PNG versions, kept there as source material for any further icons or
> modification of existing ones.

The thought did cross my mind, but in that case the release source tarballs 
contain over 380Mb "junk DNA" vs. only about 52Mb useful payload. A bit of a 
waste of bandwidth and download times, no?

> Given you seem a user of Arch or Fedora as you found those packages, you might
> want to pick up this task?

I'm not, in fact. I found them because I googled for scalable Oxygen icons, for 
a completely different reason (embedding a few in a binary resource).

> "Best quality" deoends on the capabilities of the SVG renderer deployed by the
> QIconTheme. As you found yourself, chance is that not.

Actually, for the examples I gave the rendered SVG still looks better at a 
larger size than an upscaled bitmap. The icon isn't exactly the same, but it 
doesn't look like a blown-up bitmap. This will differ from icon to icon of 
course; some may have weird rendering artefacts.

> So unless someone works on deploying a more powerful runtime SVG renderer or 

Isn't there a libsvg based on Cairo?

> someone works on trying to port all the SVG features used in the Oxygen icons 
> to SVG 1.2 Tiny (might not be even feasible), this situation is simply a 
> given state.

It might also be (more?) useful to review and simplify the Oxygen icons. Not as 
an improved replacement, but as an alternative fork, say, Oxygen-Modern. I have 
no idea if the advanced SVG features have anything to do with the non-flat 
design 
or the incredible level of detail in some icons (cf. go-jump-locationbar.svgz), 
but both aspects could surely be tuned down a bit without changing the theme's 
character completely.

>> Inkscape only complains about document-new.svg ("unknown type: ns:sfw").
> 
> Which version of inkscape?

0.91 and 0.92.2 .

Cheers,
R.

Re: what about the scalable subdir in the oxygen-icons5 sources?

[René J . V . Bertin]

Rex Dieter wrote:

> I'm not aware of fedora providing any such thing.

I still had the link in my terminal scrollback:
http://ftp.gwdg.de/pub/opensuse/tumbleweed/repo/oss/suse/noarch/oxygen5-icon-theme-scalable-5.42.0-1.1.noarch.rpm

R

Re: what about the scalable subdir in the oxygen-icons5 sources?

[Friedrich W. H. Kossebau]

Adding Andreas as cc:, given he semi-maintains the oxygen icons.

Am Freitag, 9. Februar 2018, 17:49:54 CET schrieb René J. V. Bertin:
> Friedrich W. H. Kossebau wrote:
> > Am Freitag, 9. Februar 2018, 10:07:35 CET schrieb René J.V. Bertin:
> > > Two questions arise:
> > > - why are they there so many more than there are png icons (= what are
> > > they
> > > used for)?

Too focussed on the second question, I missed this one. Hm, doing a quick 
incomplete ls -1 | wc -l on some categories I would rather see more PNG files 
per size than SVG files.

IIRC the scalable folder simply contains the raw data/sources used to generate 
the PNG versions, kept there as source material for any further icons or 
modification of existing ones.

Andreas should know actually :)

> > > - where are the instructions on how to install (only) the
> > > scalable version?
[snip]
> > SVG versions no longer need handcrafted substitutes) that would not really
> > be recommended, so no-one has yet added support for that.
> 
> I actually discovered the existence of the scalable icons because of
> "oxygen- icons5-scalable" packages provided by Fedora and Arch.

That is a decision of downstream then, compare e.g. the custom code to install 
the SVGZ icon data done for Arch:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?
h=packages/oxygen-icons

Possibly something to discuss with them, either their decision to also provide 
the scalable icons to the user makes sense, if the rendered results are 
acceptable, or something to ask them to revert, if the rendered result results 
in visual glitches and leaves a bad impression of Oxygen/KDE.
(From what I tested, the latter seems more sane to me, but needs full 
investigation by someone using the stuff in reality)

Given you seem a user of Arch or Fedora as you found those packages, you might 
want to pick up this task?
Andreas, what would do you think about those downstream approach to the Oxygen 
SVG files?

> Can we assume that QIcon will use the bitmap version if it exists for a
> given size?

If the implementation of the QIconEngine deployed (e.g. by the Plasma 
integration QPlatformTheme) correctly implements the algorithm as defined by
https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#icon_lookup
then yes.

> If so, installing the scalable versions as well shouldn't hurt
> the smaller icons on normal resolution screens, while still given the best
> quality where even on those screens a large/huge/humongous icon size is
> used (think application icons in the app switcher on Mac).

"Best quality" deoends on the capabilities of the SVG renderer deployed by the 
QIconTheme. As you found yourself, chance is that not.

> > indeed at least QSvg seems to fail on some icons by a quick test, so that
> > might be the reason.
> 
> Yeah, I also thought it might be a work-in-progress; I noticed some of those
> too:
> 
> view-list-tree.svg
> qt.svg: link use5411 hasn't been detected!
> qt.svg: tab-close.svg:6352: Could not resolve property: radialGradient3709
> qt.svg: document-new.svg:602:58: Could not resolve property:
> linearGradient5167 qt.svg: document-open.svg:4290: Could not resolve
> property: pattern5614 qt.svg: document-open.svg:4290: Could not resolve
> property: pattern5626 qt.svg: document-open-folder.svg:4224: Could not
> resolve property: pattern5614 qt.svg: document-open-folder.svg:4224: Could
> not resolve property: pattern5626

IIRC it is less work-in-progress, but simply due to mismatch of SVG features 
used to do the Oxygen icons and of what the deployed SVG runtime renderer, 
i.e. typically the QSvg* one, officially supports.

"Qt supports the static features of SVG 1.2 Tiny."
http://doc.qt.io/qt-5/svgrendering.html

While the Oxygen icons make use of more SVG features to achieve the desired 
look. That's why even the higher sizes are installed pre-rendered as PNGs.

So unless someone works on deploying a more powerful runtime SVG renderer or 
someone works on trying to port all the SVG features used in the Oxygen icons 
to SVG 1.2 Tiny (might not be even feasible), this situation is simply a given 
state.

> Inkscape only complains about document-new.svg ("unknown type: ns:sfw").

Which version of inkscape?

Cheers
Friedrich

D10414: Add move semantics support to KIO::UDSEntry.

[Mark Gaiser]

markg marked an inline comment as done.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D10414

To: markg, dfaure
Cc: apol, #frameworks, michaelh, ngraham

D10414: Add move semantics support to KIO::UDSEntry.

[Mark Gaiser]

markg updated this revision to Diff 26839.
markg added a comment.


  Remove comment about compiler generated functions.

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10414?vs=26838=26839

BRANCH
  udsentry_move

REVISION DETAIL
  https://phabricator.kde.org/D10414

AFFECTED FILES
  autotests/udsentrytest.cpp
  autotests/udsentrytest.h
  src/core/udsentry.cpp
  src/core/udsentry.h

To: markg, dfaure
Cc: apol, #frameworks, michaelh, ngraham

D10414: Add move semantics support to KIO::UDSEntry.

[Aleix Pol Gonzalez]

apol added inline comments.

INLINE COMMENTS

> udsentry.cpp:95
> +// Default implementations for:
> +// - Copy constructor
> +// - Move constructor

This comment is very confusing, especially considering that the order you used 
there isn't the same as  the ones below.

I'd just remove it all.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D10414

To: markg, dfaure
Cc: apol, #frameworks, michaelh, ngraham

D10414: Add move semantics support to KIO::UDSEntry.

[Mark Gaiser]

markg added a comment.


  Just a note.
  The fact that currently no code is structured in a way that move semantics 
are used is... slightly annoying ;)
  No as in not when running dolphin with it and profiling it to see UDSEntry 
uses. There "might" be code that uses move semantics when this patch is 
applied, but i haven't seen it yet.
  
  So, more patches to come to fix that. I've already spotted one potential case 
in KCoreDirListerCache although that probably depends on more.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D10414

To: markg, dfaure
Cc: #frameworks, michaelh, ngraham

Re: what about the scalable subdir in the oxygen-icons5 sources?

[Rex Dieter]

René J. V. Bertin wrote:


>> So all the PNG versions are there as handcrafted optimized versions of
>> their SVG counterpart, so the icons are still usable when needed in sizes
>> of 16,22,24,32,48,...
> 
> Isn't that an answer to the question "why are there also png icons" (or to
> "why are so many provided as svgs for a particular bitmap size")?
> 
>> SVG versions no longer need handcrafted substitutes) that would not
>> really be recommended, so no-one has yet added support for that.
> 
> I actually discovered the existence of the scalable icons because of
> "oxygen- icons5-scalable" packages provided by Fedora and Arch.

I'm not aware of fedora providing any such thing.

As far as I know, the .svg icons included in the tarball is generally 
considered the "source code" for the shipped (generally png) icons

-- Rex

D10414: Add move semantics support to KIO::UDSEntry.

[Mark Gaiser]

markg updated this revision to Diff 26838.
markg added a comment.


  Fix indentation.

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10414?vs=26836=26838

BRANCH
  udsentry_move

REVISION DETAIL
  https://phabricator.kde.org/D10414

AFFECTED FILES
  autotests/udsentrytest.cpp
  autotests/udsentrytest.h
  src/core/udsentry.cpp
  src/core/udsentry.h

To: markg, dfaure
Cc: #frameworks, michaelh, ngraham

D10414: Add move semantics support to KIO::UDSEntry.

[Mark Gaiser]

markg created this revision.
markg added a reviewer: dfaure.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.
markg requested review of this revision.

REVISION SUMMARY
  Adds move semantics support and a testcase (only useful in callgrind).
  Right now there are 0 uses of these semantics.

TEST PLAN
  Relevant tests (udsentrytest and kfileitemtest) pass.
  Dolphin compiles and runs just fine with it.

REPOSITORY
  R241 KIO

BRANCH
  udsentry_move

REVISION DETAIL
  https://phabricator.kde.org/D10414

AFFECTED FILES
  autotests/udsentrytest.cpp
  autotests/udsentrytest.h
  src/core/udsentry.cpp
  src/core/udsentry.h

To: markg, dfaure
Cc: #frameworks, michaelh, ngraham

D10411: Create socket file in user's runtime directory

[Chinmoy Ranjan Pradhan]

chinmoyr created this revision.
chinmoyr added reviewers: Frameworks, ossi.
Restricted Application added a project: Frameworks.
chinmoyr requested review of this revision.

REVISION SUMMARY
  "/tmp" is world writable so creating socket there is a bad idea. Instead 
create socket in user's
  runtime directory or any directory with permissions 0700. This path will be 
provided by file
  ioslave.
  
  Depends on https://phabricator.kde.org/D10410

REPOSITORY
  R241 KIO

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D10411

AFFECTED FILES
  src/ioslaves/file/sharefd_p.h

To: chinmoyr, #frameworks, ossi
Cc: michaelh, ngraham

D10410: Move the task of cleaning up of socket file to file ioslave and FdReceiver

[Chinmoy Ranjan Pradhan]

chinmoyr added a dependent revision: D10411: Create socket file in user's 
runtime directory.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D10410

To: chinmoyr, #frameworks, ossi
Cc: michaelh, ngraham

D9966: [KIO] Fix issues with sharing of file descriptor

[Chinmoy Ranjan Pradhan]

chinmoyr added a dependent revision: D10410: Move the task of cleaning up of 
socket file to file ioslave and FdReceiver.

REPOSITORY
  R241 KIO

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D9966

To: chinmoyr, #frameworks, thiago, dfaure, ossi
Cc: ngraham, fvogt, lbeltrame, dfaure, michaelh

D10409: In linux don't use abstract socket to share file descriptor

[Chinmoy Ranjan Pradhan]

chinmoyr added a dependent revision: D10410: Move the task of cleaning up of 
socket file to file ioslave and FdReceiver.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D10409

To: chinmoyr, #frameworks, ossi
Cc: michaelh, ngraham

D10410: Move the task of cleaning up of socket file to file ioslave and FdReceiver

[Chinmoy Ranjan Pradhan]

chinmoyr created this revision.
chinmoyr added reviewers: Frameworks, ossi.
Restricted Application added a project: Frameworks.
chinmoyr requested review of this revision.

REVISION SUMMARY
  The class SocketAddress is meant only for creating a proper socket address 
structure. It should not be handling
  cleanup of the socket file. FdReceiver and file ioslave are better suited for 
this job.
  
  Depends on https://phabricator.kde.org/D9966 and 
https://phabricator.kde.org/D10409

REPOSITORY
  R241 KIO

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D10410

AFFECTED FILES
  src/ioslaves/file/fdreceiver.cpp
  src/ioslaves/file/file_unix.cpp
  src/ioslaves/file/sharefd_p.h

To: chinmoyr, #frameworks, ossi
Cc: michaelh, ngraham

D10409: In linux don't use abstract socket to share file descriptor

[Chinmoy Ranjan Pradhan]

chinmoyr updated this revision to Diff 26830.
chinmoyr added a comment.


  Added back "/tmp/" prefix

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10409?vs=26828=26830

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D10409

AFFECTED FILES
  src/ioslaves/file/sharefd_p.h

To: chinmoyr, #frameworks, ossi
Cc: michaelh, ngraham

D10273: Create proper SocketAddress

[Chinmoy Ranjan Pradhan]

chinmoyr added a dependent revision: D10409: In linux don't use abstract socket 
to share file descriptor.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D10273

To: chinmoyr, #frameworks
Cc: ossi, thiago, dfaure, michaelh, ngraham

D10409: In linux don't use abstract socket to share file descriptor

[Chinmoy Ranjan Pradhan]

chinmoyr created this revision.
chinmoyr added reviewers: Frameworks, ossi.
Restricted Application added a project: Frameworks.
chinmoyr requested review of this revision.

REVISION SUMMARY
  Use pathname socket for better security. The socket path will be provided by 
file ioslave.
  
  Depends on https://phabricator.kde.org/D10273

REPOSITORY
  R241 KIO

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D10409

AFFECTED FILES
  src/ioslaves/file/sharefd_p.h

To: chinmoyr, #frameworks, ossi
Cc: michaelh, ngraham

D9840: Tentative patch to reduce I/O overhead of plasmashell when copying files

[Jaime Torres Amate]

jtamate added a comment.


  Just to let you know that I know how to reproduce the high I/O of plasmashell 
and continuous calls to Kservice.
  You can reproduce it just having opened the vivaldi web browser. (I never 
though it could be a problem).
  If it goes to a webpage that still uses flash, the effect is even bigger.
  F5700774: plasmashell_disk.png .

REPOSITORY
  R309 KService

REVISION DETAIL
  https://phabricator.kde.org/D9840

To: jtamate, #frameworks, dfaure
Cc: ngraham, mmustac, michaelh

Re: what about the scalable subdir in the oxygen-icons5 sources?

[René J . V . Bertin]

Friedrich W. H. Kossebau wrote:

Hi,


> So all the PNG versions are there as handcrafted optimized versions of their
> SVG counterpart, so the icons are still usable when needed in sizes of
> 16,22,24,32,48,...

Isn't that an answer to the question "why are there also png icons" (or to "why 
are so many provided as svgs for a particular bitmap size")?

> SVG versions no longer need handcrafted substitutes) that would not really be
> recommended, so no-one has yet added support for that.

I actually discovered the existence of the scalable icons because of "oxygen-
icons5-scalable" packages provided by Fedora and Arch.

Can we assume that QIcon will use the bitmap version if it exists for a given 
size? If so, installing the scalable versions as well shouldn't hurt the 
smaller 
icons on normal resolution screens, while still given the best quality where 
even on those screens a large/huge/humongous icon size is used (think 
application icons in the app switcher on Mac).

> Hm, actually it seems the scalable versions are not even installed by the
> buildsystem?

Nope, and there is no index.theme file in the scalable subdirectory. 

> indeed at least QSvg seems to fail on some icons by a quick test, so that
> might be the reason.

Yeah, I also thought it might be a work-in-progress; I noticed some of those 
too:

view-list-tree.svg
qt.svg: link use5411 hasn't been detected!
qt.svg: tab-close.svg:6352: Could not resolve property: radialGradient3709
qt.svg: document-new.svg:602:58: Could not resolve property: linearGradient5167
qt.svg: document-open.svg:4290: Could not resolve property: pattern5614
qt.svg: document-open.svg:4290: Could not resolve property: pattern5626
qt.svg: document-open-folder.svg:4224: Could not resolve property: pattern5614
qt.svg: document-open-folder.svg:4224: Could not resolve property: pattern5626

Inkscape only complains about document-new.svg ("unknown type: ns:sfw").

Cheers,
R.

D10365: New icon for Elisa music player

[Paul Lesur]

paullesur added a comment.


  In https://phabricator.kde.org/D10365#203432, @astippich wrote:
  
  > I was a little bit hesitant at first, but I'm starting to like the idea of 
a cassette as an icon for Elisa. But I think the text in the icon is not 
required. It will usually be so small that no-one can read it.
  >  Anyways, Matthieu should have a comment about this.
  
  
  Yes you're right, the text makes the icon more cluttered. I could remove the 
text or draw some kind of stylized text that would read better.
  
  I'm not sure about the color, is green OK ?

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D10365

To: paullesur, #breeze, #vdg, #elisa, andreaska
Cc: astippich, andreask, andreaska, ltoscano, ngraham, #frameworks, paullesur, 
michaelh, ognarb, januz, kmf, progwolff, mgallien

D9966: [KIO] Fix issues with sharing of file descriptor

[Chinmoy Ranjan Pradhan]

chinmoyr added a comment.


  Is the patch good enough to be pushed?

REPOSITORY
  R241 KIO

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D9966

To: chinmoyr, #frameworks, thiago, dfaure, ossi
Cc: ngraham, fvogt, lbeltrame, dfaure, michaelh

D6198: Add KAuth support to delete operation

[Chinmoy Ranjan Pradhan]

chinmoyr abandoned this revision.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D6198

To: chinmoyr, elvisangelaccio, #frameworks
Cc: fvogt, dfaure, davidedmundson, michaelh, ngraham

D10141: Restore Persistence=session for the file ioslave kauth helper

[Chinmoy Ranjan Pradhan]

chinmoyr added a comment.


  In https://phabricator.kde.org/D10141#197039, @fvogt wrote:
  
  > There is one issue I have with this. While this is close to the `sudo`-mode 
of temporary authorization grants, it doesn't work that way as the whole 
session has full access via file.so.
  
  
  How exactly? Is there any way for an application to choose a slave process 
instead of being assigned one at random? 
  Till now what I have observed is after a successful authentication only the 
slave process is authorised to perform the action and not the application 
itself. So if a malicious app wants to perform some kind of privileged file 
operation then it has to (somehow) pick up a slave that had been already 
authorized. And even if that were possible the slave will still show a 
confirmation dialog.
  
  > It would be great if this could work with just the application which 
initially requested the privilege.
  > With this, the whole session has full root-level access to literally 
everything on the system.
  
  I do understand having authorization persist for the entire session means 
disaster but when kauth generates the policy file this option only results in 
"auth_admin_keep". 
  Polkit's manpage says : **auth_admin_keep - Like auth_admin but the 
authorization is kept for a brief period (e.g. five minutes).**
  
  Also when I execute **pkcheck --list-temp** after authenticating a file 
operation started by dolphin the output I get includes these lines
  
subject:  unix-process:9532:1210162 (file.so [kdeinit5] file 
local:/run/user/1000/klauncherTJ7042.1.slave-socket 
local:/run/user/1000/kioslavetestAX7208.3.slave-socket)
expires:  4 min 47 sec from now (Fri Feb  9 21:43:47 2018)
  
  This suggests **auth_admin_keep** results in temporary authorization of one 
particular process for 5 minutes and not for the entire user session.
  So can you explain me one more time why you think persistence=session is a 
bad idea? Do correct me if I got anything (or everything?) above wrong.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D10141

To: elvisangelaccio, lbeltrame, dfaure, davidedmundson, fvogt, chinmoyr
Cc: #frameworks, michaelh, ngraham

D10405: Don't proceed in runCommandInternal if the executable doesn't exit

[Marco Martin]

mart added a comment.


  +1 from me

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D10405

To: hein, dfaure, davidedmundson, mart
Cc: #frameworks, michaelh, ngraham

D10405: Don't proceed in runCommandInternal if the executable doesn't exit

[Eike Hein]

hein updated this revision to Diff 26821.
hein added a comment.


  Remove unrelated changes.

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10405?vs=26820=26821

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D10405

AFFECTED FILES
  src/widgets/krun.cpp

To: hein, dfaure, davidedmundson, mart
Cc: #frameworks, michaelh, ngraham

D10405: Don't proceed in runCommandInternal if the executable doesn't exit

[Eike Hein]

hein added a comment.


  Argh, sorry for the noisy diff, I didn't do commit -a but arc did I guess ... 
I'll clean this up, one sec.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D10405

To: hein, dfaure, davidedmundson, mart
Cc: #frameworks, michaelh, ngraham

D10405: Don't proceed in runCommandInternal if the executable doesn't exit

[Eike Hein]

hein created this revision.
hein added reviewers: dfaure, davidedmundson, mart.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.
hein requested review of this revision.

REVISION SUMMARY
  Without this patch, runCommandInternal tries running first and
  handles a missing executable in slotProcessExited after process
  execution ended with a non-zero exit code.
  
  One of the side-effects is that a startup notification is created
  even if nothing is ultimately run.
  
  With this patch, we check for executable existence first and
  abort if we can't find it.
  
  This fixes a Plasma shell crash in the Task Manager applet: We
  use KRun from inside the onReleased handler of a MouseArea. In
  this error case this leads to a KMessageBox spinning the event
  loop. The delegate hosting the MouseArea is in the meanwhile
  deleted because it's replaced by a different one for the startup
  creation. After closing the dialog we're back in the destroyed
  delegate and crash.
  
  BUG:385942

REPOSITORY
  R241 KIO

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D10405

AFFECTED FILES
  src/core/kprotocolinfofactory.cpp
  src/widgets/jobuidelegate.cpp
  src/widgets/jobuidelegate.h
  src/widgets/krun.cpp

To: hein, dfaure, davidedmundson, mart
Cc: #frameworks, michaelh, ngraham

Re: what about the scalable subdir in the oxygen-icons5 sources?

[Friedrich W. H. Kossebau]

Am Freitag, 9. Februar 2018, 14:11:34 CET schrieb Friedrich W. H. Kossebau:
> Am Freitag, 9. Februar 2018, 10:07:35 CET schrieb René J.V. Bertin:
> > - where are the instructions on how to install (only) the
> > scalable version?

Oh, my reply was done for a "how to install only" question, forgot the 
implicit variants here when typing the answer after having looked at the 
CMakeLists.txt to do some research for you (reading CMakeLists.txt is not for 
everyone it seems :) ). With that in mind, context of actual answer should 
still be valid and useful I hope.

Cheers
Friedrich

Re: what about the scalable subdir in the oxygen-icons5 sources?

[Friedrich W. H. Kossebau]

Am Freitag, 9. Februar 2018, 10:07:35 CET schrieb René J.V. Bertin:
> I just discover that the huge source tarball size of the oxygen-icons5 theme
> is not a result of it using png icons, but of an enormous collection of SVG
> icons.
> 
> Two questions arise:
> - why are they there so many more than there are png icons (= what are they
> used for)?

AFAIK because the oxygen icons are more complex and detailed, the SVG version 
do not properly scale below a certain size, there are more "items" in the icon 
than what can be properly rendered onto e.g. 32x32 pixels and still be 
recognizable as result. Also are objects in the SVG not straight aligned to 
all the different pixel-sizes, given they are not based on simple 2^n scaling.

So all the PNG versions are there as handcrafted optimized versions of their 
SVG counterpart, so the icons are still usable when needed in sizes of 
16,22,24,32,48,...


> - where are the instructions on how to install (only) the
> scalable version?

Unless one has a high-dpi screen where any icon used is rendered at least as 
64x64 or 128x128 (not really sure if there is a given minimal size when the 
SVG versions no longer need handcrafted substitutes) that would not really be 
recommended, so no-one has yet added support for that.

Hm, actually it seems the scalable versions are not even installed by the 
buildsystem?
That might perhaps something worth to consider given more and more people use 
high-dpi screens. But then not sure if the svg icon rendering engine used 
supports all the SVG features used in the SVG code of the oxygen icons... 
indeed at least QSvg seems to fail on some icons by a quick test, so that 
might be the reason.

Cheers
Friedrich

what about the scalable subdir in the oxygen-icons5 sources?

[René J . V . Bertin]

Hi,

I just discover that the huge source tarball size of the oxygen-icons5 theme is 
not a result of it using png icons, but of an enormous collection of SVG icons.

Two questions arise:
- why are they there so many more than there are png icons (= what are they 
used for)?
- where are the instructions on how to install (only) the scalable version?

Thanks,
R.

D10365: New icon for Elisa music player

[Alexander Stippich]

astippich added a comment.


  I was a little bit hesitant at first, but I'm starting to like the idea of a 
cassette as an icon for Elisa. But I think the text in the icon is not 
required. It will usually be so small that no-one can read it.
  Anyways, Matthieu should have a comment about this.

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D10365

To: paullesur, #breeze, #vdg, #elisa, andreaska
Cc: astippich, andreask, andreaska, ltoscano, ngraham, #frameworks, paullesur, 
michaelh, ognarb, januz, kmf, progwolff, mgallien