Inkscape 1.0

переход на GTK3

Здравствуйте тормоза, огромные кнопки, убогие файловые диалоги и вырвиглазный вид.

А почему вообще никто не запилит адекватный форк дефолтной темы гтк3?
Неужели это так сложно?

А почему вообще никто не запилит адекватный форк дефолтной темы гтк3?

Потому-что есть адекватный гтк2

Не буду комментировать это.

Здравствуйте тормоза, огромные кнопки, убогие файловые диалоги и вырвиглазный вид.

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

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

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

а чего нет, самое то на карантине.

https://www.youtube.com/watch?v=5hNEaUp_LVY

…и дибильный диалог открытия файлов с рекурсивным поиском, где нельзя по первым буквам перейти на нужный файл.

Можно нажать Ctrl+L и начать вводить нужное имя. А вот как выполнить рекурсивный поиск в диалогах открытия файлов Qt?

Можно нажать Ctrl+L

можно. а можно и еще 20 действий выполнить. смысл-то в том, чтобы меньше нажатий совершать.

А вот как выполнить рекурсивный поиск в диалогах открытия файлов Qt?

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

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

Не реализовано - значит, не нужно, ага.

можно. а можно и еще 20 действий выполнить. смысл-то в том, чтобы меньше нажатий совершать.

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

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

вот так мы и узнали, что ты принадлежишь к группе массового пользователя.

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

- не побоюсь этого слова, элита

ну вот смотри, мы с тобой пришли к общему знаменателю:) я могу работать за компьютером быстрее и эффективнее, чем ты:)

Хоть я и редко пользуюсь поиском.

потому что ОС теперь сама запускает этот поиск:) за тебя. чем бы твой диск ни был занят, как только ты набираешь название файла, она начинает грузить твой диск еще больше:) потому что массовому пользователю иначе приходится включать голову.

ну вот смотри, мы с тобой пришли к общему знаменателю:) я могу работать за компьютером быстрее и эффективнее, чем ты:)

И этот вывод сделан на основе отношения к действию по умолчанию при наборе текста в диалоге открытия файла… Вы «особенный» - с этим не поспоришь.

потому что ОС теперь сама запускает этот поиск:) за тебя.

Ну да. Пишу я, значит, код - и тут ОС сама, без всякого моего участия, кааак запустит поиск!

Ну да. Пишу я, значит, код - и тут ОС сама, без всякого моего участия, кааак запустит поиск!

если ты это делаешь с использованием gtk3, то у тебя выбора нет.) RH не принял патч, чтобы сделать это поведение опциональным.

либо работать неэффективно (ctrl+l, да?). у меня на одной из систем еще и последняя рабочая папка не сохраняется, так что еще мышкой потыкать)

либо рекурсивный поиск...

если ты это делаешь с использованием gtk3, то у тебя выбора нет.)

Ну да. Чтобы понять разницу между просто набором текста и нажатием Ctrl+L и набором текста - это нужно быть элитой, никак не меньше.

либо работать неэффективно (ctrl+l, да?). у меня на одной из систем еще и последняя рабочая папка не сохраняется, так что еще мышкой потыкать)

либо рекурсивный поиск…

Ну разумеется. Одна общеизвестная комбинация клавиш - это жуть как неэффективно.

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

Одна общеизвестная комбинация клавиш - это жуть как неэффективно.

если использовать регулярно, то да.

А вот набирать

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

лучше посидеть подождать, пока система сама отыщет…

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

Целых полсекунды ожидания!

ты можешь это гарантировать? а как насчет 1-2 секунд? или 5-10? от чего это зависит, как ты думаешь? у меня даже на SSD это не отрабатывает за 0.5 секунды.

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

ты не поверишь... для тебя работа в shell, наверное, шоком окажется.

ты можешь это гарантировать?

Если используется механический жёсткий диск - нет. Но элита ведь может заработать на хороший рабочий SSD, правда?

ты не поверишь… для тебя работа в shell, наверное, шоком окажется.

Это точно! Сижу вот на удалённом узле, чиню библиотеку из-за глючного libmysqlclient - в полном шоке вообще!

Но элита ведь может заработать на хороший рабочий SSD, правда?

правда:) на дорогой, хороший интеловский SSD:) я только не понимаю, почему ты еще не додумался, что это от объема данных, по которым идет поиск, тоже зависит=)

чиню библиотеку из-за глючного libmysqlclient - в полном шоке вообще!

ну как починишь, давай сразу в привычный графический интерфейс (mac/windows)... киношечку и пивка... чтобы стресс, значит, снять.

правда:) на дорогой, хороший интеловский SSD:) я только не понимаю, почему ты еще не додумался, что это от объема данных, по которым идет поиск, тоже зависит=)

Ввод пользователя, каким бы он ни был, является одним из самых медленных источников данных. И утверждать, что вы наберёте путь к файлу в 10+ каталогах всегда быстрее, чем система прошуршит индекс на SSD - это надо быть очень «особенным». (Не говоря уже о том, что процесс набора имеет ещё более замедляющую его обратную связь - если, конечно, вы не помните наизусть всю иерархию до последнего листа.)

ну как починишь, давай сразу в привычный графический интерфейс (mac/windows)… киношечку и пивка… чтобы стресс, значит, снять.

Пивко не пью, а киношечку буду смотреть в видеоплеере, да. Куда уж нам, «массовым пользователям», до элиты, смотрящей кино с помощью aalib!

блаблаблабла. такие вот программисты и пишут потом софт, который тормозит.

блаблаблабла. такие вот программисты и пишут потом софт, который тормозит.

Как аргументированно, какой слог! Сразу видно элиту!

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

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

и пофигу на объемы! всегда значит, что мы захардкодим поведение в тулкит!

всегда значит, что мы захардкодим поведение в тулкит!

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

Но не вижу ничего неадекватного

давай так. произведи мне пожалуйста поиск минимум по 100Гб данных на твоем диске (без прогрева кеша, первый запуск) и покажи цифры.

time find ./ -name "*a*" | tail -n 3

точный размер папки тоже потом посмотришь, чтобы кеш не греть.

274,9 GB

real	0m1,022s
user	0m0,246s
sys	0m0,340s

кеш скорее всего. попробуй повторить, сначала «echo 3 > /proc/sys/vm/drop_caches»

Вот специально достал ноут с медленным SATA3 SSD:

aleksej@lenovo:~$ time find /etc /home /usr /var -name '*quer*' 2>/dev/null | tail -n 3
/var/lib/app-info/icons/debian-buster-main/48x48/gameconqueror_GameConqueror.png
/var/lib/app-info/icons/debian-bullseye-main/64x64/gameconqueror_GameConqueror.png
/var/lib/app-info/icons/debian-bullseye-main/48x48/gameconqueror_GameConqueror.png

real	0m1,166s
user	0m0,616s
sys	0m0,549s
aleksej@lenovo:~$ du -chs /etc /home /usr /var 2>/dev/null
5,5M	/etc
23G	/home
4,0G	/usr
2,2G	/var
29G	итого
aleksej@lenovo:~$ 

Не 100 ГБ - зато множество мелких файлов. Ну было бы 3 секунды - жуть-кошмар-кудабежать.

Ну было бы 3 секунды - жуть-кошмар-кудабежать.

ну я это понимаю так, что слив засчитан, обсуждать больше нечего. я (лично я) не подвисаю на открытии файла ни 3 секунды, ни 1 секунду. и мой ввод занимает меньше секунды. я так работаю. и заметь, никто не обязан ставить распоследний SSD, диск может быть занят другими задачами и т.д. поэтому я считаю, что с gtk3 и Gnome3 просто можно забыть о «линуксе, который быстрее, чем винда». фактически folnir прав. с такими требованиями проще использовать mac и windows, они давно рассчитаны на ленивого (и слабоумного?) пользователя и гораздо лучше удовлетворяют его нужды.

я (лично я) не подвисаю на открытии файла ни 3 секунды, ни 1 секунду. и мой ввод занимает меньше секунды

Ввод пути на всю глубину иерархии?

Замерьте как-нибудь ради интереса, сколько времени вам понадобится, чтобы добраться таким образом к файлу в 10+ каталогов ниже по дереву. И сравните с временем поиска по имени в поддереве на вашем быстром SSD от Intel, даже безо всяких индексов.

Или у вас помойка «всё в одном каталоге»?

ну я это понимаю так, что слив засчитан, обсуждать больше нечего

«Вы все ничего не понимаете!» - сказал он и прыгнул в открытую дверь, прежде чем кто-нибудь успел возразить.

с такими требованиями проще использовать mac и windows, они давно рассчитаны на слабоумного и ленивого пользователя и гораздо лучше удовлетворяют его нужды.

Честно говоря, смеяться над вашим снобизмом уже наскучило. Придумайте что-нибудь новенькое, что ли.

а ты и не можешь смеяться, после того, как твои 0.5 секунд превратились в 3.

Замерьте как-нибудь ради интереса

это не так работает. нет этой проблемы.

Что там у тебя подвисает? В текущем каталоге точное совпадение по названию ищется сразу без задержек, при наличии индекса и во вложенных за пару секунд. При этом первый результат это именно точное совпадение по названию в текущем каталоге, то же самое что и без поиска по вложенным каталогам. Но ты упорот, это уже и так ясно по предыдущим темам.

а ты и не можешь смеяться, после того, как твои 0.5 секунд превратились в 3.

3 секунды - это экстремальный вариант с поиском практически по всему разделу с кучей мелких файлов, включая кеши. Реалистичная задача:

aleksej@lenovo:~$ time find Документы/Работа/ -name '*query*' >/dev/null

real	0m0,033s
user	0m0,026s
sys	0m0,007s
aleksej@lenovo:~$ 

При этом:

aleksej@lenovo:~$ find Документы/Работа/ -name '*query*' -exec dirname '{}' \; -quit | wc -c
89
aleksej@lenovo:~$ 

Удачи быстро набрать такой путь даже с автодополнением.

они ссылаются на UE исследования

А эти UE исследования где-либо предоставлены? Их где-либо почитать можно?

я это взял из багзиллы. если просить почитать, то у них.

Inkscape 1.0 (комментарий)

Вложенность большая, а файлов, когда я тебя попросил, на 100Гб наскрести не смог.:( Я уж не стал тебе говорить, что у меня типичный датасет - пара терабайт. Ты просто компенсируешь бардак на диске и неумение думать процессорными мощностями. Я это и называю ленью и слабо-умием. А потом еще и выясняется, что ты еще и пишешь какой-то софт...:(

Вложенность большая, а файлов, когда я тебя попросил, на 100Гб наскрести не смог.:(

/facepalm

Скорость поиска по имени зависит не от суммарного размера файлов, а от их количества. Если у вас будет 5 файлов по 20 ГБ, а у меня - 1 000 000 файлов по 10 кБ, то поиск по вторым займёт больше времени, чем по первым, несмотря на меньший суммарный размер. Поэтому я и говорил о множестве мелких файлов в своём примере.

Удивительно, что приходится объяснять вам такие очевидные вещи…

Я уж не стал тебе говорить, что у меня типичный датасет - пара терабайт.

И какое же количество файлов в вашем датасете?

Ты просто компенсируешь бардак на диске

Высокий уровень вложенности (а значит, сильная иерархия) - это для вас показатель бардака? /facepalm

Что же тогда, по-вашему, не бардак - когда всё в одном каталоге?

и неумение думать

Я это и называю ленью и слабо-умием.

И это говорит человек, всерьёз делающий выводы об уровне интеллекта лишь из отношения к поведению по умолчанию в одном из интерфейсных диалогов одной из графических сред одной из операционных систем для одного из классов вычислительных машин…

ты малую вложенность «в одном из» продемонстрировал, всего 4 раза. это показатель ентелекта.

ты малую вложенность «в одном из» продемонстрировал, всего 4 раза

Где?

(Вы же не про /var, надеюсь?)

Скорость поиска по имени зависит не от суммарного размера файлов, а от их количества.

какая чушь. ты реально некомпетентен. и еще говоришь, что программист. начинаю скучать по intelfx. он одно время меня огорчал, но скоро стало ясно, что это временно. он по крайне мере прикинет механику под капотом.

следи за руками:

echo 3 > /proc/sys/vm/drop_caches;
time find /somedir/ -name "*a*" | tail -n 3

real	0m9.899s
user	0m0.059s
sys	0m0.234s
echo 3 > /proc/sys/vm/drop_caches;
time find /anotherdir/ -name "*a*" | tail -n 3

real	0m10.307s
user	0m0.212s
sys	0m0.643s

find /somedir/ | wc -l
6186

find /anotherdir/ | wc -l
37123

anotherdir - маленькие файлы, уровень вложенности совпадает.

Все, короче, завязывай:( Чем дальше мы переписываемся, тем все становится очевиднее. Это уже не имеет смысла.

какая чушь. ты реально некомпетентен.

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

Да будет вамтебе известно, что для поиска по имени сами файлы даже открывать не потребуется, поскольку вся необходимая информация хранится в каталогах, а значит, размер этих самых файлов не имеет никакого значения. Что же до каталогов, то для поиска по имени необходимо из этих каталогов прочитать записи об элементах (например, с помощью readdir(3)) и отфильтровать их, скорость чего напрямую зависит от количества этих самых элементов.

следи за руками:

sys 0m0.234s

sys 0m0.643s

Всё верно. А вот что ты там нарукоблудил, и что find делал всё оставшееся время, при том что user тоже мал, - разбирайся сам. И я, и fornlr свои выводы привели.

и еще говоришь, что программист

Интересно, написал ли ты в своей жизни что-нибудь сложнее HelloWorld?..

Чем дальше мы переписываемся, тем все становится очевиднее.

Это точно.

для поиска по имени сами файлы даже открывать не потребуется, поскольку вся необходимая информация хранится

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

Библиотека Pango отказалась от мягкого сглаживания шрифтов (hintfull) (комментарий)

если что ты это написал специалисту по high-load системам с примерно десятилетним стажем

Грустно, что такой многоопытный специалист оценивает скорость поиска по имени исходя из суммарного размера файлов.

Пока что вы самовыданных авансов не оправдываете.

И ещё раз спрошу: вы в своей жизни хоть что-нибудь сложнее HelloWorld на том же C написали?

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

Гадание об опыте и квалификации оппонента и такая смешная попытка их принизить - черты настоящего специалиста, да-да.

А ваши гонор, снобизм и хамство выдают в вас постоянного обитателя локального максимума кривой Даннинга-Крюгера.

а пока вот по теме хороший коммент

О-о-о, ну раз Midael так сказал - это в корне меняет дело! (нет)

Ещё раз:

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

   Я вам уже предлагал засечь время, за которое вы сможете добраться до файла на глубине в, пускай, 8 каталогов. А это даже не предел:

aleksej@lenovo:~/Документы/Работа$ find -type f | while read path; do delims="${path//[^\/]}"; echo ${#delims}; done | sort -nr | head
12
12
10
10
10
10
10
10
10
10

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

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

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