Эта... А толку-то?
Это в основном проблемы gtk-html, которые всем известны и БУДУТ ещё не очень скоро пофиксены.

Ура! Наконец-то!

Shadow, а туда разве Mozilla еще на затащили?

Итересно он для GTK? Или требует GNOME?

2Shadow: я не знаю ни об одной баге в gtkhtml. Все известные баги надо отрепортить разработчикам - их исправляют очень активно. И надо репортить баги не только баги в gtkhtml.
ЗЫ: Сейчас в Галерее лежит скриншот Эволюции этой версии.
> Итересно он для GTK? Или требует GNOME?
Требует GNOME, более того, последних версий библиотек.
Насчет Эволюции - есть люди, жившие под ней (под 0.16) несколько недель. Сегфолтов они не заметили, и вроде бы остались довольны.. Правда в 0.99 говорят addressbook если LDAP использует, то иногда виснет.

2maxcom: evo как-то линкуется с мозиллой - но кажется только для того, чтобы рисовать summary (вернее каналы новостей в нем). Для всего (показа мыла, набивки html мыла) используется gtkhtml.

Поправьте, если я не прав. Эта фигня использует berkeley db? Которая лекго так
теряет записи иногда... Я бы не доверил свою почту такому клиенту. И вообще,
это не unix way - делать универсальную жирную приблуду, да еще лепить в кучу
планировщик и т.д., и все это в виде несамостоятельных компонентов.

Для хранения почты используется mbox формат, а индексы для него - кажется в своем бинарном формате. Файл индексов можно убивать без всякого вреда. Для хранения календарей и заданий - VCALENDAR формат (текстовый, стандартизирован какой-то межд. организацией). Для хранения адресной книги - db3 (единственное место). Но можно AB держать на ldap.
А делать жирную приблуду имело смысл - концепция виртуальных папок очень успешно применяется для заданий, календаря и конечно мыла.
Все сделано в виде набора компонентов, которые общаются в конченом счете через CORBA ORB. Так что все максимально модульно и гибко. И вроде бы компоненты даже в память не грузяться пока их не начнут использовать (по крайне мере технически можно так сделать).

> И вообще, это не unix way - делать универсальную жирную приблуду,
> да еще лепить в кучу планировщик и т.д., и все это в виде
> несамостоятельных компонентов.
Да, может быть это и не unix-way, но в борьбе за десктоп все средства хороши. IMHO. кроме того, evo состоит из компонентов, которые можно таки ппихать куда угодно.

> Эта фигня использует berkeley db? Которая лекго так теряет записи иногда...

глупости ты говоришь. BerkeyDB поддерживает транзакции, упреждающее журналирование и пр. Записи она теряет только по вине криво использующих ее программ.

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

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

Если под GNOME то не хочу. Найду что то другое не KDE/GNOME.

>заинтерисованным в наличии продвинутого почтового

продвинутый почтовый клиент --- это мутт. Сколько
себя помню, посылать письма в HTML всегда считалось
плохим тоном (mauvais ton). А если Evolution
не только поддерживает HTML mail, но и активно его
промоутит, то прямая ей дороженька в /dev/null...

Evo может слать как html мыло, так и plain text. Ничего она не промоутит.
Насчет мутта - а слабо одновременно видеть 4 письма? А набивать одновременно более одного письма? Использовать как PIM (календарь/задания)?

> Хотя реально наверняка если
> попытаться часть Evo заюзать в своей проге то вылезет масса сложностей.

Так про то и речь.

Влад - будь честен - говори всю правду. На сегодняшний день русский plain text Ева шлет в base64. Некоторых это может раздражать. Это вопрос времени и багфикса. Действительно, многие могут справедливо считать, что PIM и почта должны быть разными прогами (конечно, связываемыми через файлы, скрипты и т.п.). Т.е. Еволюция - не для всех, а для тех, кто хочет иметь все это в одном флаконе. Остальные могут (и будут) пользовать mutt. Про реюзабельность - да, есть такая вестч. Но пока что ни один компонент из Евы нигде кроме нее самой не использовался. Декларации и намерения - дело хорошее, но мой опыт учит меня, что при самом хорошем планировании компонент проекта #1 при использовании их в проекте #2 - приходится делать некоторые (иногда весьма существенные) изменения в самих компонентах. Проект #3 обычно обходится практически даром:) Короче, когда хоть один компонент Евы сможет самостоятельно встроиться в Наутилус (или в Конвекрор:)) - вот тогда можно говорить про компонентную архитектуру Евы. Вообще, единственный известный реальный пример реюзабельности на уровне компонет в унихе - Мозилла. Обожаю галеон!

Сергей:
о base64: вроде если как outgoing mail transport ставишь sendmail, то она ему передает raw 8bit data - а он уж сам решает. Если шлется через SMTP, то мне кажется что Evo тоже должна смотреть на smtp greeting на предмет поддержки raw 8 bit и если там оно есть, то слать raw. Да и по-любому, не вижу никаких проблем в русском в base64 - стандартом это поддерживается.
О компонентах: компонентность Evo в основном для того, чтобы можно было заменить ее компоненты на какие-либо другие с тем же интерфейсом. Про применимость компонент Evo к чему-нить - я думаю они такой задачи не ставили - но все равно надо смотреть .idl файлы чтобы правильно ответить на этот вопрос. По-любому, то что XImian выпустила GAL под LGPL - даже это просто здорово! А вот где могут пригодиться компоненты Evo сами по себе - мне как-то трудно представить. А вот про подмену - одно время кто-то хотел сделать компонент-редактор писем из GVIM (чтобы его можно было использовать вместо того, что в Evo).
А про mutt vs Evo: тут я бы сказал больше вопрос о том - а может ли теоретически консольный MUA быть лучше и удобнее гуевого (при бесконечном кол-ве сил, отведенных на их полирование)? Я думаю что нет - гуевые всегда могут быть лучше из-за наличия большего кол-ва цветов, размеров, стилей и гарнитур шрифтов в графическом режиме.

Вот как раз дело в том, что не передает Ева 8-битных данных. Оно уже в исходящем сообщении base64. Уже в папке черновиков оно base64. Конечно, больших проблем нет. Но иногда так приятно почитать почту просто используя cat /path_to_some_message_file... Про заменяемость компонет - тоже вопрос. Я не видел ни одной альтернативной реализации. Может, кто-то что-то и хотел - но ничего реально нет. Заменяемость, как и реюзабельность - доказывается только практикой. А про "теоретически может быть удобнее" - это вопрос тонкий. Удобство определяется для каждого индивидуально. И никакой теории. Только статистика. Статистически гуй удобнее. И только. А для text-only почты не важны стили и цвета. Вот скорость запуска приложения - важна (особенно - для людей привычных к vi). И размер (полгига на компиляцию почтового клиента даст не всякий - даже из тех, у кого эти полгига есть). Я не нападаю на Еву и гуй (это было бы забавно с моей стороны:). Я только обращаю внимание на тот факт, что в мире есть разные люди.

Насчет base64: я сам помню летом на ximian громко наезжал по поводу неподдерживания raw 8 bit для не-latin1 мыла. Они мне сказали, что я заблуждаюсь. Действительно, месяца 3 назад было именно так как я сказал - если транспорт - sendmail, то в него вдуваются raw 8 bit. Если транспорт smtp и все-таки уходит в base64 - то значит что smtp сервер не сказал что он поддерживает raw 8 bit.
Насчет компонентности: согласен, что практика - лучший показатель.. Но все-таки .idl файлы используются не просто так - так что наверно можно реально в oaf зарегистрировать альтернативную реализацию другого компонента и она будет подхвачена.
Насчет gui vs console: согласен, люди разные. Я лично даже и не подумаю с pine уйти :) Однако для среднестатистической секретарши Evo значительно лучше pine/mutt и может даже быть удобнее чем Outlook (из-за наличия виртуальных папок, news chanels, etc). Еще - думаю что даже для text-only почты гуй тоже может быть удобнее (всякие цветные надписи, цвета сообщений в списке, и пр - все делает MUA более интуитивным).

>>>да еще лепить в кучу планировщик и т.д.

Планировщик лепится до кучи не просто так - RFC2445 и связанные с ним документы определяют почтовый транспорт (и использование MIME, BASE64 и т.д) как основной для обмена календарной информаций, интеграция МUA и CUA проистекает прежде всего оттуда...

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

> Если транспорт smtp и все-таки уходит в base64

Во всех более-менее приличных mua этот параметр изменяется в настройках.
К тому же, найти в наше время 7bit-only mta - это целая проблема...

> Планировщик лепится до кучи не просто так - RFC2445

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

   Во   всех   более-менее  приличных  mua  этот  параметр  изменяется  в
   настройках.
В Evo тоже в настройках.
   Между  мордами работает dnd. Сидя в мэйлере можно вызывать планировщик
   в отдельном окне и наоборот.
   Почему  не  сделано  так? Почему пошли по пути аутлуков, эксплореров и
   т.д.?
В Evo  - примерно так же. Каждая часть - отдельный бинарник. Вроде
может пускаться отдельно. По крайне мере каждый компонент можно пускать
в своем окне (да и вообще - Evo отлично поддерживает многооконность,
в отличие от всяких EO).
2speer: отпишите мне пожалуйста на hvv(at)hippo.ru

много писем в мутте

> Насчет мутта - а слабо одновременно видеть 4 письма?
> А набивать одновременно более одного письма?

Да не слабо.
Запускается сколько надо муттов -- и вперед.


> Использовать как PIM (календарь/задания)?

А вот это зря. Если бы эта ненужная (мне) вещь была опциональной, Evo можно было бы (мне) рассматривать всерьез.

Вообще, я согласен с криками о том, что единственный успешный на данный момент интегратор -- емакс. Остальное (netscape, staroffice, evolution) -- имхо, подсасывает.


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

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

mutt - вот самый могучий почтовый ридер!

2 E133t_HaX0r:
Вы бы лучше в школу на урок русского языка сходили, вместо баловства на сайте для серьёзных дяденек.

2hvv:
Я думал, ето глюк (когда мне пришлось для сохранения юникодовых фонтов в системе ставить юникодовые с русскими буковками т.ч.), а оказалось - это фича!
2all:
А всё равно нафиг его... Вот когда офисы всякие будут поднимать - тогда и будем использовать... IMHO, типичный groupware - дома он избыточен и непомерен...
А вот sylpheed дома меня очень радует :)
Он и по фичам Bat! напоминает... И по тому, как они реализованы.

По этому поводу могу сказать только одно:
если я всю жизнь прожил под консолью и пользовался гуями для
просмотра картинок (любимый броузер - lynx), то я никогда на 
это чудо не перейду с моего mutt.
Мой знакомый тащится от TheBat, и пользует его даже через 
wmvare :-)
Люди разные, если одному аутглюк нравится, то может под unix
он это и выберет.

Sov

> В Evo тоже в настройках.

Тогда вернемся к нашим баранам: если это в настройках, то почему не работает 8 бит smtp?

   Тогда  вернемся  к  нашим баранам: если это в настройках, то почему не
   работает 8 бит smtp?
А у тебя оно точно не работает (и smtp сервер говорит что поддерживает
8 bit)? По-любому, когда я тестировал evo месяца 2 назад в этом аспекте,
я точно помню что в очередь sendmail'а (при выборе транспорта sendmail)
мыло ложилось как raw 8bit. С транспортом smtp я Evo не пробовал (не
интересовало).
   Я  ваще  не  панимаю,  начлена  нужна  вся эта гуйня! Настоящие хакеры
   пользуются консолью! А вся эта мышиная возня меня ищо в Винде задрала,
   все  падает  и нифига не работает... А Еволюция эта - вылитый виндовый
   Оутглюк, и настоящие линоксоиды эго никогда юзать не будут.
Так она больше для рядовых пользователей, чем для хакеров.
   > Насчет мутта - а слабо одновременно видеть 4 письма?
   > А набивать одновременно более одного письма?
   Да не слабо.
   Запускается сколько надо муттов -- и вперед.
Это опробовано? Диких проблем с блокировками ящиков не возникнет?
А если почта придет после этого - она сразу появится во всех 4х мутах?
Просто несколько pine параллельно пустить не возможно - вернее можно,
но в тех, которая не первая, доступ ко всему - read only - даже письмо
как удаленное не пометишь так как это модифицирует ящик. И это только
с локальными ящиками, а что будет с IMAP (с ним точно, никаких изменений
как минимум, а в худшем случае просто на сервер не пустят).
   Честно  --  если  будет  нормально (не через base64) с русским и можно
   будет  без  календарей  и погод, и будут минимальные фичи (например --
Ну погоды и каленадри можно не открывать в отдельном окне и в них
не заходить. А что за проблемы с base64?

> А что за проблемы с base64?
Вернее, почему русский в base64 only (даже если это так) - проблема?
(если забыть про гнилые менеджеры списков рассылки).

Драсти.
Наверное это не то место, где такие вопросы задают, но чувствую флейм все равно поднимется.
Я смотрел на все эво с версии.. 0.12 по моему..
... везде у меня были одни и те же прблеммы... сначала я думал проблема в нестабильности ево, но потом понял.. что то с /dev/hands.
У меня всегда падает календарь. И всегда я не мог вводить русские буквы в тексте письма.

Вопрос вот в чем: как бы мне убить ево так, чтоб в системе небыло вообще не чего от него... rpm -e не помогает - после того, как я его снова ставлю - те же проблеммы.

Swan
Swan@HotBox.ru

2 Swan: наверно надо убить напрочь ~/evolution и ~/.evolution к тому же. Проблемы какие-то очень редкие и странные.. Рекомендую ставить rpms с ftp.ximian.com/pub/ximian-gnome

>>Насчет мутта - а слабо одновременно видеть 4 письма? А набивать одновременно более одного письма? >>Использовать как PIM (календарь/задания)? а зачем ??

Ну про набивание 4х писем одновременно и просмотр 4х одновременно - это очень часто нужно людям, интенсивно работающим с мылом. Например, 4 ч-ка прислали описание чего-то одного, и хочется их сравнить - посему хочется их открыть все в отдельных окнах и сравнивать. Про набивание 4х писем - тоже иногда требуется - например отослать нескольким людям письмо примерно одного содержания (или наоборот, чуть разного) по-ходу сочиняя письма (посему написать шаблон - не годится). Или набиваешь длинное письмо, в этот момент приходит другое, на которое надо ответить очень срочно, и во время набивания ответа на него приходит 3-е (от человека, ответ которому бьешь) - если в данной ситуации сделать postpone (в пайне как минимум) предыдущее отложенное письмо - умрет. Ну а про PIM - вопрос глупый.

2hvv
обычно обновление с этого и начинаю не помогает ;(

Swan
Swna@HotBOX.ru

> Это опробовано? Диких проблем с блокировками ящиков не возникнет?
> А если почта придет после этого - она сразу появится во всех 4х мутах?
> Просто несколько pine параллельно пустить не возможно

Не знаю, почему ты зациклился на pine - жуткий калека с многочисленными неисправимыми
проблемами с безопасностью. В mutt все это проходит на ура. Письмо появится во всех 4-х mutt'ах либо
при нажатии любой клавиши, либо обновится автоматом через определенный промежуток времени.

ОК, ты сказал как я понял про локальные ящики (и про появление писем). А как с IMAP ящиками - это пройдет? А если удалить письмо в одной копии мута - в других оно удалится тоже? А в муте с отправкой нескольких писем - можно такое (несколько одновременно набиваемых писем в разных муттах)?

IMAP'a у меня нет, потому не могу ничего сказать, а в остальном все, что ты спрашиваешь
не только возможно, а вполне естественно для mutt. Я даже никогда не задумывался о том,
что может быть как-то по-другому. Mutt умеет делать локировки при записи и распознавать
изменения, произведенные другими копиями mutt'a и не только mutt'a - вообще
любые изменения, произведенные с mbox'ом или в maildir или ?забыл третий формат ящика.

OK, посмотрю мут как будет время, спасибо за ответы. Но с имапом боюсь параллельная работа не возможна (тут уже все зависит от сервера конечно).

Я использую mutt и balsa - они чудесно дополняют друг друга - когда я в консоли работаю - mutt, когда в X-ах - balsa. Письма раскладываю по папкам через procmail. base64->8bit делает sendmail при приеме (какя вам нахрен разница, в каком формате _уходящее_ письмо?).

LVM

> base64->8bit делает sendmail при приеме

Ну а остальным что делать? Далеко не у всех sendmail. Некоторым небезразлична безопасность.
С base64 главная проблема, если отправляешь письма в англоязычные конференции.
Не принято там base64. Да и у нас в некоторых серьезных конторах жесткое требование:
koi8 plain text, все остальное в /dev/null не читая.

Совершенно верно. Некоторые imapd просто не разрешают вторую сессию, а другие не дают сохранить изменения в первой... Но mutt в этом нисколько не виноват...

   С  base64  главная  проблема,  если  отправляешь письма в англоязычные
   конференции.
Чисто латинский текст отошлется Эвой в raw форме.
   Не  принято  там  base64.  Да  и  у нас в некоторых серьезных конторах
   жесткое требование:
   koi8 plain text, все остальное в /dev/null не читая.
Оригинально. Чтой-то они так - IMHO вообще никаких вразумительных
причин для этого нет.. Я заметил, что вот smtp2fido гейтвэи или некоторые
роботы фидошников отвергают base64  письма с матом - но это совсем
не серьезно (постишь в какой список где фидошник подписался - и получаешь
матюги от его робота)..
 С  base64  главная  проблема,  если  отправляешь письма в англоязычные
   конференции.

почитал форум, и даже немного смешно стало... mutt/evo... pine...

дано пользую xemacs/gnus и для почты и для новостей. никаких проблем с четырьмя письмами, и так далее и тому подобное...

правильно тут упомянули - получилось интегрировать только у emacs. остальыне немного "не с того бока подошли". А модная CORBA, это наверное хорошо. Но зачем? неужали никто никогда не пробовал gnuclient?

> если в данной ситуации сделать postpone (в пайне как минимум) > предыдущее отложенное письмо - умрет.

Чего? Я имел по 5 postponed писем в pine и никогда никаких проблем не возникало.

> фидошников отвергают base64 письма с матом

И их можно понять. Зачем эта сложность, когда все что угодно можно прочитать
при помощи less? Сидит например на удаленном сервере большое письмо непонятно от кого.
Зашел по ssh, сделал head, сделал tail, все понятно, сделал rm (у меня maildir там).

2 bormotov: и как, есть опыт перевода секретарш с Outlook на gnus? Очевидно, что перевести секретаршу на Evo на 5 порядков легче чем на gnus.
Про pine - хм, сейчас попробовал - действительно и у меня позволяет откладывать более одного. Но так как я пускаю pine из mc, то Ctrl-O перехватывает именно он и postpone я вообще не могу использовать. Посему не знал, что можно откладывать более одного. Век живи, век учись.

to hvv: не, секретарш на gnus не переводил. ;) Но тут вроде люди пытаются сравнивать mail reader'ы для себя. И они явно не секретарши ;)

собвенно, я против "Evo для секретарш" ничего не имею. Даже если и не для секретарш, тоже ;)

2bormotov : мы с hvv в другой ветке обсуждали кое что про Evo... Так вот - образно говоря можно и топором гвозди забивать, но молотком удобней, согласен? Evo имеет замашки не только и не столько почтового клиента, сколько инструмента для организации своей работы и работы в группе... И сравнивать его с pine не совсем корректно имхо ;)

История про то, как линуксоиды хотели скомуниздить Аутлук и как у них не получилось...