DevHeads.net

Icon size in Okular and other applications

Hi,

I've got Plasma 5 on a HiDPI monitor (Apple MacBookPro 12,1, retina display).
With some tuning, I've managed to set the right size for most icons on my
desktop and many applications.

However, there are some applications where icons are still too small. One
example is Okular and the icons of the menu entries, as you can see in the
attached screenshot. There are also other applications with similar little
issues.

Is there anything I can do to change the size of these icons? Apparenlty, the
settings on System Settings -> Appearance -> Icons -> Advanced do not affect
the size of icons like these. What I notice though is that the All Icons entry
is grayed out, and I cannot choose a size, but probably this is unrelated.

I'm on debian testing (stretch).

Thanks & Regards,
Davide

Comments

Re: Icon size in Okular and other applications

By Duncan at 03/18/2017 - 01:33

solitone posted on Fri, 17 Mar 2017 06:46:01 +0100 as excerpted:

While I'm running hires, I'm also running very large displays, but
standardized to 96 dpi (actual calculated is 60-some dpi for the 65-inch
4k, 40-some dpi for the 48-inch full-hd), and I don't worry about
scaling. =:^) So I can't help you directly.

But what I /can/ do, since I'm running live-git kde-frameworks/plasma/kde-
apps (using the live ebuilds from the gentoo/kde overlay) and have been
following the commit-stream reasonably closely, is tell you this:

They're still actively working on hidpi scaling bugs in live-git, and in
fact, I believe I've seen quite some work going into it on the breeze
theme. While some of that work will be in the absolute latest releases,
you won't be seeing all of it unless you're running either live-git.

FWIW there's the kde neon project offering live-git builds on an ubuntu-
LTS base, if you're not into doing the builds yourself as I am on gentoo.

<a href="https://neon.kde.org" title="https://neon.kde.org">https://neon.kde.org</a> for more info on that.

What you /could/ try if you're curious enough, is at least a test install
of that, since it should have all the latest hidpi fixes, and they /are/
actively working on hidpi, so as I said you're likely to see some fixes
there that you won't find in any actual release yet, even the newest ones.

The other nice thing about running neon is that since you're running live-
git-current and it's on a known base, any bugs you file on it are likely
to get highest priority attention since it's what they're working on
right now on a duplicatable platform, not what they were working on six
months to a year ago, on some distro with whatever dependency versions
and unknown patches, as tends to be the case even with distros that ship
current releases, since by definition, releases are stuff they worked on
in the last development cycle, not the current one.

And of course since again they're actually focused on hidpi bugs ATM,
that's another reason bugs you file on that should get priority,
especially if you're running neon or otherwise running live-git kde.

Re: Icon size in Okular and other applications

By =?utf-8?Q?Ren=C... at 03/17/2017 - 04:25

I presume the MPB is running Linux? The scrollbar looks a lot like the native Cocoa one. The Breeze scrollbar uses larger "arrows" for me but that difference may stem from the fact you're using a higher res. screen than I do.

Only the icons in Okular's menus? That'd be suspicious.

Tastes differ, but why don't you deactivate icons in menus? I find they're just distracting visual noise most of the time (FWIW, "real Macs" don't have 'em ;))

R.

Re: Icon size in Okular and other applications

By solitone at 03/17/2017 - 05:26

On Friday, 17 March 2017 10:25:28 CET you wrote:
Yes, I'm running debian GNU/linux scratch (testing).

Yes, probably so, in fact I'm using the Breeze theme.

It's not just menu item icons in Okular. For instance, also the Save and
Cancel icons in the Okular open document popup are small (attachment 1.jpeg),
as well as the Save and Cancel icons in the Save File KDialog I get when
saving something from Chrome (2.jpeg). By contrast, when saving a file from
KWrite those two icons have a regular size (3.jpeg).

That is an interesting suggestion, although it wouldn't solve the issue I get
with some open/save dialogs.

Thanks & Cheers,
Davide

Re: Icon size in Okular and other applications

By solitone at 03/18/2017 - 01:14

On Friday, 17 March 2017 11:26:39 CET solitone wrote:
I've just noticed that in my system (debian GNU/linux stretch) kdialog and
okular are based on an older Qt version:

solitone@alan:~$ kdialog --version
Qt: 4.8.7
KDE Development Platform: 4.14.26
KDialog: 1.0
solitone@alan:~$ okular --version
Qt: 4.8.7
KDE Development Platform: 4.14.26
Okular: 0.26.1

While kate and kmail, for example, that don't have the issue, are based on Qt
5.7.1 and KDE Frameworks 5.28.0.

So the problem seems related to the version of Qt, where perhaps HiDPI support
on version 4.8.x wasn't so mature?

Cheers,
Davide

Re: Icon size in Okular and other applications

By =?utf-8?Q?Ren=C... at 03/18/2017 - 03:33

Ahhh, there's your explanation! Qt4 was never updated for hires displays as far as I know. Or if it has support it is almost certainly less evolved. Note though that Qt4 also supported SVG icons already (as well as scaling png icons) so it does have the necessary functionality to display icons at the right size. Those sizes just have to be calculated manually. I'm afraid no one will want to bother adapting such "ooold" code to solve what is not much more than a cosmetics issue.

Okular indeed hasn't yet been released in a KF5 version to my knowledge (it does exist though), but for KDialog I see no real excuse to ship the KDE4 versions other than "it's Debian".

FWIW, KF5 and KDE4 applications store their settings in different locations. It may be worth a shot to verify if you have both versions of the systemsettings app (systemsettings and systemsettings5 in that case) and check if they both show the same (your) icon size configuration.

R.

Re: Icon size in Okular and other applications

By Duncan at 03/18/2017 - 20:19

René J.V. Bertin posted on Sat, 18 Mar 2017 09:33:12 +0100 as excerpted:

According to my package query on gentoo:

$equery list -op okular
* Searching for okular ...
[-P-] [ ] kde-apps/okular-16.08.3:4/16.08
[-P-] [ ] kde-apps/okular-16.12.3:5
[I-O] [ ] kde-apps/okular-9999:5

The -op switches say list overlay (o) and main-gentoo-tree (p=portage)
hits both, not just what's installed. That way I get what's available,
not just what's installed.

The says okular-9999 is installed, the O says it's in an overlay. -9999
is the version assigned to live-git, and the overlay is gentoo/kde, where
the live-git kde packages are.

The P on the other two say they're in the main gentoo/portage tree repo.

16.08.3 is slot 4 (subslot 16.08), interpreted as kde4 based.

16.12.3 is slot 5, thus kde-frameworks5 based.

And of course the live-git I have installed is also slot 5, frameworks5
based.

So yes, there's a frameworks5 release of okular, the 16.12 series, first
released in December (12th month of 2016) and updated with monthly
releases since, the latest of which was released earlier this month.

Similar version and slot results for kdialog, so it too was still kde4
back in August (16.08), but is now frameworks5 based from the December
16.12 release.

But kdialog is a reasonably simple app compared to okular, and it's
possible that some distros were more conservative on okular and continued
to ship the kde4 16.08 or earlier version even when they had updated to
the kde5 16.12 release for kdialog.

Meanwhile, being on kde-live-git, I've been running kde5 based okular and
kdialog both, for some months now. No complaints so far. (Well a minor
one for kdialog related to its progress dialog, as the documented method
using the dbus handle for for updating it broke and the progress dialog
no longer updates and goes away when it is supposed to. I worked around
that by updating the script to use a notification popup instead. But
okular has been great, and it's good to be off kde4 for both of them. =:^)

Meanwhile, that does indeed explain the scaling issues, as qt4 indeed
never really supported hidpi scaling at all, while qt5 does.

So at least you (OP) know the problem should go away eventually, when
your distro updates to a qt5-based okular and kdialog.

Re: Icon size in Okular and other applications

By solitone at 03/19/2017 - 02:17

Hi Duncan, and thanks for your clarification on versions:

On Sunday, 19 March 2017 01:19:45 CET Duncan wrote:
Just a curiosity. In debian it seems I don't have any indication on slots, so
it's not immediate to know whether a package is based on kde4 or framework5.
For instance:

solitone@alan:~$ apt-cache policy okular
okular:
Installed: 4:16.08.2-1+b1
Candidate: 4:16.08.2-1+b1

solitone@alan:~$ apt-cache policy kde-baseapps-bin
kde-baseapps-bin:
Installed: 4:16.08.3-1
Candidate: 4:16.08.3-1

kde-baseapps-bin is the debian package providing kdialog.

Is there a quick and easy way to find out whether an application is based on
kde4 or framework5, apart from looking at the version details in every
application?

Thanks again,
Davide

Re: Icon size in Okular and other applications

By Duncan at 03/19/2017 - 04:08

solitone posted on Sun, 19 Mar 2017 08:17:39 +0100 as excerpted:

FWIW, slots are gentoo's package-management mechanism for allowing
multiple versions of something to be installed at the same time, assuming
of course that they don't actually install any files to exactly the same
path. Most commonly slots are used for libraries where the filenames
don't collide because they're say *.so.1.2.3 and *.so.2.3.4, but they are
often used for things like desktop major versions as well, to make
tracking what's installed easier even when installing all packages of
both slots isn't actually supported, and that's what you see here.

Slots default to 0 if unset, and that's what most packages that haven't
been specifically designed to allow more than one version to be installed
at the same time use.

So it's not surprising that Debian doesn't have an exactly similar
mechanism because slots, as seen here, are gentoo-specific.

**BUT**...

There should be a way to query dependencies, and they have to be set
correctly no matter the package management system or the package will
have much bigger problems.

I don't know Debian's packaging system well enough to give you an exact
command, but querying it for what it depends on, and then piping that
query to a grep for something like kdelibs, a kde4-only package that any
kde4-based app should depend on, should work. Or grep for the qt
dependency, qt4 or qt5.

Alternatively, a method that doesn't depend on a package-manager query,
but instead on the elf-executable information, run ldd on one of the
binaries. That should produce a list of all the libraries it's linked
against, and again, you can grep that for kdelibs or one of the qt
libraries, and see that way whether it's kdelibs4 or kde-frameworks5
based, or qt4/5 based.

You'll probably have to play around with the command and grep a bit (does
the STDOUT or STDERR need piped to grep? do you want to do a grep -q and
rely only on exit code, or do you prefer to see the actual grepped line,
etc.), but either of these should be reliable enough to script if you
like, once you get it working. Then you'll have your own script to run
and won't have to remember the details. =:^)

Someone here that's more familiar with Debian package management can
probably post a nice one-liner, if you're not comfortable using grep, etc.