Что касается класса "оболочка дешевая к mkisofs и cdrecord" я не понимаю, а нафига вообще нужен этот класс. Поэтому лучшее оно или худшее в своем классе - оно нафиг не нужно.
С digicam - вопрос более интересный. Не исключаю того, что приложение, умеющее быстренько посмотреть что там в фотоаппарате валяется на флэшке, имеет свою нишу не только среди людей, которые решают любую задачу посредством "а ну-ка погуглим какие программы на эту тему понаписаны". Но если digicam лучшее в этом классе, то пользоваться программами этого класса не стоит.
Кстати, есть подозрение что сделать действительно вменяемую программу этого класса невозможно без поддержки со стороны софта фотоаппарата. Потому что как ни крути, передаваться по USB полноразмерные картинки будут недопустимо медленно для GUI.
"Оболочка" тупо удобнее, чем куча ключей. Особенно в случае, если пишешь от случая к случаю. Да и вариант "записать пять альбомов из разных мест" мне удобнее путём их перетаскивания в одно, а не набором в строке кучи путей. Хотя дело вкуса, конечно.
Digikam это не "умеющее быстренько посмотреть что там в фотоаппарате валяется на флэшке" - для этого хватает чего угодно. Это программа ведения базы фотографий. Ну Picasa гугшовскую видели? Оттуда же. Плюс showfoto (который и отдельным проектом идёт) на мой взгляд самый удобный редактор для правки фотографий. Хотя, конечно, imagemagick может всё то же самое, небось ;-)
Я, кстати, ещё Amarok забыл.
P.S. А вопрос про KDE4 возник в связи с его приползанием в testing, черти бы его взяли совсем :-(
По-моему, для ведения базы фотографий НЕ МОЖЕТ существовать лучшего решения на все случаи жизни. Даже если размер дистрибутива этого решения будет сравним с размером дистрибутива Microsoft office.
Слишком разные у разных людей подходы к этой задаче. При этом задача сильно связана с другими задачами хранения информации. Не исключено, что для кого-то лучшим способом ведения базы окажется блог, например.
То же самое касается задачи записи сидюка от случая к случаю. Идеальным решением было бы вообще не выделять эту задачу из прочих задач манипулирования файлами. Кстати, coreutils + growisofs на мой взгляд к этому решению максимально близки. При условии что для манипулирования файлами привычно использовать именно coreutils. Если нет, то функция записи должна встраиваться в привычный инструмент манипулирования файлами, а не представлять собой отдельную программу.
Ок, не "лучшее", а "одно из лучших", поэтому на мой взгляд неосомтрительно выкидывать его из рассмотрения.
С записью - не уверен. В смысле, я не уверен, что "встроенный" вариант задачи "записать пять папок из разных мест + девять из десяти файлов из шестой на CD" будет удобнее "внешнего". При условии, конечно, что я не использую "для манипулирования файлами именно coreutils" всегда.
Да и, к примеру, пункт в контекстном меню "записать на диск" для папки вообще не понятно какой "внешний" или "внутренний" :-)
В любом случае, то, что сами KDE/Gnome (особоенно KDE4) как минимум "странные" системы, не говорит о том, что _все_ программы, написанные с использованием их библиотек являются такими же странными :-)
P.S. А то ещё kopete есть. По сравнению с тем же gaim'ом - удобнейшая программа. Да, я не могу отказаться от ICQ по не завичящим от меня причинам.
С записью - не уверен. В смысле, я не уверен, что "встроенный" вариант задачи "записать пять папок из разных мест + девять из десяти файлов из шестой на CD" будет удобнее "внешнего". Помнится, даже в таком ублюдочном fm, как mc были всякие средства для создания виртуальных панелей. Вот собрать "пять папок из разных мест и девять файлов из шестой" на виртуальную панель файлменеджера, а потом её записать - это концептуально целостное интерфейсное решение в рамках концепции файл-менеджера. Причем, что характерно, если встанет задача "записать то же самое на флэшку" или "заархивировать в zip", содержательно это будут в основном те же самые действия, отличающиеся только последней командой.
Да и, к примеру, пункт в контекстном меню "записать на диск" для папки вообще не понятно какой "внешний" или "внутренний" :-)
С точки зрения интерфейса - несомненно внутренний. P.S. А то ещё kopete есть. По сравнению с тем же gaim'ом - удобнейшая программа
Ну это из серии "в G еще хуже чем K".
Вопрос в том, почему люди так настаивают на том, что поддержка левых проприетарных протоколов должна быть в клиенте? Есть же pyicqt. И прекрасно работает.
Я бы вас сам забанил только за эту фразу. Курсовой немецкого студента по недоразумению оказавшийся в production-использовании. При наличии 1000 единовременных пользователей у транспорта - живёт не более суток, потом умирает и убивает ejabberd по дороге. Memory leaks однако, что особенно приятно вычёсывать из питоновского рантайма.
Годится только для маленьких карманных серверов.
Держу на сервере только из за большой пользовательской базы icq и потребности в нём юзеров.
> Вопрос в том, почему люди так настаивают на том, что поддержка левых проприетарных протоколов должна быть в клиент? Есть же pyicqt. И прекрасно работает.
Ну, допустим, pyicqt. А чем к оному коннектиться? Чтобы удобно и комфортно общаться было. В больших объёмах, в нескольких чатах одновременно, с людьми, у каждого из которых может быть с десяток разных контактов (в гуглтолке, в корпоративном жаббере, парочка-троечка разных личных жаббер-адресов...)
Искал несколько лет. Плюнул и остановился на том же Kopete. Не-жабберные эккаунты к нему сейчас не подключены вообще.
Слишком разные у разных людей подходы к этой задаче. При этом задача сильно связана с другими задачами хранения информации. Не исключено, что для кого-то лучшим способом ведения базы окажется блог, например.
Apache и PHP-движок, но не блог, а более "широкая" CMS/CMF. Видел такие заявления, и даже сам подумываю, - потому что ждать появления для этой задачи чего-то фунционально преображаемого и поддерживаемого на уровне Firefox - это долго и скучно, а PHP-движки уже научились тому, чего не умеют десктопные клиенты (и полнотекстовый поиск, и категоризация/таксономия, и теги, и закладки-переходы откуда куда нужно, и ссылки откуда куда хочешь, и свои подборки - делай не хочу).
Есть, правда, гибридные решения вроде Wikipad, но он меня не вдохновил.
Меня еще лет десять назад поражало, сколь много есть людей, готовых возиться со сложными web-интерфейсами, но не готовых изобразить простейший локальный GUI.
Хотя для задачи каталогизации фотографий это действительно вариант. В конце концов фотографии делаются для того, чтобы людям показывать. У меня тоже фотоархив живет в ~/public_html. Хотя вот php и вообще server-side скриптинга там нету.
Переходы по ссылкам, внутренним и внешним, - это в моем разумении больше, чем простейший GUI.
А работа с хорошим хранением информации ("подшивки", поиск, теги, дополнительные поля) начинает превращаться в работу с БД - вот и оказывается, что веб-движки, уже ориентированные на работу с БД, оказываются и хорошими инструментами для структурированного хранения, и GUI надо за ними наверстывать-догонять.
«Записать пять альбомов из разных мест» — это, на самом деле, типовой сценарий для программы архивирования файлов. И решаться должен, соответственно, через подключение mkisofs или функционального расширения оного как backend’а к любимой программе работы с архивами, будь то File Roller, Krusader, Midnight Commander или FAR.
Прекрасно. И какое "встроенное" решение Вы видите? Не важно, для архиватора или для записи на болванку. Мне кроме как "перетащить мышой это всё куда-нибудь" в голову не приходит.
В варианте одной папки - всё просто. Одна команда и не важно архивнуть или записать
Когда мне надо было надёжно качать по FTP много разных каталогов с разных серверов — я открывал файловый менеджер, умеющий FTP, и текстовый редактор; находил те каталоги, которые мне нужны; копировал через буфер их URL’ы в редактор; полученный файл скармливал wget’у. Или конвертировал его в формат, который можно подать на вход lftp.
Я не имею ничего против «перетащить мышой куда-нибудь» (хотя предпочитаю «выделить Insert’ом и нажать F5 куда-нибудь»). Но вот это «куда-нибудь» должно быть под руками и открываться единообразно независимо от того, что с этим будет делаться — решение о действии и способе действия принимается потом, когда объект действия уже сформирован.
Что касается класса "оболочка дешевая к mkisofs и cdrecord" я не понимаю, а нафига вообще нужен этот класс.
Не, Витус, тут смешнее. cdrecord аккуратно обрабатывает то ли буферизацию, то ли ошибки железа и дисков не портит. Но не умеет писать dvd (умеет, но только проприетарная версия под другим названием, которую мне своё время не удалось запустить, кстати). k3b, соответственно, наоборот (оно тупо пишет в /dev/sth).
Так года три назад было, по меньшей мере.
А оболочки дешёвые на баше надо писать. У меня такая была, помнишь, зело полезная вещь.
growisofs тоже вроде дисков не портит. В чем и прелесть встраивания писалок в CLI - ну не умеет cdrecord писать DVD, возьмем другую утилиту.
А оболочки дешёвые на баше надо писать. У меня такая была, помнишь, зело полезная Еще б к тому bash-у какой-нибудь GUI-тулкит прикрутить. Причем того же уровня абстракции что и сам bash... Tcl/Tk я последнее время считаю слишком низкоуровневым языком для casual scripting.
Для удобного писания оболочек дешевых, нужен прибамбас, который бы сам читал man (или хотя бы выдачу --help) и генерировал вменяемое диалоговое окно опций.
Для удобного писания оболочек дешевых, нужен прибамбас, который бы сам читал man (или хотя бы выдачу --help) и генерировал вменяемое диалоговое окно опций.
zsh'ский completion уже умеет такое. Башевский, подозреваю, тоже... Функция-то несложная, взял да написал...
Не, тут речь идет не столько о том, чтобы парсить --help, сколько о том, что к языку уровня shell нужен сравнимый по уровню GUI-тулкит. О том что шеллы без GUI уже умеют --help парсить, я в курсе.
А вот чтобы по результатам этого парсинга GUI нарисовать - задачка посложнее.
Tk - адекватен для языков уровня Tcl и perl. Shell - язык заметно более высокого уровня. В нем нету, к примеру, операции "открыть файл". Есть операция "переназначить вывод".
cdrecord как раз давно умеет (и у нее это давно уже не коммерческое). Не умеет wodim. Он же не умеет адекватно работать с железом, ну и k3b, пользующийся им, как следствие, тоже.
no subject
Date: 2009-06-01 06:08 am (UTC)P.S. Я так понимаю, теперь Вы на 4-е КДЕ обновились? ;-)
no subject
Date: 2009-06-01 08:20 am (UTC)Что касается класса "оболочка дешевая к mkisofs и cdrecord" я не понимаю, а нафига вообще нужен этот класс.
Поэтому лучшее оно или худшее в своем классе - оно нафиг не нужно.
С digicam - вопрос более интересный. Не исключаю того, что приложение, умеющее быстренько посмотреть что там в фотоаппарате валяется на флэшке, имеет свою нишу не только среди людей, которые решают любую задачу посредством "а ну-ка погуглим какие программы на эту тему понаписаны". Но если digicam лучшее в этом классе, то пользоваться программами этого класса не стоит.
Кстати, есть подозрение что сделать действительно вменяемую программу этого класса невозможно без поддержки со стороны софта фотоаппарата. Потому что как ни крути, передаваться по USB полноразмерные картинки будут недопустимо медленно для GUI.
no subject
Date: 2009-06-01 08:27 am (UTC)Digikam это не "умеющее быстренько посмотреть что там в фотоаппарате валяется на флэшке" - для этого хватает чего угодно. Это программа ведения базы фотографий. Ну Picasa гугшовскую видели? Оттуда же. Плюс showfoto (который и отдельным проектом идёт) на мой взгляд самый удобный редактор для правки фотографий. Хотя, конечно, imagemagick может всё то же самое, небось ;-)
Я, кстати, ещё Amarok забыл.
P.S. А вопрос про KDE4 возник в связи с его приползанием в testing, черти бы его взяли совсем :-(
no subject
Date: 2009-06-01 08:40 am (UTC)Даже если размер дистрибутива этого решения будет сравним с размером дистрибутива Microsoft office.
Слишком разные у разных людей подходы к этой задаче. При этом задача сильно связана с другими задачами хранения информации. Не исключено, что для кого-то лучшим способом ведения базы окажется блог, например.
То же самое касается задачи записи сидюка от случая к случаю. Идеальным решением было бы вообще не выделять эту задачу из прочих задач манипулирования файлами. Кстати, coreutils + growisofs на мой взгляд к этому решению максимально близки. При условии что для манипулирования файлами привычно использовать именно coreutils. Если нет, то функция записи должна встраиваться в привычный инструмент манипулирования файлами, а не представлять собой отдельную программу.
no subject
Date: 2009-06-01 08:48 am (UTC)С записью - не уверен. В смысле, я не уверен, что "встроенный" вариант задачи "записать пять папок из разных мест + девять из десяти файлов из шестой на CD" будет удобнее "внешнего". При условии, конечно, что я не использую "для манипулирования файлами именно coreutils" всегда.
Да и, к примеру, пункт в контекстном меню "записать на диск" для папки вообще не понятно какой "внешний" или "внутренний" :-)
В любом случае, то, что сами KDE/Gnome (особоенно KDE4) как минимум "странные" системы, не говорит о том, что _все_ программы, написанные с использованием их библиотек являются такими же странными :-)
P.S. А то ещё kopete есть. По сравнению с тем же gaim'ом - удобнейшая программа. Да, я не могу отказаться от ICQ по не завичящим от меня причинам.
no subject
Date: 2009-06-01 09:12 am (UTC)Помнится, даже в таком ублюдочном fm, как mc были всякие средства для создания виртуальных панелей. Вот собрать "пять папок из разных мест и девять файлов из шестой" на виртуальную панель файлменеджера, а потом её записать - это концептуально целостное интерфейсное решение в рамках концепции файл-менеджера. Причем, что характерно, если встанет задача "записать то же самое на флэшку" или "заархивировать в zip", содержательно это будут в основном те же самые действия, отличающиеся только последней командой.
С точки зрения интерфейса - несомненно внутренний.
Ну это из серии "в G еще хуже чем K".
Вопрос в том, почему люди так настаивают на том, что поддержка левых проприетарных протоколов должна быть в клиенте? Есть же pyicqt. И прекрасно работает.
no subject
Date: 2009-06-01 09:14 am (UTC)Прямое решение. Особенно если учесть, что у меня icq контактов за сотню точно, а jabber'х - десятка полтора.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2009-06-01 09:49 am (UTC)Я бы вас сам забанил только за эту фразу. Курсовой немецкого студента по недоразумению оказавшийся в production-использовании. При наличии 1000 единовременных пользователей у транспорта - живёт не более суток, потом умирает и убивает ejabberd по дороге. Memory leaks однако, что особенно приятно вычёсывать из питоновского рантайма.
Годится только для маленьких карманных серверов.
Держу на сервере только из за большой пользовательской базы icq и потребности в нём юзеров.
(no subject)
From:no subject
Date: 2009-06-01 10:05 am (UTC)Ну, допустим, pyicqt. А чем к оному коннектиться? Чтобы удобно и комфортно общаться было. В больших объёмах, в нескольких чатах одновременно, с людьми, у каждого из которых может быть с десяток разных контактов (в гуглтолке, в корпоративном жаббере, парочка-троечка разных личных жаббер-адресов...)
Искал несколько лет. Плюнул и остановился на том же Kopete. Не-жабберные эккаунты к нему сейчас не подключены вообще.
no subject
Date: 2009-06-01 09:58 am (UTC)Apache и PHP-движок, но не блог, а более "широкая" CMS/CMF. Видел такие заявления, и даже сам подумываю, - потому что ждать появления для этой задачи чего-то фунционально преображаемого и поддерживаемого на уровне Firefox - это долго и скучно, а PHP-движки уже научились тому, чего не умеют десктопные клиенты (и полнотекстовый поиск, и категоризация/таксономия, и теги, и закладки-переходы откуда куда нужно, и ссылки откуда куда хочешь, и свои подборки - делай не хочу).
Есть, правда, гибридные решения вроде Wikipad, но он меня не вдохновил.
no subject
Date: 2009-06-01 10:04 am (UTC)Хотя для задачи каталогизации фотографий это действительно вариант. В конце концов фотографии делаются для того, чтобы людям показывать. У меня тоже фотоархив живет в ~/public_html. Хотя вот php и вообще server-side скриптинга там нету.
no subject
Date: 2009-06-01 10:53 am (UTC)А работа с хорошим хранением информации ("подшивки", поиск, теги, дополнительные поля) начинает превращаться в работу с БД - вот и оказывается, что веб-движки, уже ориентированные на работу с БД, оказываются и хорошими инструментами для структурированного хранения, и GUI надо за ними наверстывать-догонять.
no subject
Date: 2009-06-01 09:08 am (UTC)mkisofs
или функционального расширения оного как backend’а к любимой программе работы с архивами, будь то File Roller, Krusader, Midnight Commander или FAR.no subject
Date: 2009-06-01 09:12 am (UTC)В варианте одной папки - всё просто. Одна команда и не важно архивнуть или записать
no subject
Date: 2009-06-01 11:53 am (UTC)Когда мне надо было надёжно качать по FTP много разных каталогов с разных серверов — я открывал файловый менеджер, умеющий FTP, и текстовый редактор; находил те каталоги, которые мне нужны; копировал через буфер их URL’ы в редактор; полученный файл скармливал
wget
’у. Или конвертировал его в формат, который можно подать на входlftp
.Я не имею ничего против «перетащить мышой куда-нибудь» (хотя предпочитаю «выделить Insert’ом и нажать F5 куда-нибудь»). Но вот это «куда-нибудь» должно быть под руками и открываться единообразно независимо от того, что с этим будет делаться — решение о действии и способе действия принимается потом, когда объект действия уже сформирован.
no subject
Date: 2009-06-01 09:12 am (UTC)Не, Витус, тут смешнее. cdrecord аккуратно обрабатывает то ли буферизацию, то ли ошибки железа и дисков не портит. Но не умеет писать dvd (умеет, но только проприетарная версия под другим названием, которую мне своё время не удалось запустить, кстати). k3b, соответственно, наоборот (оно тупо пишет в /dev/sth).
Так года три назад было, по меньшей мере.
А оболочки дешёвые на баше надо писать. У меня такая была, помнишь, зело полезная вещь.
no subject
Date: 2009-06-01 09:15 am (UTC)Еще б к тому bash-у какой-нибудь GUI-тулкит прикрутить. Причем того же уровня абстракции что и сам bash... Tcl/Tk я последнее время считаю слишком низкоуровневым языком для casual scripting.
Для удобного писания оболочек дешевых, нужен прибамбас, который бы сам читал man (или хотя бы выдачу --help) и генерировал вменяемое диалоговое окно опций.
no subject
Date: 2009-06-01 09:45 am (UTC)zsh'ский completion уже умеет такое. Башевский, подозреваю, тоже... Функция-то несложная, взял да написал...
no subject
Date: 2009-06-01 09:46 am (UTC)no subject
Date: 2009-06-01 09:50 am (UTC)А вот чтобы по результатам этого парсинга GUI нарисовать - задачка посложнее.
Tk - адекватен для языков уровня Tcl и perl. Shell - язык заметно более высокого уровня. В нем нету, к примеру, операции "открыть файл". Есть операция "переназначить вывод".
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2009-06-01 09:44 am (UTC)no subject
Date: 2009-06-01 09:19 pm (UTC)а cdrecord и компанией я 10-к dvd-r испортил.
no subject
Date: 2009-06-01 10:01 am (UTC)no subject
Date: 2009-06-01 10:09 am (UTC)no subject
Date: 2009-06-01 02:11 pm (UTC)Одна проблема у него — платформа.