История изменений
Исправление wandrien, (текущая версия) :
Хочешь сказать, что primary/secondary/clipboard selection (сам же только что упоминал) берутся из астрала, а название утилиты xsel — поклёп и клевета?
Ты достаточно умный, чтобы самостоятельно понять свою логическую ошибку. Так что эту попытку троллинга я оставлю без корма.
Как я и сказал в самом начале, линукс в жопе не потому что 15 стандартов, а потому что юникс-какиры дальше собственного носа не видят.
В данном случае «юникс-какиры» ясно видят цену предлагаемых фич и решений. Делать в одно рыло «новую ОС» в мои планы не входит. Извини.
Я вот например хочу воспользоваться твоей фичой для того, чтобы открыть в другой программе документ, которого ещё нет на диске. Ну, скажем, я вот сделал скриншот области экрана, вижу перед собой окно скриншотилки, предлагающей сохранить или отменить, и хочу отправить этот скриншот в графический редактор. Что прикажешь делать?
Моя фича не подходит для этого кейса. Фича ориентирована на обработку СВЯЗИ между представлением документа в окне приложения и этим документом как файловым объектом. Если нет файла, то и связи нет.
А то, что ты хочешь, напрямую отсылает нас к объектно-ориентированным программным средам, среди которых единственной успешной реализацией является OLE. Чтобы «картинка» была представителем класса «картинок» со всеми возможными свойствами и методами, независимо от того, где она находится, и является ли настоящей «картинкой» вообще.
В винде такая объектная модель действительно возможна и применяется. Но не всегда она работает реально «без диска», для некоторых таких обменов объектами по факту под капотом используется временный файл.
В линуксе объектное решение невозможно в связи с отсутствием аналога COM.
И оно не просто невозможно, так тебе еще и отдел разработки Гнома и половина ЛОРа ответит, что это «ненужно». Так и живём.
Что прикажешь делать?
Механизм selections предполагает возможность пересылки объектов любого MIME-типа. Придумай что-нибудь с его участием. Как это должно работать на уровне UI, я без понятия, это ведь твоя идея.
Ты определись уже — ты хочешь монолит, который берёт на себя абсолютно всё, до чего можешь дотянуться (aka X11, в чьё пространство имён ты предлагаешь запихивать абсолютно нерелевантные отображению окон задачи), или россыпь аккуратных API, каждое из которых решает только свою задачу и делает это хорошо?
А в каком пространстве имён это «релевантные» задачи?
Давай включи немного мозг в рамках объектной модели, раз ты любишь проектирование.
Один и тот же объект реализует как интерфейс X11Window, так и интерфейс DocumentPath. Где этому объекту место?
Оказывается, в линуксе нет подходящей шины вообще.
Исправление wandrien, :
Хочешь сказать, что primary/secondary/clipboard selection (сам же только что упоминал) берутся из астрала, а название утилиты xsel — поклёп и клевета?
Ты достаточно умный, чтобы самостоятельно понять свою логическую ошибку. Так что эту попытку троллинга я оставлю без корма.
Как я и сказал в самом начале, линукс в жопе не потому что 15 стандартов, а потому что юникс-какиры дальше собственного носа не видят.
В данном случае «юникс-какиры» ясно видят цену предлагаемых фич и решений. Делать в одно рыло «новую ОС» в мои планы не входит. Извини.
Я вот например хочу воспользоваться твоей фичой для того, чтобы открыть в другой программе документ, которого ещё нет на диске. Ну, скажем, я вот сделал скриншот области экрана, вижу перед собой окно скриншотилки, предлагающей сохранить или отменить, и хочу отправить этот скриншот в графический редактор. Что прикажешь делать?
Моя фича не подходит для этого кейса. Фича ориентирована на обработку СВЯЗИ между представлением документа в окне приложения и этим документом как файловым объектом. Если нет файла, то и связи нет.
А то, что ты хочешь, напрямую отсылает нас к объектно-ориентированным программным средам, среди которых единственной успешной реализацией является OLE. Чтобы «картинка» была представителем класса «картинок» со всеми возможными свойствами и методами, независимо от того, где она находится, и является ли настоящей «картинкой» вообще.
В винде такая объектная модель действительно возможна и применяется. Но не всегда она работает реально «без диска», для некоторых таких обменов объектами по факту под капотом используется временный файл.
В линуксе объектное решение невозможно в связи с отсутствием аналога COM.
И оно не просто невозможно, так тебе еще и отдел разработки Гнома и половина ЛОРа ответит, что это «ненужно». Так и живём.
Что прикажешь делать?
Механизм selections предполагает возможность пересылки объектов любого MIME-типа. Придумай что-нибудь с его участием. Как это должно работать на уровне UI, я без понятия, это ведь твоя идея.
Ты определись уже — ты хочешь монолит, который берёт на себя абсолютно всё, до чего можешь дотянуться (aka X11, в чьё пространство имён ты предлагаешь запихивать абсолютно нерелевантные отображению окон задачи), или россыпь аккуратных API, каждое из которых решает только свою задачу и делает это хорошо?
А в каком пространстве имён это «релевантные» задачи?
Давай включи немного мозг в рамках объектной модели, раз ты ты любишь проектирование.
Один и тот же объект реализует как интерфейс X11Window, так и интерфейс DocumentPath. Где этому объекту место?
Оказывается, в линуксе нет подходящей шины вообще.
Исходная версия wandrien, :
Хочешь сказать, что primary/secondary/clipboard selection (сам же только что упоминал) берутся из астрала, а название утилиты xsel — поклёп и клевета?
Ты достаточно умный, чтобы самостоятельно понять свою логическую ошибку. Так что эту попытку троллинга я оставлю без корма.
Как я и сказал в самом начале, линукс в жопе не потому что 15 стандартов, а потому что юникс-какиры дальше собственного носа не видят.
В данном случае «юникс-какиры» ясно видят цену предлагаемых фич и решений. Делать в одно рыло «новую ОС» в мои планы не входит. Извини.
Я вот например хочу воспользоваться твоей фичой для того, чтобы открыть в другой программе документ, которого ещё нет на диске. Ну, скажем, я вот сделал скриншот области экрана, вижу перед собой окно скриншотилки, предлагающей сохранить или отменить, и хочу отправить этот скриншот в графический редактор. Что прикажешь делать?
Моя фича не подходит для этого кейса. Фича ориентирована на обработку СВЯЗИ между представлением документа в окне приложения и этим документом как файловым объектом. Если нет файла, то и связи нет.
А то, что ты хочешь, напрямую отсылает нас к объектно-ориентированным программным средам, среди которых единственной успешной реализацией является OLE. Чтобы «картинка» была представителем класса «картинок» со всеми возможными свойствами и методами, независимо от того, где она находится, и является ли настоящей «картинкой» вообще.
В винде такая объектная модель действительно возможна и применяется. Но не всегда она работает реально «без диска», для некоторых таких обменов объектами по факту под капотом используется временный файл.
В линуксе объектное решение невозможно в связи с отсутствием аналога COM.
И оно не просто невозможно, так тебе еще и отдел разработки Гнома и половина ЛОРа ответит, что это «ненужно». Так и живём.
Что прикажешь делать?
Механизм selections предполагает возможность пересылки объектов любого MIME-типа. Придумай что-нибудь с его участием. Как это должно работать на уровне UI, я без понятия, это ведь твоя идея.
Ты определись уже — ты хочешь монолит, который берёт на себя абсолютно всё, до чего можешь дотянуться (aka X11, в чьё пространство имён ты предлагаешь запихивать абсолютно нерелевантные отображению окон задачи), или россыпь аккуратных API, каждое из которых решает только свою задачу и делает это хорошо?
А в каком пространстве имён это «релевантные» задачи?
Давай включи немного мозга в рамках объектной модели, раз ты ты любишь проектирование.
Один и тот же объект реализует как интерфейс X11Window, так и интерфейс DocumentPath. Где этому объекту место?
Оказывается, в линуксе нет подходящей шины вообще.