Вышел менеджер закачек Steadyflow 0.1

> Зачем вообще в гноме калькулятор - есть же баш? echo $[] и всё ;-)

Обычный кроссплатформенный программер способен, сцуко, так избаловаться Tortoise SVNом, что попав в консоль целевой платформы делает FFUUU^W обиженное лицо и задает дурацкие вопросы «как вкомитить N-файлов в разных папках». То что у него под руками еще один вполне себе язык программирования, позволяющий делать то же самое и еще кучу всего, почему-то в сознании не откладывается даже в виде подозрения, а при виде пункта «Subversion» в контекстной менюшке KDevelop - ога, вострорг и тонны щастья. Так что не в юзерах убунты дело, а в довлении привычек: «Хочу мышкой и кнопку „сделать заебись!“ А если ее нет, то драма.

Хмм, резонно. Ладно, пусть тогда шлют патчи.

Было бы лучше если бы был какой-то план, навроде «to do». Тогда другие люди бы смогли взяться за понравившеяся им дело.

пруф?

И чего вы так на хабр все взъерошились?

А багтрекер на что? :) Хотя, когда народ немного отойдёт и поток багов и фичреквестов кончится, составлю, наверное, blueprint на релиз 0.2.

пруф?

http://live.gnome.org/GnomeGoals/GSettingsMigration

Интерфейс трансмиссии божественен

+1

делающего упор на удобство пользователя и минимализм.

Очень важно для программы, которая что-то качает иметь режим работы в виде демона. Умеет?

Кстати, есть хорошая архитектура

1. Програма-демон запускает для закачек копии curl, клиенты bittorrent, и своих утилит для поддержки остальных протоколов.

2. Гуй управляет ей через dbus

3. Еще есть консольный фронтенд. Один на базе curses, другой просто cli.

Такой менеджер закачек реально бы рулил

«Не читал, но осуждаю!» (с). Ъ же.

Хм, почему GSettings не работает поверх GConf? Развели тут мир с КДЕшниками )) Ну ладно, плюсую

Согласно сайту Curl (и libcurl) он поддерживает

DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMTP, SMTPS, TELNET and TFTP. curl supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form based upload, proxies, cookies, user+password authentication (Basic, Digest, NTLM, Negotiate, kerberos...), file transfer resume, proxy tunneling and a busload of other useful tricks.

Очень важно для программы, которая что-то качает иметь режим работы в виде демона. Умеет?

Не совсем понятно, почему это так _очень_ важно. На роутер ставить, что ли? Судя по dbus - нет. Тогда зачем?

Не, не надо. А через GIO надо писать что-то ънтерпрайзное, где закачка не главное. Вот когда нужно балансировать нагрузку и т.д, то лучше wget, а еще лучше curl

Deluge/deluged знаете? Так у нас есть сервер качальщик/раздавальщик. Для большого числа людей.

Это правильная архитектура unix-way. Можно поставить на закачку и вылогиниться из ssh.

И конечно... Громадный + за Vala

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

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

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

> будет жуткий комбайн качалки , торрент клиента, rss читалки, браузера, веб сервера, расшаренного каталога и еще 1000 ненужных большинству функций

Такой уже есть. Leechcraft называется.

ОМГ, долго тебе обьяснять.

1. Качает демон. Он надежный и автономный. Может работать на сервере без иксов, разработчики не морочат голову HIGом, а просто пишут качественную серверную программу. Все задача решена, качалка есть. Точка.

2. Для серверов делается webui и консольный клиент. Админы и гики довольны

3. Для десктопов делается гуйный клиент, который делают опытные гуеклепатели и не морочат голову себе разной серверной ерундой. Один гуй можно сделать на Gtk+, на Qt4. ВСЕ счастливы на десктопе. Домохозяйки счастливы, так как гуй при отсутствии демона в системе делает fork/exec и вообще никогда не говорит пользователю о существовании какого-то демона.

В итоге счастливы: админы, гики, домохозяйки, гномеры и кдешники = ВСЕ. Прекрасная модульность, гибкость и широта целевой аудитории

ОМГ, долго тебе обьяснять.

4. Это все есть в трансмиссии (ну может qt-шной морды нет, тулкитофобов мне не жалко), но тем не менее, когда я ее запускаю на десктопе - у меня один процесс.

5. Зато у нее нет какой-то кучи процессов с каким-то мутным RPC и прочим геморроем.

Нафиг ненужное месиво. Под каким пользователем будет работать демон? И как он раскидывает файлы в пользовательские директории (вопросы риторические). Такое деление имеет смысл делать только для раздачи торентов и т.п.

На самом деле код Steadyflow достаточно хорошо приспособлен для выделения качальщика в отдельный процесс. Базовые абстракции - это IDownloadService и IDownloadFile, которые общаются с гуём исключительно через сигналы. А уж сделать прокси-классы, общающиеся с настоящими через D-Bus - дело техники.

Другой вопрос, что поллить процесс через D-Bus каждые 200 мс (интервал обновления гуя сейчас) для вообще всех!!! файлов в списке - это всё-таки чересчур. Скачанные-то файлы будут скапливаться в списке, если их вручную не удалять.

Можно сделать как с Quassel. Там есть отдельный бинарник для кутешного клиента, отдельный для демона (к которому можно и по сети подключаться), и отдельный, в котором всё находится в одном процессе. Правда, для IRC для этого есть отдельная мотивация: можно запускать демон на удалённом сервере. А для качалки оба процесса всё равно должны располагаться локально, иначе в чём тогда смысл?

Один процесс - это как раз месиво. А относительно настроек, то это как сконфигурирует юзер, или по невозможности - мейнтейнер пакета. Для сервера, там админ разберется. А для десктопа, то пусть под юзером работает в режиме fork/exec. Главное что это будет одно и то же приложение для сервера и десктопа

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

Но в данном случае лучше демон.

Ну это можно через любой IPC. Благо быстрых много. Можно прибегнуть в труъ-проверенных: FIFO, shared memory. Для fork/exec вообще pipes прямо напрашиваются

И конечно, sockets же

5. Зато у нее нет какой-то кучи процессов с каким-то мутным RPC и прочим геморроем.

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

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

Но в этом нет потребности. Совсем нет, два процесса буду работать на ура

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

Куча - это один или два?

два и больше

Ты ж программист, должен знать, что есть только 3 числа - 0, 1 и куча.

Ааа... Ты еще curl посчитал. Ну есть ведь libcurl. Не проблема. Главное наявность безиксовой качалки и чтобы ее не пришлось заново писать. Для упоротых как ты я предложил использовать почти весь код в библиотеке. А к ней написать 3 программы: gui, webui, cli

Главное что это будет одно и то же приложение для сервера и десктопа

Всё ещё не понимаешь, что для HTTP... и прочих качалок серверное приложение не нужно. Городишь месиво технологий (в первую очередь) там, где они не нужны.

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

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

Всё ещё не понимаешь, что для HTTP... и прочих качалок серверное приложение не нужно.

Yeah, right )))

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

P.S. Только обзываться не надо, ок, тебе кдешников мало, что ты уже на своих кидаешься? ;-)

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

Считайте, что сабж — гуй к GIO. Полегчало?

Демон может сильно ассоциироваться с init.d. Но я имел ввиду программу, которую можно запустить в screen и передать ей список файлов в файле, как wget -i. Только в отличии от него поддерживать большой набор протоколов. Потом можно будет к нему добавлять закачки, в том числе и через dbus, можно настроить в виде демона, без иксов все это. Так же можно управлять с гуя. Все довольны, проблем нет.

Дайте помечтать.

Не буду больше. Да и кдешников надо беречь. Ведь доставляющих еденицы, они всегда будут востребованы

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

я лично ненавижу — потоумчто Хабр этож обычный блог (типа ЖЖ или ЛиРу`шечка) — но откаментить там нельзя [без инвайта, и кармы]..

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

[...может его Microsoft спонсирует специально чтобы там изредка писали глупости, я уж незнаю :) :)...]

даже если кто-то сделает себе stand-alone wordpress — то даже там есть поле для комментов ..

....но нет, хабр он особенный, его комментировать нельзя :-/ ..пффффф

(и email`ы не отображаются от хабропользователей... так что email тоже написать нельзя)



чем такая схема работы лучше чем зомбоящщик? %) %) %)

Автор, почему вы не сделали свою программу как оболочку для aria-2 или wget? С первым бы вы сразу получили многопоточность и торренты.

Решал эту же задачу через wget+bash+zenity

http://habrahabr.ru/blogs/linux/68668/

И на кой этот велосипед? Есть wget, aria2, да даже тот же downthemall! для ff смотрится выигрышнее.

Есть же addon к Firefox - DownThemAll. Больше ни чего и не нужно.

:) если бы ты поглубже с девелоперами познакомился, то понял бы, что там много достаточно много умных людей. dconf пишется очень умными людьми. Colin Walters один чего стоит. Я не думаю что многие лоровцы могут похвастаться такими знаниями как он.

А феерически убогий eog, от нехватки девелоперов. сядь исправь ошибки то.

> А в чем плюсы?

Шило на мыло. .. только там один бинарный файл вместо папки с XML. Короче, они изобрели реестр.

Профит есть. И его много. Во-первых он не работает с тормозным и одновременно кривыми orbit/bonobo. Во-вторых dconf многопоточен. В-третьих, никаких мегабайтов xml. То что формат бинарный окупается наличием пачкой хороших утилит для управления параметрами.

В общем касательно скорости все сделано правильно, у меня вопрос только по стабильности. Как бы из-за одного касякя не рушилась вся dconf база.