LINUX.ORG.RU

KDE Applications 19.12

 


1

0

🎆🎆🎆12 декабря вышла новая версия набора приложений проекта KDE! 🎆🎆🎆

Сначала — пара фраз об экспансии приложений KDE на другие платформы распространения. Так, в магазине приложений Microsoft Store появились Okular, Kate, KStars, Kile и FileLight. А количество пакетов Snap почти достигло сотни!

Ну, а теперь расскажем о самых заметных изменениях в некоторых приложениях KDE.

Менеджер файлов Dolphin

  • Переработан интерфейс встроенного поиска — он стал компактнее.
  • Также в новом интерфейсе недоступные опции поиска отображаются неактивными, а повторное нажатие кнопки поиска сворачивает его.
  • При нажатии и удержании кнопок «Назад» и «Вперёд» выпадает список с историей каталогов.
  • Попытка отмонтирования используемого раздела выводит предупреждение с названием «удерживающих» раздел программ.
  • В панели «Точки входа» (Places) плохо работавший пункт «Недавно сохранённые» заменён на пункты «Недавние папки» и «Недавние файлы».
  • Переделан облик панели инструментов в пользу большей лаконичности.
  • Поведение при клике на исполняемом файле можно выбрать из 3 вариантов: «запустить», «открыть в приложении», «всегда спрашивать».
  • Улучшена интеграция Git — в частности, отображение статусов файлов в больших репозиториях.
  • Ускорено открытие сетевых ресурсов благодаря локальному сохранению настроек отображения.
  • Исправлено отображение даты фотографирования в метаданных JPEG.
  • Информация о файле под курсором больше не исчезает из строки состояния через секунду.
  • Панель информации о файле теперь правильно показывает укороченные даты, в том числе и для метаданных.
  • Также она научилась показывать анимацию в миниатюрах для gif, webp и mng.
  • Кликом по миниатюре звукового или видеофайла на панели информации можно его воспроизвести, при этом на миниатюре появляется кнопка паузы.
  • Исправлены проблемы поведения фокуса в клавиатурной навигации.
  • Контекстное и инструментальное меню переработаны в пользу большей логичности и согласованности друг с другом.
  • Появилась опция сброса настройки масштабирования значков на значение по умолчанию.
  • При сортировке по меткам первыми отображаются файлы и папки с метками.
  • Исправлены недочёты при группировании файлов с кириллическими названиями.
  • Полностью цветные значки в окне настройки приложения.

Просмотрщик изображений Gwenview

  • Ускорена загрузка файлов с потенциально медленных сетевых ресурсов.
  • Исправлены проблемы при импорте фото с переименованием по шаблону со слэшами.
  • Также при импорте нужные каталоги создаются теперь автоматически.
  • Обрезка изображений по краю с сохранением пропорций больше не увеличивает область обрезки на 1 пиксель.
  • Единый интерфейс настройки качества сохраняемых JPEG для Gwenview и Spectacle.
  • Полностью цветные значки в окне настройки приложения.

Эмулятор терминала Konsole

  • Больше не оставляет после себя сотни и тысячи временных файлов в каталоге /tmp.
  • Исправлена проблема с перемещением фокуса на встраиваемый терминал после его закрытия и повторного открытия.
  • На вкладках снова отображается активность.
  • Новые вкладки при разделении окна (Split View) могут стартовать с адреса текущей вкладки.
  • Также починено перетаскивание между секциями на Wayland.
  • Полоса прокрутки стала работать нормально при запуске приложения вне KDE-окружения.
  • Диалог подтверждения закрытия нескольких вкладок можно отключить навсегда.
  • Опция использования случайного цвета для фона ориентируется на цвет текста для лучшей контрастности.
  • Убраны глюки отрисовки встраиваемых терминалов на 2 и более HiDPI-экранах.
  • Исправлены проблемы с восстановлением сеансов.
  • Закладки-дубли больше не создаются.

Просмотрщик документов Okular

  • Прокрутка документов стала инертной и плавной.
  • Настройки масштаба, режима отображения и боковой панели запоминаются для каждого файла отдельно.
  • Через контекстное меню можно найти повторы выделенного фрагмента текста в текущем документе.
  • Реализована поддержка комикс-формата CB7 (Dolphin также научился создавать миниатюры для этих файлов).
  • При рисовании стилусом в режиме презентации курсор мыши превращается в перекрестие в ответ на приближение стилуса к экрану.
  • Также убраны ненужные всплывающие подсказки и диалоги при приближении стилуса к экрану.
  • Улучшен диалог создания заметок: выводятся предупреждения об эксприментальных опциях, отображаются миниатюры прикрепляемых изображений.

Текстовый редактор Kate

  • Возвращена поддержка плагина «Внешние инструменты» (External Tools) для создания собственных скриптов обработки текста и файлов.
  • Используя «Внешние инструменты», можно создать новую панель кнопок с полностью настраиваемыми действиями.
  • Исправлены проблемы с сортировкой в обозревателе символов.
  • Модуль поиска и замены по регулярным выражениям обзавёлся встроенной памяткой.
  • Начальная поддержка языков Frotran и D для Language Server Protocol.
  • Исправлено падение при нажатии переназначенной на закрытие приложения клавиши Esc.
  • При выходе из окна настроек с неактивированными изменениями выводится предложение активировать или отменить их.

Другие изменения

  • Утилита для работы с камерами Kamoso получила новый интерфейс в стиле Kirigami.
  • Программа для создания снимков экрана Spectacle научилась сохранять снимки сразу после их создания.
  • Также можно включить опцию сохранения текущих снимков в буфер обмена.
  • А выделять отдельные области экрана для снимка стало намного проще и нагляднее.
  • Обновление коллекции в музыкальном плеере Elisa больше не порождает дублирующиеся записи.
  • Также в Elisa исправлена проблема с повтором одной выделенной песни.
  • Наконец, добавлена поддержка интернет-радио.
  • У видеоредактора Kdenlive кардинально снижено потребление оперативной памяти благодаря ряду мер.
  • Также он получил множество исправлений ошибок и улучшений интерфейса.
  • Исправления для HiDPI в Kate, Yakuake, Ark, Elisa и ряде других приложений.

Дополнительный источник: блог Нейта Грэхема

>>> Подробности

Deleted

Проверено: shell-script ()
Последнее исправление: Deleted (всего исправлений: 15)

Ответ на: комментарий от Deleted

тормозит люто на фоне pacman

Потому что ostree тот еще тормоз, просто вследствие принципа своей работы. Так быстро как простой распаковщик архивов оно работать не может.

curufinwe ★★★★★
()

Переделан облик панели инструментов в пользу большей лаконичности.

Да ладно! Кто-то занялся дизайном в KDE! Земля налетит на небесную ось!

Тред не читал, крики про гномоподобность уже были?

anonymous
()
Ответ на: комментарий от Deleted

Есть свои плюсы, как и минусы. Плюсы - дедупликация одинаковых файлов, что позволяет иметь несколько версий пакета одновременно и переключаться между ними по принципу гита, без лишнего расхода дискового места. Обновления дельтами, что позволяет не дробить все на 100500 мелких пакетов. Если флатпаковые рантаймы, которых ставится сразу несколько, имеют одинаковые файлы, то они тоже физически на диске не дублируются.

curufinwe ★★★★★
()
Ответ на: комментарий от ChekPuk

А вообще, если выбиратт между «нестандартными» пакетами, то я за аппимэдж. Он могет всё что мне нужно. А остальное выкинуть, потому что это не гонка технологий, а война редхата и каноникла

Лучше всех троих расстрелять. Такая хуйня не должна жить.

anonymous
()
Ответ на: комментарий от anonymous

Лучше всех троих расстрелять. Такая хуйня не должна жить.

Ты про себя и своих предков чтоль? Согласен.

anonymous
()
Ответ на: комментарий от insw

Спасибо за разъяснение, а то моё предположение о поддержке языков как средства написания плагинов меня самого настораживало.

grem ★★★★★
()
Ответ на: комментарий от Ivan_qrt

Глупости какие-то. Ничто в пакмане не мешает создать пакет (и поддерживать его в автоматическом или полуавтоматическом или ручном режиме). Пакман просто следует указаниям сборки и контроля. Это делает его простым в использовании? Да! Но никак не примитивным. С точки зрения установки и обслуживания пакета как раз флатпак примитивен. А весь остальной его функционал - лишь попытки сделать бардак из натасканых с помойки, практически виртуалок, более безопасным от васяномайнинга. Разница для тебя, пользователя в обоих состоит лишь в том, что ты думаешь, что флатпак, это манна небесная, ты не видишь как создаются пакеты и для тебя это все «простаработаит». Единственный плюс - флатпак универсален (там где можно поставить флатпак). Но даже этот плюс лишь попытка усидеть на всех стульях. Тьфу на флатпак!

ChekPuk ★★★
()
Ответ на: комментарий от curufinwe

Вот ты человек умный, знающий, вот скажи, какое приложение тебе понадобилось в нескольких версиях? Я только слышу об этом как о мегафиче, но кроме Блендера 2.7 и 2.8 не могу придумать. И то, могу без флатпака оба поставить. Опять же, если мне нужно жёстко зафиксированное приложение, зачем мне его делтаобновленмями обновлять? Смысл происходящего можешь мне разложить на пальцах?

ChekPuk ★★★
()
Ответ на: комментарий от anonymous

Кто-то занялся дизайном в KDE!

Возможно, для тебя будет новостью, но разработчики KDE целенаправленно взяли в команду UI/UX-дизайнеров, чтобы те занимались конкретно им и ничем иным. Т.е. этому вопросу среди прочих так же стали уделять приоритетное внимание и уделять не силами программистов, которые хорошо (или нет) пишут код, но не всегда (зачастую, никогда) не умеют в дизайн, а силами профессионалов конкретно в дизайне.

anonymous
()

Менеджер файлов Dolphin … Панель информации о файле теперь правильно показывает укороченные даты, в том числе и для метаданных. Также она научилась показывать анимацию в миниатюрах для gif, webp и mng.

Это вызывало самые большие упреки, в уменьшении безопасности, среди бывших пользователей KDE.

Класический пример этого жанра:

Смонтировали флешку с опциями nodev,noexec,nosuid, на флешке фотки, одна заражена вирусом. В системе есть уязвимая библиотека для обработки графических форматов (обыденная ситуация), которую использует файловый менеджер Dolphin, для отображения миниатюр. Допустим, что пользователю, даже сказали, какая фотография вирусная, чтобы он ее не открывал. Пользователь только открыл в Dolphin католог где находится вирусное фото …. и доблесный файловый менеджер Dolphin сразу создал миниатюру с вирусной фотки, используя при этом уязвимую графическую библиотеку!!!

Какие планы в команды KDE по увеличению надежности и безопасности их DE?

А может хоть что-то уже сделано в плане безопасности KDE?

anonymous
()
Ответ на: комментарий от ChekPuk

какое приложение тебе понадобилось в нескольких версиях?

В основном это нужно для быстрого отката неудачного обновления, либо во время разработки может понадобится, например версию тулчейна, IDE менять или что-то типа того. Лично мне пока не сильно нужно, я все это ковыряю из технического интереса, чтобы оценить его перспективы и насколько это надо вообще.

И то, могу без флатпака оба поставить.

Без флатпака можно вообще что угодно сделать, вопрос только что удобнее и кому.

Опять же, если мне нужно жёстко зафиксированное приложение, зачем мне его делтаобновлениями обновлять?

Во флатпаке каждый пакет имеет одну зависимость - рантайм. А в нем кучу все библиотеки системные свалены. Обновлять его без дельт крайне проблематично было бы. А другой вариант - разрезать его на 100500 мелких пакетов с деревом зависимостей, что свои минусы имеет и есть уже и так в стандартных пакетных системах.

То есть за счет дельт можно иметь один жирнющий пакет с библиотеками вместо 100500 мелких и не иметь головной боли с развесистыми деревьями зависимостей.

И все это надо рассматривать применительно к системе типа Silverblue, где вся «хостовая» система тоже сидит в ostree и обновляется как один большой пакет.

Я проводил эксперименты с засовыванием Arch Linux с KDE в ostree, и построением на этой основе системы типа Silverblue. В целом это делается весьма просто, но возникло непреодолимое пока препятствие - ostree не хранит timestamps, метки времени файлов, а ставит все даты создания всех файлов на 1 января 1970 года. От этого у плазмы съезжает крыша, и ничего нормально не работает. Гном видимо как-то пофиксили, а KDE в такой среде пока не работает.

curufinwe ★★★★★
()
Ответ на: комментарий от ChekPuk

В целом, я пока так и не понял, что перевешивает - плюсы или минусы.

Пока к однозначным плюсам могу отнести только:

  1. Возможность для разработчика собрать свое приложение сразу под любой линукс, без выноса мозга. А это дает дорогу официальным версиям от разработчика, например я так ставлю LibreOffice с тех пор как он в репах Арча тупо сломан был.

  2. Независимость от обновлений самой системы. Установленное из AUR приложение может просто не запуститься в любой момент. Когда обновится библиотека. И происходит это у меня в самый неподходящий момент. Вот был случай, даже tubeAmp внезапно перестал запускаться. И тогда надо копать, какая библиотека все ломает и пересобирать. Флатпак же решает радикально эту проблему. Если приложение установлено, оно будет работать всегда.

curufinwe ★★★★★
()
Ответ на: комментарий от curufinwe

Я хотел запилить аналогичное решение, но без всяких тормозных ostree. Только для этого нужны жёсткие ссылки на каталоги, чего ядро не умеет((

Deleted
()
Ответ на: комментарий от Deleted

А почему, никак нельзя обойтись без жестких ссылок на каталоги? Я помню твой тред, только не помню уже суть идеи. И почему-то я ее тогда не поддерживал, может я просто не так понял.

curufinwe ★★★★★
()
Ответ на: комментарий от curufinwe

никак нельзя обойтись без жестких ссылок на каталоги?

Нэт. Если без них - начинается вакханалия с симлинками, которые нужно будет создавать десятками тысяч на типовой системе. Это тормоза и потенциальные глюки, плюс меньшая прозрачность и функциональность.

Если бы кто-то запилил патч для ядра, реализующий хардлинки для каталогов, я бы запилил потихоньку прототип своего nextgen-ПМ, посмотрели бы что вышло)

Deleted
()
Последнее исправление: Deleted (всего исправлений: 2)
Ответ на: комментарий от Deleted

Так можно же настоящие каталоги создавать, а внутрь файлы хардлинками, как ostree делает. И воссоздание всей структуры системы из репозитория у него занимает при этом секунд 10, на моем тормозном HDD.

curufinwe ★★★★★
()
Ответ на: комментарий от curufinwe

Так можно же настоящие каталоги создавать, а внутрь файлы хардлинками

Сорян, я хардлинки на файлы и имел в виду в комменте выше. Не симлинки, а хардлинки.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Сами хардлинки не тормозят, и есть особо не просят. Только вот этот подход, когда один «физический» файл подключается сразу в несколько альтернативных мест, требует чтобы была запрещена модификация файлов, иначе изменение в одном месте поломает все другое.

А обновлять немодифицируемую систему так же просто и быстро как это делается, например, в Арче (выбросили все файлы старого пакета, добавили все файлы нового), не получится уже.

curufinwe ★★★★★
()
Ответ на: комментарий от curufinwe

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

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Это похоже, с некоторыми небольшими отличиями, на NixOS, насколько я понял? Но правда там версии зафиксированы, как в РБ говорят, жэстачайшэ.

Тогда вопрос - а почему нужны именно хардлинки на каталоги, и не проканают симлинки на каталоги?

curufinwe ★★★★★
()
Ответ на: комментарий от curufinwe

Уот: Человеческое управление пакетами в Linux

Но это прежняя версия, я потихоньку подпиливаю концепцию, чтобы переход не требовал лишних движений мантейнеров и пользователя.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Спасибо, нашел там ответ на вопрос, почему не канают симлинки.

curufinwe ★★★★★
()
Ответ на: комментарий от Deleted

Только для этого нужны жёсткие ссылки на каталоги, чего ядро не умеет((

Умеет, но совсем чуть-чуть: элементы . и .. являются жёсткими ссылками на текущий и родительский каталоги, и иных жёстких ссылок на каталоги не разрешается.

Действительно, куда должен ссылаться элемент .. в случае нескольких жёстких ссылок на каталог? Ведь в таком случае у этого каталога есть более одного родительского, и дерево файлов перестаёт быть деревом. Другой пример: пусть в каталоге А есть жёсткая ссылка Б на А - куда указывает путь А/Б/..?

Это ещё и опасно: как удалять каталоги, если где-нибудь глубоко внутри в нём может быть жёсткая ссылка на, например, корень?

Есть некое подобие жёстких ссылок в виде mount --bind, но оно работает только в runtime, поскольку ядру приходится подставлять разные значения для .. корневого элемента поддерева.

Rootlexx ★★★★★
()
Последнее исправление: Rootlexx (всего исправлений: 1)
Ответ на: комментарий от Rootlexx

Я не спрашивал почему жёсткие ссылки для каталогов запрещены. Я только сказал, что мне нужны жёсткие ссылки на каталоги. Уж попутные проблемы я решу, благо эта функция мне нужна чисто для одной цели.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Я не спрашивал почему жёсткие ссылки для каталогов запрещены

Вы спрашивали в теме, ссылку на которую дали. Там толком не объяснили, поэтому решил написать.

Rootlexx ★★★★★
()
Ответ на: комментарий от Rootlexx

Насколько помню, там всё это упоминали. Вообще, не думаю, что это прям фатальный затык. Можно пораскидать мозгом и решить всё это.

Deleted
()
Ответ на: комментарий от Deleted

Вообще, не думаю, что это прям фатальный затык. Можно пораскидать мозгом и решить всё это.

Ну вот разработчики разных ОС пораскинули и решили «Ну его нафиг!». :) Попробуйте - если получится решить, будет замечательно.

Кстати, в описанной вами концепции есть ошибка:

При удалении пакета полностью удаляется его каталог со всеми deps-пакетами. Если они где-то используются - они остаются там. Если больше нигде не используются - удаляются вместе с пакетом. Такая автоматическая сборка мусора без лишних сущностей.

При удалении каталога deps-пакета будет произведён его рекурсивный обход и удаление всего его содержимого. Так что по второй жёсткой ссылке останется лишь совершенно пустой каталог.

Rootlexx ★★★★★
()
Ответ на: комментарий от ChekPuk

Ничто в пакмане не мешает создать пакет

Я и не говорил, что мешает. Проблема в том, что не помогает. В этом и примитивность.

Была, например, в недавнем прошлом показательная ситуация с libpng. Сменили api, и одним приложениям нужна старая версия, другим уже новая. И в рамках пакмана никак не решить эту проблему, кроме как руками прописывать, что старая версия будет лежать тут-то, новая в другом месте, а если при сборке в системе есть обе версии, то ещё и системе сборки указывать откуда брать правильную версию.

В дебиане это решают названиями пакетов и прописыванием зависимостей ручками. В арче, насколько я в курсе просто забили.

Или другой пример:

У тебя есть библиотеки, например кде-фреймворки. В твоём дистре ещё не обновились на новую версию, а ты хочешь потыкать апстрим какой-нибудь софтины (тот же kube). А ей для корректной работы нужны самые последние версии. И либо ты собираешь и обновляешь все кедолибы в своём дистре и получаешь кучу геморроя, либо стиснув зубы идёшь доказывать на форум, что пакман не примитивен, а флатпак не нужен. Приложуху, при этом, естественно, не ставишь.

Те же проблемы возникают при попытках установить старые не поддерживаемые приложения, хоть и реже.

С флатпаком такой херни нет как класса. Ты собираешь пакет под конкретный рантайм. Периодически обновляешь пакеты под новые рантаймы. Но то, какой рантайм ты используешь не зависит от того, какой рантайм используют другие приложения.

Я понимаю, что когда

ты не видишь как создаются пакеты и для тебя это все «простаработаит» не легко понять, сколько сложностей и ограничений у мейнтейнеров дистра, но может хотя бы попробуешь, прежде чем плеваться на всё вокруг?

ЗЫЖ Аппимэйдж флатпака хуже, т.к. он не умеет следить за обновлениями и на деле его переносимость сильно зависит от рук сборщика и окружения, в котором производилась сборка.

В общем-то нужность аппимэйджа сомнительна, т.к. от старого доброго собранного tar.xz он ушёл только в том, что распаковывать не надо.

Ivan_qrt ★★★★★
()
Ответ на: комментарий от Rootlexx

Так что по второй жёсткой ссылке останется лишь совершенно пустой каталог.

Чего это? Если несколько приложух используют libdep, то содержимое каталога libdep одинаково у всех экземпляров, и удаление одного экземпляра ничего не сделает с остальными, вплоть до последнего удаления.

Deleted
()
Ответ на: комментарий от Deleted

Для всего? Или только для libpng и ещё нескольких исключений? В дебиане, если не для всего, то для очень многого.

Ivan_qrt ★★★★★
()
Ответ на: комментарий от Deleted

Чего это? Если несколько приложух используют libdep, то содержимое каталога libdep одинаково у всех экземпляров, и удаление одного экземпляра ничего не сделает с остальными, вплоть до последнего удаления.

Ну хорошо, вот есть у нас каталог:

A/
    F1
    F2
    D1/
        F3
    D2/
        F4

Пусть Б - жёсткая ссылка на А, т.е. оба ссылаются на один и тот же inode N.

Удаляем файлы F1 и F2. Это означает, что удаляются жёсткие ссылки на них из каталога А, т.е. из каталога по inode N. А поскольку Б ссылается на А (читай на тот же inode, что и А), их содержимое идентично, и эти файлы пропадут и из каталога Б. (Если предположить иное, то в каталогах А и Б будем иметь различное содержимое, что противоречит самой идее жёсткой ссылки.)

Rootlexx ★★★★★
()
Ответ на: комментарий от Deleted

Ну под забили я это и имел ввиду. Понятно, что где надо костыли подставлены. Дистр-то работает.

Ivan_qrt ★★★★★
()
Ответ на: комментарий от Rootlexx

Удаляем файлы F1 и F2

Зачем? Это эквивалентно удалению зависимости нескольких установленных пакетов, т.е. ты намеренно ломаешь систему.

Deleted
()
Ответ на: комментарий от Rootlexx

Какой именно каталог? Ты удаляешь deps-каталоги при остающемся родительском приложении, т.е. ломаешь зависимости. Это всё равно что сейчас ты удалишь, например, glibc из системы. Я не говорил, что моя система гарантирует защиту от выстрела себе в ногу) хотя, в принципе, можно и на этот счёт подумать

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Какой именно каталог? Ты удаляешь deps-каталоги при остающемся родительском приложении

При удалении пакета полностью удаляется его каталог со всеми deps-пакетами

Rootlexx ★★★★★
()
Ответ на: комментарий от Deleted

В этом сценарии удаляется каталог А, а не F1 и F2

А как вы собрались удалить каталог, не удаляя его содержимое?

Без обид, но похоже, вы немного «плаваете» в теме.

Rootlexx ★★★★★
()
Ответ на: комментарий от Deleted

Ответы выше.

Не вижу ответа на вопрос «А как вы собрались удалить каталог, не удаляя его содержимое?»

Напоминаю, что просто имя каталога - уже жёсткая ссылка на оный. Как происходит удаление каталога, вы, полагаю, понимаете.

Вам здесь поможет разве что ФС с CoW и дедупликацией.

Rootlexx ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.