Re: amarok & libgtk2.0-0, lenny

[Artem Chuprina <ran@ran.pp.ru>]

Иван Лох -> debian-russian@lists.debian.org  @ Fri, 27 Feb 2009 20:03:03 +0300:

 >>  >>  c> А гном у нас значит не уродский ? :)
 >>  >> 
 >>  >> Уродский.  Но это не делает KDE менее уродским :-)
 >> 
 >>  ИЛ> А bonobo там еще живо? Меня просто поражает, почему нельзя
 >>  ИЛ> подготовить картинку в одной программе, сохранить в файл, и
 >>  ИЛ> вставить в публикацию в другой. Зачем нужны все эти COM.
 >> 
 >> С точки зрения UI удобно, работая с "другим" документом,
 >> вставить/подредактировать картинку "здесь".  Можно, конечно, через файл

 ИЛ> Не думаю. Работать в полноценной программе, управляемой WM, всегда
 ИЛ> удобней, чем в кастрированном компоненте. Надежность и безопасность
 ИЛ> программы, вынужденной запускать в своем адресном пространстве
 ИЛ> чужой код IMHO сразу падает на порядок. Ошибки, вообще, штатными
 ИЛ> способами искать невозможно.

 ИЛ> Простой пример. Есть, скажем, веб-броусер и в нем открыта страница
 ИЛ> содержащая textarea. На первый взгляд, как было бы здорово иметь
 ИЛ> там vim компонент... Он, кстати, для gnome есть. Но в отличии от
 ИЛ> обычного vim, понять где сохраняются файлы в случае его падения мне
 ИЛ> не удалось. Да и работать в vim 30X5 как-то не очень удобно. И он
 ИЛ> падал. И я как писал в обычном vim, так и пишу. Какое-то расширение
 ИЛ> его само открывает.

Это уже вопрос не "зачем нужны COM", а "почему данная конкретная функция
реализована в кастрированном компоненте".  Ну и не путать
"кастрированный" и "reparented"...  Ничто не мешает с помощью COM
отправлять картинку на редактирование в полноценную программу, при
необходимости ее запуская.

 >> гонять, всякие почтовые программы в юниксах так и делают.  Но вокруг
 >> этого тоже надо навинчивать обвязку.  В частности, это означает, что
 >> программе, в которой оно редактируется, хорошо бы уметь серверную
 >> функцию (дабы не запускать вторую копию, если можно воспользоваться
 >> первой - уже даже emacs грузится, мягко говоря, не мгновенно, что уж пр
 >> Gimp говорить).

 ИЛ> Вторая копия программы должна запускаться дешево _любым путем_. В
 ИЛ> принципе, весь код уже в памяти, а данные, так и так
 ИЛ> новые. Насколько я знаю, ядро опять пилят в этом направлении. Если
 ИЛ> у программы инициализация сложная как gimp (и emacs), то надо
 ИЛ> думать как это кэшировать.

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

 >> И малость метаинформации хочется передать.  А порой и
 >> не малость.  

 ИЛ> Передавать еще один файл с метой? Использовать форматы способные
 ИЛ> хранить мету?  Они, кстати, есть.

Угу, и все приложения ему обучать.  Нет, понятно, что есть - тот же
MIME...

 >> И индикацию завершения иметь понадежнее, чем завершение
 >> запущенного процесса (как у почтовок).  Ну и...

 ИЛ> Код возврата?

Нет.  При таком подходе на время редактирования письма почтовка
блокируется.  Ровно по этой причине я пользуюсь не mutt с emacs в
качестве редактора, а gnus.  Хотя mutt с почтой работает не в пример
лучше.

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

-- 
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru

Functional programming is like describing your problem to a
mathematician.  Imperative programming is like giving instructions to
an idiot.
 -- arcus, #scheme on Freenode