Иван Лох -> [email protected] @ 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: [email protected]
Functional programming is like describing your problem to a
mathematician. Imperative programming is like giving instructions to
an idiot.
-- arcus, #scheme on Freenode
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
