Обновить кэш иконок linux

Arch Linux

You are not logged in.

#1 2012-05-07 03:08:21

The GTK icon cache conspiracy

I’ve wondered for a while why GTK (both 2 and 3) seem so slow even on (relatively) powerful computers.

I’ve also wondered why stock Slackware is very responsive. And why it is equally slow to boot.

Turns out all those things are connected. GTK uses a cache file that helps it access icons. Keep the cache updated with gtk-update-icon-cache, and GTK wil be fast. Do not use the cache, and it will be slow.

Slackware solves this by running the cache updater on boot. Especially with Slack’s completely non-parallel init system, this slows things down a bit, but makes for a very response Xfce desktop.

Most other major distros. Don’t seem to deal with this. Debian and Fedora at least do not, and I’m pretty sure Ubuntu doesn’t either.

That’s reasonable for a DIY distro like Arch, or if you’re running a server without X. Otherwise, though, I have to wonder what gives, because users will definitely be left wondering why their desktop is slower than Windows 7 on the same hardware. Why not e.g. package a cache-updating script for desktop users, and run it as a daily cron job? Heck, why not package it as an initscript? Slackware’s initscripts do nothing in parallel, but most desktop distributions boot quite fast, and that shouldn’t be compromised by updating the icon caches.

Is there any particular reason why nobody (other than Pat Volkerding and company) does this as part of a default desktop setup? Other than that it doesn’t help KDE and Qt applications, perhaps?

#2 2012-05-07 03:17:40

Re: The GTK icon cache conspiracy

I just updated my cache, thanks to your recent post in the other thread.

Is this something that needs to be done every boot, or only when changing something (changing themes, adding new icons)?

#3 2012-05-07 03:27:43

Re: The GTK icon cache conspiracy

Only when changing or adding icon themes, AFAIK.

Edit: also, if you don’t have any cache files to start with, you probably need to use ‘gtk-update-icon-theme -f’ to force the generation of caches. Otherwise no new caches will be generated.

Last edited by Gullible Jones (2012-05-07 03:31:29)

#4 2012-05-07 03:31:57

Re: The GTK icon cache conspiracy

. GTK uses a cache file that helps it access icons. Keep the cache updated with gtk-update-icon-cache, and GTK wil be fast. Do not use the cache, and it will be slow.

. Is there any particular reason why nobody (other than Pat Volkerding and company) does this as part of a default desktop setup? ..

I’ve been wondering about this myself. I compile everything from source and my build scripts run namcap on every package that I generate. Namcap is smart enough to complain about packages that contain gtk icons and don’t call gtk-update-icon-cache (namcap seems to be pretty darn good). After reading GJ’s question I checked my build script and found that I’ve left myself this note:
# Quite some packages install icons in the hicolor icon theme.
# These packages should depend on hicolor-icon-theme and should have
# gtk-update-icon-cache -q -t -f usr/share/icons/hicolor (WITHOUT leading slash)
# in the post_install, post_upgrade and post_remove function.

I’ve been doing the cache update manually.

Does anyone know of a reason that the Arch packages do not have a call to gtk-update-icon-cache in a post_install function? Obviously our packagers see the namcap complaint when they check their packages so I suppose that there might be some reason for not doing the update as part of the install, but I don’t know of any reason to avoid it.

#5 2012-05-07 07:22:28

Re: The GTK icon cache conspiracy

Debian and Fedora at least do not, and I’m pretty sure Ubuntu doesn’t either.

Yes they do. Debian/Ubuntu do it via package manager hooks — not exactly sure how, but in Ubuntu I see it run. Edit: If my memory is not playing tricks on me, it gets deferred until the bundle of packages have been updated — which is quite neat.

With Arch: Do a git checkout of Arch packages. Then:

So which distros are you SURE of, that don’t run gtk-update-icon-cache?

Last edited by brebs (2012-05-07 07:27:36)

#6 2012-05-07 13:40:09

Re: The GTK icon cache conspiracy

The Fedora one you linked to only does it for the hicolor theme. It looks to me like that may be the only one that normally gets a cache created.

Last edited by Gullible Jones (2012-05-07 13:40:28)

#7 2012-05-07 14:05:09

Re: The GTK icon cache conspiracy

only does it for the hicolor theme

That’s the only one needed, the vast majority of the time. An exception is gnome-icon-theme:

#8 2012-05-07 14:46:25

Re: The GTK icon cache conspiracy

On my Arch system I grepped my local repo PKGCHECK files (output of namcap for the package) to find packages that seemed to lack the call to gtk-update-icon-theme:

It’s a fairly short list actually. Most Arch packages seem to update the cache properly:

Notice that namcap complained that gpodder and handbrake had «no call to gtk-update-icon-cache» but they do have the update in their install scripts, which their pkgbuilds fail to use properly

The funniest failure is the hicolor-icon-theme package itself: if fails to update the hicolor icon cache!

#9 2012-05-07 19:01:52

Re: The GTK icon cache conspiracy

Strange that you didn’t noticed this before. It must be that you use stronger pc than mine (1.7GHz 32bit from 2002 here with 512MB of ram at that time). Also, i developed many icons and sets in the past (i believe that none of them ever came online since i used them only localy). I will try to write something about this so you can understand much more about icons and how they work. My english is bad and i’m lazy to correct all errors so pay no attention to them

Cache helps to gather all info about sizes in icon sets and all other attributes (where to put arrows etc). Many people just install or extract icon sets and dont give a lot of thinking about set itself. The real problem is in type of images used for icons. You can get SVGs and make your set stretch in all sizes. In theory, that means that 32×32 set can be defined only once in icon set index and apply that to all sizes on your screen.

So what is the problem then? SVG’s looks better to develop and easier to manage. Well, the problem is that vector icons are drawn on your screen whenever you use them: when you start your file manager, when you get new message and icon in try changes or when you see new notification about XX program on your desktop. Here is cache coming to rescue. You can use it to reduce resource usage on your computer and therefore, the whole DE will be faster to load stuff on your screen.

Now, in gnome2 era, i used it for some time and i tested almost every release. I developed there and i tried to find out as much as i can about icons since i used them and i loved them (i still do). The problem with SVG sets was that there was no good developers who really understood the point of icon index files and icon development process. Tango set was the best thing that happened in that field. In short, Tango used raster icons in 16, 22, 24 and 32 sizes (sizes are in pixels). They left 48px version in SVG format thus they enabled for 48+ sizes to stretch to 512×512 if you wanted. They, however, limited sizes in index so they made 16px icons appeared only on places where 16×16 icons are supposed to show: in places where 16×16 icons have 16×16 space for icon. So, if sys tray had 16x16px space for icon, tango used (as defined in index) 16×16 version of icon and only that size. That is why Tango icons looked so crisp on well configured systems and DE’s.

The problem with sizes was in developers and their desire to draw pure SVG sets in only one size. So we got many sets with 48×48 vector format in that gnome2 era. By rules, you can use 48×48 vector or raster images for any size so 48px icon could be used for tray that can use only 16x16px icons. SVG enabled that and rules in indexes allowed us to mess up with all that. Today we got some amazing sets like elementary where developers actually learned about how to effectively create icons and how to make them small thus fast when you use them in DE’s. Back in the gnome2 era, we had a mess in this field. Then we got many forks of Tango, gnome-colors, erectus, gnome default set (latter, they used Tango guidelines) and other good sets that learned that sets can be very pleasant and fast.

The only thing that could speed up all this was to convert all images to raster ones. Raster icons allows you to use them and minimize sys resource usage and drawing process on screen. If you have slower pc, you can try to compare sets in vector and raster versions. Try older elementary set in SVG format and then convert all those icons to raster ones and try again. Raster set is faster? A lot? No wonder when you used fixed images and applied good rules in index of set. Your system now does not have to bother with rendering vector imags since you gave icons that:
— does not have to be rendered;
— are defined in index and therefore system will apply rules in certain cases.

Today great example of good set that uses all the goodies is Faenza. Faenza gives you smallest sizes in raster versions up to 48×48 sizes. Most people use 48×48 in file manager (nautils use them by default), 24×24 in toolbars and 16-24px icons in sys tray. So Faenza covered all popular sizes in raster versions.

So imagine what would happen if you use raster set with good index rules and with icon cache. I use icons this way for years and i had no slowdowns ever in any DE (have in mind that i’m reffering here to part of DE that is used for icon drawing on screen).

Источник

Кастомный LiveCD Ubuntu за 5 шагов / Ubuntu LiveCD Remastering

Предисловие

Последние года 3 я активный пользователь Linux. Мне нравится возможность полной настройки и экспериментов, которые позволяет эта система. Единственным неудобством, на мой взгляд, являлась невозможность сохранить свои изменения в сам LiveCD с системой. Это решалось послеустановочными скриптами, но хотелось сделать уже настроенную под себя систему прямиком в LiveCD. Потратив кучу времени, сил и нервов мне удалось реализовать эту цель. Далее постараюсь описать все шаги подробно, чтобы не оставлять «пустых» мест.

Я прикипел к дистрибутиву Lubuntu, на его примере и опишу кастомизацию, но вы можете использовать мои рекомендации для Debian, Ubuntu (любой редакции), Manjaro. На этих Linux мой алгоритм испробован с успехом. Вероятно с другими ОС он тоже сработает, но сам не проверял.

Шаг №0

Подготовим хостовую систему (у меня Lubuntu) для сборки кастомного LiveCD. Нам понадобится несколько дополнительных приложений.

Если у вас хостовая система Manjaro или Arch, вместо пакета isolinux установите syslinux

Шаг №1. Копирование файлов iso

Этот шаг до ужаса прост. Монтируем LiveCD, создаем каталог для копирования файлов и копируем.

Шаг №2. Распаковываем систему

После копирования файлов iso образа нам необходимо найти запакованную систему. В Ubuntu это файл filesystem.sqashfs, находящийся в папке casper. Этот файл — и есть вся операционная система, сжатая в «архив». В iso других ОС название и расположение файла может отличаться.

Шаг №3. Выполняем вход в систему и настраиваем ее

В папке rootfs у нас уже лежит операционная система. Теперь мы можем запустить ее в окружении chroot. По сути мы загружаем новую ОС в терминале, условно говоря. Если мы сейчас так и поступим, то все изменения нам придется вносить вручную. Вариант не лучший, на мой взгляд.

Предложу создать автоматизированный скрипт установки пакетов программ и настроек.

1. При настройке системы в chroot не рекомендую обновлять приложения (apt upgrade или pacman -Syu). Иначе придется возиться с настройкой нового ядра (точнее initramfs). Если умеете — в путь. Я предпочитаю не усложнять.

2. Чтобы перенести настроки рекомендую воспользоваться ленивым вариантом. Загружаетесь в нужной системе, можно даже в LiveCD. Выполняем настроки системы и приложений. После этого большинство из них можно найти в папке .config личного каталога пользователя. Просто находим файлы настроек приложений копируем их в любой каталог, я скопировал в каталог files. Туда же отправляем картинки, обои например, если вы их используете.

После «сбора» всех необходимых настроек, нам нужно знать куда их разместить. В Linux есть «чудо-католог» /etc/skel (от слова skeleton). Когда создается новый пользователь, файлы лежащие в этом каталоге будут закидываться в личную папку пользователя. Это нам и нужно. Просто создадим подкатологи /etc/skel/.config и другие если нам они нужны и скопируем настройки сюда. Таким образом, при создании любого пользователя в личную папку будут копироваться все наши настройки.

Далее собственно код с подробными комментариями.

Краткий комментарий к скрипту.

Чтобы не возиться с правами и владельцами файлов все настройки я переношу через следующую конструкцию: cat /files/файл-настроек | tee /etc/skel/.config/файл-настроек.

Все что написано между EOF . EOF передается цельным потоком в программу tee, которая все это записывает в файл.

Разумеется файл скрипта сокращен, полный вариант смотрите в моем GitHub, ссылка будет в конце статьи.

Вот и все. Далее соберем все обратно.

Шаг №4. Сжимаем кастомизированную систему

Когда мы внесли все необходимые изменения, можно собирать систему обратно в squashfs. Тут никаких хитростей. Удаляем filesystem.squashfs из папки с файлами iso и создаем новый.

Шаг №5. Собираем новый iso

ДОПОЛНЕНИЕ С УЧЕТОМ КОММЕНТАРИЕВ

Чтобы LiveCD работал без ошибок и сохранилась возможность установки с вашей сборки, необходимо обновить в исходных файлах iso сумму md5, файл filesystem.size и список установленных пакетов в файле filesystem.manifest.

Далее собираем образ iso.

Здесь есть одна тонкость. В зависимости от вашей хостовой системы путь к файлу isohdpfx.bin может отличаться. В Ubuntu он в каталоге /usr/lib/ISOLINUX, в Manjaro /usr/lib/syslinux/bios (если не ошибаюсь).

В коде ниже смените ISO_NAME во второй и предпоследней строках на свои названия вашей сборки.

По итогу вы получаете свой кастомизированный LiveCD Ubuntu за 5 шагов. Все приведенные выше коды собраны мной в скрипты, которые вы можете взять на github.

Источник