gqview http://gqview.sourceforge.net/view-shot.html

> интересно, почему отрисовка в Dolphin-е и крусаке тормозит на компе, на котором летала HL2? Наверное потому, что разрабы qtсофта как-то неправильно используют /dev/head и /dev/hands.

fixed for great justice

тулкитофобия со временем лечится

Ничего подобного. Чем дольше живу, тем отчетливее понимаю — нет ни одной нормальной программы на qt, которой можно просто пользоваться, и которая не выглядит новогодней елкой, из-за поналепленных куда ни попадя контролов, сомнительного предназначения. Более того, qt все сильнее и сильнее закрепляется на поприще тулкита для новичков, которые не смогли осилить gtk. Отсюда, уровень безблагодатности будет только расти.

смотрите сообщение, которое на 2 выше вашего ;)

ой, он на гтк сорри

>нет ни одной нормальной программы на qt, которой можно просто пользоваться, и которая не выглядит новогодней елкой

сходу - transmission-qt

Тулкит не виноват в криворуких разрабах

>интересно, почему отрисовка в Dolphin-е и крусаке тормозит на компе, на котором летала HL2?

мало ли, кривые видеодрова, тяжелая тема.

УМВР даже на p3 и атоме

Мне больше интересно, почему, например, в GTKшной трансмиссии зверски тормозит скроллинг. Особенно это заметно в списке файлов: прокрутишь чуть-чуть колесом — потом еще пару секунд ждешь, пока оно доползёт. Похожие тормоза наблюдаются и в наутилусе в режиме списка, и еще во многих программах на GTK. Ни в одной Qtшной программе я таких тормозов не видел.

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

>может это говорит о том, что gtk ведущий тулкит, а qt - догоняющий? :)
ну да, гтк отстает уже на целый круг и кутя его догоняет.

может это говорит о том, что gtk ведущий тулкит, а qt - догоняющий? :)

Скорее о том, что разработчики Qt подумали о том, что у пользователя уже может стоять Ubuntu (по дефолту с гномом) и им не сильно интересно, какой там тулкит у программы, а интересно, чтобы программы выглядели в едином стиле. Т.е. разработчики Qt подумали о пользователях, а разработчики GTK решили, что они и так #1, и о пользователях думать не надо.

> почему, например, в GTKшной трансмиссии зверски тормозит скроллинг. Особенно это заметно в списке файлов: прокрутишь чуть-чуть колесом — потом еще пару секунд ждешь, пока оно доползёт. Похожие тормоза наблюдаются и в наутилусе в режиме списка, и еще во многих программах на GTK.

Не знаю, что там накодили в трансмиссии, а что касается наутилуса, то радиус кривидны рук разработчиков гнома общеизвестен. Но судя по:

прокрутишь чуть-чуть колесом — потом еще пару секунд ждешь, пока оно доползёт

— может плавная прокрутка глючит?

Открыл вот щас в pcmanfm каталог с 4500 подкаталогами — ничего не тормозит. Ни в режиме иконок, ни в режиме таблицы.

>Кстати, кто-нибудь нормально может объяснить, что нужно собственно от KDE всем этим программам вроде Krusader,
в кделибс содержатся обертки для практически всех стандартных куте-контролов, эти оберкти значительно расширяют функционал и очень удобны для пользователей и разработчиков, например известный диалог открытия файлов (который по дефолту содержит больше функционала чем целый ФМ nautilus), работа с сессиями, сохранение настроек, диалог «о программе», шорткаты, локализация, однообразное и дефолтное меню. Если это все отвязывать от кде, то автору придется городить велосипеды, а это не линукс вей и требует мотивации и трудозатрат.

И вообще начать нужно с того что любое кде приложение начинается с класса KApplication.

ты запятую пропустил :)
у меня zsh пока в «dual-shell» ) на поиграться, mc используется все реже.

> может плавная прокрутка глючит?

Нет, плавная прокрутка не при чем. Для наглядности можно даже колесом пару раз быстро-быстро повозить туда-сюда, а потом остановиться и наблюдать за тем, как список еще секунд 5 будет медленно и размеренно ползать вверх-вниз. На нетбуке это особенно заметно.

Открыл вот щас в pcmanfm каталог с 4500 подкаталогами — ничего не тормозит. Ни в режиме иконок, ни в режиме таблицы.

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

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

После устранения ШГ весьма доставляет. Спасибо!

Спасибо!

Давненько пользуюсь. Весьма удобный и лёгкий ФМ, легко настраиваемый и функциональный. Большое спасибо!

>> нет ни одной нормальной программы на qt

Неправда, по крайней мере часть Hedgewars — на Qt :)

>> Мне больше интересно, почему, например, в GTKшной трансмиссии зверски тормозит скроллинг. Особенно это заметно в списке файлов: прокрутишь чуть-чуть колесом — потом еще пару секунд ждешь, пока оно доползёт. Похожие тормоза наблюдаются и в наутилусе в режиме списка, и еще во многих программах на GTK.

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

O_O Зверь машина на 286-ом? Тестовая версия GTK 6.0? Параллельная вселенная? Одна догадка страшнее другой. Чинить вам надо что-то, уважаемый.

Нетбук EeePC 1000H. Попробуй включить подсветку вайтспейсов и открыть более-менее большой файл, а потом поскроллить. Это ж песец.

gtksourceview действительно ублюдочен.

Поставил gedit, но там такой опции нету. Поверю на слово.

Не знаю, чему там вообще в GTK можно тормозить. У меня только в Lenny субъективно чуть медленнее оно работало. И не думаю, что дело в процессоре, потому как нагрузка околонулевая :)

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

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

> Мне не жалко 200 метров на хорошую программу. Мне жалко 200 метров на тормозную поделку со свистелками, которая по ошибке почему-то называется тулкитом.

Мне не жалко 200метров на хороший тулкит. Мне жалко 200метров на очередной ФМ.

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

Можно пример реальной ситуации, когда вам требуется вручную разгребать сотни файлов? Ситуации «накачал в ~/downloads всякой фигни, и теперь жалко удалить» не рассматриваем.

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

> «накачал в ~/downloads всякой фигни, и теперь жалко удалить»

Кажется тут более запущенный случай - «накачал в ~/ всякой фигни и не знаю что с ней делать» :)

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

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

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

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

Это решается потребностями бизнеса а не понятиями админов этого сервера об минимализме,аскетизме и нужности.

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

И им конечно тоже хватит голого баша,да?

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

> Это решается потребностями бизнеса а не понятиями админов этого сервера об минимализме,аскетизме и нужности.

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

> Ох,вроде и прописные истины,но как же наивно звучит.Скажите,drull,вы работаете в коллективе? Никак не пойму почему банальщину всякую приходится объяснять.

Ты лучше объясни откуда может взяться несколько тысяч не сортированных файлов?

Если они откуда-то появились, то значит с организацией работы что-то не так.

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

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

Долго читал ваш спор, решил вклиниться. ))

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

> Простая ситуация - приехали из отпуска, на фотике несколько сотен фоток, и столькоже скинули на следующий день родственники. Какие осмысленные названия дает фотик сам знаеш. Все это дело нужно раскидать по событиям/датам, кое-что распечатать. Что предложиш?

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

1) cd /path/to/photo_dir
2) feh/xview *.jpg
3) ... Смотрим фотки за N-ое событие. Когда они кончаются и начинается N+1-ое событие:
4) for i in `seq <START_NUMBER> <END_NUMBER>`; do mv PHOTO$i.jpg /another/path/to/photo/N ; done;
5) Перейти к пункту 3

По датам компутер раскидает сам.

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

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

Срочно в отпуск! И куда-нибудь в деревню (там люди душевнее). ))
Это я к тому, что некоторые «даты» вспоминаются только после просмотра фотки.

В итоге от ручной сортировки все равно не уйти, и сортировать лучше до того, как фотки будут перемещены на пмж в нужное место. Для этого случая двухпанельник с превьюшками и F5/F6 подходит более всего. Но где такой найти?

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

(хотя спс за вариант, возьму на заметку)

Для этого случая двухпанельник с превьюшками и F5/F6 подходит более всего. Но где такой найти?

geeqie — ни в коем месте не двухпанельник, но средства для удобного растаскивания кучи фоток по разным каталогам там были предусмотрены. Может проще им воспользоваться?

> а) вперемешку (могут быть из разных источников, но на одну тему)

В любом случае операцию сортировки нужно будет выполнять для каждого источника отдельно.

Ладно, давай сойдемся на том, что для сортировки фоток нужно использовать специальный сотф, типа shotwell или digikam.

у фоток есть время создания (и в exif тоже) т.ч. раскидать их по папкам можно одной командой в баше а дальше уже mc и gqview ;)

Я пример с фотками привел потому, что он очень наглядный и почти каждый попадал в подобную ситуацию. На месте фоток может оказаться куча текстовых файлов, архивов и прочего хлама, или все вместе. И удобней всего (обычному хомячку) разгребать все это с помощью файлового менеджера. А уже из него вызывать нужные проги для нужных файлов. Да и обьяснить людям что для открытия нужного файла достаточно «тыцнуть вот в эту кнопочку» тоже гораздо проще чем городить костыли на каждый чих.

> На месте фоток может оказаться куча текстовых файлов, архивов и прочего хлама, или все вместе.

Хлам надо удалять. Или не доводить до того, чтобы он скапливался. Кроме того, группировку текстовых файлов можно процентов на 90% автоматизировать, а оставшееся и руками разобрать не проблема.

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

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

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

// может подскажет кто - как из тогоже feh отправить фотку на печать (желательно, чтоб с вызовом стандартного меню отправки на печать)?

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

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

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

Нужда в двухпанельниках сильно преувеличена свитчерами с винды, где TC является самым удобным средством для взаиможействия с файловой системой. В Linux bash + coreutils позволяют работать эффективнее, чем позволяет двухпанельник (если гонитесь именно за эффективностью).

Но тем не менее, да, хорошего двухпанельника под Linux нет.