История изменений

А разве нужны такие агенты? mv, cp и rm уже есть.

Предлагаю ответить на такие вопросы:
1. Почему люди, которые используют для копирования утилиты с UI, используют именно их, а не cp?
2. Обязателен ли ФМ для того, чтобы запустить копирование файлов?

Далее, чуть выше вы пишете, что задачей libfm будет отвечать на вопрос о свойствах файла. Почему же окошко свойств не будет показывать та же libfm?

Потому что «окошко свойств» — это главным образом задача именно «нарисовать окошко», а не «определить свойства». И она никак не привязана к ФМ.

Внутри диалога «свойства» будут свои интерфейсные задачи, но с логикой _получения_ свойств они никак не связаны. С интерфейсом главного окна ФМ — тоже не.

Или её будет линковать внешняя утилита-агент?

Достаточно запустить некоторый бинарник.

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

К тому же, придется организовывать межпроцессное взаимодействие между таким зоопарком агентов, а это также скажется на производительности.

Критичные к производительности места — это получение оглавления каталога и рендеринг его view.

Первое будет сидеть целиком в libfm. Дополнительные свойства будут подгружаться асинхронно или по явному запросу приложения. Собственно, так сейчас и реализовано.

Второе упирается в тормоза gtk, но на современном железе это не заметно. (Вот на Celeron D есть небольшая вялость интерфейса, да.) И в целом это не зависит от архитектуры ФМ: все приложения на gtk подтормаживают на рендеринге объектов типа icon view. Я планирую с этим немного побороться, если будет время.

Задачи же типа «дай мне контекстное меню для файла» к производительности не критичны, т.к. заведомо уложатся в приемлимое время отклика.

А разве нужны такие агенты? mv, cp и rm уже есть.

Предлагаю ответить на такие вопросы:
1. Почему люди, которые используют для копирования утилиты с UI, используют именно их, а не cp?
2. Обязателен ли ФМ для того, чтобы запустить копирование файлов?

Далее, чуть выше вы пишете, что задачей libfm будет отвечать на вопрос о свойствах файла. Почему же окошко свойств не будет показывать та же libfm?

Потому что «окошко свойств» — это главным образом задача именно «нарисовать окошко», а не «определить свойства». И она никак не пивязана к ФМ.

Внутри диалога «свойства» будут свои интерфейсные задачи, но с логикой _получения_ свойств они никак не связаны. С интерфейсом главного окна ФМ — тоже не.

Или её будет линковать внешняя утилита-агент?

Достаточно запустить некоторый бинарник.

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

К тому же, придется организовывать межпроцессное взаимодействие между таким зоопарком агентов, а это также скажется на производительности.

Критичные к производительности места — это получение оглавления каталога и рендеринг его view.

Первое будет сидеть целиком в libfm. Дополнительные свойства будут подгружаться асинхронно или по явному запросу приложения. Собственно, так сейчас и реализовано.

Второе упирается в тормоза gtk, но на современном железе это не заметно. (Вот на Celeron D есть небольшая вялость интерфейса, да.) И в целом это не зависит от архитектуры ФМ: все приложения на gtk подтормаживают на рендеринге объектов типа icon view. Я планирую с этим немного побороться, если будет время.

Задачи же типа «дай мне контекстное меню для файла» к производительности не критичны, т.к. заведомо уложатся в приемлимое время отклика.