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

Вот тут не уверен в полезности этого подхода. Допустим работал я с текстом в редакторе и остался у меня там выделенным какой-нибудь «begin»,а мне надо погоду в браузере посмотреть и я его запускаю. И что - браузер сходу попытается мне открыть http://begin.html ?

Что-то ты мимо текста читаешь. «Запустить программу» и «запустить программу для указанного пути» – разные хоткеи.

Но сразу возникают вопросы: какой каталог открывать в файловом менеджере если терминалов запущено два?

Мимо текста читаешь 2.

Информация берётся из активного окна.

Вопрос второй - как заставить одну программу «отдать» другой программе путь к файлу с которым она работает?

Я об этом в тесте не написал, но я буду делать два пути: «надежный» и «легкий».

Надёжный – программа будет на своём окне выставлять атом _SDE_DOCUMENT_PATH со значением нужного пути.

За что я люблю X11 это за то, что можно легко и просто запилить любые дополнительные свойства окон или межоконные взаимодействия. Не спрашивая разрешения ни у какого комитета стандартизации.

Лёгкий – если атом не выставлен, то обработчик будет пытаться распознать путь к существующему файлу в заголовке окна.

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

Непонятно, о чем ты. Задача обработчика сначала сформировать путь согласно правилам, а затем вызвать для его обработки заданную программу. Всё остальное – задача приложения.

Не уверен в осмысленности этого. Опять же по причине множественности документов, используемых в процессе работы программиста.

А я уверен. Работая за компьютером, я мыслю в понятиях объектов, которые обрабатываю.

Вот эти вот приколы в стиле Гнома, когда ты сначала видишь документ в редакторе, а потом тебе надо с этим документом работать уже как с файлом, и ты как дурак вручную навигуешь по всей файловой системе, чтобы до него добраться. А при этом на форуме мне пишут идиоты: «мне такого никогда не надо, ты за компом работать не умеешь!».

У меня подход простой: пусть лошадь думает, у неё голова большая… ой, не то. Пусть машина рутиной занимается, у неё для этого гигагерцы. Во.

У меня 10 лет назад вообще была идея подгружать часть ФМ в область заголовка окна приложений через XEmbed. Для того, чтобы «открытый документ» и «файл на диске» были связаны на уровне UI/UX. Но это оверкил. Описанное в ОП решение не требует вообще ничему обучать ни ФМ, ни WM, кроме того, что они и так уже умеют делать в силу своей природу.

Вот тут не уверен в полезности этого подхода. Допустим работал я с текстом в редакторе и остался у меня там выделенным какой-нибудь «begin»,а мне надо погоду в браузере посмотреть и я его запускаю. И что - браузер сходу попытается мне открыть http://begin.html ?

Что-то ты мимо текста читаешь. «Запустить программу» и «запустить программу для указанного пути» – разные хоткеи.

Но сразу возникают вопросы: какой каталог открывать в файловом менеджере если терминалов запущено два?

Мимо текста читаешь 2.

Информация берётся из активного окна.

Вопрос второй - как заставить одну программу «отдать» другой программе путь к файлу с которым она работает?

Я об этом в тесте не написал, но я буду делать два пути: «надежный» и «легкий».

Надёжный – программа будет на своём окне выставлять атом _SDE_DOCUMENT_PATH со значением нужного пути.

За что я люблю X11 это за то, что можно легко и просто запилить любые дополнительные свойства окон или межоконные взаимодействия. Не спрашивая разрешения ни у какого комитета стандартизации.

Лёгкий – если атом не выставлен, то обработчик будет пытаться распознать путь к существующему файлу в заголовке окна.

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

Непонятно, о чем ты. Задача обработчика сначала сформировать путь согласно правилам, а затем вызвать для его обработки заданную программу. Всё остальное – задача приложения.

Не уверен в осмысленности этого. Опять же по причине множественности документов, используемых в процессе работы программиста.

А я уверен. Работая за компьютером, я мыслю в понятиях объектов, которые обрабатываю.

Вот эти вот приколы в стиле Гнома, когда ты сначала видишь документ в редакторе, а потом тебе надо с этим документом работать уже как с файлом, и ты как дурак вручную навигуешь по всей файловой системе, чтобы до него добраться. А при этом на форуме мне пишут идиоты: «мне такого никогда не надо, ты за компом работать не умеешь!».

У меня подход простой: пусть лошадь думает, у неё голова большая… ой, не то. Пусть машина рутиной занимается, у неё для этого гигагерцы. Во.

У меня 10 лет назад вообще была идея подгружать часть ФМ в область заголовка окна приложений через XEmbed. Для того, чтобы «открытый документ» и «файл на диске» были связаны на уровне UI/UX. Но это оверкил. Описанное в ОП решение не требует вообще ничему обучать ни ФМ, ни WM, кроме того, которые они и так уже умеют делать в силу своей природу.

Вот тут не уверен в полезности этого подхода. Допустим работал я с текстом в редакторе и остался у меня там выделенным какой-нибудь «begin»,а мне надо погоду в браузере посмотреть и я его запускаю. И что - браузер сходу попытается мне открыть http://begin.html ?

Что-то ты мимо текста читаешь. «Запустить программу» и «запустить программу для указанного пути» – разные хоткеи.

Но сразу возникают вопросы: какой каталог открывать в файловом менеджере если терминалов запущено два?

Мимо текста читаешь 2.

Информация берётся из активного окна.

Вопрос второй - как заставить одну программу «отдать» другой программе путь к файлу с которым она работает?

Я об этом в тесте не написал, но я буду делать два пути: «надежный» и «легкий».

Надёжный – программа будет на своём окне выставлять атом _SDE_DOCUMENT_PATH со значением нужного пути.

За что я люблю X11 это за то, что можно легко и просто запилить любые дополнительные свойства окон или межокооные взаимодействия. Не спрашивая разрешения ни у какого комитета стандартизации.

Лёгкий – если атом не выставлен, то обработчик будет пытаться распознать путь к существующему файлу в заголовке окна.

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

Непонятно, о чем ты. Задача обработчика сначала сформировать путь согласно правилам, а затем вызвать для его обработки заданную программу. Всё остальное – задача приложения.

Не уверен в осмысленности этого. Опять же по причине множественности документов, используемых в процессе работы программиста.

А я уверен. Работая за компьютером, я мыслю в понятиях объектов, которые обрабатываю.

Вот эти вот приколы в стиле Гнома, когда ты сначала видишь документ в редакторе, а потом тебе надо с этим документом работать уже как с файлом, и ты как дурак вручную навигуешь по всей файловой системе, чтобы до него добраться. А при этом на форуме мне пишут идиоты: «мне такого никогда не надо, ты за компом работать не умеешь!».

У меня подход простой: пусть лошадь думает, у неё голова большая… ой, не то. Пусть машина рутиной занимается, у неё для этого гигагерцы. Во.

У меня 10 лет назад вообще была идея подгружать часть ФМ в область заголовка окна приложений через XEmbed. Для того, чтобы «открытый документ» и «файл на диске» были связаны на уровне UI/UX. Но это оверкил. Описанное в ОП решение не требует вообще ничему обучать ни ФМ, ни WM, кроме того, которые они и так уже умеют делать в силу своей природу.